亂筆

理解《互聯網信息服務管理辦法（修訂草案徵求意見稿）》——針對翻牆的一刀切要來了嗎？

Sun, 05 Jul 2026 13:44:28 +0000

近期網信辦對《互聯網信息服務管理辦法（修訂草案徵求意見稿）》（以下簡稱《辦法》）再次公開徵求意見¹，稿件內部分修訂的條文引起了很多人的擔憂——尤其是涉及「穿透、繞過技術措施」和「被依法阻斷的信息」等表述，一時間「翻牆徹底違法」「一刀切要來了」的聲音甚囂塵上。

網上幾乎每年都能見到所謂「一刀切」、「白名單」的討論，如果不能體會這種論調的市場有多大，看看前幾年「禁止相關個人數據出境」的條文在當時是如何被解讀的就知道了。那好，我們就來看看這次的《辦法》到底是一般的技術性修法還是真的所謂「管控升級」。

第二十六條：明確規定「翻牆」違法？

第二十六條 任何組織和個人不得實施下列行為，擾亂互聯網信息服務秩序：

（一）實施信息發佈、刪除、屏蔽、斷開鏈接、替換、下沉、算法推薦等行為，或者為他人提供信息發佈、刪除、屏蔽、斷開鏈接、替換、下沉、算法推薦等服務；

（二）虛假註冊或者批量註冊互聯網賬號、非法囤積或者非法交易互聯網賬號；

（三）操縱、利用多個互聯網賬號批量發佈含有法律、行政法規禁止內容的信息和不良信息，從事虛假點擊、投票、榜單、排行、評論、交易、評價等活動，實施流量造假、流量劫持，製造虛假輿論熱點，操控榜單、熱搜等重點環節等；

（四）實施違法穿透、繞過國家有關機構技術措施的活動；

（五）法律、行政法規禁止的其他行為。

互聯網信息服務提供者應當採取異常數據監測、人工複審複核等措施，加強對前款規定行為的預防和監測。

乍一看確實很嚇人，這不就是明確規定翻牆違法了嗎？法律法規的訂立往往需要嚴格的咬文嚼字，每一條法律條文幾乎都經過反覆的推敲和字句斟酌，再讀一遍這一句：

實施違法穿透、繞過國家有關機構技術措施的活動

「違法」是定語，修飾「穿透、繞過國家有關機構技術措施的活動」這個行為。意思是：不是所有穿透、繞過都被禁止，只有「違法的」穿透、繞過才被禁止。

何謂「違法」

那什麼是「違法」呢？

全國人大法工委的《立法技術規範》對「違法」的概念有明確的界定：「違法」一般用於違反法律強制性規範的行為²。換言之，要判定一個行為「違法」，必須存在一條明確的法律強制性規範被違反——不能憑空認定。以下是這份規範給出的參考用例：

示例一：被檢查單位或者個人拒不停止違法行為,造成嚴重水土流失的,報經水行政主管部門批准,可以查封、扣押實施違法行為的工具及施工機械、設備等。（水土保持法第四十三條）
示例二：村民委員會不及時公佈應當公佈的事項或者公佈的事項不真實的,村民有權向鄉、民族鄉、鎮的人民政府或者縣級人民政府及其有關主管部門反映,有關人民政府或者主管部門應當負責調查核實,責令依法公佈;經查證確有違法行為的,有關人員應當依法承擔責任。（村民委員會組織法第三十一條）

如果依然不能理解，可以對比看看「非法」，《立法技術規範》對「非法」的說明是：「非法」通常情況下也是違法，但主要強調缺乏法律依據的行為。什麼意思呢？當然不是指「找不到允許你做的法律條文」，而是指：這類行為本來依法必須有某種依據、許可、資格、授權或合法來源，但行為人沒有。例如「非法行醫」——你本來應該要有執業醫師資格證的，但你沒有，所以你是非法行醫。同樣的結構，如果換成「違法行醫」，那聽起來就像是你有執業醫師資格證，但是行醫的方式錯了，這種表達也不太常用。

用語	焦點	隱含意思
非法行醫	你根本沒有醫師資格	你不該行醫
違法行醫	（不太常用）暗示有資格但違規操作	你行醫方式不對
非法持有槍支	你沒有合法持有依據	你不該有這東西
非法拘禁	你沒有法定權力拘禁他人	你無權這麼做
違法穿透	已有相關法律和行政命令明令禁止「穿透」	有個法律、禁令在那裡，你違反了

從這份技術規範及其用例可以看出，要判定一個行為是否「違法」，需要有明確的前置法律依據。問題是，你上哪裡去找這樣一個前置法律依據呢？眾所周知，GFW 阻斷 Google、YouTube、Twitter 等網站，但這種阻斷從來沒有對應的法院命令、簽署後的行政文件，甚至連一份非正式的官方封鎖列表都沒有³。法外狂徒張三自行搭建 ShadowSocks 服務器並且用來訪問 Google、YouTube、Twitter 等網站，首先其並未構成法規適用的前提——擾亂互聯網信息服務秩序，其次亦沒有任何法規和行政文件明確封鎖或者禁止訪問這些網站，因此，在單純的法律意義上，張三是不「違法」的。

也就是說，第二十六條第（四）項對張三並不適用——因為他的行為不滿足「違法」這一前置要件。

這條法規主要針對誰

這條是和以下行為並列的：

操縱信息發佈/刪除/算法推薦
批量虛假註冊賬號
刷量、刷榜、假流量、假輿情
違法穿透、繞過國家有關機構技術措施
其他

前三項打擊的對象比較清楚，無非就是黑產、水軍、SEO/GEO操控。第（四）項和它們並列，語境上暗示它針對的也是有組織的、商業化的、擾亂信息服務秩序的行為，而不是張三在家上個 Google Scholar 查論文。

可能的打擊對象：

商業機場、VPN 服務（未經許可經營電信業務和穿透技術措施，這個在以前以加速器的名義處在灰色地帶，現在理論上也可以）
用翻牆工具做境外輿論操控、跨境詐騙、賭博引流的
幫助已被依法關停的網站通過技術手段復活的
突破政府、企業的內網、專網等網絡的安全措施的攻擊行為

第三十條：掐死整個灰色產業鏈？

第三十條　明知他人違反本辦法規定實施以下行為的，任何組織和個人不得為其提供數據、技術、程序、工具、軟件、廣告、服務、支付結算等方面的支持、協助或者其他幫助：

（一）製作、複製、發佈、傳播違反本辦法第二十四條和第二十五條第一款、第二款規定的信息的；

（二）違反本辦法第二十六條第一款規定，擾亂互聯網信息服務秩序的；

（三）為他人獲取、傳播被依法阻斷的信息的。

這條看起來也很嚇人，只要在任何相關的環節幫助他人看到依法阻斷的信息就算違法？那豈不是機場老闆、風險支付商、評測推廣頻道、翻牆內核的開發者這一路人全都被納入了這條法律的管轄範圍？

何謂「被依法阻斷的信息」

現實中的「依法阻斷」大概分為這幾類：法院裁定、行政處罰、公安辦案、部委專項行動。

法院裁定在知識產權領域最常見。比如版權方起訴某盜版網站，法院判決侵權成立，裁定要求ISP屏蔽該域名。有判決書、有案號、有被告、有生效日期。

再說行政處罰，例如通管局對某未備案網站作出行政處罰決定，責令改正後拒不執行，再通知接入商停止服務。有處罰決定書編號、有送達回證、有法律依據引用、有救濟告知（如不服本處罰決定，可在收到本決定書之日起六十日內向XX機關申請行政複議，或者在六個月內向XX人民法院提起行政訴訟。）。

公安機關辦案這一類很好理解，比如掃黃，涉及詐騙、賭博、色情的網站，公安立案偵查後可以要求 ISP 配合切斷。通常有立案決定書、有協助通知書發給運營商。運營商檔案裡會留存公安的正式函件。

部委專項行動這一類稍微特殊一些，比如國家版權局每年的「劍網行動」，會公佈一批侵權網站名單，通知各ISP屏蔽。有公開的通知文件、有網站列表、有引用的法律依據。雖然程序簡化了，但至少有白紙黑字的部門文件可查。

幫助他人「翻牆」，算他人獲取、傳播被依法阻斷的信息嗎？

這裡的邏輯和前文類似，現實中，沒有任何一份公開的行政文書、法院命令寫著類似「依據《某法》第某條，決定阻斷對 Google/YouTube/Telegram 的訪問」的內容。你找不到一個蓋章的決定書，找不到作出阻斷決定的具體行政機關署名，找不到阻斷的期限，找不到申訴途徑。

GFW 對境外網站的封鎖，在法律性質上一直是一個事實行為而非法律行為。它存在，它運作，但它沒有走過「作出行政決定 → 通知當事人 → 可申訴」這套程序。不難看出，GFW 對於 Google、Twitter 等平臺的封鎖並不是法條中提到的「依法阻斷」

到了這裡可能有人要問了，第八條規定在境內提供互聯網信息服務必須取得 ICP 牌照 → Google 沒有 ICP 牌照 → Google 屬於非法提供服務 → 對非法服務進行阻斷 = 依法阻斷，這不就構成了依法阻斷嗎？這看起來有道理，實際上問題卻很大。

其一，管轄權問題。 第二條寫的是「在中華人民共和國境內從事互聯網信息服務」。Google 的服務器不在中國，公司不在中國（當年退出中國的時候保留部分研發部門至今，但研發部門並不從事任何 Google 直接面向公眾的業務），它沒有主動在境內從事服務——中國用戶訪問它，和它主動在境內從事服務，是兩個完全不同的事。第九十二條確實說「境外的組織、個人向中華人民共和國境內提供互聯網信息服務的，應當遵守法律」——但這只是一個義務宣示，不等於自動取得管轄權。你得先認定它「向境內提供服務」，這個認定本身需要一個正式的行政程序。

其二，未取得 ICP 牌照的法律後果並非「阻斷」。 第七十四條寫得很清楚：未取得許可擅自從事互聯網信息服務的——「由電信主管部門責令改正；拒不改正的，責令停業整頓」。注意法律後果是「責令改正」和「責令停業整頓」，不是阻斷。這些處罰措施的前提是你能送達、能執行——對境內主體可以這麼做，對境外主體你怎麼責令？你連個送達地址都沒有，難不成你把法律文件寄到山景城去嗎？

