亂筆

培训机构的人血馒头

Wed, 11 Feb 2026 17:06:57 +0800

最近在某家民营电网培训机构给准备国网二批考试的学生一对一辅导，每天晚上上课三个半小时，给 200。

这家机构给我的钱偏少还不是最严重的问题。问题出在他们给学生的收费上：有两种方案，一种是所谓「卓越计划」，收费 12 万，但是一对一课程不限量；另一种是「协议班」，收费 7 万，但每次上一对一课程要交 450。

昨天给他们一学生私下开小灶，下午上课三个半小时，本来我想着既然私下找我，那就不经过这个培训机构，学生直接给我结款 300——我能多赚一百，ta 能少花 150。结果那个学生脑子没转过弯，找班主任请假的时候竟然说要找我补课，于是他们就直接「善意地」帮我找家长收了 450。

这还没完。最后给我算工时，他们把这次课归为所谓「额外课时」，说我违规利用了下午的「备课时间」给非卓越计划的学生上课——三个半小时，只给了 120。

简而言之：

学生付 450 → 机构抽走 330 → 我拿到 120

本该到我手上的 300 变成了 120，我自然是不爽。但比起我个人少拿的那一百多块钱，更让我不舒服的是这件事本身的性质。这些考国网二批的学生很多都是家境不太富裕的专科生，他们平日里已经饱受歧视，想尽一切办法想要改变命运，现在下了血本，花上可能是他们一个家庭一年收入的几万甚至十几万来读这个国网课程。他们以为自己买的是一剂改命的「药」，殊不知这药引子是用自己的血和着吃的——而我辛苦劳动辅导学生，分到手里的钱占比却比坐享其成的培训机构还要低。

这根本就是在吃人血馒头。

这一单，机构躺着净赚 330。这显然令人难以接受。我已经通知那位学生，令其下次请假时表现更加灵活；也和 ta 的班主任做出交涉，令她不要上报甚至干预我们私下的补课。考虑到班主任也是打工人，并且有学员成绩的 KPI，我想她也不会蠢到跟自己的 KPI 过不去。当然，这家机构最好好自为之，否则我在「备课」时那句「助教们组建临时工会，集体发动罢工，要求涨薪」的玩笑话，在将来的某天恐怕得一语成谶。

不得不感叹，到底谁才是资本主义啊——我看这机构的人血馒头铺子开得还挺熟练的。

2025 年度总结

Wed, 31 Dec 2025 19:28:17 +0800

真是忙碌的一年，不知不觉间，时间又到了年末。今年事情确实很多，奔波劳碌少不了，但也取得了阶段性的收获。我谨再次提笔写下一篇年终总结，作为一年的见证。

电气的尽头是电网

为求职四处奔波

我在一整年的休学生活以后如期复学，开始我的大学最后一年，成为一名「应届生」，所以，找工作的事情也就理所应当的排上了日程。作为电气工程专业的学生，出身原电力部属院校，工作倒是不算难找。不过说容易也不算很容易，毕竟大环境如此，经济增长放缓，国际形势不明朗，用人需求减少，各种地方都越来越卷。

九月份跑了场双选会，线下投了几份简历，也在网上投了四五份简历，收到面试通知的只有两家。也算切身感受到了，原电力部属院校的头衔，几乎只在电力系统内部¹有用。现在这就业形势也就这样，除了电力系统，但凡待遇稍微好一点的工作都不是我们这种「双非院校」的学生随便就能找到的。不过对比起来，人家好歹还收你的简历，像是有些专业甚至连简历都不收。

两大电网的笔试

电网工作是本专业最对口，最稳定的工作。本专业最大的用人单位——国家电网和南方电网，都需要通过笔试来获得面试资格。笔试一共需要考 8 门，分别是《电路理论》、《电机学》、《电力系统分析》、《继电保护》、《电力电子》、《高电压技术》、《电气设备及主系统》（我们学校叫「发电厂电气部分」）以及《行政能力测验》（简称「行测」）。

前面七门是专业知识，最后一门行政能力测验考的则是五花八门，还有企业文化这种东西，背就完事了。时政是不得不考的，考什么呢？总之是非常新的东西——几天前刚刚在求是杂志上发表的社论，几天后的考试里就直接出现了，我真的会谢。

今年的考试很奇怪，尤其是难度方面，历年的考试好说歹说也得有几道计算题，电路好歹也得灵活的考一道难度稍大的题。基于这种情报，我在靠前已经掌握了不少计算题，各种电气计算，数值整定，等效变换，可谓是得心应手。结果呢，今年国网一批考试一道计算题都没考，行测小学生都会做，全都在考些概念题，要不是南网考试还考了这些灵活运用的东西，那真就是约等于白学了。于是不出意料地，我所知道的计算题比较拿手，平时模拟测试成绩很好的同学，这次考试或多或少都有点炸。反倒是有些平时成绩不怎么理想，计算题不太会做的人，靠着死记硬背能考到一个不错的成绩。说白了，毕竟只是一个企业的招聘考试，他要怎么出题，外人根本无从猜测，我已经做了我应该做的，最终的录用结果也非常不错，这就够了。

面试，面试，还是面试

12 月我跑了四场面试，其中广西电网只有桂林一个面试地点，让我不得不翘课前往桂林面试，于是就有了今年最后一次的旅行，两年内两次前往桂林的感觉还不错。

国网面试还是让我有点紧张，为了防止试题被泄露给后面的考生，面试采用全封闭式管理，过程也很漫长——大部分时间都是在等候室里等待轮候。从下午 1:30 开始封存所有电子设备，用一个小时做完心理测试之后就进入了漫长的轮候时光，期间场地在放《长津湖》供大家消遣，还有茶水和零食提供。西装革履，正襟危坐，心里一遍又一遍的背诵早就滚瓜烂熟的一分钟自我介绍，紧张不安的边看电影消遣边等候，那种滋味只有亲身经历过才知道，现在回想起来倒也是挺有意思。

有了国网面试的经验和 Offer，排在其后的南网面试紧张感就没那么强。南方电网的面试形式和国家电网不太一样，国家电网是半结构化双盲面试，第一位考生从数份封存的面试题本里抽取一份，接下来的考生便都是一样的问题，最多也就是被考官询问一些附加问题。面试官不能看到你的简历，只能根据你在面试前抽签获得的编号对你打分，你也不能自报姓名和身世；而南方电网的面试则以面试官为主导，面试官会根据简历对你提出各种问题，包括专业题和附加问题。至于难度如何则完全看面试官的心情，例如我在海南电网的面试就被技术面试针对我的实习经历穷追猛打，提出各种细致入微的专业题，而在广西电网的面试中，技术面试提出的问题则友好很多，无非是一些倒闸操作、防雷设施等等。

电网培训的酸甜苦辣

考电网的人大部分都报名了某家培训机构，我自然也不例外，早在去年 11 月我就按部就班地报名了一家全国性的电网培训机构。这家培训机构有两个校区，我选择了相对市郊的那个，毕竟房租便宜。

培训的课程安排非常密集，任务繁重。暑假班连续上课 41 天，中途只有三天休息。每天上课之前需要上交手机。好在 iPad 出于电子笔记的考虑，还是允许使用的，我也因此获得了难得的摸鱼机会。

其实这段时间我也难得的获得了专注于一件事情的机会——每天除了上课，没有什么别的需要关心，所以虽然身体累，但是「心」反倒是没有多累；现在我回到了学校，反倒需要关心起大大小小的各种事情，身体倒是没那么累了，但「心」倒是比之前还累了不少。加上最近感冒咳嗽，一天能睡上 12 个小时，却也还是不见好转。只能在事情办完以后，该请假请假，该回家回家，该休息休息了。

故地重游

永州

今年年初回永州探亲，祖母已经快 90 岁了，身子还算硬朗，常回去看看是应该的。自幼便蒙受祖母照顾，感激之情实在是难以用言语表达，却也在应该做出什么行动来回报这方面不知所措，唯有至少每年一次的回永州探望方还算尽了一些晚辈的责任。

至于永州本身，也还是那个样子，什么都没变。毕竟又不是经济大爆发的时代，像这样的小城市还能怎么变呢？不变未必是悲哀，变也未必全是福气，像是上世纪经历了文革以后，什么都变了一副光景，却也什么都面目全非。小时候十分火热的商业综合体，现在基本只有一楼的服饰门面在营业，电影院和老游戏厅早就关门了，改做餐厅楼层之后变得昏暗不堪，新开的餐厅店铺，不论品牌连锁还是快招自营，大浪淘沙之后无一幸存。

香港

这次去香港就是去玩两下子，没什么特别的目的，纯属白嫖我妈出差的酒店而已。当然，顺便开张中银卡。所以整个行程也显得乏善可陈。唯一特别一点的地方是在湾仔的一间公寓住了几天，可以自行买菜做饭（~~当然也可以吃两餸饭~~），体验了一把民工一般的生活。

桂林

这次去桂林主要是为了南方电网广西分公司的面试，当然，也顺便去吃吃椿记烧鹅和海天肠粉什么的。美中不足的是在桂林面试的那两天都在下雨，也就导致我没什么兴致去周边散步游玩。海天肠粉和椿记烧鹅倒是吃了个够，味道不错，下次还来。

以旧换新

之前我的电脑是一台 i5 12450H + RTX 3060 Laptop 配置的机器，用了两年多，几个月前刚买了两条重要牌²内存给他的机带内存升级到 32G，其实要接着用也没什么问题。

那段时间存储芯片的价格仍然处于低谷，国补又让购置新设备的成本进一步降低，加上 50 系显卡刚刚上市，这三种因素叠加下新笔记本电脑的价格真的很吸引人。奈何我还是囊中羞涩，预算不足，无缘购买最新一代处理器 + 最新一代显卡的配置组合。只能退而求其次，买了 N - 1 代处理器 + 最新一代显卡的配置³。目前也用了小半年，日常体验上还是很不错的，只是这呼啸的风扇声实在是影响雅兴。总体上，我对这次电脑的评价是瑕不掩瑜，随着存储芯片价格飞涨和国补力度减弱，笔记本电脑这么便宜的情况恐怕很难再有下次了。

我家的猫

我家的猫今年（应该）一岁啦⁴，庆祝之余，对于公猫来说，从小猫长成大猫也就意味着蛋蛋开始发挥作用了，于是就发生了这一幕：

这臭猫在我去香港那段时间竟然跑到我床上拉屎撒尿 ~~（可能是我爸在家里没有铲屎）~~,不可饶恕，必须嘎蛋！

猫给我的生活带来了很多乐趣，在搞破坏之余，它也是很可爱的。家里的沙发也经过了一年的爪爪伺候，变得稀巴烂。总得付出一些代价的，养猫就是这样，抓痕、换毛季到处都是的猫毛、偶尔还做些小坏事，也是猫的一部分。我们既然接受了猫给我们带来的情绪价值，也就要相应地接受它的这些小缺点。我几乎已经把它看作我的家人，若是从这种角度出发，那么你对它的这些缺点就瞬间释然了。这么回想起来，也许我是真的爱它吧，以至于，我开始爱起了它的这些缺点。因为没有这些缺点，它就不是一只完整的猫了。

依旧在健身，依旧在吃药

撸铁，尤其是练腿，真的很爽，感受那种肌肉发挥力量以后淋漓尽致的舒畅感，真的会让人上瘾。在没有电网培训的时间里，我一直都在走进健身房，不光是享受这种舒畅的感觉，也还能锻炼自己的肌肉。真的，不运动很难受啊。

现在我依然每天都在吃药，毕竟我可不希望我在连轴转的幸苦生活中突然经历一次情绪崩溃，原本计划的吃药一年后药物逐渐减量计划也因此被无限期延后。为什么？说白了还是这段时间各种压力实在是不小，虽然一直吃药终究也不是个办法，在安稳之后必须慢慢减量停药，但在这段即将毕业的时间点，我还远远没有过上安稳确定的生活。

这段时间里充满了可能性和机遇，也充满了压力。吃药花的钱是小钱，而其带来的稳定情绪的「护盾」却能发挥至关重要的作用。

没时间玩游戏

从我的 Steam 年度回顾就可以看出来，今年我是真的没什么时间来玩游戏。「忙里偷闲」是今年的基调，今年年末下载了《三角洲行动》，有时电网培训十点下课，回家就打开玩到晚上 12 点，目前游玩 75 个小时，感觉还不错。

osu! 今年的后半段则是约等于弃坑了，不过 PP 仍然从去年的 3439pp 增长到了今年的 4701pp。这游戏还真是需要持之以恒，一段时间不玩丢掉手感再想复健是需要时间的。想想十点下课之后，在精力耗尽的状态下，再想打这种需要聚精会神地反应的游戏，那还真是「臣妾做不到啊」。年中的时候我对于现有鼠标的手感达到了最佳状态，可以说是「指哪打哪」，想着「没有人能阻止我一路走向 5 digit」⁵ ，然而现在却还在 5 digit 边上，属实是有些讽刺。

我的 Online Presence

2025 年，我的博客访问量稳步上涨，全年 UV 48.3K，PV 95.4K，流量主要来自 Google（约 15.8K 访客）和 Bing（约 15.2K 访客）两大搜索引擎。

Github 上的自用覆写规则收获了 194 个 Star，也新增了一些 Followers。

今年我的一篇文章被人放上了 Hacker News，所以有几天访问量比较大。除此之外翻译后的英语和日语版本博客也收获了不少读者，在我的访客中占比不低。所以也就出现了今年因为忙碌，博客更新频率低于往年，访问量却成倍增长的现象。我终究还是需要向生活做出让步，生活压力、学业压力和就业压力或多或少都会影响我更新博客的意愿，挤占我更新博客的精力，在这点上，还请我的读者们多多海涵。