其三，第六十七條管不到從未持有許可的境外網站。 「被電信主管部門吊銷/撤銷/註銷許可或取消核准編號的，由電信主管部門通知相關互聯網接入服務提供者和域名解析服務提供者停止為其提供服務。」這條最接近依法阻斷——通知 ISP 切斷服務。但它的適用對象是「被吊銷/撤銷/註銷」的——你得先有許可，然後被取消，才觸發這條。從來沒有取得過許可的境外網站，這條完全管不到。

事實上，從備案制度實施至今的互聯網現狀就能反推出這一點。已知：如果對所有未經備案的網站一律執行「依法阻斷」，其效果等同於白名單制度——只有備案過的網站可以訪問，其餘全部封鎖。然而現實是，國內互聯網顯然不是白名單狀態，大量未備案的境外網站仍然可以正常訪問。由此可以得出結論：GFW 對特定網站的封鎖並非法條意義上的「依法阻斷」。既然通過翻牆獲取的信息不屬於「被依法阻斷的信息」，第三十條第（三）項自然也就不適用。

第十五條：正式給專線機場判死刑？

第十五條　國家對互聯網協議地址的分配使用實行備案管理。互聯網協議地址分配機構應當及時向電信主管部門報備互聯網協議地址信息。

互聯網接入服務提供者提供接入服務前，應當核驗相應互聯網協議地址備案信息，不得為未實名或者虛假的互聯網協議地址提供服務。

這條針對 IDC、ISP 的監管規定是早就有了，然而機場依舊通過「加速器」等名義或者掛靠別的持有牌照的實體照常運作，具體什麼時候查、用什麼力度查由工信部根據國內的政治經濟需要隨時調整。近期大規模的拔線潮，時間上恰好與工信部領導層調整吻合——這種執法力度是否屬於「新官上任三把火」式的階段性運動，還是意味著長期收緊，尚有待觀察。

罰則和其他細節

第八十四條　違反本辦法第二十六條、第三十條、第三十二條、第四十八條、第四十九條規定，依照有關法律、行政法規的規定處罰。法律、行政法規沒有規定的，由網信、電信、公安部門和其他有關主管部門依據職責責令限期改正，可以並處10萬元以上100萬元以下罰款；拒不改正或者情節嚴重的，處100萬元以上500萬元以下罰款，並可以責令暫停相關業務、停業整頓。

注意這裡的罰款起步就是 10 萬元，上限 500 萬元，還可以「責令暫停相關業務、停業整頓」——這些措辭明確指向的是組織和商業化主體，而非個人用戶。個人在家用代理看個 Google 的行為，既不涉及「業務」也不涉及「整頓」，從罰則的設計邏輯上也可以印證：這套條文針對的是有組織的商業行為，而不是普通網民。

此外，罰則適用的前提是違反第二十六條和第三十條——而前文已經分析過，個人翻牆行為在法律構成要件上並不滿足這兩條的適用條件。罰則再重，構成要件不滿足，也輪不到你頭上。

現實中對「翻牆」行為的處罰

達摩克利斯之劍

前面從法律條文的角度分析，個人翻牆行為並不滿足新《辦法》相關條款的構成要件。但法律文本是一回事，現實執法是另一回事。

事實上，針對個人使用 VPN 的行政處罰一直存在，依據的也不是這部新《辦法》，而是 1997 年便已頒佈的《計算機信息網絡國際聯網管理暫行規定》第六條⁴——「計算機信息網絡直接進行國際聯網，必須使用郵電部國家公用電信網提供的國際出入口信道」，以及第十四條規定的處罰措施：警告、沒收違法所得、對個人處以最高 5000 元罰款，對單位處以最高 15000 元罰款。

這條規定掛在那裡將近三十年了，大部分時間處於休眠狀態。但它從未被廢止，意味著執法機關隨時可以選擇將它激活——而激活的時機、力度和對象，完全取決於當時的政治氣候和地方執法意願。

值得一提的是，「國際出入口信道」這個概念本身就存在定義模糊的問題。《暫行規定》要求必須使用「國家公用電信網提供的國際出入口信道」，但許多專線機場採購的恰恰就是中國電信、中國聯通、中國移動三大運營商運營的 IPLC（國際專用租用線路）或 IEPL（國際以太網專用線路）——這些都是三大運營商合法銷售的國際信道產品，面向企業客戶公開經營。如果用戶通過合法採購的運營商國際專線訪問境外網絡，是否滿足了「使用國家公用電信網提供的國際出入口信道」這一要件？條文沒有給出答案，執法實踐中也從未做出明確界定。這種模糊性進一步加劇了選擇性執法的空間。

真實案例

根據公開可查的行政處罰信息⁵，截至目前可檢索到的涉及個人使用 VPN 的處罰案例遠超公眾認知。以下是幾個有據可查的案例：

廣東韶關南雄（2019年）：當事人使用藍燈（Lantern）翻牆共 487 次，被南雄市公安局予以警告並處罰款 1000 元。
浙江金華（2020年）：金公東(網警)行罰決字[2020]00751號，當事人因使用未經授權的國際信道被處以行政處罰。
四川遂寧（2019年）：遂船公(永)行罰決字[2019]489號，類似處罰。
某地（2025年）：當事人「小張」在網絡安全檢查中被發現存有 VPN 使用記錄，被處罰款 15000 元（頂格處罰）。
湖北孝感（2026年3月）：孝感新華派出所出動 10 餘名警力上門，當事人因使用 VPN 被處罰款 500 元。

上述案例幾乎全部援引同一法律依據：《計算機信息網絡國際聯網管理暫行規定》第六條和第十四條。

執法中的問題

從這些案例中可以看出幾個值得注意的問題：

選擇性執法。 中國的翻牆用戶保守估計有數千萬⁶，而公開可查的處罰案例僅數十起。這意味著絕大多數人並不會被追究，但任何人都有可能成為那個被追究的人——法規在這裡充當的不是普遍適用的規範，而是一把懸在頭頂的劍，什麼時候落下來取決於執法者的意志。這些年經濟增長放緩，地方財政壓力不斷增大，部分地區出現的「遠洋捕撈」便是這種選擇性執法最具諷刺性的寫照——欲加之罪，何患無辭？乖乖交出你的「違法所得」，老子的績效獎金終於有著落了。

法律適用混亂。 不同地區對相同行為援引的法條不同：有的用《暫行規定》第六條，有的用《網絡安全法》第二十七條或第六十三條，有的甚至用《治安管理處罰法》中的條款。同一個行為在不同地方可能面對完全不同的法律評價，這本身就說明法律適用標準是混亂的。需要指出的是，中國是成文法國家而非判例法國家，法院判決不具有先例約束力，你在 A 地因翻牆被罰 500 元，在 B 地同樣的行為可能被罰 15000 元或者乾脆不被追究，而你無法援引 B 地的不追究來為自己在 A 地辯護。

執法手段與違法程度不成比例。 湖北孝感案例中，出動 10 餘名警力處理一起最終罰款 500 元的行政違法行為——這種執法姿態更像是震懾而非正常的行政管理。

援引其他口袋罪名。 部分案例中，翻牆本身的處罰微乎其微，但公安機關以此為切入點，進一步追查當事人在境外平臺上的言論，繼而以「尋釁滋事」等口袋罪追究刑事責任。翻牆在這裡成了援引其他口袋罪名的引子——處罰的不是翻牆本身，而是借翻牆的由頭處罰當事人的言論或政治立場。

你能做什麼

說了這麼多，你可能會覺得：法律條文上不構成，但現實中還是有風險，那不就等於白說了？

不，這是一份徵求意見稿，你現在擁有一個白紙黑字寫在法定程序裡的參與立法工作的渠道。

提交立法意見

《辦法》目前處於公開徵求意見階段。根據《規章制定程序條例》第十五條，任何公民都有權對徵求意見稿提出意見。這不是恩賜，這是法定程序。你可以通過網信辦公佈的徵求意見渠道，正式提交你的意見——比如建議對「違法穿透、繞過」的表述增加更明確的構成要件界定，或者建議對「依法阻斷」做出程序性定義以防止概念被濫用。

聯繫你的人大代表

《中華人民共和國憲法》第四十一條：

中華人民共和國公民對於任何國家機關和國家工作人員，有提出批評和建議的權利。

《中華人民共和國全國人民代表大會和地方各級人民代表大會代表法》第四條：

代表應當與原選區選民或者原選舉單位保持密切聯繫，聽取和反映選民和選舉單位的意見和要求，努力為人民服務。

你所在選區的區/縣人大代表有義務聽取你的意見，各區縣人大常委會官網通常會公佈代表名單及聯繫方式。找到你的代表，打個電話或者寫封信，告訴他們：

你認為互聯網立法應當遵循明確性原則，模糊的條文不應成為選擇性執法的工具；
你支持依法治網，但反對以「依法」之名行「無法可依」之實；
你希望「被依法阻斷」這一概念在法律中獲得明確的程序性定義。

踐行社會主義核心價值觀，從聯繫你的人大代表開始。

TL;DR

是技術性修法，該怎麼過日子以後還怎麼過，任何行為自己權衡風險，都散了吧。

《互聯網信息服務管理辦法（修訂草案徵求意見稿）》全文及徵求意見公告可在國家互聯網信息辦公室官網查閱: https://www.cac.gov.cn/2025-04/15/c_1746821732498092.htm ↩︎
參考《立法技術規範（試行）（二）》: https://npcobserver.com/wp-content/uploads/2023/02/Technical-Specifications-for-Legislation-for-Trial-Implementation-II.pdf ↩︎
中國政府從未正式承認 GFW 的存在，也從未公佈過被封鎖網站的完整列表。2015 年國務院新聞發言人在回答外國記者提問時僅表示「中國依法管理互聯網」，但未指明具體的法律依據或封鎖清單。 ↩︎
《計算機信息網絡國際聯網管理暫行規定》（1997年頒佈，2024年最新修訂）全文可參閱國務院官網: https://www.cac.gov.cn/1996-02/02/c_126468621.htm ↩︎
王宇揚（2020年9月5日）通過裁判文書網和行政處罰信息公開平臺檢索，共找到 51 起相關案例。 ↩︎
GlobalWebIndex 在 2014 年的調查報告顯示中國 VPN 用戶約 9300 萬，約佔當時網民總數的 14%。考慮到此後網民總數持續增長且翻牆工具日益普及，當前實際用戶數只會更高。 ↩︎