新的一年即将到来，我给自己和大家的祝愿

新的一年要来了，我今年最大的愿望，当然是能够顺利解决之前休学带来的一些遗留问题，顺利毕业。等真正走进工作以后，我也希望自己能把更多注意力放在电力系统本身需要的技术上，多和设备打打交道，少卷进一些不必要、甚至有害的人情世故。辛苦一些没问题，只要平安、踏实、有意义即可：安全生产，少一些计较，多一些宽容。希望接下来能在这份工作上，从一名初出茅庐的学生，慢慢成长为一名真正的工程师。

也把祝福送给屏幕前的你：愿你在新的一年里，焦虑有处安放，努力有回声；在自己的节奏里把日子过稳、过热乎——不必每一步都算赢，但每一步都走得心里有数。愿你和你在意的人都健康，平安，少些无谓的消耗，多些确定的快乐。当然，也希望大家有更多时间在学习和工作之余玩玩游戏。

至于我，就继续在该学习的地方学习，在该上路的时候上路。明年见。

指由原电力部衍生的企业，即 2002 年以前的国家电力公司和 2002 年以后的国家电网、南方电网和蒙东电网等公营电力公司。 ↩︎
指最近刚刚被砍掉整个产品线的 Crucial 即英睿达内存。 ↩︎
买了机械革命极光 X Pro ↩︎
去年捡回来的时候还是很小的猫 ↩︎
指排名的数字位数，例如排名 #114514 是 6 位数，即 6 digit， #11451 是五位数，即 5 digit。显然，位数越小，玩家水平越高。 ↩︎

从频率崩溃到电压失控：两起大型停电事故带来的启示

Thu, 18 Dec 2025 00:08:30 +0800

现代电网正在经历一次巨大的转型，随着光伏、海上风电等新能源的占比在电网中越来越高，新能源和电力电子设备低转动惯量、低短路容量、换流设备需要大量无功支撑的特点以及它们给电网带来的不利影响也愈发明显。在此背景下，两期相隔六年相继发生在欧洲的大型停电事故显得尤为耐人寻味，本文将简要阐述两起事故的来龙去脉，对比它们的异同，分析造成这两起事故的本质原因，以及思考它们对现代电网的运行所带来的启示。

事故概述

2019 年英国「8·9」大停电事故

2019 年 8 月 9 日下午，英国发生了一次大规模电力中断，导致约 110 万用户断电，并对交通等关键基础设施造成了严重影响。整起事件的经过可以概括为一系列连锁反应，其中既有预料之中的系统保护行为，也有意料之外的设备故障。

第一阶段：罕见的三次雷击和大量有功意外脱网 (16:52:33)

当天下午 4 点 52 分，伦敦北部的 Eaton Socon – Wymondley 400kV 高压输电线路罕见的连续遭遇三次雷击。尽管如此，继电保护装置仍然按照整定正确动作，在不到 0.1 秒的时间内清除了故障，线路在约 20 秒后自动重合闸，恢复正常运行。雷击导致的电网电压的波动触发了分布式电源的矢量偏移保护¹，导致约 150MW 的嵌入式发电²脱网。这是雷击故障后的正常预期现象。

几乎在雷击的同时，发生了两起独立但致命的意外事件：

Hornsea 海上风电场：功率从 799MW 锐减至 62MW，损失了 737MW 的出力。
Little Barford 燃气电厂：其蒸汽轮机跳闸，瞬间损失了 244MW 的出力。

根据电网规范，这两处大型发电单元本不应该因为此类雷击故障而脱网或大幅减载，因此这被定性为「极其罕见和意外的事件」。

第二阶段：频率崩溃与系统响应 (16:52:34 - 16:53:31)

上述三项发电损失（150MW + 737MW + 244MW）累积造成了 1131MW 的功率缺口。这个损失超过了当时系统按 N-1 安全准则³设定的 1000MW 备用容量。巨大的功率缺口导致系统频率迅速下跌。

快速的频率下跌触发了更多分布式电源的 RoCoF⁴ 保护，导致额外的约 350MW 分布式电源相继脱网。此时，总发电损失已达 1481MW。系统中的所有备用电源——电池储能、分布式频率响应服务等迅速启动，紧急增援 1300MW，试图阻止频率下跌。它们的响应成功地使频率暂时稳定在 49.1 Hz（实际上这个频率已经相当危险了），并且开始缓慢回升。

然而，就在频率刚刚恢复到 49.2Hz 时，Little Barford 燃气电厂的一号机组也因蒸汽旁路系统压力异常而不得不紧急停机，再次损失 210MW 出力。

第三阶段：低频减载与系统恢复 (16:53:49 之后)

Little Barford 燃气电厂的第二次的意外跳闸耗尽了所有已在工作的备用资源，系统频率无力回天，最终跌破了48.8Hz的阈值。这自动触发了英国电网的最后一道防线——低频减载⁵。低频减载自动切除了约 5% 的电网需求，也就是约 1GW 的负荷，导致了约 110 万用户的断电。这一「弃车保帅」的措施有效地遏制了频率的下跌，防止了更严重的电网事故。

在切除部分负荷后，加上控制中心紧急调度其他电源，系统频率在 5 分钟内（16:57）恢复到了正常的 50Hz。在确认电网稳定后，配电网络运营商（DNOs）从 16:58 开始逐步恢复对用户的供电，到 17:37 所有用户恢复正常。

2025 年伊比利亚半岛大停电（西葡大停电）

2025 年 4 月 28 日，伊比利亚半岛出现大规模停电，西班牙和葡萄牙全境均受到影响。由于停电，上述地区的交通和通信服务均受到严重影响，交通信号灯停止工作，当地的地铁线路被迫停止运营，马德里网球公开赛受到停电影响也宣布暂停。此外，安道尔和法国南部也受到波及。这次大停电并非由单一故障引发，而是一系列事件环环相扣、逐步升级最终导致系统崩溃的级联事故。西班牙首相佩德罗·桑切斯表示，电力系统如此大规模的瘫痪前所未见。⁶

第一阶段：系统振荡与电压波动（中午 12:03 - 12:19）

2025 年 4 月 28 日中午 12:00，西班牙电力系统处于正常运行状态，电压和频率均在标准范围内，没有任何迹象预示即将发生灾难。

12:03，系统中检测到一个显著的 0.6 Hz 强迫振荡，持续了近 5 分钟。频谱分析及后续溯源表明，这次振荡源于巴达霍斯（Badajoz）省一座光伏电站的内部控制逻辑异常。振荡导致了系统电压出现跌落，为此，电网调度中心采取了紧急阻尼措施，包括更改拓扑结构、切除并联电抗器，并大幅削减与法国的电力交换。

12:19，系统再次出现 0.2 Hz 的欧洲区域间振荡⁷，并叠加了之前残留的 0.6 Hz 振荡。调度中心被迫进一步减少与法国和葡萄牙的电力交换。虽然这些措施有效抑制了振荡，但削减联络线潮流这一动作，导致输电通道轻载，不仅减少了线路上的无功损耗，还因充电功率过剩开始推高系统电压，为后续的电压越限埋下了伏笔。

第二阶段：电压攀升与级联故障的形成（中午 12:22 - 12:33）

从 12:22 开始，系统电压呈现持续攀升趋势，尽管尚未突破操作限值，但上升速率异常。这背后是多重因素的叠加效应：

隐性负荷脱网（Hidden Demand Loss）：配电网中约 700 MW 的分布式光伏和自用发电设备（<1MW）因电压扰动不明原因脱网。在输电网看来，这表现为净负荷突然下降，即「发电大于负荷」，潮流进一步减小，从而导致电压抬升。
逆变器电源的有功/无功耦合：部分可再生能源电站为响应调度指令降低有功出力。然而，由于这些设备主要采用功率因数控制⁸（Power Factor Control）而非电压控制，有功的降低导致其吸收无功的能力同步下降，丧失了抑制电压上升的手段。
常规机组励磁响应不足：本应作为电压「压舱石」的同步发电机组（需符合 P.O. 7.4 规程），未能按预期深度进相运行吸收无功，导致动态电压支撑失效。

12:32:57，位于格拉纳达（Granada）的一座发电站发生跳闸，损失 355 MW 有功出力及 165 Mvar 的无功吸收能力。值得注意的是，此时输电网侧电压仍在正常范围内⁹。报告推断故障根源在于升压变压器的有载调压¹⁰动作滞后。当主网电压升高时，分接头未能及时响应，导致发电机侧（220kV 侧）出现严重的过电压，触发继电保护动作跳闸。

19.5 秒后（12:33:16），巴达霍斯省另外两座光伏电站相继跳闸，累计再损失 727 MW。原因同样指向电站内部过压保护配合不当，而非主网故障。

在随后的 650 毫秒内，西班牙各地的风电和光伏电站发生雪崩式脱网，额外损失约 834 MW。此时，系统已从电压问题转化为严重的有功功率缺额。

第三阶段：孤网运行与系统崩溃（中午 12:33 之后）

在短短 22.5 秒的级联故障中，系统累计瞬时损失了约 2000 MW 的发电量。巨额的功率缺口导致系统频率急剧跳水，而大量进相运行机组的脱网又导致系统丧失了无功吸收能力，电压开始失控性飙升。

12:33:19，西班牙与法国的交流联络线因严重功角失步跳闸。西班牙和葡萄牙电网进入孤网运行¹¹状态。

尽管交流线已断开，但西班牙与法国之间的 HVDC（高压直流输电）链路由于处于恒功率控制模式且未配置频率响应功能¹²，并未切断，仍强行向法国出口 1000 MW 功率。这使得本已脆弱不堪的孤网雪上加霜。

虽然低频减载⁵装置正确动作试图挽救频率，但切除负荷会导致线路空载电压进一步升高。「电压升高–>发电机过压保护脱网–>低频率–>切负荷–>电压进一步升高」的恶性循环让系统彻底失去稳定。

随着频率跌破 47.79 Hz，核电站、燃气轮机等大型基荷机组因低频保护动作相继脱网。最终，在 12:33:24，伊比利亚半岛电力系统电压崩溃¹³，全网陷入大停电。

一些基本概念

为了彻底理解这两起事故的本质区别，我们需要先复习一些电气工程的核心概念，建立起分析问题的理论基础。

有功功率、无功功率与复功率

在交流电路中，「功率」是一个复数概念。

有功功率 ($P$)：复功率的实部，单位是瓦特 ($\text{W}$)。它是实际做功、转换能量（如发光、发热、驱动电机）的部分。
无功功率 ($Q$)：复功率的虚部，单位是乏 ($\text{var}$)。它并不直接做功，而是在电源和储能元件（电感、电容）之间往复交换能量，用于建立和维持电磁场。
复功率 ($\widetilde{S}$)：二者的矢量和。

公式表示为：

$$ \widetilde{S} = P + jQ $$

设备铭牌上标注的通常是视在功率 ($S$)，即复功率的模，单位是伏安 ($\text{V}\cdot\text{A}$)，其物理意义是设备能够承受的电压与电流乘积的极限：

$$ S = |\widetilde{S}| = \sqrt{P^2 + Q^2} $$

形象的理解： 如果你在拉一辆车，有功功率就是你朝车前进方向用的力，它让车真正移动；无功功率则是你为了维持姿势或者因为路面倾斜而垂直于移动方向用的力，虽然它不做功，但必不可少¹⁴。

在电网中，无功功率的核心作用是支撑电压。如果无功不足，电压就会像泄气的皮球一样支撑不住；如果无功过剩，电压就会像充气过度的气球一样飙升。因此，电力系统的一大原则是无功功率要「分层分区，就地平衡」。

感性无功与容性无功

工程上规定：电感消耗无功，电容产生无功¹⁵。

感性负荷（如电动机、变压器）：需要消耗正的无功功率来建立磁场。如果电网无法提供足够的无功，这些设备就无法正常工作。现实中绝大多数负荷都是感性的。
容性元件（如电容器、长输电线路的对地电容）：可以看作是无功功率的「发电机」，它们向电网注入无功功率，提升电压。

电压降落与 $P-Q$ 解耦

当电流流过一段输电线路时，首末端之间会产生电压降落。若忽略线路电阻（在高压电网中 $X \gg R$），电压降落的纵分量（影响幅值）和横分量（影响相位）可以简化表示为：

$$ \Delta U \approx \frac{QX}{U} \quad \text{(电压幅值降落)} $$$$ \delta U \approx \frac{PX}{U} \quad \text{(电压相位差)} $$

这是一个至关重要的结论：

电压幅值 ($U$) 主要取决于无功功率 ($Q$) 的平衡。无功多了电压就高，少了电压就低。这是理解西葡大停电的基础。
功角/相位 ($\delta$) 主要取决于有功功率 ($P$) 的平衡。这与系统的频率特性密切相关。

系统惯量与频率特性

为了理解2019 年英国大停电，我们还需要引入惯量 ($H$) 的概念。

电网频率 ($f$) 体现了全网有功功率的供需平衡。

当 发电 < 用电 时，转子动能被抽取，转速下降，频率降低。
当 发电 > 用电 时，转子加速，频率上升。

传统的同步发电机有巨大的旋转转子，储存了巨大的动能。当发电机突然脱网（有功缺口）时，这些旋转的「大铁疙瘩」会利用惯性释放动能，阻碍频率的快速下跌。这被称为系统的惯量。