關於 DNS 洩露及其相關誤解的說明

Sun, 17 May 2026 16:46:00 +0000

點進這篇文章的人想必基本都對 DNS 洩露這一概念有所耳聞了，其中也不乏談 DNS 洩露色變者，由於評論區和 Issue 裡提出相關問題的人已經有數位，鄙人這次寫一篇說明，儘可能將這個問題講清楚，澄清一些大家對這個概念可能的誤解，也為各位編寫自己的代理配置提供一個參考。

這個概念已經被一些 VPN 廠商和一大堆 YouTuber 講爛了，基本的意思是：當你在代理時，電腦卻通過本地網絡向本地 DNS 請求你正在訪問的網址，使得運營商可以依據你的 DNS 請求記錄得知你的瀏覽記錄。

flowchart LR
    U[用戶設備
瀏覽器 / App] --> VPN[VPN 客戶端
加密隧道]

    VPN -->|正常情況：DNS 請求走 VPN| VPNDNS[VPN 提供的 DNS 服務器]
    VPNDNS --> NET[目標網站 / 互聯網]

    U -.->|異常情況：DNS 洩露| ISP[本地 ISP DNS 服務器]
    ISP -.-> LOG[ISP / 第三方可記錄
訪問過的域名]

    NET --> SITE[example.com]

    subgraph Normal[正常 DNS 解析路徑]
        VPN
        VPNDNS
        NET
    end

    subgraph Leak[DNS 洩露路徑]
        ISP
        LOG
    end

    classDef safe fill:#e8f7ee,stroke:#2e7d32,stroke-width:2px,color:#1b5e20;
    classDef danger fill:#fdecea,stroke:#c62828,stroke-width:2px,color:#7f0000;
    classDef user fill:#e3f2fd,stroke:#1565c0,stroke-width:2px,color:#0d47a1;

    class U user;
    class VPN,VPNDNS,NET,SITE safe;
    class ISP,LOG danger;

搞清楚需求

首先需要想明白的是，我們煞費苦心地防止 DNS 洩露究竟是為了什麼——大家的第一反應可能都是：「那還用說！肯定是為了不讓審查者看到我們通過代理訪問了哪些網站啊！」

其實這個說法並不完全準確，具體還得看情況。不妨想一想：讓審查者知道你在刷抖音、聊微信會有什麼實質性的危害嗎？恐怕沒有。但如果讓審查者發現你在訪問維基百科、瀏覽 X（推特）或者其他帶有明確政治傾向的敏感內容，那問題就有點大了。防止 DNS 洩露的目的，從來不是為了讓你在所謂的「DNS 洩露測試」網站上拿到一個全綠的滿分，也不是為了隱藏你使用國內常用服務的事實，而是為了不讓審查者知道你在訪問那些被封禁、被視為敏感的網站和服務。

對於生活在牆內的我們來說，區分什麼是敏感內容其實非常簡單：直接參考 GFWList¹ 即可——能讓 GFW 專門將其重點關照的，自然就是敏感內容。

那些 DNS 洩露測試的網站，測試用的隨機域名甚至連 GFWList 的邊都沾不上，本身就毫無敏感性可言。對於一些經過優化的正常代理配置來說，這類域名連看都不想多看一眼，通常會直接被略過並扔給最後的兜底規則（比如 MATCH, DIRECT）去處理，這個過程自然而然地觸發了本地 DNS 解析。於是，測試網站便如獲至寶般地亮起紅燈，警告你「存在 DNS 洩露」。但明白機制的我們自然清楚，很多時候這種所謂的洩露完全是無關痛癢的，只要配置得當，你真正需要保護的敏感訪問記錄，早就匹配到前面的分流規則被安全地送進加密隧道了。

更有甚者，諸如 Surfshark、ExpressVPN 這類海外商業 VPN 廠商，以及一眾跟著恰飯的無良 YouTuber，成天拿這種毫無實際意義的測試結果製造隱私焦慮。可笑的是，這些傳統的商業 VPN 客戶端往往連最基礎的域名分流規則功能都不具備，全靠粗暴的一把梭將所有網絡請求強行塞進虛擬網卡。而更諷刺的是，即便是這種簡單粗暴的全局代理，他們過去還曾因為自身客戶端軟件的缺陷，真真切切地導致過 DNS 洩露問題。所以，與其聽信這些販賣焦慮的恰飯營銷，不如自己弄懂代理軟件的運作原理。

出現洩露的環節

其實現在主流的代理軟件都比較成熟，配置得當完全不需要擔心 DNS 洩露的問題。問題出就出在很多配置根本就不得當。接下來我將會簡要地解釋代理軟件在系統代理模式和透明代理（虛擬網卡）模式下可能出現 DNS 洩露的環節。

代理軟件本身

在使用系統代理的情況下（假設代理地址是socks5://127.0.0.1:7890²）用瀏覽器訪問https://www.example.com，會經歷如下的請求過程：

第一步：瀏覽器會把網絡請求打包發送給socks5://127.0.0.1:7890
第二步：代理軟件收到請求後根據配置的分流規則匹配節點
第三步：代理軟件根據匹配結果向節點轉發整個網絡請求

sequenceDiagram
    participant B as 瀏覽器
    participant P as 代理軟件
(127.0.0.1:7890)
    participant R as 分流規則引擎
    participant N as 遠端代理節點

    B->>P: ① 將請求打包發送
(攜帶域名, 不做 DNS 解析)
    Note over B,P: 瀏覽器不發起 DNS 查詢
不會洩露
    P->>R: ② 根據域名等信息
匹配分流規則
    Note over P,R: 規則匹配過程
可能觸發 DNS 查詢 ⚠️
    R-->>P: 返回匹配結果
(PROXY / DIRECT / REJECT)
    P->>N: ③ 加密轉發請求至節點
    Note over P,N: 加密隧道傳輸
不會洩露
    N-->>P: 返回響應
    P-->>B: 返回響應

在整個發起請求的過程中，瀏覽器將網絡請求打包交給代理，不會向本地 DNS 發出請求，這一環節不會產生 DNS 洩露；代理軟件將網絡請求轉發給服務器，整個過程加密，也不會產生 DNS 洩露；真正產生 DNS 洩露的環節，是根據分流規則匹配的過程。

向本地 DNS 發起域名查詢這件事情本身並不一定是壞事，但配置不當的分流規則會讓代理軟件在拿到域名後過早地向本地 DNS 發起查詢，導致洩露不應洩露的隱私信息。假設在極端情況下，蓋世太保從運營商調取所有人的 DNS 查詢記錄，凡是查詢過域名包含 GFW 封鎖列表中的項目者都拉出去槍斃，在這種情況下，為了保全自身，我們需要恰當地配置分流規則。

以使用廣泛的 Mihomo 內核為例，在作為客戶端開啟系統代理模式、使用 Chrome 進行到前文所述的第二步時，內核已知的信息有：

主機³：example.com
目標端口：443
網絡協議：TCP
發起請求的進程的名稱和具體路徑：C:\Application\chrome.exe
入站 IP：127.0.0.1
入站名稱：DEFAULT-MIXED
入站端口：隨機的高位端口

內核不會進行多餘的 DNS 請求，根據已知的信息，內核可以在不發起 DNS 解析的情況下，匹配所有基於域名、端口、進程名稱以及網絡協議匹配的路由規則：

rules:
  # 基於域名的匹配規則
  - DOMAIN,ad.com,REJECT
  - DOMAIN-SUFFIX,google.com,auto
  - DOMAIN-KEYWORD,google,auto
  - DOMAIN-WILDCARD,*.google.com,auto
  - DOMAIN-REGEX,^abc.*com,PROXY
  - GEOSITE,youtube,PROXY
  # 基於端口的匹配規則
  - DST-PORT,80,DIRECT
  - SRC-PORT,7777,DIRECT
  # 基於進程名稱的匹配規則
  - PROCESS-PATH,/usr/bin/wget,PROXY
  - PROCESS-PATH,C:\Application\chrome.exe,PROXY
  - PROCESS-NAME,curl,PROXY
  - PROCESS-NAME,chrome.exe,PROXY
  # 基於網絡協議的匹配規則
  - NETWORK,UDP,REJECT
  # 不依賴任何信息的匹配規則
  - MATCH,DIRECT

因此，上述這些種類的規則不會產生 DNS 洩露，因為內核匹配它們的時候根本沒必要發起 DNS 解析。

對於剩下種類的規則，需要在第二步獲知目標 IP 信息才能讓匹配進行下去：

rules:
  - GEOIP,cn,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT
  - IP-SUFFIX,8.8.8.8/24,PROXY
  - IP-ASN,13335,DIRECT

在默認情況下，為了確保匹配的準確性，進行到第二步時，內核不知道目標 IP，只知道目標主機地址www.example.com，此時內核不得不對www.example.com的 IP 地址進行查詢，這也就造成了 DNS 洩露。如果在規則的末尾加上no-resolve⁴，則匹配到基於 IP 的規則時會直接跳過，這就使得no-resolve很適合用來分流 Telegram 等軟件的裸 IP 請求。

透明代理的問題（TUN 模式⁵）

透明代理顧名思義即被代理的系統/軟件感知不到自己被代理了的代理方式。這種方式非常省事，TUN 模式一開，所有軟件通通都能用，無須繁瑣的逐一配置不遵循系統代理的軟件。代價就是這種省事本身——目標系統/軟件都不知道自己被代理了，他們在正常網絡上該有的行為都會照常進行，其中自然也包括 DNS 解析，可是目標系統/軟件並不知道自己被代理了，他們想要和遠端建立連接，總得要先拿到一個 IP 才行吧。為了解決這個問題，以 Mihomo 為例，有兩種 DNS 劫持模式，redir-host和fake-ip。

redir-host 模式：

flowchart TD
    A1[目標軟件發起 DNS 查詢] --> A2[代理軟件向上遊 DNS
查詢真實 IP]
    A2 --> A3[上游 DNS 返回真實 IP]
    A3 --> A4[將真實 IP 返回給目標軟件]
    A4 --> A5[目標軟件用真實 IP 建立連接]
    A5 --> A6[代理軟件攔截並分流]

    A2 -.- LEAK["⚠️ 真實 DNS 請求洩露到外部網絡"]

    classDef danger fill:#fdecea,stroke:#c62828,stroke-width:2px,color:#7f0000;
    class LEAK danger;

fake-ip 模式：

flowchart TD
    B1[目標軟件發起 DNS 查詢] --> B2[代理軟件立即返回假 IP
如 198.18.0.x]
    B2 --> B3[目標軟件用假 IP 建立連接]
    B3 --> B4[代理軟件攔截, 查映射表
還原真實域名]
    B4 --> B5[通過加密隧道轉發請求]

    classDef safe fill:#e8f7ee,stroke:#2e7d32,stroke-width:2px,color:#1b5e20;
    class B2,B4,B5 safe;

其中redir-host比較老實，既然目標系統/軟件發起了 DNS 查詢，那就老老實實通過上游 DNS 去查，把查詢到的真實的 IP 返回給目標系統/軟件。由於這種模式下系統必定會發生一次真實的 DNS 解析請求尋址過程，存在著先天的結構性缺陷，不可避免地會造成 DNS 洩露。原來的 Clash 核心在後續的版本更新中乾脆直接砍掉了 redir-host 模式。

不過，繼承了 Clash Meta 核心的 Mihomo 內核選擇了將其保留下來，並且加入了sniffer⁶對其進行增強。在redir-host模式下，sniffer依靠嗅探數據包中的特徵（比如從 TLS 的 SNI 字段⁷）嘗試將被解析成裸 IP 的流量恢復成連接域名，再用這個域名走一遍分流規則的匹配，補齊了redir-host模式在分流上的諸多短板。但需要特別注意：sniffer 解決的是分流準確性的問題，並不能消除 DNS 洩露本身——DNS 查詢請求在 sniffer 介入之前就已經發出去了，運營商該記錄的早就記錄了。

但這裡需要提醒：如果你在透明代理環境下仍然堅持使用redir-host模式，就必須在配置一套無汙染的 DNS，具體的例子可以參考我的另一篇文章，否則你的 DNS 訪問記錄依然會洩露。

相對而言，fake-ip模式則採用了截然不同的解決思路，不僅完美規避了透明代理環境下的 DNS 洩露問題，甚至還能順帶提升瀏覽器的網頁響應速度。

如何規避 DNS 洩露

優化餵給代理軟件的分流規則

前面已經提到過，不當的分流規則會讓代理軟件過早地觸發解析。一個典型的反面例子如下：

rules:
  - GEOIP,cn,DIRECT
  - GEOSITE,telegram,Telegram
  - GEOIP,telegram,Telegram
  - MATCH,Proxy

問題出在第一條 GEOIP,cn,DIRECT。當設備請求 telegram.org 這個域名時，內核從上往下匹配，第一條就是個 IP 規則。可域名不是 IP，要判斷它到底落不落在中國大陸的網段裡，內核只能先把 telegram.org 拿去解析一遍。這一解析，DNS 查詢就發出去了——哪怕下面第二條 GEOSITE,telegram 本來能直接命中，根本用不著知道 IP。

flowchart TD
    Start[請求 telegram.org] --> Rule1{第 1 條
GEOIP,cn?}
    Rule1 --> Leak[⚠️ IP 規則遇上域名
必須先解析 telegram.org
DNS 查詢就此洩露]
    Leak --> Judge{解析出的 IP
在中國大陸?}
    Judge -- 否 --> Rule2{第 2 條
GEOSITE,telegram?}
    Rule2 -- 是 --> ProxyTG[走 Telegram 代理
但 DNS 已經洩露了]

    classDef danger fill:#fdecea,stroke:#c62828,stroke-width:2px,color:#7f0000;
    class Leak danger;

解析請求一旦發出，運營商那頭就記下了。後面命中哪條規則或者走不走代理都不重要，反正運營商已經知道你在訪問 Telegram。

規則匹配自上而下順序進行，內核每收到一個請求就一條一條往下比，直到命中為止。換句話說，一個域名只要被前面的規則匹配到，後面的規則，第二條、第三條、哪怕第一千萬條，都不會再跑。

正因如此，寫規則時要遵循域名規則在前，IP 規則在後的原則。就算是針對某個服務的專用規則集，也要給裡面靠前的 IP 規則加上 no-resolve 標記，告訴內核這條 IP 規則匹配不上就跳過，別去解析。一個典型的例子：

DOMAIN-SUFFIX,e-hentai.org
DOMAIN-SUFFIX,ehgt.org
DOMAIN-SUFFIX,ehwiki.org
DOMAIN-SUFFIX,exhentai.org
DOMAIN-SUFFIX,hath.network
DOMAIN-SUFFIX,hentaiverse.org
IP-CIDR,178.175.128.0/21,no-resolve

用 GeoSite 和 GeoIP 數據庫時同理，靠前的 IP 規則都要帶上 no-resolve。

rules:
  - GEOSITE,telegram,Telegram
  - GEOIP,telegram,Telegram,no-resolve
  - GEOSITE,gfw,Proxy
  - GEOIP,cn,DIRECT
  - Match,Proxy

把這套規則和前面的反面例子對照著看，差別就在 DNS 解析觸發的時機上：

flowchart TD
    Start[請求 telegram.org] --> Rule1{第 1 條
GEOSITE,telegram?}
    Rule1 -- 是 --> ProxyTG[走 Telegram 代理
✅ 全程未解析]
    Rule1 -- 否 --> Rule2{第 2 條
GEOIP,telegram,no-resolve?}

    Rule2 -- 是
僅匹配裸 IP 請求 --> ProxyTG
    Rule2 -- 否 --> Rule3{第 3 條
GEOSITE,gfw?}

    Rule3 -- 是 --> ProxyGFW[走 Proxy 代理
✅ 全程未解析]
    Rule3 -- 否 --> NeedIP[到這一步才需要 IP
觸發本地 DNS 解析]

    NeedIP --> Rule4{第 4 條
GEOIP,cn?}
    Rule4 -- 是 --> Direct[DIRECT 直連]
    Rule4 -- 否 --> ProxyOther[Match,Proxy
走 Proxy 代理]

    classDef safe fill:#e8f7ee,stroke:#2e7d32,stroke-width:2px,color:#1b5e20;
    classDef warn fill:#fff3e0,stroke:#ef6c00,stroke-width:2px,color:#8a4b00;
    class ProxyTG,ProxyGFW safe;
    class NeedIP warn;

同樣是請求 telegram.org，這回第一條就是 GEOSITE,telegram，域名直接命中，請求甩給代理，全程沒碰 DNS。訪問其他掛在 GFW 列表上的網站也一樣，會先撞上 GEOSITE,gfw,Proxy，趕在那條非解析不可的 GEOIP,cn,DIRECT 之前就把請求送進了節點。該走代理的早早走了代理，靠後那些基於 IP 的規則壓根沒輪到執行，DNS 也就沒機會洩露出去。

用 Fake-IP 規避透明代理問題

fake-ip 模式則解決了透明代理下的 DNS 洩露問題，還能順帶提升瀏覽器的網頁響應速度。

在fake-ip模式下進行透明代理，當目標軟件發起 DNS 查詢時，代理軟件並不會傻乎乎地去本地或遠端上游查詢真實 IP，而是直接在本地瞬間返回一個假的內網保留 IP（例如198.18.0.2⁸）。目標軟件拿到這個假 IP 後信以為真，緊接著就會拿著這個假 IP 嘗試建立連接。

而在代理軟件這裡，它只需要攔截所有發往自己簽發過的這些假 IP 的請求即可。由於代理軟件內部維護了一張詳細的「假 IP 對應真實域名」的映射表，所以即便目標軟件發來的是往假 IP 發送的包，代理軟件依然心知肚明你其實想訪問的是什麼域名。於是，代理軟件直接提取出原始域名，將網絡請求順著加密代理隧道發往遠端節點去處理。

sequenceDiagram
    participant App as 目標軟件
(瀏覽器等)
    participant TUN as TUN 虛擬網卡
    participant Proxy as 代理軟件
(Mihomo)
    participant Node as 遠端代理節點
    participant Web as 目標網站

    App->>TUN: DNS 查詢: google.com 的 IP 是?
    TUN->>Proxy: 轉發 DNS 查詢
    Note over Proxy: 不向外部發起任何 DNS 請求!
從 198.18.0.0/15 池中分配假 IP
記錄映射: 198.18.0.5 → google.com
    Proxy-->>TUN: 返回假 IP: 198.18.0.5
    TUN-->>App: DNS 響應: 198.18.0.5

    App->>TUN: 連接 198.18.0.5:443 (HTTPS)
    TUN->>Proxy: 轉發連接請求
    Note over Proxy: 查映射表:
198.18.0.5 → google.com
匹配分流規則 → PROXY
    Proxy->>Node: 加密轉發: 請連接 google.com:443
    Node->>Web: 建立真實連接
    Web-->>Node: 返回網頁內容
    Node-->>Proxy: 加密回傳
    Proxy-->>TUN: 返回內容
    TUN-->>App: 收到響應

    Note over App,Web: 全程無真實 DNS 請求洩露到外部網絡 ✓

這一機制解決了redir-host模式下透明代理必然會向外部網絡暴露域名查詢記錄的結構性缺陷。但必須指出的是，fake-ip僅僅是繞過了目標軟件發起 DNS 查詢時的洩露風險。正如前文所述，如果分流規則配置不當，代理內核自身依然會主動向上游發起真實的 DNS 解析，從而導致洩露。在分流規則配置妥當的前提下，fake-ip模式不僅能讓審查者無從窺探你的真實訪問目標，還能因為免去了本地設備等待 DNS 真實響應的時間，順帶大幅度降低網頁訪問的首字節加載延遲（TTFB⁹），可謂一石二鳥。