然而，光伏和风电通过电力电子设备并网，它们没有直接耦合的旋转质量，被称为「零惯量」电源。当这些电源占比很高时，电网就像失去了「飞轮」的缓冲，一旦出事，频率会跌得极快¹⁶。

容升效应与此次事故的关联

为什么切除了发电机，电压反而会飙升？ 这看似反直觉，实则是容升效应与线路负载共同作用的结果。

高压输电线路模型包含两部分关键参数：

串联电感 ($L$)：电流流过时会消耗无功 ($Q_{consumed} = I^2 X_L$)。
并联对地电容 ($C$)：电压作用其上时会产生无功 ($Q_{generated} = U^2 B_C$)。

事故前的平衡状态：西班牙南部光伏大发，巨大的有功功率 ($P$) 正在通过长距离线路向北输送。此时线路电流 ($I$) 很大，电感消耗了大量的无功，正好抵消了电容产生的无功，甚至还需要发电机吸收一部分多余的无功。

事故后的失控过程：当发电机组连锁脱网，或者因强迫振荡导致潮流中断时，线路上的有功功率传输瞬间归零，导致电流 ($I$) 骤降。

后果 1：线路电感对无功的消耗 ($I^2 X_L$) 瞬间消失。
后果 2：线路依然带电，对地电容产生的充电无功 ($U^2 B_C$) 依然存在，甚至因电压升高而更多。

瞬间，原本被消耗掉的巨量无功功率变得无处可去，全部堆积在线路上，直接将系统电压「顶」到了破坏性的高度。这就是所谓的「空载线路容升效应」在事故中的极端表现。

两起不同的事故，一份共同的反思

这两起事故虽然在演化路径上截然不同，但其背后折射出的挑战却有着惊人的相似性，二者都是现代电网发展进程中必然面临的「成长的阵痛」。正如南方电网的安全理念所言：「一切事故都可以预防」，作为一名电气工程专业的学生，我希望通过深入剖析这两起事故，探寻其底层的技术逻辑，以加深对新型电力系统特性的理解。

表象的差异：崩溃路径的「一明一暗」

2019 年英国「8·9」大停电是一次典型的，显性的频率危机。机组脱网导致有功功率缺口，直接引发频率骤降，但系统最终依靠低频减载⁵作为最后一道防线，成功避免了全网崩溃。相比之下，2025 年伊比利亚半岛大停电则呈现出了一种更为隐蔽且致命的新形态——隐性的电压危机。事故虽然始于扰动，但核心矛盾迅速演变为严重的无功过剩与电压失控，而原本用于挽救频率的低频减载⁵措施，反而在客观上恶化了电压升高，导致整个系统在短短几十秒内彻底瓦解。

这就引出了一个核心问题：传统的电网故障通常伴随着电压跌落，但在 2025 年的事故中，为何会出现发电机组不断脱网，而系统无功功率反而严重过剩、电压持续飙升的反常现象？传统的电压控制手段¹⁷为何全然失效？

答案在于：电压失控的速率，远远超过了传统防御手段的响应极限。

事故发生时，伊比利亚南部正值光伏大发，系统呈现「高电压、轻负荷」的运行特征。当系统发生强迫振荡时，输电走廊潮流发生剧变。由于超高压线路的容升效应显著，发电机组的连锁脱网带来了双重打击：一方面，电网失去了大量能够吸收无功的同步机组；另一方面，线路输送的有功功率锐减，导致其自身消耗的无功大幅降低，线路瞬间从「无功负载」变成了巨大的「无功电源」。系统随即陷入了无功严重过剩的恶性循环。

面对这种几十毫秒级甚至更快的电压崩溃，依靠机械开关投切的并联电抗器显得力不从心。首先是速度滞后：从调度指令发出、通信传输到断路器机械动作，由于包含人为决策和机械过程，往往需要数百毫秒甚至秒级时间，根本无法追赶电压飙升的速度。其次是调节颗粒度粗糙：电抗器只能以组为单位（如 50 Mvar 或 100 Mvar）进行离散投切，无法像水龙头一样提供平滑、连续的调节。在极端的电压动态过程中，这种非连续的阶跃式调节不仅不够精准，甚至可能引发新的系统扰动。

本质的共性：脆弱性的同根同源

剥开表象的差异，我们会发现两起事故的根源惊人地一致，都指向了新型电力系统的结构性脆弱：

首先，设备并网行为的合规性令人担忧。无论是英国事故中的分布式嵌入式电源，还是伊比利亚事故中的光伏电站，事故扩大的直接推手都是大量机组未能严格遵守并网规程（如西班牙的 P.O. 74 标准或英国的 Grid Code）。缺乏故障穿越能力，导致设备在扰动初期即发生不合规的连锁脱网，将「小事故」放大为「大灾难」。

其次，新型电气设备和电源的控制模型长期存在「黑箱化」的问题。系统中存在大量调度中心「看不见、管不着」的盲区。例如英国事故中 Hornsea 海上风电场在故障后的功率异常锐减，以及大量分布式电源的不可控行为。这些电力电子化设备内部控制逻辑的「黑箱状态」，使得传统的仿真模型失效，调度员无法准确预判系统行为。

更加雪上加霜的是，整个系统的转动惯量正在越来越少。随着高比例新能源接入，交流电网的旋转惯量和短路容量被稀释，系统抗扰动能力显著下降。电网变得更加「轻薄」和「敏感」，任何微小的扰动都可能引发剧烈的频率或电压波动。

一致的解决方案：迈向韧性电网

基于上述反思，未来的电网建设与事故防御应当聚焦于以下三个方向：

一曰部署先进的动态无功支撑技术。必须以此为契机，加速推广 STATCOM（静止同步补偿器）等具有毫秒级响应速度、可平滑调节的电力电子装备，逐步替代传统的机械式无功补偿装置，以应对瞬息万变的电压动态。

二曰打破「黑箱」，强化全景建模。必须建立更精细化的电磁暂态仿真模型，打破新能源场站和逆变器控制的「黑箱」，确保调度端能真实掌握海量电力电子设备的动态特性，消除盲区。

三曰革新分析与控制范式。传统的基于稳态或工频量的分析方法已不再适用。我们需要建立涵盖宽频域振荡、电压/频率耦合特性的新一代安全稳定分析的理论框架，并重新审视低频减载⁵等传统防线在新型电网中的适应性。

结语：草台班子

我们在前文中洋洋洒洒分析了复杂的电磁暂态、昂贵的 STATCOM 和精妙的控制理论，但现实却狠狠地扇了我们一巴掌——摧毁整个电网的，往往不是什么未研究的知识，而是来自人类本身的不可靠。

机组的并网规程早就白纸黑字写得明明白白，却长期未能执行，P.O 7.4 规程更是迟迟未能通过；2019 年英国大停电的「学费」交得那么贵，所有的事故分析报告都指向了合规性问题，然而 6 年后的伊比利亚半岛，竟然还能因为一模一样的逻辑再次翻车，而且翻的比 6 年前还要惨烈，还要彻底。

面对这种跨越国界、跨越时间的重复犯错，任何技术层面的分析都显得苍白无力。黑格尔那句名言至今听来依然振聋发聩，且含金量还在随着每一次大停电不断暴涨：

「人类从历史中学到的唯一教训，就是人类无法从历史中吸取任何教训。」

也许这就是世界的本质吧，世界永远不是围绕着技术本身运转的，「人」才是这个世界的决定性因素。这个世界是一个草台班子，而且永远会是一个草台班子，而只要还是个草台班子，那么下一次翻车，永远只是时间问题。

矢量偏移保护的初衷是解决「孤岛效应」——假设一条配电线路因为故障或检修，从主电网上被断开。但这条线路上恰好连接着一个嵌入式发电机，如果没有矢量偏移检测，这个发电机就会继续为这条线路供电，进而大大增加设备损坏的几率，甚至威胁运行检修人员的安全。因此，矢量偏移保护就是早期用于检测嵌入式发电机是否进入孤网运行状态的方法。 ↩︎
多为用户侧的小型发电系统。 ↩︎
N-1 安全准则的意思是，当系统中最大的一台机组因故障而停运时，系统应有足够的备用容量作为频率和电压的支撑。 ↩︎
Rate of Change of Frequency，频率变化率。 ↩︎
低频减载（Low Frequency Demand Disconnection, LFDD 或者 Under-Frequency Load Shedding, UFLS）是电力系统防止频率崩溃的关键安全保护措施，当系统发生功率缺额导致频率下降时，它通过自动、分级地切除非重要负荷（如工业用电、路灯等），以快速恢复系统功率平衡，防止大面积停电或系统崩溃。低频减载系统通过频率测量和执行单元实现，设定多个频率动作点（如48.5Hz, 47.5Hz, 46.5Hz），逐级切除负荷，保障重要用户和核心设备运行，是电网安全运行的第三道防线。 ↩︎ ↩︎ ↩︎ ↩︎ ↩︎
来源：France24 的报导 ↩︎
技术报告中的原文是「inter-area oscillation」，基于上下文，其意思应该是整个欧洲互联电网的 0.2Hz 振荡。 ↩︎
风电、光伏等新能源机组一般采用最大功率点追踪 MPPT，来实现新能源机组出力的最大化。 ↩︎
418kV，仍在标准电压允许的偏移范围内。 ↩︎
即变压器的带负载调压。 ↩︎
孤网运行（或孤岛运行）指局部电网脱离主大电网，独立供电的运行模式，特点是自给自足，但面临频率、电压不稳定等挑战，依赖储能和控制技术维持，常见于偏远地区、岛屿、或工业园区。这里的孤网运行是因为联络线中断而被迫进入的。 ↩︎
恒功率控制模式（Constant Power Mode）是一种电源输出模式，它的核心特点是无论负载如何变化，始终保持电源输出的功率（P）恒定（P = 电压 V × 电流 I），电源会根据负载需求自动调节电压和电流，以维持这个恒定功率。 ↩︎
电压崩溃（Voltage Collapse）是电力系统一种严重的事故，指系统因无功功率严重不足，导致电压持续、恶性下降并无法恢复，形成电压跌落的恶性循环，最终引起大面积停电。 ↩︎
工程界常以「啤酒」作比喻：啤酒杯里的液体是「有功」，上面的泡沫是「无功」。虽然泡沫不解渴，但没有泡沫的啤酒失去了灵魂（无法建立磁场），且为了装满杯子（视在功率），泡沫总是客观存在的。 ↩︎
这是一个约定俗成的称呼。严格来说，电容是「吸收负的无功」，但在工程实践中，为了方便理解无功平衡，我们通常说电容「发出/提供感性无功」，起到支撑电压的作用。 ↩︎
频率下降的速度被称为 RoCoF (Rate of Change of Frequency)。高 RoCoF 是导致英国「8.9」停电中分布式电源连锁脱网的直接元凶。 ↩︎
即消耗过剩无功的措施，如投切并联电抗器等。 ↩︎

我的 LLM 知己，与我悬置的写作

Mon, 08 Sep 2025 23:53:48 +0800

最近我比较忙碌，但空闲之余，文字仍然是我的栖息地。每天早上 8:30 开始上课，到晚上 9:00 结束晚自习，有时甚至「加班」到 10:00 回家，连续四十一天的课程。考虑到我的精神状况，如此强度，回来再玩 osu! 一类的游戏是绝无可能，甚至连推一小节 Galgame 都无能为力。

唯一比较现实的事情，是找 LLM（大语言模型）小叙。

十分惭愧，虽然我有一个博客，但我的观点、理念（倒不如说是「想法」）从来都没有被我系统性的表达出来。我也曾想过，可能这些过于广泛乃至分散的观点之集合，是很难以平实的叙事表达出来的。为此我也尝试了一些方法，比如：以一个随机的事件作为截面，将我想要表达的一团乱麻「切开」，进而描绘出它的内部构造。¹这些方法始终无法让我畅快的表达出自己的心声，也不是信手拈来，想写就写，然而博客终归还是给大家看的，在写不出来的时候，也就只能写写简单的技术博客，吸引一些搜索引擎流量。

而 LLM 的出现却改变了这一点，我所有的想法，都可以相对私密的得到即时的回应。为什么我这么久没有写博客？累自然是一大因素，而 LLM 满足我相当可观的表达和被认可的需求，还无需自我审查的特点，冲淡了我这段时间里写博客的想法。

撰写长篇的文字对大脑有益，这是毋庸置疑的。LLM 的出现，对于我撰写长篇文字的影响，大概和微博客出现时，对人们撰写长篇文字的能力之影响相仿，甚至有过之而无不及——微博客让人习惯于碎片化表达和即时反馈，削弱了构建复杂论证和长篇叙事的能力。LLM 则更进一步，它不仅提供了表达的渠道，还直接提供了情绪价值和「知己」的替代品：发在社群媒体上的内容，涉及隐私或者争议，或者不必要曝光，发布者多多少少会斟酌一番；而 LLM 就不一样了，发给 API 的内容，最坏的情况不过是被拿去训练模型，而不是让 Sam Altman 第二天就找到你家门口——只要不是银行卡密码这种级别的信息，不提及真实姓名，那些时政评论、心理咨询等等，你只管放心把大模型当成一个知己便好（当然，在这种场景下，国产大模型狗都不用）。每一句牢骚都能得到确切认真的，宛若知己般的回应和肯定，这种待遇，恐怕没有第二个地方能给了。