太長不想讀（小結）

DNS 洩露本身並不可怕，可怕的是不明就裡地被焦慮營銷牽著鼻子走。理解了機制之後，應對思路其實很清晰：

系統代理模式：遵循「域名規則在前，IP 規則在後」的原則，為所有 IP 類規則加上 no-resolve，敏感域名在觸發 DNS 解析之前就已經被分流走了。
TUN 透明代理模式：優先選用 fake-ip，從根源上杜絕 DNS 查詢外洩，同時還能獲得更低的 TTFB。如果堅持使用 redir-host，必須搭配無汙染的上游 DNS，且要清楚 sniffer 只能改善分流準確性，無法阻止 DNS 請求本身的洩露。
不要迷信洩露測試網站：測試用的隨機域名根本不在 GFW 封鎖列表內，觸發本地解析是正常且無害的行為，綠燈與否不是衡量配置質量的標準。

被中國大陸防火長城（Great Firewall, GFW）封鎖的域名列表。 ↩︎
SOCKS5 是一種網絡代理協議（RFC 1928），工作在會話層，支持 TCP 和 UDP 轉發，且允許客戶端將域名直接傳遞給代理服務器解析，而非在本地解析後再連接——這正是它在防止 DNS 洩露方面優於普通 HTTP 代理（非 CONNECT 隧道模式）的關鍵特性。 ↩︎
可以理解為域名。 ↩︎
no-resolve 是附加在 IP 類規則末尾的標記，作用是告訴內核：當流量的目標是域名而非 IP 時，跳過此規則，不要為了匹配它而主動發起 DNS 解析。但如果流量本身就是直接連接 IP（如 Telegram 客戶端直連服務器 IP），則該規則仍然會正常參與匹配。 ↩︎
也就是我們所說的虛擬網卡模式 ↩︎
流量嗅探（Sniffer）是指代理軟件通過檢查數據包的協議特徵來還原目標域名的技術。例如，HTTPS 連接在握手階段會以明文發送目標域名（即 SNI），HTTP 請求頭中也包含 Host 字段，代理軟件可以從這些特徵中提取出真實的目標域名。 ↩︎
Server Name Indication，TLS 協議的擴展字段。由於同一 IP 上可能託管多個 HTTPS 站點，客戶端在 TLS 握手的 ClientHello 階段需要以明文告知服務器自己要訪問哪個域名，以便服務器返回正確的證書。這也是為什麼即使使用了 HTTPS，中間人仍然能看到你訪問的域名（但看不到具體路徑和內容）。 ↩︎
Mihomo 默認使用 198.18.0.0/15 地址段分配假 IP。該地址段由 IANA 在 RFC 2544 中保留，專門用於網絡設備基準測試，不會出現在正常的互聯網路由表中，因此不會與任何真實的公網地址衝突。整個 /15 段可提供約 131,072 個地址供映射使用。 ↩︎
Time To First Byte，即從客戶端發出請求到收到服務器響應第一個字節所經過的時間。在傳統模式下，瀏覽器需要先等待 DNS 解析完成（通常耗時 20-120ms）才能發起 TCP 連接；而 fake-ip 模式下 DNS 響應幾乎是瞬時的（<1ms），因此能顯著縮短整體的頁面加載時間。 ↩︎

Terraform IaC 初體驗

Thu, 09 Apr 2026 07:13:35 +0000

Terraform 是一款 IaC 工具，所謂 IaC 就是「基礎設施即代碼」，將我們的基礎設施以聲明式的代碼寫出來，隨後使用terraform apply即可完成基礎設施的部署，同一份配置，部署出來的一定是一模一樣的基礎設施（Nix OS 用戶狂喜）。

為什麼要用 Terraform

傳統的基礎設施管理絕大部分基於人力和各種雲服務商的 Dashboard，這就帶來了下面這些痛點：

痛點	說明
難以重現	通過 Dashboard 點點點進行配置，容易改錯或者改漏，而且難以復現
環境漂移	手動操作導致生產和測試環境配置逐漸偏離，導致極端情況下測試沒問題生產直接崩
難以擴展	新增一套環境需要重複大量手工操作，耗時且容易出錯
難以審計	沒有變更記錄，~~出了事不好甩鍋~~
難以協作	基礎設施由少數「懂的人」掌控，誰想要改都得去找這些人，效率低

為了解決這些問題，「基礎設施即代碼」¹的概念被提了出來，Terraform 就是其中一個著名的解決方案。

假設一個現實的使用場景，例如你每年都會購買新的 GCP 的 $300 試用金賬號，雖然便宜，但是每年都要重新跑到 GCP 的面板裡開機器。而有了 Terraform，想要部署同樣配置的機器，只要在每次更換賬號之後，將 API Token 替換成新的，隨後terraform apply，只需要幾分鐘就能開出和你上個賬號一模一樣的機器、VPC、S3、防火牆配置等等。

再比如 Cloudflare DNS 和 Tunnel 的管理和遷移，也只需要將原 Tunnel 的 Ingress Rule 複製到新 Tunnel 的 Ingress Rule。即使將來要遷移到 AliDNS、Route 53 等其他服務商，我們也可以原封不動的將數據複製過去²。

尤其是到了多人協作的時候，配合 Git，每次更改都有跡可循，更不需要擔心合併衝突，PR 可以自動生成更改預覽，出現問題可以立刻回滾到上一個版本，這些都是傳統依賴人力去直接操作服務提供商 Dashboard 的做法完全無法做到的。

Terraform 的安裝

Terraform 是用 Go 寫的，編譯出來的產物自然也是單個可執行文件，所以安裝起來也非常容易，Windows 下可以直接使用 Winget 安裝：

winget install Hashicorp.Terraform

如果不想使用 Winget，也可以使用 Scoop 等其他包管理器，或者將預編譯的二進制文件放入$PATH，即可完成安裝。

如果你在 Linux 環境下，則使用對應的包管理器安裝即可，如果使用將二進制文件放入$PATH的安裝方法，則要記得sudo chmod +x terraform賦予文件的執行權限。

Terraform 的兩個基本概念

Provider(s)

我們前面已經提到，Terraform 是一個款礎設施即代碼工具，作為一個工具本身，他並不綁定某個平臺，而是通過 Provider(s) 與各個平臺對接，要查看有哪些 Provider(s)，可以瀏覽 Terraform 的 Registry。

狀態管理

Terraform 將每次執行基礎設施變更操作時的狀態信息保存在一個狀態文件中，默認情況下會保存在當前工作目錄下的terraform.tfstate文件裡³，我們也可以修改配置文件自行指定其他的存儲後端，例如 S3、Postgres。每次我們執行terraform apply時，Terraform 都會將目前配置文件聲明的狀態同現有的狀態文件進行比對，從而計算變動的部分，自動確定調整順序之後操作 Provider 落實狀態變動。

Terraform 的資源導入難題

現有資源的導入一直是 Terraform 為人詬病的難題，Hashi Corp. 似乎一直在堅持著一個固執且愚蠢的觀點：你所有的基礎設施從一開始就應當是用我們的 Terraform 創建的，所以也不存在什麼資源導入的問題。

時間	版本	進展	問題
2014–2022	v0.x–v1.4	只有 `terraform import`，一次一條，而且完全不生成配置	導入完還得自己手寫 HCL⁴
2023.06	v1.5	引入 `import` 塊和 `-generate-config-out`參數，可以生成配置了	然而還是得一條一條寫，而且還得自己提供現有資源的 ID
2024.01	v1.7	`import` 塊支持 `for_each`	批量了，但 ID 還得自己搞
2024 下半年	v1.12	引入了 `terraform query` 和 `list` 塊，終於實現了自動發現資源的功能	然而這個功能要 Provider 要自己實現，大量 Provider 根本沒跟上

這麼多年的時間，社區一直在罵，然而，「我有一堆現有資源，怎麼導入 Terraform」這個問題一直沒有被認真對待。Terraform 作為「基礎設施即代碼」工具，設計哲學就是聲明式和冪等性⁵，Hashi Corp. 他們篤信「一切以代碼聲明的狀態為準，就應該用 Terraform 從零開始創建資源」。但現實是絕大多數公司都有大量歷史存量資源，先有資源、後有代碼才是常態。這個矛盾 Hashi Corp. 承認得很晚，v1.12 的 terraform query 才算是官方第一次認真面對這個問題——但 Provider 生態的跟進嘛……真的是一言難盡。

Terraform 的文件結構

Terraform 的文件結構很簡單，其主程序運行時會無腦讀取工作目錄下所有的.tf文件，只要信息齊全，想給文件取什麼名字都可以，比如我的文件結構就長這樣：

❯ tree -a -I .git
.
├── .editorconfig
├── .github
│   ├── dependabot.yml
│   └── workflows
│       ├── terraform-apply.yml
│       ├── terraform-plan.yml
│       └── your-fork.yml
├── .gitignore
├── .terraform.lock.hcl
├── cf_dns_zones.tf
├── cf_tunnel.tf
├── dns_example_com.tf
├── dns_example_net.tf
├── dns_example_top.tf
├── dns_example_cn.tf
├── main.tf                 # 基礎配置（terraform 塊）
├── moved.tf                # 移動過的資源
├── provider.tf             # 每個 Provider 的配置
├── README.md
├── rename_resources.ps1
└── variables.tf            # 自定義的變量

main.tf用於存放基礎配置:

terraform {
  required_providers {
    cloudflare = {
      source  = "cloudflare/cloudflare"
      version = "~> 5"
    }

    tencentcloud = {
      source  = "tencentcloudstack/tencentcloud"
      version = ">= 1.81.43"
    }
  }
}

provider.tf用於存放每個 Provider 的配置：

provider "cloudflare" {}
provider "tencentcloud" {}

這裡留空是因為我們可以通過環境變量來傳遞 Credentials，而不是直接將 Credentials 寫在配置文件中，例如 Cloudflare 的 Provider 就接受CLOUDFLARE_API_TOKEN作為api_token這個變量的替代。

variables.tf用於聲明自定義的變量：

variable "cloudflare_zone_example_com" {
  description = "Cloudflare zone ID for example.com"
  type        = string
}

variable "cloudflare_zone_example_top" {
  description = "Cloudflare zone ID for example.top"
  type        = string
}

這些變量可以通過前綴為TF_VAR_的環境變量傳入，Terraform 也會自動讀取terraform.tfvars文件中的變量，變量的主要用途是在別的配置文件中調用，例如：

resource "cloudflare_dns_record" "example_cname" {
  content = "${cloudflare_zero_trust_tunnel_cloudflared.Production_Tunnel.id}.cfargotunnel.com"
  name    = "example.example.com"
  proxied = true
  tags    = []
  ttl     = 1
  type    = "CNAME"
  zone_id = var.cloudflare_zone_id_example_com  #這裡調用了cloudflare_zone_example_com這個變量
  settings = {
    flatten_cname = false
  }
}

有了這些基礎配置，我們就可以運行terraform init初始化 Terraform 環境並鎖定依賴版本，剩下的就都是我們資源的聲明瞭。

將現有資源導入 Terraform

前文提到過 Terraform 的狀態管理這個概念，狀態管理雖好，但在我們初始化時也帶來了一個問題——在默認狀態下，Terraform 的狀態文件顯然是空的。

此時我們需要做的是將雲服務提供商上現有資源的狀態導入 Terraform，這樣 Terraform 才能無縫接手並管理我們的基礎設施。相信大家也都看到了前文對 Terraform 資源導入問題的吐槽。以導入 Cloudflare 上託管的 DNS 記錄為例，前文提到過，如果 Provider 支持，可以使用 Terraform 在 1.12 版本之後引入的terraform query，然而大多數情況下，Providers 都是沒有跟進這個新功能的，Cloudflare 就屬於不支持的那一類。

好在雖然 Hashi Corp. 不認真解決問題，各路高強度使用 Terraform 管理基礎設施的公司就各顯神通。Cloudflare 就維護了名為 cf-terraforming 的導入工具，免去了很多手動導入的麻煩。首先安裝cf-terraforming，這個工具是用 Go 語言編寫的，需要在有 Go 語言環境的情況下安裝，或者將官方編譯好的二進制文件其放入$PATH並賦予其執行權限。

go install github.com/cloudflare/cf-terraforming/cmd/cf-terraforming@latest

這個工具的用法還是比較簡單的，首先你需要以下環境變量：

# 如果你使用 API Token
export CLOUDFLARE_API_TOKEN='Hzsq3Vub-7Y-hSTlAaLH3Jq_YfTUOCcgf22_Fs-j'

# 如果你使用 API Key
export CLOUDFLARE_EMAIL='user@example.com'
export CLOUDFLARE_API_KEY='1150bed3f45247b99f7db9696fffa17cbx9'

# 指定需要導入的域名的區域 ID，如果導入的是賬戶資源（例如 Cloudflare Tunnel）則不需要
export CLOUDFLARE_ZONE_ID='81b06ss3228f488fh84e5e993c2dc17'

💡 提示
此處的命令假設你正在使用 Bash，如果使用的是與 Bash 語法不兼容的 Shell，則需要做出調整，例如對於 Windows 上的 PowerShell，導入環境變量的語法如下：
$env:CLOUDFLARE_API_TOKEN='Hzsq3Vub-7Y-hSTlAaLH3Jq_YfTUOCcgf22_Fs-j'

通常我們只需要設置CLOUDFLARE_API_TOKEN和CLOUDFLARE_ZONE_ID就可以了，在控制檯創建 API Token 時，記得賦予這個 Token 必要的權限，本次我們只是導入 DNS 記錄，所以只賦予編輯區域 DNS 的權限即可。

好了，準備工作全部完成，現在可以開始生成配置文件：

首先導入賬戶中域名的配置，也就是cloudflare_zone：

cf-terraforming generate \
  --key $CLOUDFLARE_API_KEY \
  --resource-type "cloudflare_zone" > zone.tf

這一步會在當前目錄下生成一個名為zone.tf的文件，裡面會有如下格式的內容：

resource "cloudflare_zone" "REDACTED" {
  name                = "REDACTED"
  paused              = false
  type                = "full"
  vanity_name_servers = []
  account = {
    id   = "REDACTED"
    name = "REDACTED"
  }
}

resource "cloudflare_zone" "REDACTED" {
  name                = "REDACTED"
  paused              = false
  type                = "full"
  vanity_name_servers = []
  account = {
    id   = "REDACTED"
    name = "REDACTED"
  }
}

現在域名資源已經導入了，但是裡面的配置並沒有。接下來，導入域名下的 DNS 記錄：

cf-terraforming generate \
  --zone $CLOUDFLARE_ZONE_ID \
  --key $CLOUDFLARE_API_KEY \
  --resource-type "cloudflare_dns_record" >> dns.tf

這一步會在當前目錄下生成一個名為dns.tf的配置文件，裡面會有如下格式的內容：

resource "cloudflare_dns_record" "terraform_managed_resource_5deb14xxxxxb629bf123xxxxxxxc8f_0" {
  content  = "67.24.33.108"
  name     = "example.example.com"
  proxied  = true
  tags     = []
  ttl      = 1
  type     = "A"
  zone_id  = "81c7f2de8dfxxxxxx52629xxxxxxfc"
  settings = {}
}

resource "cloudflare_dns_record" "terraform_managed_resource_89xxxxx0bf9cxxxxxx9a_1" {
  content  = "35.27.108.33"
  name     = "terraform.example.com"
  proxied  = true
  tags     = []
  ttl      = 1
  type     = "A"
  zone_id  = "8xxxxxx7644e428526xxxxxx"
  settings = {}
}

如果有多個域名需要導入，則多次分別設置環境變量CLOUDFLARE_ZONE_ID再重複運行命令即可。

這裡生成的配置文件可以直接使用，也就是我們之後需要的 Terraform 配置文件。然而，此時我們僅僅只是生成了配置文件，但是目前 Terraform 的狀態依然是空的，這時要是直接terraform apply，Terraform 會不管三七二十一將我們剛剛導入的聲明一律視為新增資源，然後甩出一大堆「Alredy Exists」報錯。所以接下來，我們需要將生成的配置文件導入 Terraform 的terraform.tfstate狀態。

Terraform 在 1.5 版本引入了import塊，相比以往一行一行輸入命令的方式更加現代。其導入流程是先生成一個包含import塊的.tf文件，下次進行terraform apply時，Terraform 就會自動為我們執行導入操作。

生成cloudflare_zone的import塊：

cf-terraforming import \
  --resource-type "cloudflare_zone" \
  --modern-import-block \
  --key $CLOUDFLARE_API_KEY \
  --zone $CLOUDFLARE_ZONE_ID >> import.tf

生成cloudflare_dns_record的import塊：

cf-terraforming import \
  --resource-type "cloudflare_dns_record" \
  --modern-import-block \
  --key $CLOUDFLARE_API_KEY \
  --zone $CLOUDFLARE_ZONE_ID >> import.tf

這一步會在當前目錄下生成import.tf，它包含了所需要的導入信息，作用就是告訴 Terraform 上一步生成的每個resource塊到底對應的是哪一個雲服務提供商的資源 ID。這個 ID 是雲服務提供商內部標記資源的代碼，平常是不會在控制面板上顯示的，只有在用 API 特別請求時才會知道。Terraform 在導入過程中需要用到這個 ID 以確認本地的定義對應的雲端資源，以實現嚴格的冪等性。

好了，現在我們運行terraform plan：

$ terraform plan
cloudflare_dns_record.minio_a: Refreshing state... [id=xxxxxxxxxxx53]
cloudflare_zero_trust_tunnel_cloudflared_config.raspberrypi: Refreshing state...
......

Terraform will perform the following actions:

  # cloudflare_dns_record.terraform_managed_resource_0 will be imported
    resource "cloudflare_dns_record" "terraform_managed_resource_REDACTED_0" {
        content     = "67.24.33.108"
        created_on  = "2026-04-08T10:18:12Z"
        id          = "5deb14c21xxxxxxx20f1c8f"
        meta        = jsonencode({})
        modified_on = "2026-04-08T10:18:12Z"
        name        = "example.example.com"
        proxiable   = true
        proxied     = true
        settings    = {}
        tags        = []
        ttl         = 1
        type        = "A"
        zone_id     = "REDACTED"
    }

  # cloudflare_dns_record.terraform_managed_resource_1 will be imported
    resource "cloudflare_dns_record" "terraform_managed_resource_89c149exxxxxxxxxxxba13xxxxxa_1" {
        content     = "35.27.108.33"
        created_on  = "2026-04-08T10:17:54Z"
        id          = "89cxxxxxxxxxxxxxxxxxx09a"
        meta        = jsonencode({})
        modified_on = "2026-04-08T10:17:54Z"
        name        = "terraform.example.com"
        proxiable   = true
        proxied     = true
        settings    = {}
        tags        = []
        ttl         = 1
        type        = "A"
        zone_id     = "81xxxxxxxxxxxxxxxxxxxxxfc"
    }

Plan: 2 to import, 0 to add, 0 to change, 0 to destroy.

────────────────────────────────────────────────────────────────────────────────────────────────────────

Note: You didn't use the -out option to save this plan, so Terraform can't guarantee to take exactly
these actions if you run "terraform apply" now.

如果需要 Add、Change 和 Destroy 的資源數量都是 0，說明我們的導入操作沒有問題，直接terraform apply --auto-approve，資源就導入完成了。

$ terraform apply --auto-approve
cloudflare_dns_record.push_a: Refreshing state... [id=REDACTED]