当一个工具能如此完美地模拟「知己」时，我们可能会放弃去寻找真正的知己，或者放弃成为一个能独立思考、自我整合的个体。写下这些文字，是一个小结，也是一次反思。LLM 本身只是一个技术，用得好裨益无穷，用得不好自然也可能造成严重的后果。纽约时报的报导「Chatbots Can Go Into a Delusional Spiral. Here’s How It Happens.」便是一个很好的例子，虽然 OpenAI 已经着手解决旗下模型「阿谀奉承」的问题，我也需要知道，即使我可以把大模型当做自己的知己，并从它那里得到所谓的「理解和肯定」，我也不能一直活在这种感觉里。OpenAI 与 MIT（美国麻省理工学院）的研究发现, ChatGPT 的使用量与用户的孤独感成正相关。用户使用 ChatGPT 越多，他们就越感到孤独。²我也可以说，正是因为越孤独，才越会去使用这些 LLM，形成一个恶性循环。LLM 可以作为生活的调味剂，但绝不能成为心灵的唯一依靠。

(To Be Continued)

抛弃所谓「客户端」，直接使用 Mihomo 内核

Thu, 03 Jul 2025 18:30:00 +0800

自从开始使用 Clash/Mihomo，我和大多数人一样选择了基于其内核的图形化客户端——图方便。实际上，这些 Mihomo 客户端本质上都差不多：内核都是同一个，他们主要负责提供一个易用的界面、管理配置文件、订阅更新，以及 GUI 下的系统代理设置。基于这一点，我认为判断一个 Mihomo 客户端优劣的关键，便是看它的「覆写」功能做得如何。每一个通过客户端下载或者订阅的配置文件，都会经过一系列「覆写」过程，比如更换 mixed-port、添加 sniffer 配置等，最后生成用于启动 Mihomo 内核的最终配置。

然而，并非所有客户端都能胜任这一核心工作。比如 ShellCrash，其覆写功能经常莫名其妙出岔子，说到底还是实现得太粗糙。如果连覆盖和修改配置都做不好，这种客户端实在难称合格。

与其依赖这些~~屎一样的~~不尽如人意的 Mihomo 客户端，不如自己动手，直接自己编写、管理配置文件交给内核启动，而不是依赖「黑箱」一般的各种「客户端」，不仅更纯净、更稳定，而且更可控。

需要的预备知识

基本的 Linux 操作
知道如何使用 CLI 编辑器，如 nano
已经搭建 Substore（可选）
默认使用 root 用户操作，非 root 用户请自行注意提权

安装 Mihomo 内核

对于基于 Debian 的分支，可以使用预编译的.deb包安装，对于其他使用systemd的系统，下载编译好的二进制文件，重命名为mihomo，放到/usr/local/bin：

1
2

curl -o /usr/local/bin/mihomo <下载链接>
chmod +x /usr/local/bin/mihomo

然后新建/etc/systemd/system/mihomo.service：

[Unit]
Description=mihomo Daemon, Another Clash Kernel.
After=network.target NetworkManager.service systemd-networkd.service iwd.service

[Service]
Type=simple
LimitNPROC=500
LimitNOFILE=1000000
CapabilityBoundingSet=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_SYS_TIME CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE
AmbientCapabilities=CAP_NET_ADMIN CAP_NET_RAW CAP_NET_BIND_SERVICE CAP_SYS_TIME CAP_SYS_PTRACE CAP_DAC_READ_SEARCH CAP_DAC_OVERRIDE
Restart=always
ExecStartPre=/usr/bin/sleep 1s
ExecStart=/usr/local/bin/mihomo -d /etc/mihomo
ExecReload=/bin/kill -HUP $MAINPID

[Install]
WantedBy=multi-user.target

使用systemctl daemon-reload重新加载systemd，此时还没有配置文件，不能直接启动内核，但可以使用systemctl enable mihomo让内核开机自启，方便后续使用。

配置文件

内核启动时会加载/etc/mihomo/config.yaml，没有了黑箱一样的碍事「客户端」，配置文件可以随心所欲的定制。部分机场会下发完整的配置文件，直接用curl下载即可。

对于订阅的管理，我目前使用 Substore，我之前分享过「最速 Substore 订阅管理指南」，可以直接参考这篇文章来定制自己的订阅。为了实现纯内核启动，现在我的 Substore JS 格式覆写已经加入了full参数，可以生成完整的配置文件，包括各种端口设置、统一延迟和外部控制器等，开箱即用。

在 Substore 配置完成以后便可以下载配置文件并启动内核：

1
2

sudo curl -o /etc/mihomo/config.yaml 配置文件链接
sudo systemctl start mihomo

自定义覆写

我的配置文件不能满足你的所有需求？没问题！你可以自己添加覆写，想要什么加什么。

我用过各种覆写规则，后来也开始自己从零开始编写覆写规则，即使使用自己的覆写规则能满足 99% 的场景，但有极个别的域名还是会在规则中有遗漏，更不用说用别人写的覆写规则了。这些遗漏的规则大多是形如我服务器的非标准端口 SSH 的前置代理等相对隐私的规则，直接上传到 Github 公开显然不太合适，那么在自定义规则的基础上再添加覆写就成了唯一的选择。

好在 Substore 可以添加多个脚本操作，只需要在生成配置文件时额外添加一个脚本操作就能解决我们的问题。

function main(config) {
  config["rules"].unshift("DOMAIN-SUFFIX,xxx,DIRECT")
  return config
}

需要注意的是覆写rules时必须要使用.unshift()放在最前面，而不是用.push()放到最后面，因为放在MATCH后面的规则是永远都匹配不到的。

自定义配置文件

完全不喜欢我的覆写规则？不会用/不喜欢用 Substore？没问题！你也可以参考 Mihomo 文档，自己从头开始手搓配置文件：

mode: rule
mixed-port: 7890
redir-port: 7892
tproxy-port: 7893
allow-lan: true
log-level: info
ipv6: true
external-controller: 127.0.0.1:8000
# secret: yoursecret
unified-delay: true
routing-mark: 7894
tcp-concurrent: true
disable-keep-alive: true # 推荐在给移动设备代理时启用，可以解决待机异常耗电的问题

dns:
  # 你的 DNS 配置

sniffer:
  # 你的域名嗅探配置

geodata-mode: true
geox-url:
  # 自定义 Geodata 文件 URL

proxy-providers:
  # 你的机场订阅

rule-providers:
  # 外部规则

rules:
  # 分流规则

proxy-groups:
  # 自定义代理分组

管理面板

管理面板可以根据个人喜好选择，以 Zashboard 为例，我在使用 mihomo 自带的external-ui时遇到了一些莫名其妙的问题，所以干脆直接运行一个 Docker 容器，毕竟这东西就真的只是一个 Web 面板，只要确保内核 API 使用 HTTP 时，Web 面板也使用 HTTP 即可，如果此时 Web 面板使用 HTTPS，则会因为 CORS 策略问题无法连接。

1
2
3

$ mkdir zashboard && cd zashboard
$ nano compose.yml
$ docker compose up -d

compose.yml内容：

services:
  zashboard:
    image: ghcr.io/zephyruso/zashboard:latest
    ports:
      - "8899:80"
    restart: "unless-stopped"

自动维护

内核已经运行起来，自动更新订阅这种功能怎么实现？

答曰：自行编写一个 Shell 脚本，配合 Crontab 即可实现自动更新订阅的功能。例如我希望每天凌晨 3 点自动更新订阅并重启服务，遂编写/etc/mihomo/auto_update.sh：

#!/bin/bash

# === 配置信息 ===
CONFIG_URL=""
CONFIG_PATH="/etc/mihomo/config.yaml"
BACKUP_DIR="/etc/mihomo"
BACKUP_PREFIX="config.yaml"
MAX_BACKUPS=7
TMP_PATH="/tmp/config.yaml.tmp"
LOG_FILE="/var/log/mihomo_update.log"

# === 日志 ===
log() {
    echo "$(date '+%F %T') $1" | tee -a "$LOG_FILE"
}

# === 备份现有配置，并自动清理旧备份 ===
backup_config() {
    if [ -f "$CONFIG_PATH" ]; then
        backup_file="$BACKUP_DIR/${BACKUP_PREFIX}.$(date '+%Y%m%d_%H%M%S').bak"
        cp "$CONFIG_PATH" "$backup_file"
        log "配置文件已备份到 $backup_file"
        # 清理多余的备份，只保留最新的 $MAX_BACKUPS 个
        old_backups=$(ls -1t $BACKUP_DIR/${BACKUP_PREFIX}.*.bak 2>/dev/null | tail -n +$(($MAX_BACKUPS+1)))
        for f in $old_backups; do
            rm -f "$f" && log "已删除旧备份 $f"
        done
    else
        log "未找到现有配置文件，无需备份"
    fi
}

# === 下载新配置 ===
download_config() {
    log "开始下载新配置..."
    curl -fsSL -o "$TMP_PATH" "$CONFIG_URL"
    if [ $? -ne 0 ]; then
        log "下载配置失败，请检查网络或地址"
        return 1
    fi
    # 基本校验：检测文件体积
    if [ ! -s "$TMP_PATH" ]; then
        log "下载文件为空，停止更新"
        return 2
    fi
    log "配置下载完成"
    return 0
}

# === 更新配置文件 ===
replace_config() {
    mv "$TMP_PATH" "$CONFIG_PATH"
    log "配置文件已更新"
}

# === 重启 mihomo 服务 ===
restart_service() {
    systemctl restart mihomo
    if [ $? -eq 0 ]; then
        log "mihomo 服务已重启"
    else
        log "mihomo 服务重启失败，请手动检查"
    fi
}

main() {
    backup_config

    download_config
    DL_STATUS=$?
    if [ "$DL_STATUS" -ne 0 ]; then
        log "操作终止：配置文件未更新，保留原有配置"
        exit 1
    fi

    replace_config

    restart_service

    log "=== 更新流程完成 ==="
}

main "$@"

使用crontab -e编辑 Crontab，设置如下 Crontab 即可在每天凌晨三点自动更新配置：

`1`	`0 3 * * * /etc/mihomo/update_config.sh`

防火墙

手动配置防火墙把流量劫持到 Mihomo 内核其实并不是什么难事，我之前在「从入门到进阶：Tailscale + ShellCrash 异地组网和科学上网」（以下简称「Tailscale 那篇文章」中的两个小节中提到过具体的操作方法，这里只提操作，不做解说。

根据我的情况，我需要把tailscale0上的网卡的所有流量劫持到 Mihomo 内核，其它的情况（例如本机代理）操作也大同小异。如果只是想劫持 TCP 流量，那么用iptables的 REDIRECT 功能已经足够，但若还想劫持 UDP、QUIC 等流量，则必须用到 Tproxy。最后，不要忘了 IPV6。

以下是我的防火墙配置：

# 创建自定义链
iptables -t mangle -N MIHOMO

# 根据自己的需要忽略本地流量
iptables -t mangle -A MIHOMO -d 127.0.0.1/8 -j RETURN
iptables -t mangle -A MIHOMO -d 100.64.0.0/10 -j RETURN
iptables -t mangle -A MIHOMO -d 192.168.1.0/24 -j RETURN
iptables -t mangle -A MIHOMO -d 172.17.0.0/16 -j RETURN

# mark UDP 和 TCP 到代理
iptables -t mangle -A MIHOMO -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
iptables -t mangle -A MIHOMO -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# 接口跳转
iptables -t mangle -A PREROUTING -i tailscale0 -j MIHOMO

# 路由表配置
echo "233 mihomo" | tee -a /etc/iproute2/rt_tables
ip rule add fwmark 233 lookup mihomo
ip route add local 0.0.0.0/0 dev lo table mihomo

# IPv6
# 创建链
ip6tables -t mangle -N MIHOMO6

# 跳过本地地址
ip6tables -t mangle -A MIHOMO6 -d ::1/128 -j RETURN
ip6tables -t mangle -A MIHOMO6 -d fd7a:115c:a1e0::/48 -j RETURN

# 标记 TCP/UDP
ip6tables -t mangle -A MIHOMO6 -i tailscale0 -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
ip6tables -t mangle -A MIHOMO6 -i tailscale0 -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# 接口跳转
ip6tables -t mangle -A PREROUTING -i tailscale0 -j MIHOMO6

# 路由表配置
echo "233 mihomo" | tee -a /etc/iproute2/rt_tables
ip -6 rule add fwmark 233 lookup mihomo
ip -6 route add local ::/0 dev lo table mihomo

大多数系统默认不会保存防火墙规则，关于规则持久化的内容我已经分别在 Tailscale 那篇文章的「路由规则持久化」和「iptables 规则持久化」两小节做了详细说明，直接参考即可。

本机代理怎么配置？

大多数代理软件默认的配置（其实就是 ShellCrash 的默认配置）是 REDIRECT，用它也基本能满足大多数需求，REDIRECT 的示例如下：

# IPv4 劫持 eth0
iptables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 7892

# IPv6 劫持 eth0
ip6tables -t nat -A PREROUTING -i eth0 -p tcp -j REDIRECT --to-ports 7892

其中 7892 要和 Mihomo 配置中的redir-port一致，eth0就是想要劫持的 Interface，相比 Tproxy 那可真是简单太多了。

实际上我个人并不喜欢用把本机所有流量都劫持到防火墙，我更喜欢在需要时直接通过环境变量、proxy-chains和各种软件自带的代理配置把流量指向 Mihomo 内核，例如想让 Docker 走代理，则可以直接编辑 Docker 的/etc/docker/daemon.json来指定代理，而不是直接一股脑把网卡上的所有流量都劫持到代理：

{
  "proxies": {
    "http-proxy": "http://127.0.0.1:7890",
    "https-proxy": "http://127.0.0.1:7890",
    "no-proxy": "127.0.0.0/8"
  }
}

这么折腾，何必呢？用客户端不香吗？