Terraform will perform the following actions:

  # cloudflare_dns_record.terraform_managed_resource_REDACTED_0 will be imported
    resource "cloudflare_dns_record" "terraform_managed_resource_REDACTED_0" {
        content     = "67.24.33.108"
        created_on  = "2026-04-08T10:18:12Z"
        id          = "REDACTED"
        meta        = jsonencode({})
        modified_on = "2026-04-08T10:18:12Z"
        name        = "example.example.com"
        proxiable   = true
        proxied     = true
        settings    = {}
        tags        = []
        ttl         = 1
        type        = "A"
        zone_id     = "REDACTED"
    }

  # cloudflare_dns_record.terraform_managed_resource_REDACTED_1 will be imported
    resource "cloudflare_dns_record" "terraform_managed_resource_REDACTED_1" {
        content     = "35.27.108.33"
        created_on  = "2026-04-08T10:17:54Z"
        id          = "REDACTED"
        meta        = jsonencode({})
        modified_on = "2026-04-08T10:17:54Z"
        name        = "terraform.example.com"
        proxiable   = true
        proxied     = true
        settings    = {}
        tags        = []
        ttl         = 1
        type        = "A"
        zone_id     = "REDACTED"
    }

Plan: 2 to import, 0 to add, 0 to change, 0 to destroy.
cloudflare_dns_record.terraform_managed_resource_REDACTED_1: Importing... [id=REDACTED/REDACTED]
cloudflare_dns_record.terraform_managed_resource_REDACTED_1: Import complete [id=REDACTED/REDACTED]
cloudflare_dns_record.terraform_managed_resource_REDACTED_0: Importing... [id=REDACTED/REDACTED]
cloudflare_dns_record.terraform_managed_resource_REDACTED_0: Import complete [id=REDACTED/REDACTED]

Apply complete! Resources: 2 imported, 0 added, 0 changed, 0 destroyed.

狀態存儲和持續集成

IaC 的核心價值之一就在於可以輕易實現基於 Git 的多人協作，以及 CI 的持續集成，但是在此之前，又有一個新的問題需要解決——terraform.tfstate到底放哪裡：沒人想要換一次環境辛辛苦苦導入的狀態就丟一次。

Terraform 目前支持以下幾種保存狀態的後端：

local
remote
azurerm
consul
cos
gcs
http
Kubernetes
oci
oss
pg
s3

沒有特殊需求可以像我一樣選擇s3，畢竟 Cloudflare R2 有免費額度，不用白不用。

terraform {
  backend "s3" {
    bucket = "terraform"
    key    = "terraform.tfstate"
    region = "auto"
    endpoints = {
      s3 = "https://REDACTED.r2.cloudflarestorage.com"
    }

    # R2 不需要這些 AWS 的驗證
    skip_credentials_validation = true
    skip_metadata_api_check     = true
    skip_region_validation      = true
    skip_requesting_account_id  = true
    use_path_style              = true
  }
}

對於 S3 的後端，建議用AWS_ACCESS_KEY_ID和AWS_SECRET_ACCESS_KEY兩個環境變量來存儲 Credentials：

export AWS_ACCESS_KEY_ID='REDACTED'
export AWS_SECRET_ACCESS_KEY='REDACTED'

配置完成，運行terraform init -migrate-state，配置就成功存儲到雲上了，以後不論在何處修改配置、運行terraform apply都無須擔心 Terraform 的 State 不同步的問題。

接下來就是 Github CI 的配置，其實很簡單，無非就是每次git push時觸發一次terraform init、terraform fmt和terraform apply，以下是我的.github/workflows/apply.yml：

name: "Terraform Apply"

on:
  push:
    branches:
      - main

env:
  TF_IN_AUTOMATION: "true"
  CLOUDFLARE_API_TOKEN: "${{ secrets.CLOUDFLARE_API_TOKEN }}"
  AWS_ACCESS_KEY_ID: "${{ secrets.AWS_ACCESS_KEY_ID }}"
  AWS_SECRET_ACCESS_KEY: "${{ secrets.AWS_SECRET_ACCESS_KEY }}"
  TF_VAR_cloudflare_zone_id_example_com: "${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_COM }}"
  TF_VAR_cloudflare_zone_id_example_top: ${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_TOP }}

jobs:
  terraform:
    name: "Terraform Apply"
    runs-on: ubuntu-latest
    permissions:
      contents: read
    concurrency:
      group: terraform-apply
      cancel-in-progress: false
    steps:
      - name: Checkout
        uses: actions/checkout@v6

      - name: Setup Terraform
        uses: hashicorp/setup-terraform@v4

      - name: Terraform Init
        run: terraform init -input=false

      - name: Terraform Apply
        run: terraform apply -input=false -auto-approve

對於 PR 則應當讓 CI 自動為每次 PR 附上terraform plan的輸出：

name: Terraform Plan

on:
  pull_request:
    paths:
      - "**/*.tf"
      - ".github/workflows/terraform-plan.yml"

permissions:
  contents: read
  pull-requests: write

env:
  TF_IN_AUTOMATION: "true"
  CLOUDFLARE_API_TOKEN: ${{ secrets.CLOUDFLARE_API_TOKEN }}
  AWS_ACCESS_KEY_ID: ${{ secrets.AWS_ACCESS_KEY_ID }}
  AWS_SECRET_ACCESS_KEY: ${{ secrets.AWS_SECRET_ACCESS_KEY }}
  TF_VAR_cloudflare_zone_id_example_com: "${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_COM }}"
  TF_VAR_cloudflare_zone_id_example_top: ${{ vars.TF_VAR_CLOUDFLARE_ZONE_ID_EXAMPLE_TOP }}

jobs:
  plan:
    name: Terraform Plan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6

      - uses: hashicorp/setup-terraform@v4

      - name: Terraform fmt
        id: fmt
        run: terraform fmt -check -recursive
        continue-on-error: true

      - name: Terraform Init
        id: init
        run: terraform init -input=false

      - name: Terraform Validate
        id: validate
        run: terraform validate -no-color

      - name: Terraform Plan
        id: plan
        run: terraform plan -input=false -no-color
        continue-on-error: true

      - name: Post Plan to PR
        uses: actions/github-script@v8
        with:
          github-token: ${{ secrets.GITHUB_TOKEN }}
          script: |
            const { data: comments } = await github.rest.issues.listComments({
              owner: context.repo.owner,
              repo: context.repo.repo,
              issue_number: context.issue.number,
            });
            const botComment = comments.find(c =>
              c.user.type === 'Bot' && c.body.includes('')
            );

            const planOutput = `${{ steps.plan.outputs.stdout }}`.substring(0, 65000);

            const body = `
            #### Terraform Plan

            | Step     | Result                            |
            | -------- | --------------------------------- |
            | fmt      | \`${{ steps.fmt.outcome }}\`      |
            | init     | \`${{ steps.init.outcome }}\`     |
            | validate | \`${{ steps.validate.outcome }}\` |
            | plan     | \`${{ steps.plan.outcome }}\`     |

            展開 Plan 詳情

            \`\`\`terraform
            ${planOutput}
            \`\`\`
            `;

            if (botComment) {
              await github.rest.issues.updateComment({
                owner: context.repo.owner,
                repo: context.repo.repo,
                comment_id: botComment.id,
                body
              });
            } else {
              await github.rest.issues.createComment({
                issue_number: context.issue.number,
                owner: context.repo.owner,
                repo: context.repo.repo,
                body
              });
            }

      - name: Fail if plan failed
        if: steps.plan.outcome == 'failure'
        run: exit 1

後續的工作流程

到這一步，Terraform 的「接管初始化」已經結束了，後面就進入了日常維護階段。這個階段其實就三件事：

創建新資源
修改現有的資源
刪除不再需要的資源

常用的操作就兩個：terraform plan和terraform apply，如果是個人使用，小的改動直接提交就算了；如果是團隊協作，每次修改則應當遵循能 PR 就不直接 Commit 的原則。

創建基礎設施

假設你現在要新增一條 DNS 記錄，或者新建一個 Tunnel、一個對象存儲桶，流程如下：

flowchart TD
  C1[新建分支
如 feat/add-minio-record] --> C2[新增 resource 塊]
  C2 --> C3[terraform fmt + validate]
  C3 --> C4[terraform plan]
  C4 --> C5{僅新增預期資源?}
  C5 -- 否 --> C6[修正配置後重跑 plan]
  C6 --> C4
  C5 -- 是 --> C7[提交 PR]
  C7 --> C8[合併後 CI apply]

最理想的plan輸出是：

X to add
0 to change
0 to destroy

如果你只是想加東西，結果出現了to destroy，那就先別衝動，通常是引用寫錯、變量搞錯，或者不小心改了資源地址，仔細檢查是什麼地方出了問題。

修改與刪除基礎設施

修改流程和創建類似，但要多一步——評估變更是否會觸發重建。

因為很多 Provider 字段是ForceNew，你以為只是改個字段，Terraform 看完說：「好的，刪了重建。」這在我們修改 DNS 的這個場景並不是什麼很大的問題，但是到了雲實例這種資源，如果刪除重建勢必會造成損失。

建議按下面這個順序來：

flowchart TD
  M1[修改 .tf] --> M2[terraform plan]
  M2 --> M3{出現 replace/destroy?}
  M3 -- 否 --> M7[確認影響範圍]
  M7 --> M8[terraform apply]
  M3 -- 是 --> M4[暫停並複核變更]
  M4 --> M5[必要時加 lifecycle 保護]
  M5 --> M6[安排變更窗口]
  M6 --> M8

對生產環境來說，創建、修改得慢一點並不是什麼很大的問題，最應當看重的是操作的正確性，慢一點，不要出錯。IaC 不是比手速，IaC 比的是可預期性。

如果是刪除資源（比如下線某個 DNS 記錄、清理廢棄 Tunnel），走下面這個流程⁶：

flowchart TD
  D1[確認資源已廢棄
  檢查業務/監控/腳本依賴] --> D2[刪除 resource 塊或調整 count/for_each]
  D2 --> D3[terraform plan]
  D3 --> D4{to destroy 是否符合預期?}
  D4 -- 否 --> D5[回滾修改並繼續排查依賴]
  D5 --> D1
  D4 -- 是 --> D6[準備回滾方案並選低峰窗口]
  D6 --> D7[PR 審核通過]
  D7 --> D8[terraform apply]
  D8 --> D9[刪除資源後的可用性檢查]

日常協作建議

把 Credentials 放環境變量或 CI Secret，別寫進.tf和倉庫
對關鍵資源開啟保護策略，防止誤刪
將目錄按資源類型拆分
定期執行terraform plan做基礎設施漂移檢查⁷和校正，避免在面板誤操作手動修改

雖然這套流程看起來很麻煩，但每一次變更都有記錄、可審計、可回滾，最重要的是可復現，這才是 IaC 最有價值的地方。

參考

Infrastructure as Code，是指採用機器可讀的配置文件定義所需要的基礎設施的部署方法。 ↩︎
每個供應商的配置文件字段命名和格式都有區別，但這可以很容易的編寫腳本進行轉換。 ↩︎
需要特別注意的是，狀態文件中可能包含數據庫密碼、API 密鑰等明文存儲的敏感信息，因此絕對不要將 .tfstate 文件提交到公開的代碼倉庫中。 ↩︎
HashiCorp Configuration Language，HashiCorp 自家開發的一種聲明式配置語言，旨在兼顧機器可讀性與人類可讀性。 ↩︎
冪等性（Idempotence）指計算機系統或接口在接收到同一請求的多次操作時，產生的影響與一次執行的結果相同，不論執行多少次，系統的最終狀態始終保持一致。 ↩︎
如果你僅僅是想讓 Terraform 不再管理某個資源，而不是真正在雲端銷燬它，應該使用 terraform state rm 命令，而不是在代碼中刪掉資源塊然後 apply，否則雲環境上的真實資源也會被一併銷燬。 ↩︎
基礎設施漂移（Infrastructure Drift）是指現實中通過控制檯點按等非 IaC 途徑修改了基礎設施，導致其實際狀態與代碼中聲明的狀態不一致的情況。 ↩︎

永遠忙碌

Fri, 13 Mar 2026 15:14:26 +0000

工作，工作，至死方休。

寒假給別人上課，幾乎就沒有停過，春節名義上休息，也只不過是換了一種形式工作罷了——各種應酬，舟車勞頓，回家剛安頓好，又馬不停蹄的投入到上課工作中去。給別人上課也真是不容易，跟我在同一家機構當助教的同學一起交流時，大家都戲稱上課就是「赤石」：死記硬背的是記不住的，算數是不會算的，概念是混淆的，交流是沒辦法正常交流的。這倒也不怪他們，要怪也只能怪他們經歷過的教育環境，畢竟家家有本難唸的經。各種原因導致他們基本上走的都是高職單招，沒有經過高考的洗禮，有的甚至連初中都沒怎麼讀好，現在也只是想找個工作，所以才願意花錢請我們來給他們上一對一課程。

一開始我在一家機構做助教，後來出來單幹，提高了部分收入，還節省了部分備課的時間。每天的上課是從7:30-11:00,價格是 ¥400。看似時薪過百比較高，實則結合學生的基礎狀況考慮，這錢我是賺得問心無愧，甚至我可以說，這錢真賺得也是不容易。

回到正題，現在開學了，我又要馬不停蹄的投入到我自己的學業事務中去。真的感覺自己永遠都在忙，所謂的休息，也只不過是換點輕鬆的事情做一做罷了，教學教累了回家就 Vibe Coding 放鬆一下，坐在電腦前煩躁了就把家裡收拾一下打掃衛生。在做事情的動力、以及人的有限總精力這方面，我能真切的感受到人與人之間的差距：有的人天賦異稟，精力非常充沛，成果做了一個又一個，論文發了一篇又一篇，產出很高，好像制約他們的永遠都是時間，而不是他們的精力和動力；而更多人則是像我一樣的凡人，即使想要這種生活狀態，卻也還是心有餘而力不足，可是看到前面一類人的高產，又難免心生焦慮，只能在最大限度下把自己當成一個實際永動機¹。

從小到大接受的中式教育異化了我們，那句湯家鳳經典的「你這個年紀怎麼睡得著的」，雖然本意是訓斥上課睡覺的學生，卻也在某種程度上潛移默化影響著我們這一代，以至於到了一種病態的狀態。人生沒有絕對的「上岸」，小學要去上小升初的岸，初中要去上中考的岸，高中要去上高考的岸，大學要去上考研、讀博、考公、找工作的岸，完成學業參加工作了，還有各種升遷績效、柴米油鹽需要考慮。工作，工作，至死方休。想要上岸而一勞永逸嗎，不好意思，那是不可能的。

雖然深知這一點，我還是會停下來休息就空虛難受，所以，永遠忙碌，永遠工作。滿足自己身體需要的休息，用鍛鍊身體平衡自己的內分泌，休息就是換一件自己喜歡且比較輕鬆的事情做，由於受中式教育、績優主義的影響太深，這種生活狀態，我想在很長一段時間裡是不會改變了。

不過往好的方面看，通過這段時間的忙碌，我也是自己把自己這個學期的生活費給賺出來了，還有富餘給我媽準備一臺新手機當生日禮物。突然也覺得，永遠忙碌這件事，好像也沒這麼糟。

這裡是用理想電流源和實際電流源的區別來類比所謂「理想永動機」和實際永動機的區別——前者是真正意義上的永動機，後者則是我等凡夫俗子用血肉之軀拼勁全力去接近的「實際永動機」 ↩︎

培訓機構的人血饅頭

Wed, 11 Feb 2026 09:06:57 +0000

最近在某家民營電網培訓機構給準備國網二批考試的學生一對一輔導，每天晚上上課三個半小時，給 200。

這家機構給我的錢偏少還不是最嚴重的問題。問題出在他們給學生的收費上：有兩種方案，一種是所謂「卓越計劃」，收費 12 萬，但是一對一課程不限量；另一種是「協議班」，收費 7 萬，但每次上一對一課程要交 450。

昨天給他們一學生私下開小灶，下午上課三個半小時，本來我想著既然私下找我，那就不經過這個培訓機構，學生直接給我結款 300——我能多賺一百，ta 能少花 150。結果那個學生腦子沒轉過彎，找班主任請假的時候竟然說要找我補課，於是他們就直接「善意地」幫我找家長收了 450。

這還沒完。最後給我算工時，他們把這次課歸為所謂「額外課時」，說我違規利用了下午的「備課時間」給非卓越計劃的學生上課——三個半小時，只給了 120。

簡而言之：

學生付 450 → 機構抽走 330 → 我拿到 120

本該到我手上的 300 變成了 120，我自然是不爽。但比起我個人少拿的那一百多塊錢，更讓我不舒服的是這件事本身的性質。這些考國網二批的學生很多都是家境不太富裕的專科生，他們平日裡已經飽受歧視，想盡一切辦法想要改變命運，現在下了血本，花上可能是他們一個家庭一年收入的幾萬甚至十幾萬來讀這個國網課程。他們以為自己買的是一劑改命的「藥」，殊不知這藥引子是用自己的血和著吃的——而我辛苦勞動輔導學生，分到手裡的錢佔比卻比坐享其成的培訓機構還要低。

這根本就是在吃人血饅頭。

這一單，機構躺著淨賺 330。這顯然令人難以接受。我已經通知那位學生，令其下次請假時表現更加靈活；也和 ta 的班主任做出交涉，令她不要上報甚至干預我們私下的補課。考慮到班主任也是打工人，並且有學員成績的 KPI，我想她也不會蠢到跟自己的 KPI 過不去。當然，這家機構最好好自為之，否則我在「備課」時那句「助教們組建臨時工會，集體發動罷工，要求漲薪」的玩笑話，在將來的某天恐怕得一語成讖。

不得不感嘆，到底誰才是資本主義啊——我看這機構的人血饅頭鋪子開得還挺熟練的。

2025 年度總結

Wed, 31 Dec 2025 11:28:17 +0000

真是忙碌的一年，不知不覺間，時間又到了年末。今年事情確實很多，奔波勞碌少不了，但也取得了階段性的收穫。我謹再次提筆寫下一篇年終總結，作為一年的見證。

電氣的盡頭是電網

為求職四處奔波

我在一整年的休學生活以後如期復學，開始我的大學最後一年，成為一名「應屆生」，所以，找工作的事情也就理所應當的排上了日程。作為電氣工程專業的學生，出身原電力部屬院校，工作倒是不算難找。不過說容易也不算很容易，畢竟大環境如此，經濟增長放緩，國際形勢不明朗，用人需求減少，各種地方都越來越卷。

九月份跑了場雙選會，線下投了幾份簡歷，也在網上投了四五份簡歷，收到面試通知的只有兩家。也算切身感受到了，原電力部屬院校的頭銜，幾乎只在電力系統內部¹有用。現在這就業形勢也就這樣，除了電力系統，但凡待遇稍微好一點的工作都不是我們這種「雙非院校」的學生隨便就能找到的。不過對比起來，人家好歹還收你的簡歷，像是有些專業甚至連簡歷都不收。

兩大電網的筆試

電網工作是本專業最對口，最穩定的工作。本專業最大的用人單位——國家電網和南方電網，都需要通過筆試來獲得面試資格。筆試一共需要考 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。顯然，位數越小，玩家水平越高。 ↩︎

從頻率崩潰到電壓失控：兩起大型停電事故帶來的啟示

Wed, 17 Dec 2025 16:08:30 +0000

現代電網正在經歷一次巨大的轉型，隨著光伏、海上風電等新能源的佔比在電網中越來越高，新能源和電力電子設備低轉動慣量、低短路容量、換流設備需要大量無功支撐的特點以及它們給電網帶來的不利影響也愈發明顯。在此背景下，兩期相隔六年相繼發生在歐洲的大型停電事故顯得尤為耐人尋味，本文將簡要闡述兩起事故的來龍去脈，對比它們的異同，分析造成這兩起事故的本質原因，以及思考它們對現代電網的運行所帶來的啟示。

事故概述

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 15:53:48 +0000

最近我比較忙碌，但空閒之餘，文字仍然是我的棲息地。每天早上 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 10:30:00 +0000

自從開始使用 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：

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 配置完成以後便可以下載配置文件並啟動內核：

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 策略問題無法連接。

$ 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 即可在每天凌晨三點自動更新配置：

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 11:54:56 +0000

看到「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 ↩︎

亂筆