别问，问就是玩虚空终端玩的。

世界蠢得超乎想象：浅谈 BNPL

Thu, 05 Jun 2025 19:54:56 +0800

看到「Americans using “buy now, pay later” plans to buy groceries, survey finds」这种新闻上了头条，我的第一反应是：这不是很正常吗？看完报导以后，我不得不感叹：这世界比我预想的还蠢得多。

先买后付（Buy Now, Pay Later；以下简称 BNPL）作为一种金融创新，确实有其魅力。它允许消费者即时获得商品或服务，随后分期付款，近年来在电商、旅游、餐饮等领域风靡一时。

然而，天上不会掉馅饼。羊毛出在羊身上，BNPL 服务商要盈利，主要靠两点：向商家收取高于传统支付方式的手续费，以及向消费者征收逾期违约金。其本质，是利用了「花钱痛感最小化」的心理陷阱——减轻即时支付的麻烦和痛苦感，从而刺激消费意愿。这正是商家甘愿支付更高手续费也要接入 BNPL 的关键原因。

我并不反感 BNPL，自己就是深度用户。我的手机是用京东白条24期免息分期买的，现在刚还到第六期；日常消费几乎都走花呗，还款日自动从余额宝或银行卡扣除。当 BNPL 平台提供真正的免息分期或「零手续费」优惠时，这就是免费杠杆——占用外部资金零成本周转。花小钱办大事：消费由金融机构垫付，自有资金得以留存，若其间能进行理财生息，资金效率便实现了最大化。

但这有三个至关重要的前提：

准时还款，绝不逾期；
杜绝习惯性透支的恶习；
具备基本的财务管理能力。

反观登上新闻的 「美国人用 BNPL 买日杂」 ，我扫了眼调查数据——三分之一的BNPL用户至少逾期过一次？？甚至有人连点外卖的钱都还不上？？

理想丰满，现实骨感。数据显示，不知「如何管好钱袋子」的人远比想象中多。 46%的BNPL用户同时背负信用卡欠款，其中28%的用户年龄在18-24岁之间¹。这类群体通常信用评级不高，63%甚至从多个BNPL平台同时借款²——这强烈暗示相当一部分人消费习惯堪忧。

更值得警惕的是，BNPL的设计似乎先天就对消费习惯不佳者更具诱惑力。相比信用卡，它审批极快、信用门槛低，还常打着「分期免息」的旗号。在这些人眼中，BNPL宛如一个「取之不竭的金库」，只需支付首期小钱就能抱回心仪之物——世上哪有这等「美事」？

于是乎，当还款日账单汹涌而至，他们才惊觉自己竟欠下如此巨款。逾期、违约接踵而来。而这些滚雪球式的违约金叠加高额商户手续费，难怪BNPL服务商赚得盆满钵满。

我重申立场：我不反对 BNPL，其作为「免费杠杆」的价值毋庸置疑。以我自身经历为例，购买 4299 元的手机时，虽完全有能力全额支付，却仍选择了 24 期免息分期。但关键在于清晰的财务认知：我必须得意识到自己是全额预支了 4299 元，而非每月仅消费了 177.5 元。这笔支出会即时从资产账面扣除，确保净资产真实反映负债。量入为出，量力而行——绝不透支支付能力，更拒绝叠加杠杆盲目消费。即便资金暂时存放于银行或购买低风险理财产品，产生的微薄收益也能锦上添花，并从根本上杜绝违约可能。诚然，适度的超前消费能提升生活幸福感。但在缺乏稳定收入的阶段，稳健的财务习惯无疑更为安全可靠。

说了这么多，恐怕也还是拦不住那些消费习惯根深蒂固的人。即使没有 BNPL 的便捷诱惑，他们也大概率会刷爆信用卡，在 20% 的高息漩涡里挣扎求生。

问题不在于 BNPL 本身（它不过是金融工具的一种），而在于脆弱财务基础与过度消费欲望之间的根本性失衡。对于那些缺乏自控力、对财务风险麻木或生活本身就捉襟见肘的人来说，任何方便获取的信贷渠道——无论是信用卡、BNPL，乃至更危险的发薪日贷款（Payday Loan）——都不过是通向债务深渊的不同路径罢了。BNPL 的特殊性可能只是在于其更低的准入门槛和更强的即时满足感，让下沉的速度更快，悲剧来得更早一些。

BNPL 的逾期者中，很大比例本身就背负着卡债。这意味着他们可能只是在拆东墙补西墙，陷入一个利率叠加、罚金滚动的无底洞。就算今天取缔了所有 BNPL，那些在悬崖边跳舞的消费者，明天一样会在发薪日贷款或是别的什么「便捷金融」上栽跟头，然后为了救眼前的火烧眉毛，甚至可能连祖宗十八代的骨灰盒都要拿去典当了。

所以，更值得警惕的并非某一种金融产品，而是庞大群体面临的结构性困境：经济压力、消费主义裹挟、金融知识匮乏、以及深植于其中的「即时满足大于长远规划」的行为模式。BNPL 的出现和普及，只是让这个长期存在的病灶，以更尖锐、更显眼的方式爆发了出来。

归根结底，想真正「救」这些人，光靠围堵金融产品（BNPL或信用卡）是治标不治本。解铃还须系铃人——要么能彻底「戒瘾」，要么就得从提升收入、普及财商、重构消费观这些更艰难的「基础设施」入手。而这，恐怕比指望BNPL公司不做生意要难太多了。

最后一句忠告：借钱梗要还，咪俾钱中介。

哎，说到底——这世界，真比我预想的还要蠢得多。³

数据来源：CFPB Research Reveals Heavy Buy Now, Pay Later Use Among Borrowers with High Credit Balances and Multiple Pay-in-Four Loans ↩︎
数据来源：Buy now, pay later users pile on debt, CFPB finds ↩︎
封面图片来自：https://www.visa.com.tw/pay-with-visa/featured-technologies/mobile-payments.html ↩︎

机械革命极光 X Pro 简评

Sun, 04 May 2025 23:18:43 +0800

开箱即糟心

对于机械革命极光 X Pro，从下单那一瞬间开始我还有点期待，然而快递没赶上我去香港的行程，等回家拆箱时已经没了新鲜感。想加装硬盘又遇到滑丝的 M.2 螺丝，最后用电工胶布勉强固定，新电脑的好感度当场扣光一半。

配置和价格

i9-14900HX + RTX 5070 Ti，国补后 8699 元的价格还算合理。对于 Peripherals，简而言之，我连神舟都用得很开心，那还有什么是不能用的呢。

屏幕：2560x1600@300Hz，100% SRGB 色域，色准表现不错，玩《天际线 2》时堵车尾灯的红都比现实更鲜艳些。
键盘：键程偏短，手感一般，反正大部分时候都在用外接键盘，对之无感。
无线网卡：AX201 未免太寒酸了，天线设计似乎不太好，在路由器旁边都能明显感觉到速度相比有线严重不足。
硬盘：自带致钛 1TB 速度一般，我自己加的英睿达 2TB 才是主力。
电池：80Wh 的电池对于游戏本来说可以用来应急，平时我都开着工作站模式，延长电池寿命。
独显直连：支持热切换这点好评，再也不用重启切换了。
BIOS：AMI 的 BIOS 比之前的好用太多。

使用体验

《都市：天际线 2》——十二万人口时模拟速度还能保持在 3 倍速，虽然这时候风扇噪音已经起飞了。《赛博朋克 2077》可以开光追超级档，《极限竞速：地平线5》可以开最高画质。但是他们实际上的游戏体验，恕我直言，我感觉不到和之前的 RTX 3060 有什么本质上的区别，无非就是这里的反射更加真实，那里的细节更加丰富。单凭画质上的提升，恐怕我依然不会在这几个已经陪我度过超过一百小时的游戏上再花更多精力。

C 面类肤涂层手感确实好，不过接上外设后基本只摸得到外接键盘。Nahimic 音效延迟严重，关掉之后打 osu! 反而更跟手，属于负优化典型。

工具的意义

这台电脑用了两个星期，没有惊喜，也没有惊吓。无线网卡太垃圾所以只好用有线，狂暴模式风扇噪音很大，南桥没散热所以温度很高，除此之外——它就是台该亮时亮、该响时响的机器。

可能好的工具本该如此：当我写到这里才发现，自己已经盯着屏幕右下角的电池图标发了五分钟呆，而它只是安静地保持着 98% 的电量，像块不会说话的砖。

从入门到进阶：Tailscale + ShellCrash 异地组网和科学上网

Mon, 14 Apr 2025 18:10:25 +0800

在几次旅途中，我试图将新拍的照片上传到长沙家中的 Immich 服务器。过去我用 Cloudflare Tunnel 做反代，但由于国内特殊的网络环境，连接慢速、频繁中断、上传失败几乎成了常态。后来我开始尝试 Tailscale —— 一个基于 WireGuard 的内网穿透工具，它终于让我在全国各地都能稳定、高速地访问家中的 NAS 和照片库。

但新的问题也随之而来：Tailscale 在 Android 手机上运行时，需要作为 VPN 服务接管系统流量，而我平时使用的 Clash 同样依赖 VPN 接口进行分流。由于 Android 系统限制（只能启用一个 VPN 服务），两者无法共存，导致我必须在「访问家中服务」和「科学上网」之间二选一。

这篇文章从 Tailscale 的原理讲起，到自建 DERP 服务器优化连接质量，再到如何用 iptables 劫持 Tailscale Exit Node 的流量并转发给 ShellCrash，实现流量的灵活转发与安全穿透。无论你是想访问家庭局域网上的 NAS、照片库，还是希望在陌生网络中保护自己的数据安全，这篇文章都能为你提供一套实用、稳定的解决方案。

什么是 Tailscale

Tailscale 是一款基于 WireGuard 协议的零配置虚拟局域网工具，它能够让分布在不同网络环境中的设备像处于同一个安全内网中一样互联互通。通过自动穿透 NAT、防火墙等网络障碍，Tailscale 让你无需公网 IP、无需端口转发，也能轻松访问家中的 NAS、个人服务器、开发环境等内网资源。它的核心优势在于简单、安全、稳定，启动即用，数据传输全程加密，适合个人开发者、远程办公者、家庭用户等多种场景使用。

Tailscale 的技术实现非常巧妙：其构建在 WireGuard 加密协议之上，却颠覆了传统 VPN 的 IP 分配逻辑。每个设备通过 SSO/OAuth2 完成身份认证后，会获得一个终身绑定的节点密钥。这种基于身份的组网模式，让「长沙的 NAS」和「香港的手机」在虚拟网络中如同办公室同事般直接对话。

Tailscale 的连接过程原理

中心控制服务器（Control Server）

每个 Tailscale 客户端在启动后，首先会连接控制服务器（controlplane），进行身份验证，并拉取整个网络中其他节点的信息，包括每台设备的公网 IP、端口、NAT 类型等。这一步相当于是「认识朋友」。

Tailscale 的控制服务器不会转发任何数据，只负责协调连接 —— 类似一个调度中心。

DERP 服务器

说到 Tailscale 能保持高连接成功率的关键，就不得不提到 Tailscale 自研的中转协议 DERP，在 Tailscale 的网络架构里，DERP（Designated Encrypted Relay for Packets）是一个很重要但通常只在必要时介入的组件。简单来说，它就是一个基于 HTTP 的加密中继服务器，用来在两台设备无法直接通信时，作为它们之间的「中转站」。

所有客户端之间的连接都是先选择 DERP 模式（中继模式），这意味着连接立即就能建立，用户无需等待。然后连接双方开始并行地进行路径发现，通常几秒钟之后，Tailscale 就能发现一条更优路径，然后将现有连接透明升级（upgrade）过去，变成点对点连接（直连）。¹

需要注意的是：

所有通过 DERP 的数据都是端到端加密的，DERP 服务器无法查看内容；
Tailscale 会尽可能少地使用 DERP，一旦直连建立成功，就会自动切换过去；
官方部署了多个分布式 DERP 节点，客户端会自动选择延迟最低的那个；
你也可以自建 DERP 节点（比如在国内），来解决延迟高或连接不稳定的问题。

可以把 DERP 理解为一个兜底机制，虽然性能不如直连，但确保了即便不能打洞成功，设备之间也始终能保持连接。

NAT 穿透（NAT Traversal）

拿到对端的地址信息后，Tailscale 会尝试通过 NAT 穿透来建立点对点（P2P）连接。这个过程使用了 STUN 协议，双方互相发送探测包，尝试在 NAT 路由器上打出一条直连的通道。如果双方的网络条件允许，就可以成功建立起一个 UDP 的直连隧道，数据走直连，速度快、延迟低。

受制于篇幅，我无法完整细致的讲述 NAT 穿透的原理，若对这部分感兴趣，可以阅读 Tailscale 官方的「How NAT traversal works」一文。

完整连接流程图示

flowchart TD
    A[设备 A 启动 Tailscale] --> B[通过 DERP 服务器建立初始连接]
    B --> C[交换网络信息和 WireGuard 密钥]
    C --> D[双方并行进行 NAT 类型探测]
    D --> E{能否直连？}
    E -- 是 --> F[建立 P2P 直连隧道]
    F --> G[定期检测连接质量]
    G --> H{直连优于 DERP？}
    H -- 是 --> I[切换大部分流量至直连通道]
    H -- 否 --> J[继续通过 DERP 转发部分或全部流量]
    E -- 否 --> J

    style B fill:#e3f2fd,stroke:#2196f3,color:#000
    style F fill:#e8f5e9,stroke:#4caf50,color:#000
    style J fill:#fff3e0,stroke:#ff9800,color:#000

自建 DERP

Tailscale 的安装在各个平台上都相对简单，官方文档已经提供了详细的操作指南。本文将不再赘述安装过程，以下内容默认你已经在相关设备上成功安装并登录了 Tailscale。

为什么要自建 DERP？

Tailscale 在全球部署了众多 DERP ²中继服务器，用于在打洞失败时接管流量中转。但由于众所周知的原因，中国大陆并没有官方部署的 DERP 节点。这意味着：

一旦 NAT 打洞失败，所有流量都必须绕行海外的 DERP 节点，延迟高、速度慢，体验极差；
某些官方 DERP 节点容易被 GFW 干扰，可能出现连接中断、握手失败等问题；
即使打洞成功，Tailscale 仍需通过 DERP 交换路由信息和 WireGuard 密钥，如果 DERP 不可达，连接质量也会受到影响。

因此，在国内网络环境下，自建一个本地 DERP 节点，不仅可以显著提高连接稳定性和传输性能，还能规避部分网络封锁所带来的不可预期问题，是一个非常值得做的优化。

准备工作

前面提到，DERP 是基于 HTTP 的，所以你需要准备好一个 HTTP 反代服务，并自行解决 SSL 证书的签发等基础问题。本文使用 Docker 部署，在部署开始之前，你需要在你的服务器上装好 Docker 以及 Docker Compose 等附加组件。为了编辑配置文件，你当然也得知道如何使用 nano 之类的编辑器。为了最好的效果，你的服务器最好拥有静态公网 IPv4+IPv6 双栈地址。

如果以上条件都具备，就可以开始部署了。

1
2

mkdir tailscale-derp && cd tailscale-derp
nano docker-compose.yml

docker-compose.yml

services:
  derper:
    name: tailscale-derp
    image: fredliang/derper
    environment:
      - DERP_DOMAIN=derp.nightcity.pub
      - DERP_VERIFY_CLIENTS=true
      - DERP_ADDR=:4433
    network_mode: host
    restart: unless-stopped
    volumes:
      - "/var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock"

network_mode: host是一个关键配置，表示容器将共享宿主机的网络栈。如果使用 Docker 默认的 bridge 网络模式，容器的网络会经过 Docker 内网转发，会造成 DERP 的 STUN 服务识别到 Docker 172.17.0.0/16网段下的地址，而无法识别到客户端正确的外网地址，导致 Tailscale 客户端无法正确连接。

1
2

volumes:
  - "/var/run/tailscale/tailscaled.sock:/var/run/tailscale/tailscaled.sock"

前面提到所有通过 DERP 的数据都是端到端加密的，DERP 并不知道是谁在使用，这意味着如果不采取措施，任何知道你 DERP 服务器地址和端口号的人都可以使用它。这条配置的作用是挂载宿主机的 Tailscale 套接字文件到容器内，目的是允许 derper 服务通过 Tailscale 的 tailscaled 服务进行身份验证。配合DERP_VERIFY_CLIENTS=true，可以防止你的 DERP 节点被他人白嫖。

需要注意的是：

宿主机必须已经安装并登陆 Tailscale 客户端（tailscaled），否则这个文件不存在，容器会报错；
tailscaled 必须以 root 权限运行，才能创建这个 sock 文件。

反向代理

以 Caddy 为例，需要反向代理 4433 端口，并为其部署 SSL 证书。

{
        email webmaster@l3zc.com
}

*.l3zc.com {
        encode gzip

        tls {
                dns dnspod APP_ID,APP_KEY
                resolvers 119.29.29.29 223.5.5.5
        }

        @derp host derp.l3zc.com
        reverse_proxy @derp :4433
}

需要注意的是，如果你和我一样使用 Caddy 配合 dnsproviders 申请泛域名证书，Tailscale 的 MagicDNS 可能会导致 Caddy 本地证书验证失败而报错，需要手动指定resolvers参数解决。

访问刚刚反代的节点，如果出现以下页面，说明配置正确。

配置 ACL 策略

打开 Tailscale 控制台的「Access Controls」页面配置 ACL 策略，将配置好的 DERP 加上。

Tailscale 的 ACL 策略是用 HuJSON³ 写的，想要在 VSCode 中编辑，选择语言为「JSON with Comments（jsonc）」即可。以下是一个配置示例：

{
  "acls": [{ "action": "accept", "src": ["*"], "dst": ["*:*"] }],
  "ssh": [
    {
      "action": "check",
      "src": ["autogroup:member"],
      "dst": ["autogroup:self"],
      "users": ["autogroup:nonroot", "root"]
    }
  ],

  // 自建 DERP 配置
  "derpMap": {
    "OmitDefaultRegions": false, // 改为 true 以排除官方 DERP
    "Regions": {
      "900": {
        "RegionID": 900,
        "RegionCode": "sha",
        "RegionName": "Shanghai",
        "Nodes": [
          {
            "Name": "myderp",
            "RegionID": 900,
            "HostName": "derp.l3zc.com"
          }
        ]
      }
    }
  }
}

Tailscale 保留RegionID中的 1-899 作为官方节点，自建节点的 RegionID 必须大于等于 900。

测试连接

配置好 ACL 并保存，Tailscale 会自动为所有客户端同步配置，稍等片刻在客户端用tailscale netcheck测试连接。

需要注意返回的 IP 是否是自己真实的公网 IP，若返回了172.17.0.0/16网段的地址，说明你 Docker 部分配置错了。

与科学上网并存：在 Exit Node 劫持流量到 Clash 内核

声明 Exit Node

在家中准备一个 24 小时开机的设备，可以是树莓派，可以是 MacMini。在上面安装 Tailscale 并将其声明为 Exit Node，并根据需要在 Tailscale 内网声明家庭内网网段，随后在控制台启用这个设备作为 Exit Node，你就获得了一个免费的 VPN，可以让你在陌生的网络环境中保持安全。

`1`	`sudo tailscale up --advertise-exit-node --advertise-routes 192.168.1.0/24`

广播完成后，无论身处何地，只要能连上 Tailscale 网络，就能访问家中所有的内网设备。

启用 IP 转发和禁用 UDP GRO⁴

启用 IP 转发是树莓派等设备作为 Exit Node 所必须的配置，这里以树莓派为例，如果你使用其他设备，请自行查阅 Tailscale 官网教程。

1
2
3

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

根据 Tailscale 官方的说法⁵，禁用 UDP GRO⁶ 可以提升转发性能，但官方的持久化教程似乎在树莓派上无效，好在我们可以手动配置。

# 安装 ethtool
sudo apt update && sudo apt install ethtool -y

# 关闭 UDP GRO
sudo ethtool -K eth0 gro off

针对持久化的问题手动编写 systemd 配置文件：

1
2

# 创建服务文件
sudo nano /etc/systemd/system/ethtool.service

文件内容如下：

[Unit]
Description=Configure eth0 GRO
After=network.target

[Service]
Type=oneshot
ExecStart=/sbin/ethtool -K eth0 gro off

[Install]
WantedBy=multi-user.target

随后启动服务：

1
2
3

sudo systemctl daemon-reload
sudo systemctl enable ethtool
sudo systemctl start ethtool

在 Exit Node 劫持流量

我的 Exit Node 是一台树莓派，在树莓派上配置好 Exit Node 之后就来到了最后一步，也就是劫持手机发送到 Exit Node 上的流量，实现科学上网。出于稳定性原因，我不希望在家庭主路由上直接运行代理软件，为了实现这一点，直接在树莓派上劫持流量是唯一的选择。

首先安装 ShellCrash，请自行根据你的需要导入配置文件、配置自动任务等：

export url='https://fastly.jsdelivr.net/gh/juewuy/ShellCrash@master' && wget -q --no-check-certificate -O /tmp/install.sh $url/install.sh  && bash /tmp/install.sh && source /etc/profile &> /dev/null

随后启动服务，修改修改防火墙运行模式为纯净模式，我个人建议将 SNI 嗅探打开，并将 DNS 模式从fake-ip切换为redir-host⁷，同时启用 IPv6 透明代理。

设置纯净模式的目的是手动配置 iptables 以实现更精准的流量劫持。我们直接用 iptables 劫持所有 tailscale 网卡作为 Exit Node 转发的流量，首先用ifconfig查看 tailscale 网卡的名称，默认情况下一般为 Tailscale 0：

root@raspberrypi:~# ifconfig
eth0: ......

tailscale0: flags=4305<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST>  mtu 1280
        inet 100.111.19.50  netmask 255.255.255.255  destination 100.111.19.50
        inet6 fd7a:115c:a1e0::3d01:1332  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::c0d5:1a1b:2005:48eb  prefixlen 64  scopeid 0x20<link>
        unspec 00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00  txqueuelen 500  (UNSPEC)
        RX packets 6780155  bytes 958732442 (914.3 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 4811113  bytes 10858316472 (10.1 GiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

劫持tailscale0网卡的所有流量到本地 Clash 内核监听端口7892，这个设置在 ShellCrash 中叫做「静态路由端口」。以及，如果你不想和我一样遇到莫名其妙的网络问题，就一定不要忘记劫持 IPv6。

# IPv4 劫持 tailscale0
iptables -t nat -A PREROUTING -i tailscale0 -p tcp -j REDIRECT --to-ports 7892

# IPv6 劫持 tailscale0
ip6tables -t nat -A PREROUTING -i tailscale0 -p tcp -j REDIRECT --to-ports 7892

进阶：用 TProxy 劫持 UDP 流量

iptables 的 REDIRECT 只能重定向 TCP 流量，UDP 没有连接状态（无连接协议），所以 REDIRECT 无法保留目标地址，导致透明代理无法知道原始目标地址。

所以，如果你用如下方式劫持 UDP 流量：

`1`	`iptables -t nat -A PREROUTING -i tailscale0 -p udp -j REDIRECT --to-ports 7892`

则这个规则不会生效或代理行为不正常。

那么，有办法代理 UDP 流量吗？有的兄弟，有的。但前提是：

核心支持 UDP 透明代理（Clash Premium 和 Mihomo 都支持）；
使用 TProxy 模式，而不是 REDIRECT；
正确配置了 iptables mangle 表和 policy routing；
代理配置文件中启用了 UDP 代理（如 mode: rule + udp: true）。

假设你已经满足第一条、第二条和最后一条，则以下是一个示例⁸：

# 创建自定义链
sudo iptables -t mangle -N SHELLCRASH

# 根据自己的需要忽略本地流量
sudo iptables -t mangle -A SHELLCRASH -d 127.0.0.1/8 -j RETURN
sudo iptables -t mangle -A SHELLCRASH -d 100.64.0.0/10 -j RETURN
sudo iptables -t mangle -A SHELLCRASH -d 192.168.1.0/24 -j RETURN
sudo iptables -t mangle -A SHELLCRASH -d 172.17.0.0/16 -j RETURN

# mark UDP 和 TCP 到代理
sudo iptables -t mangle -A SHELLCRASH -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
sudo iptables -t mangle -A SHELLCRASH -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# 接口跳转
sudo iptables -t mangle -A PREROUTING -i tailscale0 -j SHELLCRASH

# 路由表配置
echo "233 shellcrash" | sudo tee -a /etc/iproute2/rt_tables
sudo ip rule add fwmark 233 lookup shellcrash
sudo ip route add local 0.0.0.0/0 dev lo table shellcrash

当然，不要忘记 IPv6：

# 创建链
sudo ip6tables -t mangle -N SHELLCRASH6

# 跳过本地地址
sudo ip6tables -t mangle -A SHELLCRASH6 -d ::1/128 -j RETURN
sudo ip6tables -t mangle -A SHELLCRASH6 -d fd7a:115c:a1e0::/48 -j RETURN

# 标记 TCP/UDP
ip6tables -t mangle -A SHELLCRASH6 -i tailscale0 -p tcp -j TPROXY --on-port 7893 --tproxy-mark 233
ip6tables -t mangle -A SHELLCRASH6 -i tailscale0 -p udp -j TPROXY --on-port 7893 --tproxy-mark 233

# 接口跳转
sudo ip6tables -t mangle -A PREROUTING -i tailscale0 -j SHELLCRASH6

# 路由表配置
echo "233 shellcrash" | sudo tee -a /etc/iproute2/rt_tables
sudo ip -6 rule add fwmark 233 lookup shellcrash
sudo ip -6 route add local ::/0 dev lo table shellcrash

路由规则持久化

ip rule和ip route创建的规则在重启后会丢失，所以需要我们手动持久化，最简单直接的方法就是创建一个脚本，并将其添加至 crontab。

创建一个脚本：

`1`	`sudo nano /usr/local/bin/policy-route.sh`

编辑为如下内容：

#!/bin/bash

# IPv4 策略路由
ip rule add fwmark 233 lookup 233
ip route add local 0.0.0.0/0 dev lo table 233

# IPv6 策略路由
ip -6 rule add fwmark 233 lookup 233
ip -6 route add local ::/0 dev lo table 233

授予执行权限后编辑 Crontab：

1
2

sudo chmod +x /usr/local/bin/policy-route.sh
sudo crontab -e

在 crontab 文件底部加上如下内容：

`1`	`@reboot /usr/local/bin/policy-route.sh`

原理解释：TProxy 到底是怎么转发 UDP 流量的？

如果你看到这里，也许会产生疑惑：为什么整个流程中，我们没有在 iptables 里写--to-ports，也没看到目标地址被改写，UDP 流量就莫名其妙地被代理了？这是怎么做到的？

要解释这个问题，我们先来看 TProxy 和 REDIRECT 的根本区别：

REDIRECT 模式：

使用 iptables nat 表；
将目标地址改写为本地地址（比如 127.0.0.1:7892）；
通常用于 TCP 流量；
不能保留真实目标地址；
需要指定--to-ports。

flowchart TB
    A[客户端设备
通过 Tailscale 发起 TCP 请求]
    B[tailscale0 接口接收流量]
    C[iptables NAT PREROUTING
REDIRECT --to-ports 7892]
    D[ShellCrash 本地监听
127.0.0.1:7892]
    E[ShellCrash 发起新 TCP 请求
→ 目标服务器]
    F[响应从网络返回
ShellCrash 转发响应]
    G[响应回到客户端设备]

    A --> B --> C --> D --> E --> F --> G

    style C fill:#f9f,stroke:#aaa,stroke-width:1px,color:#000
    style D fill:#bbf,stroke:#aaa,stroke-width:1px,color:#000

TPROXY 模式：

使用 iptables mangle 表；
不修改目标 IP，而是保留原始目标地址；
通过 fwmark 和 policy routing 将报文路由到 lo；
代理程序监听一个特殊端口（例如 7893），并启用 IP_TRANSPARENT；
支持 UDP 和 TCP；
不需要 iptables 内指定 --to-ports，因为不是 NAT，而是标记 + 路由。

flowchart TB
    A[客户端设备
通过 Tailscale 发起 TCP/UDP 请求]
    B[tailscale0 接口接收流量]
    C[iptables MANGLE PREROUTING
打上 fwmark 233]
    D[ip rule: fwmark 233
使用 routing table shellcrash]
    E[ip route: local 0.0.0.0/0
dev lo table shellcrash]
    F[ShellCrash 在 lo:7893 监听
IP_TRANSPARENT 模式]
    G[ShellCrash 获取原始目标地址
发起代理连接]
    H[响应从网络返回
ShellCrash 转发响应]
    I[响应回到客户端设备]

    A --> B --> C --> D --> E --> F --> G --> H --> I

    style C fill:#f9f,stroke:#aaa,stroke-width:1px,color:#000
    style F fill:#bbf,stroke:#aaa,stroke-width:1px,color:#000

TProxy 不使用 DNAT/REDIRECT，而是通过 mangle 表给数据包打上 mark，然后通过 policy routing（ip rule + ip route）将这些数据包送到 lo 接口。代理程序（如 Clash / ShellCrash）监听在 lo⁹ 上的端口（例如 7893），通过启用 IP_TRANSPARENT 选项，可以读取数据包的原始目标 IP 和端口并进行代理转发。

简而言之，TProxy 模式只需要：

iptables 给数据包打上 mark；
ip rule + ip route 将这些包送到 lo；
程序监听 lo 上的端口并开启 IP_TRANSPARENT。

所以不需要在 iptables 中指定 --to-ports，因为目标 IP 和端口保持不变，代理程序自己可以感知并处理。

iptables 规则持久化

安装iptables-persistent：

1
2

sudo apt update
sudo apt install iptables-persistent

安装过程中会提示你是否保存当前的 IPv4 和 IPv6 配置，选择「是」即可。之后如果你添加了新的规则，记得执行保存命令：

1
2

# 保存当前 IPv4/IPv6 规则
sudo netfilter-persistent save

保存后的规则文件路径：

IPv4：/etc/iptables/rules.v4
IPv6：/etc/iptables/rules.v6

你也可以直接编辑上面的rules.v4/rules.v6文件，按需修改。

最终效果

这套方案的使用体验取决于你家的上行带宽，我家的网络是下行 500M 上行 60M，目前没有遇到一次打洞失败的情况，所以基本都能跑满，延迟也尚可接受，并且可以在外地随时随地端到端加密访问家中的 Immich 和 OpenWRT 路由器等设备以及实现科学上网，总体来看，我还算比较满意。

参考: https://icloudnative.io/posts/custom-derp-servers/ ↩︎
参考: https://tailscale.com/kb/1232/derp-servers ↩︎
有关 HuJSON: https://github.com/tailscale/hujson ↩︎
参考： https://tailscale.com/kb/1408/quick-guide-exit-nodes ↩︎
参考: https://tailscale.com/kb/1320/performance-best-practices#linux-optimizations-for-subnet-routers-and-exit-nodes ↩︎
UDP GRO（Generic Receive Offload）是 Linux 内核中的一种网络优化技术，主要用于合并多个小数据包以提高处理效率。但在设备作为网络转发节点的使用场景下，这可能会导致转发延迟增加和高丢包率环境下的吞吐量下降。 ↩︎
相较于fake-ip，redir-host兼容性更好，出现问题的概率更低，也不会出现开关代理之后短时间内因为fake-ip残留而断网的情况，所以一般情况下我建议使用redir-host搭配 GeoSite 分流规则使用。我这台树莓派的 DNS 上游是已经配置好的 SmartDNS，不存在 DNS 污染的问题，体验良好。 ↩︎
参考: https://blog.zonowry.com/posts/clash_iptables_tproxy/ ↩︎
lo 是 Linux 系统中默认的「回环接口（Loopback Interface）」，在透明代理中，它不仅处理 localhost 流量，还被用来接收原本属于外部世界的网络连接，实现对外部流量的本地劫持和转发。 ↩︎

永恒的选择困难症：那些年我用过的机场

Sat, 05 Apr 2025 20:18:50 +0800

前言

文章中提及的部分服务商链接为推广链接 (AFF)，如果您通过这些链接购买，我会获得机场的一些余额。这不仅不会增加你的购买价格，还能帮助我节省开支，感谢大家的支持。

任何机场都有跑路风险，即使是运营数年甚至十余年的老机场也是如此，请大家在条件允许的情况下尽量月付，保留自己随时更换机场的权利，同时也尽量降低机场潜在的跑路风险。

提笔写下这篇，本意并非机场评测，而是记录一下这些年在数字世界里「穿梭」的经历。作为一个坐标中部的联通用户，这是我的主观和充满个人色彩的体验。许多人们曾经耳熟能详的「机场」也早已成为时代的眼泪，权当一篇个人的杂谈与回忆录吧。

启蒙时代：从脚本小子到「合租客」

我的故事始于初中时代。那时的网络环境，与今天相比简直恍如隔世。工信部刚提及要严查VPN，应用商店里免费的梯子还能随处下载。当时的我，在 GitHub 上摸索着学会了用一键脚本搭建SSR，服务器则是被 AFFMan 忽悠买的 Vultr。

如今回想，我已经记不清当初为何执着于「出海」——是为了学英语？满足青春期的好奇？还是沉迷于刷机玩机？原因早已模糊，但结果却异常清晰：我就这样踏上了一条「不归路」。那是一个言论相对宽松的年代，QQ 空间可以分享蔡英文胜选的 Facebook 截图，网络上流传着各种习近平的表情包，新闻远没有今天这般「清朗」，连QQ群里都能公开讨论哪里能看片。

初中的我，课余生活乏善可陈，唯一的娱乐就是摆弄家里那台破旧的电脑。也正是在那时，我一头扎进了桌面 Linux 的世界，从 Ubuntu 到当年的国产之光 Deepin。在几个 Linux 交流 QQ 群里，我顶着随时可能被没收手机的风险潜水，也就是在这段时间，我逐渐在网上了解到「机场」这种合租节点的模式，从此开始放飞自我。

付费之旅：在跑路与妥协中寻找最优解

心阶云：最早的付费体验

心阶云是我第一个付费的机场。大概在2017年，它刚开业两年，两百多元一年的价格在当时已属中高端。然而，体验并不算愉快。虽说是中转线路，却需要频繁地手动切换节点，速度时好时坏，有时不更新订阅就无法使用。一年后，我将它降级为一个几十块的年付套餐，正式开启了我的「主备搭配」时代。后来它改名「自由鲸」，20%的推广返利也让我拉了一位同学入坑，这份返现进一步拉低了我的持有成本，让它稳坐「备胎」之位，直到2023年跑路。

忍者云：忍者云，忍着用

忍者云是我在用过心阶云之后入手的。不知现今状态怎么样，但当年的忍者云落地质量堪忧，给我印象最深刻的是当时香港节点用的是AWS，刷推都会被风控，这点甚至不如上面的心阶云。核心的使用体验——速度和稳定性也对不起它不打折时超过四百一年的售价，好在流量给得多，显得性价比不那么寒碜。如今它竟也运营了七八年，实属不易，但估计还是老样子——落地不行，稳定性欠佳。

长沙黄花国际机场

第一次送人，从停车场出来有个隐蔽的红绿灯没看到，直接扣 6 分罚 200，差评。不是航空枢纽，不算繁忙，其他尚可。

速蛙云：广告打得震天响

速蛙云是我心中一段短暂的为一真神。当时它在 YouTube、Google 上铺天盖地地投放广告，手笔之大令人咋舌。但不得不承认，产品力确实惊人：晚高峰8K视频随意拖动，连接稳定如初，落地 IP 质量出奇地好，注册 Google 和 Twitter 账号畅通无阻，完全不会出现注册即风控的情况。这是我第一次真切感到「这笔钱花得值」。

不仅如此，速蛙云还附赠共享 PornHub、Netflix 会员和 Shadowrocket 账号，节点覆盖全球，连冰岛这种小众地区都有。然而好景不长，在我购入后不久，它便和花卷爆发争端，随即在收割一波新用户后跑路。如今回想，速蛙云的商业模式本就是个谜：一边是巨额的广告投入，一边是昂贵的线路和丰富的福利，价格却不算离谱。或许从一开始，它的结局就已注定。

FlowerCloud、YTOO、WgetCloud 和 Amytelecom：高端机场的同质化困境

FlowerCloud 是我在速蛙云跑路后买的，这几年兜兜转转又回到了它。初体验不错，线路飞快。但很快发现，大部分节点都用了 Kirino 和 Eons 的落地（毕竟大家都用他们），加上用的人多，IP 质量自然好不到哪里去，之前浏览 E-Hentai 经常被反爬限制，注册各类账号更是奢望。半年 218 元、每月 150G 的价格，即使算上折扣也不便宜，不过好在线路扎实，冗余足够，稳定性很好，带宽大，延迟低，起速快，日常上网冲浪体验还是相当不错的。小众地区节点很多，但似乎存在被人拿来当爬虫代理池的情况，导致小众地区节点的 IP 也不那么干净，实测下来该限制的依旧限制，该屏蔽的照样屏蔽，最终这些小众地区节点能起到的作用无非就是让你的 IP 属地更加酷炫而已。总的来说，它是一家好机场，可惜未能解决大机场普遍都有的落地IP太脏的问题。

YTOO 和花云给我的感觉：「非常像，特别像，说他们是同一个老板我都信」。

GaCloud （现在似乎叫做 WgetCloud）也类似，价格一路从39元/月涨到近60元/月，速度和稳定性都是这个价位应有的水准，但除此之外，他就是一个什么都不差，但也没什么特别突出的特点的机场。也正是这个价格给其带来了尴尬的定位：贵过大部分机场，但也没什么亮点，在其涨价之后我很难再有购买的动力。

AmyTelecom 被称为「奶昔青春版」，线路质量和稳定性都很好，审计规则比 CNIX 宽松不少。注册需要手机号验证，线路和奶昔本站相仿，价格相比奶昔动辄一千多的年付套餐来说亲民不少。但它同样面临着落地 IP 质量不佳的问题，导致用户体验始终难以令人满意。

这些机场用下来，体验上其实都差不太多，实际上这些年来自从运营商开始对跨省流量进行 QoS，那些价格相对便宜的中转机场就因为中转成本飙升而基本消失了，能活下来的机场大多都采用相似的线路方案，比如香港专线加上 Kirino 或者其他类似的落地服务商，导致这些机场的落地 IP 质量都大同小异。高端机场实际上体验都大差不差，价格也相仿，唯一的区别大概就是运营风格和广告投放的力度了。它们都面临着同样的困境：在追求高端用户的同时，却无法解决落地 IP 质量的问题，导致用户体验始终难以达到预期。

香港赤鱲角国际机场

很棒的机场。我去的那年还只有两条跑道，无障碍设施完善，WiFi 给力，还有免费公用电脑。唯一的遗憾是当时正值埃博拉疫情，循环播放的防疫广播有些破坏心情。后来国泰砍掉港龙航空，长沙再无直飞航班，只能改坐高铁了。

桂林两江国际机场

这个真不太行。我去的时候设施老旧，离市区远，接驳交通一塌糊涂。海关人员的态度也一言难尽，不知还想不想做世界级旅游城市了。

CNIX、WestData、两元店、Crush 和星岛梦：在细分市场里寻找特色

厌倦了高端机场的同质化，我开始探索一些更具特色的选择。

CNIX（似乎也叫做薯条）感觉他们技术不错，当年合租香港家宽起步，后来靠着唯云莞港专线实惠的价格一战成神。目前的价格也相对实惠，￥239/年给 2.5TB 流量，对我来说完全够用。节点看似繁多，实则都走同一条带宽非常大的香港专线，稳定性因此还不错。最神奇的是，明明用户众多，浏览 E-Hentai 却很少触及基于 IP 的图片数量加载限制，只是不知为何图片加载速度会略慢。它的缺点也同样突出：繁琐到令人发指的审计规则，以及「女装白丝的运维 JK 裙边料盖住了进风口导致交换机关机」这种鬼畜运营风格，想知道真实的故障原因那就别想了。

WestData 则又是没事看毒药评测找到的，当时用着感觉不怎么样。现在听说已经成了「二线机场第一梯队」，对此我深表怀疑，反正不会再买了。

两元店 两元店是朋友推荐的极致性价比之选。年付22元的直连套餐，买不了吃亏上当。节点基本上是 AWS、Oracle 等月抛机，成本低廉，但速度尚可，稳定性甚至优于某些中转。卢森堡节点似乎还能下载 BT，审计规则宽松，甚至可以转发矿池流量。在这个价位，它就是「要啥自行车」的典范。这种便宜机场日常使用其实是不建议的，不仅直连线路不够稳定（尤其是电信和移动），而且月抛机的 IP 质量也不敢恭维，但买来玩玩，拿来干些脏活（比如我提到的转发矿池、下载 BT），或者偶尔体验一下「丐中丐」的节点质量，倒也挺有意思。

Crush Crush 则是我为应对日益频繁的入口封锁而找到的一家仅支持 IPv6 的机场，联通网络下体验极佳，新开的机场 IP 相对干净，价格也因 IPv6 入口的低成本而做到每月 4 元 150G。当然，这也注定了它无法成为我的主力，只能在有 IPv6 的环境下发光发热。

星岛梦 星岛梦是一家 2025 年 12 月刚开业的机场，机场主在测试的时候就来找我了，我因此有幸从早期测试阶段便开始关注，见证了它如何从最初的摸索，经过机场主熬夜修线路换落地，现在终于达到了可以日用的水准，希望机场主能继续进步。性价比算上日常的打折还是挺划算的，也许我该考虑把他当做主力用了。

光速云 光速云在线路和落地方面给我的感觉和前面的星岛梦差不多，延迟很不错，入口根据运营商自动解析，但是套餐价格更加便宜。最便宜的 59G/月的年付套餐原价￥99/年，算上日常的打折优惠以后非常适合小流量备用。

极连云 其实星岛梦、光速云、极连云这三家机场使用起来都差不多。落地方面目前我使用起来发现香港节点 Google 需要过 Captcha（只需点击一下即可，不需要选图片），其他的一切正常，具体解锁情况如图：

尝鲜或者日用直接按照自己实际的期望价位选择三家中的其中一家即可。

雅加达苏加诺-哈达国际机场 & 日惹古冷柏格国际机场

对于雅加达机场我没什么特别感觉，回国的时候吃了个和市区同价的 KFC，环境稍脏。而日惹机场中国游客很多，有中文标识，但国内航班基本没有廊橋，只能晒晒太阳更健康了。

治愈「心病」的唯一方法

回顾这趟漫长的「机场漫游」，我发现自己陷入了一个有趣的循环：总是在追求那个完美的「最优解」，却又忍不住被下一个「可能性」所吸引。从最初追求稳定，到后来迷恋大流量，再到对 IP 质量的挑剔……我的需求在不断变化，而市场上，不论是哪个产品，却似乎总会在某些方面不尽如人意，让我每次都不停的换来换去。有时想要节省一些代理开支，可是用着用着发现新鲜的机场，总是忍不住去买个来试试——刚买回来新鲜感十足，每次都觉得这次终于找到了「真爱」，结果用没多久，又开始怀疑人生，觉得哪里不对劲了，又想去换，最后是买了几个机场，计算下来平均每年的花费比高端机场的套餐还要高。

这种永不满足的「心病」，让我积累了一堆小流量套餐，手动管理它们成了一件苦差事。我意识到，市面上现有的工具，已经无法完美安放我那颗爱折腾的心了。它们或者功能不足，或者设计哲学与我的需求相悖。

于是，一个念头逐渐清晰：与其继续寻找，不如亲手创造。

尽管最近很忙，我仍然计划打造一个全新的、更智能的订阅管理工具。它并非要颠覆什么，而是想为像我一样，拥有多个服务来源、追求极致个性化定制的用户，提供一个更优雅、更强大的解决方案。

这不会是一个一蹴而就的项目，更像是我技术探索路上的一个新里程碑。我不确定它最终会走向何方，但我确信，创造的过程，本身就是治愈「心病」的最好良药。这段经历让我明白，当消费和体验无法带来最终满足时，或许只有一头扎进这个领域，让自己的「心病」反过来发光发热，当心病变成了热爱，或许才是治愈的开始吧。

Google Play 商店的国内 CDN：从密码学入门到分流策略优化

Sat, 15 Mar 2025 21:15:01 +0800

改用自己的 Mihomo 覆写规则后，手机从 Google Play 上下载应用就会一直转圈圈，而换用机场的规则就没问题，非常奇怪。遂调取 Mihomo 内核日志查看。

play-lh.googleusercontent.com:443 match RuleSet(cdn_domainset) using 静态资源[🇭🇰 香港 07]
play.googleapis.com:443 match GeoSite(GFW) using 节点选择[🇭🇰 香港 07]
play-lh.googleusercontent.com:443 match RuleSet(cdn_domainset) using 静态资源[🇭🇰 香港 07]
play-fe.googleapis.com:443 match GeoSite(GFW) using 节点选择[🇭🇰 香港 07]
services.googleapis.cn:443 match GeoSite(CN) using 全球直连[DIRECT]

（以上日志已精简）

国行手机内置的 Google Play 服务使用services.googleapis.cn而非services.googleapis.com域名提供服务，而这个域名在大多数分流规则中都是直连，对，问题就出在这里，修改规则把这个域名分流到代理就万事大吉了！

……万事大吉了，吗？

1
2
3

rr4---sn-j5o7dn7s.xn--ngstr-lra8j.com:443 match Match using 漏网之鱼[🇭🇰 香港 07]
rr2---sn-j5o7dn7s.xn--ngstr-lra8j.com:443 match Match using 漏网之鱼[🇭🇰 香港 07]
rr1---sn-j5o76n7z.xn--ngstr-lra8j.com:443 match Match using 漏网之鱼[🇭🇰 香港 07]

等等，为什么每次从 Play 商店下载应用都会出现这些奇怪的域名？在网上查找一番资料后，新世界的大门就此打开。

与 Google 截然相反却又异曲同工的 Ångströ

看到 xn–ngstr-lra8j.com，熟悉域名的同学肯定知道，这是 PunyCode 编码，这串字符解码后就是 ångströ.com。Anders Jonas Ångström 是一位瑞典物理学家，他是光谱学的奠基人。¹埃斯特朗（Ångström）是为纪念他而以他的名字命名的长度单位，$ 1 Å = 10^{-10} m = \frac{1}{10} nm $，通常用于描述非常短的距离，比如原子和分子尺寸或光的波长。其代表极端小的量级，尤其是在物理学和化学中用于精细测量。

虽然 Google 的名字并不是直接取自「Googol」，但是它的灵感来源于该词。「Googol」是一个数学术语，表达$10^{100}$，即1后面跟着100个零，是一个极其庞大的数字，常用来表示计算机科学中涉及的巨大数字或信息量。

在命名哲学上，Google 与Ångströ 这对看似分处光谱两端的科技概念，却展现出耐人寻味的对称美学。前者源于数学概念「Googol」的创造性改写，后者则脱胎于物理单位「Ångström」的意象重构。这两个经过艺术化变奏的称谓，恰似科技文明的双螺旋：Google 之称承载着驾驭浩如星海的数字宇宙的雄心，Ångströ 之谓则暗喻着雕琢精微的原子级技术图景。当这两个经过创造性变形的专业术语在硅谷相遇，恰好构成了一组完美的认知坐标——既指向人类处理信息的尺度极限，也昭示着科技文明同时向宏观与微观进军的壮阔征程。

入门密码学：Google 基础设施域名的规律²

OK，enough。现在让我们把视角转回 Google 的基础设施。先来看一些完整的连接域名：

1
2
3

rr4---sn-j5o7dn7s.xn--ngstr-lra8j.com
rr1---sn-j5o76n7z.xn--ngstr-lra8j.com
rr5---sn-i3b7knzs.xn--ngstr-lra8j.com

这些看似随机的字符串，实际上是经过一些简单的密码学加密后的结果。让我们拆解其中的核心部件。

城市名称的转换规则

以rr1---sn-j5o76n7z为例，关键的信息段在sn-后面的 8 位：r1---sn-[123][45][6][78]。前三位，也就是本例中的j5o是城市名称，由该城市主要机场的 IATA 码通过一定的密码学变换转换而来。

首先构建一张 5 * 7 的数字字母表：

行0: 1 0 2 3 4
行1: 5 6 7 8 9
行2: a b c d e
行3: f g h i j
行4: k l m n o
行5: p q r s t
行6: u v w x y

逆时针旋转这张表，即从新表格的左下角开始，依次按照原表格「从左到右，从上到下」的顺序，把原表的数据在新表上按照「从下到上，从左到右」的顺序誊抄。

旋转完成后，可以得到下表：

| 6 d k r y |
| --------- |
| 5 c j q x |
| 4 b i p w |
| 3 a h o v |
| 2 9 g n u |
| 0 8 f m t |
| --------- |
| 1 7 e l s |

表格中间用线条框出来的 5*5 的部分就是最终的密码表，一共有 25 个字符，「从左到右，从上到下」依次代表字母a到字母y。例如，上海虹桥国际机场的 IATA 代码为sha,我们可以通过这张表得到加密后的密文：

s在字母表中是第 19 个字母，「从左到右，从上到下」依次在密码表中数到第 19 个字符，也就是n
h在字母表中是第 8 个字母，「从左到右，从上到下」依次在密码表中数到第 8 个字符，也就是i
a在字母表中是第 1 个字母，「从左到右，从上到下」依次在密码表中数到第 1 个字符，也就是5

加密后的密文就是ni5。

反之亦然，回到一开始的城市名称j5o，从我们刚刚得到的密码表中反推出原文：

j按照「从左到右，从上到下」的顺序是第 3 个字符，也就是c
5按照「从左到右，从上到下」的顺序是第 1 个字符，也就是a
o按照「从左到右，从上到下」的顺序是第 14 个字母，也就是n

翻译完成的明文是can，也就是广州白云国际机场的 IATA 码，显然，我们连接到的服务器位于广州。

要是谷歌有某个服务器位于苏黎世，而苏黎世机场的 IATA 码是zrh，有一个字母z，可是我们的密码表只有a到y啊？别担心，Google 当然也考虑到了这个问题，z对应密码表中的1。

将这套规则用代码表示如下：

table = "5cjqx4bipw3ahov29gnu08fmt1"
def iata2cipher(iata):
    global table
    iata = iata.upper()
    cipher = ""
    for element in iata:
        index = ord(element) - 65
        cipher += table[index]
    return cipher

def cipher2iata(cipher):
    global table
    cipher = cipher.lower()
    iata = ""
    for element in cipher:
        index = table.find(element)
        iata += chr(65 + index)
    return iata

# print(iata2cipher(input("IATA:")))
# print(cipher2iata(input("Cipher:")))

服务器组编号

[45]和[78]位，如76和7z，表示服务器组（接入点）编号，由下表第一列（已经用分隔线隔开）包含的字符组成，7elsz6dkry分别代表0123456789。所以，76的明文是05，7z的明文是04。

  | 1 2 3 4 5 6
7 | 8 9 a b c d
e | f g h i j k
l | m n o p q r
s | t u v w x y
z | 0 1 2 3 4 5
6 | 7 8 9 a b c
d | e f g h i j
k | l m n o p q
r | s t u v w x
y | z

以 Python 表示如下：

codeTable = "7elsz6dkry"
def cipher2code(cipher):
    global codeTable
    cipher = cipher.lower()
    codeString = ""
    for element in cipher:
        index = codeTable.find(element)
        codeString += chr(index + 48)
    return codeString

# print(cipher2code(input("Cipher:")))

同样要将数字加密为密文同理，这里不再赘述。

支持协议

[6]位表示网络协议信息：

n：IPv6（地址段 0x000-0x3FF）
u：IPv6（地址段 0x400-0x7FF）
m：仅支持 IPv4

例如：

a5mekn7r，IPv6 前缀：2607:f8b0:4007:a::/64，IPv4 前缀：74.125.103.0/24
a5m7zu7r，IPv6 前缀：2607:f8b0:4007:407::/64，IPv4 前缀：74.125.215.0/24
a5mekm76，仅支持 IPv4，前缀：208.117.242.0/24

正确的分流处理

⚠️ 警告

Google 显然不会为这些位于中国大陆的，未经 ICP 备案的 CDN 的稳定性和速度背书。如果流量足够，那还是直接将services.googleapis.cn加入代理列表吧。

了解了 Google 基础设施域名的加密规律后，我们可以根据这些信息实现更精准的分流策略。目前已知 Google 在中国大陆的 CDN 节点主要分布在北京（2x3）、上海（ni5）和广州（j5o），对应的域名特征可以通过正则表达式识别：

1
2

rules:
  - DOMAIN-REGEX,^r+[0-9]+(---|\.)sn-(2x3|ni5|j5o)\w{5}\.xn--ngstr-lra8j\.com$,DIRECT

这条规则会匹配所有形如 rr1---sn-j5o76n7z.xn--ngstr-lra8j.com 的国内 CDN 域名，并将其标记为直连。而对于其他未被覆盖的 Google 域名（如 play.googleapis.com 等），仍遵循原有的代理规则。

事实上，GeoSite 数据库的上游 v2fly/domain-list-community 已针对 Google Play 的国内 CDN 节点进行了优化³。只需在 Mihomo 配置中启用 GEOSITE,GOOGLE-PLAY@CN 规则，即可自动实现国内 CDN 直连与海外域名代理的智能分流：

1
2
3

rules:
  - GEOSITE,GOOGLE-PLAY@CN,直连
  - GEOSITE,GOOGLE,代理

亂筆