技術 on 亂筆

關於 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 途徑修改了基礎設施，導致其實際狀態與代碼中聲明的狀態不一致的情況。 ↩︎

拋棄所謂「客戶端」，直接使用 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"
  }
}

這麼折騰，何必呢？用客戶端不香嗎？

別問，問就是玩虛空終端玩的。

從入門到進階：Tailscale + ShellCrash 異地組網和科學上網

Mon, 14 Apr 2025 10:10:25 +0000

在幾次旅途中，我試圖將新拍的照片上傳到長沙家中的 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 雙棧地址。

如果以上條件都具備，就可以開始部署了。

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 客戶端無法正確連接。

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，可以讓你在陌生的網絡環境中保持安全。

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

廣播完成後，無論身處何地，只要能連上 Tailscale 網絡，就能訪問家中所有的內網設備。

啟用 IP 轉發和禁用 UDP GRO⁴

啟用 IP 轉發是樹莓派等設備作為 Exit Node 所必須的配置，這裡以樹莓派為例，如果你使用其他設備，請自行查閱 Tailscale 官網教程。

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 配置文件：

# 創建服務文件
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

隨後啟動服務：

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  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
        inet6 fe80::c0d5:1a1b:2005:48eb  prefixlen 64  scopeid 0x20
        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 流量：

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。

創建一個腳本：

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：

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

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

@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：

sudo apt update
sudo apt install iptables-persistent

安裝過程中會提示你是否保存當前的 IPv4 和 IPv6 配置，選擇「是」即可。之後如果你添加了新的規則，記得執行保存命令：

# 保存當前 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 流量，還被用來接收原本屬於外部世界的網絡連接，實現對外部流量的本地劫持和轉發。 ↩︎

Google Play 商店的國內 CDN：從密碼學入門到分流策略優化

Sat, 15 Mar 2025 13:15:01 +0000

改用自己的 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域名提供服務，而這個域名在大多數分流規則中都是直連，對，問題就出在這裡，修改規則把這個域名分流到代理就萬事大吉了！

……萬事大吉了，嗎？

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 的基礎設施。先來看一些完整的連接域名：

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），對應的域名特徵可以通過正則表達式識別：

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 直連與海外域名代理的智能分流：

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

最速 Substore 訂閱管理指南

Fri, 07 Mar 2025 10:54:29 +0000

當我趁著春節各家機場的促銷訂閱多個機場之後，如何充分利用每個節點就變成了說難不難說簡單也不簡單的問題，我當然可以訂閱各家機場提供的配置文件，然後在他們之間切換，但這樣未免也太麻煩了。更何況我還有自建節點，我可不想為了這一個節點專門去開一個新的配置。

Sub-Store 很好的解決了這個問題，它可以從多個訂閱中抽取節點信息，通過正則表達式或者 JS 整理它們，最後輸出一個整合了所有節點信息的訂閱。

部署它可以直接使用 xream 打包好的鏡像，這個鏡像整合了前後端，如果在公網部署，記得更改一下後端路徑，否則你的配置文件很可能會被盜用。

services:
  sub-store:
    image: xream/sub-store
    container_name: substore
    restart: always
    environment:
      - SUB_STORE_CRON=55 23 * * *
      - SUB_STORE_FRONTEND_BACKEND_PATH=/super-random-path
    ports:
      - "3001:3001"
    volumes:
      - ./data:/opt/app/data

反代 3001 端口即可訪問 Substore 的前端，這裡以 Caddy 為例：

sub-domain.example.com {
        reverse_proxy :3001
}

當然，初次進入前端別忘了新增後端地址，這時的後端地址取決於之前 compose file 裡的設置，在本文的例子中，後端地址為https://sub-domain.example.com/super-random-path。

組合訂閱的管理

添加所有機場上游和自建節點之後，就可以開始把它們全都加進單個組合訂閱，但各個機場對節點的命名五花八門，默認情況下看起來非常雜亂，甚至不同機場之間的節點還有重名的可能。好在 Sub-Store 有通過腳本對節點進行批量重命名操作的功能，這裡推薦一個腳本，能夠幫我們為所有的機場節點重命名。

欲使用這個腳本，只需在編輯訂閱時將以下地址粘貼到腳本操作處即可。

https://raw.githubusercontent.com/Keywos/rule/main/rename.js

最後再進行一些你喜歡的節點操作，可以整理出一個統一規範的節點列表。

生成 Clash 配置

現在雖然已經有了節點列表，但現在生成的配置文件並不包含任何規則，需要自行編寫或者拉取第三方規則。

轉到 Substore 的文件管理，創建一份新的 Mihomo 配置：

「來源」選擇組合訂閱，並在訂閱名稱上選擇你的訂閱組
在腳本操作中填入自己的覆寫配置

這是我自己的覆寫規則 powerfullz/override-rules，為 Mihomo/Substore 設計，核心特色如下：

集成 SukkaW/Surge 與 217heidai/adblockfilters 等優質規則，兼容性強，覆蓋面廣。
針對 Truth Social、E-Hentai、TikTok、加密貨幣等場景，新增專用分流規則，滿足多樣化需求。
精簡冗餘，結構清晰，維護便捷。
深度融合 Loyalsoldier/v2ray-rules-dat GeoSite/GeoIP，分流更精準。
IP 規則默認添加 no-resolve，有效減少本地 DNS 解析，提升速度與隱私。
動態覆寫：自動識別節點國家/地區，僅生成實際存在的分組，節點名稱實時枚舉，配置更智能。

JavaScript 格式覆寫

複製 JavaScript 格式覆寫文件的鏈接https://cdn.jsdelivr.net/gh/powerfullz/override-rules@1/convert.min.js，並根據需要在後面附加參數，格式如下：

https://cdn.jsdelivr.net/gh/powerfullz/override-rules@1/convert.min.js#參數1=true&參數2=true

目前支持如下參數：

參數	功能
`loadbalance`	啟用國家/地區節點組的負載均衡
`landing`	啟用落地節點功能
`ipv6`	啟用 IPv6 支持
`full`	生成針對純內核使用場景的完整配置
`keepalive`	啟用 TCP KeepAlive
`quic`	允許 QUIC 流量¹
`fakeip`	DNS 增強模式使用 fake-ip²
`regex`	各國家代理組改用 include-all + 正則過濾模式³
`threshold`	國家/地區節點數量小於該值時不顯示分組（默認 0）

例如，若有負載均衡和 IPv6 需求，最終的覆寫腳本鏈接為：

https://cdn.jsdelivr.net/gh/powerfullz/override-rules@1/convert.min.js#loadbalance=true&ipv6=true

將最終的覆寫腳本鏈接粘貼到腳本操作處，使用 Substore 的生成預覽功能確認沒有問題後即可保存。

YAML 格式覆寫

~~YAML 格式覆寫我自己已經不用了，隨緣維護，但歡迎 PR~~

寫了個 Github Actions 自動根據 JS 格式覆寫生成 YAML 格式覆寫，所以現在 YAML 格式又開始維護了。

除了直接引用 convert.js 動態覆寫，你也可以使用倉庫中預先生成好的 32 份 YAML 格式覆寫——它們都放在 yamls/ 目錄裡，由 GitHub Actions 在每次推送後自動重新生成、覆蓋。適用於諸如 Clash Verge 等不支持 JS 覆寫的客戶端和轉換服務。

文件命名規則：

config_lb-{0|1}_landing-{0|1}_ipv6-{0|1}_full-{0|1}_keepalive-{0|1}_fakeip-{0|1}_quic-{0|1}.yaml

示例（開啟 full，其餘關閉）：

https://raw.githubusercontent.com/powerfullz/override-rules/refs/heads/main/yamls/config_lb-0_landing-0_ipv6-0_full-1_keepalive-0_fakeip-0_quic-0.yaml

CI 只是套用一份假的fake_proxies.json來生成覆寫，所以不可能實現 JS 覆寫自動根據節點匹配生成對應代理組的功能，只能把所有地區節點組都放進去。如果你已經搭建 Substore，並且想要「動態識別國家 + 傳參」的靈活性，還是推薦使用 JS 覆寫。

生成下載鏈接

保存成功後點擊分享按鈕生成分享鏈接，設置分享有效期後點擊「創建分享」，生成的鏈接即最終成型的 Mihomo 配置文件，將其作為訂閱鏈接在你的代理軟件內訂閱就大功告成了。

部分機場 UDP 性能差，開啟後可能出現體驗降級。 ↩︎
開啟後可能有助於解決 TUN 模式無法上網的問題。 ↩︎
各國家代理組改用 include-all + 正則過濾模式，由 Mihomo 內核在運行時按正則動態篩選節點，而非在腳本執行時枚舉節點名稱（默認 false） ↩︎

我的家庭網絡域名解析方案

Thu, 06 Feb 2025 09:01:51 +0000

人在中國，用起 DNS 會碰到兩個問題，一個是 DNS 汙染，另一個是 DNS 洩露。想要上網上得痛快，就必須要先解決 DNS 的問題。

什麼是 DNS 洩露

如果你現在正在開著代理看這篇文章，可以先打開這個網站檢測一下自己的 DNS 請求是否被髮送到了國內的 DNS 服務器上。

簡單來說，當你在使用 VPN 等代理工具時，你認為你的請求不會被除了你和 VPN 提供商以外的第三方看到，然而主機的 DNS 請求卻被髮送送給了運營商的 DNS 服務器或者是公共 DNS 服務器(阿里、騰訊等)進行解析，而你的真實 IP 地址和請求的域名都會被記錄下來。如果 DNS 請求解析一些敏感網站的域名(比如電報、維基解密等)，就會被監管者注意到，從而被警告或者請去喝茶。¹

因此，正確地配置代理工具的分流策略來避免 DNS 洩露就顯得尤為重要。

SmartDNS 的配置

防止 DNS 洩露

DNS 作為上網的指路人，排在第一位的要求就是必須要快，在這樣的要求下本地部署 SmartDNS 充當家庭網絡的 DNS 服務器真的再合適不過了。關於 SmartDNS 的作用和配置技巧，以及其如何優選 CDN 加快網絡訪問速度，Sukka 的「我有特別的 DNS 配置和使用技巧」已經講的很好，推薦在繼續閱讀本文之前先去看看這篇文章，其中的內容我在這裡便不再贅述，我的敘述重心將會放在如何在 Luci 界面上實現這些配置。

如果你和我一樣使用 OpenWRT，SmartDNS 的 Luci App 會在每次啟動時根據面板上保存的配置自動生成新的配置文件，所以，不要直接修改/etc/smartdns目錄下原有的配置文件，所有的更改都應該在 Luci App 裡操作。

基本上，SmartDNS 上游數量越多越好，因為較多的上游並不會影響 SmartDNS 的性能²，並且多個上游可以增加冗餘。為了防止 DNS 洩露，在配置上游時，應當在默認分組添加國外 DNS 上游（當然，最好是加密 DNS），並將國內的服務器歸入一個單獨的分組（例如domestic），並加上-exclude-default-group的額外參數以將它們從默認分組中排除。

加速國內域名解析

設置好國外上游，DNS 洩露的問題就解決了，但因為我們在默認分組中排除了國內上游，訪問新的域名時需要等待國外上游返回結果，這顯然會拖慢國內網站的訪問速度，並且還會劣化 CDN。

dnsmasq-china-list 是 Felix Yan 的項目，目前支持通過 Makefile 生成 SmartDNS 格式的配置文件，目前已經有人做好了現成的 Github Action 每天自動更新，直接下載就可以了，注意這些配置文件只會在國內 DNS 上游分組名稱為domestic時生效。

cd /etc/smartdns
wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/accelerated-domains.china.domain.smartdns.conf
wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/apple.china.domain.smartdns.conf
wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/chinalist.domain.smartdns.conf
wget https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/google.china.domain.smartdns.conf

隨後在 SmartDNS 中引入這些配置文件，將下面的內容粘貼到「自定義設置」欄的末尾。

conf-file /etc/smartdns/accelerated-domains.china.domain.smartdns.conf
conf-file /etc/smartdns/apple.china.domain.smartdns.conf
conf-file /etc/smartdns/chinalist.domain.smartdns.conf
conf-file /etc/smartdns/google.china.domain.smartdns.conf

這樣配置之後，國內域名的訪問速度便不再會受到影響，訪問國外域名時，也不會再有 DNS 洩露的問題了。

去廣告

DNS 層面的去廣告效果有限，重點應該放在防止誤殺上，所以不要用那臭名昭著³的號稱自己是「致力於成為中文區命中率最高的廣告過濾列表」的 Anti AD，而是使用一些別的規則。個人使用的規則是 217heidai/adblockfilters，這是一個已經整理好的聚合規則，直接拉取即可。

wget -O /etc/smartdns/adblock.conf https://gcore.jsdelivr.net/gh/217heidai/adblockfilters@main/rules/adblocksmartdns.conf

最後引入配置文件：

conf-file /etc/smartdns/adblock.conf

自動更新規則

設置如下 Crontab 即可在每天凌晨三點自動更新所有規則。

0 0 3 * * ?  wget -O /etc/smartdns/adblock.conf https://gcore.jsdelivr.net/gh/217heidai/adblockfilters@main/rules/adblocksmartdns.conf
0 0 3 * * ? wget -O /etc/smartdns/accelerated-domains.china.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/accelerated-domains.china.domain.smartdns.conf
0 0 3 * * ? wget -O /etc/smartdns/apple.china.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/apple.china.domain.smartdns.conf
0 0 3 * * ? wget -O /etc/smartdns/chinalist.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/chinalist.domain.smartdns.conf
0 0 3 * * ? wget -O /etc/smartdns/google.china.domain.smartdns.conf https://gcore.jsdelivr.net/gh/Olixn/china_list_for_smartdns@main/google.china.domain.smartdns.conf

旁路由可以用嗎

除非不使用 IPv6，否則最好還是將 OpenWRT 路由器作為主路由。在作為旁路由的情況下，某些系統（說的就是你，Windows）會不遵守旁路由廣播的 IPv4 DNS，而執意使用運營商光貓廣播的 IPv6 DNS 進行解析，我嘗試修改過一些相關的註冊表鍵值，但毫無作用。無奈只好讓運營商上門將光貓改為橋接模式，並將 OpenWRT 用作主路由。

覆寫 Clash 規則

這時如果你開著 Clash 去跑 DNS 洩露測試，大概率還是會看到你的 DNS 請求被髮到了中國的 DNS 服務器上——幾乎所有機場的默認配置都會使用騰訊、阿里等國內大廠的加密 DNS，雖然不至於明文洩露到運營商 DNS 而導致你接到反詐中心的電話，但總讓人膈應 ~~（強迫症犯了）~~，更有甚者甚至完全沒有相關配置。

好在如果使用的是 Clash Verge Rev，那麼可以很方便的覆寫機場的配置，這裡分享我的覆寫配置，將其粘貼到全局擴展配置中即可覆寫機場的配置。

dns:
  enable: true
  ipv6: false
  prefer-h3: true
  use-system-hosts: true
  nameserver:
    - "https://dns.cloudflare.com/dns-query"
    - "https://dns.sb/dns-query"
    - "https://dns.google/dns-query"
    - "https://public.dns.iij.jp/dns-query"
    - "https://jp.tiar.app/dns-query"
    - "https://jp.tiarap.org/dns-query"
  nameserver-policy:
    "geosite:cn":
      - system
  fallback:
    - "tls://8.8.4.4"
    - "tls://1.1.1.1"
  proxy-server-nameserver:
    - "https://doh.pub/dns-query"
    - "https://223.5.5.5/dns-query"
  direct-nameserver:
    - system

配置解析

根據 Mihomo 文檔⁴，其 DNS 請求的流程如下：

flowchart TD
  Start[客戶端發起請求] --> rule[匹配規則]
  rule -->  Domain[匹配到基於域名的規則]
  rule --> IP[匹配到基於 IP 的規則]

  Domain --> |域名匹配到直連規則|DNS
  IP --> DNS[通過 Clash DNS 解析域名]


  Domain --> |域名匹配到代理規則|Remote[通過代理服務器解析域名並建立連接]

  Cache --> |Redir-host/FakeIP-Direct 未命中|NS[匹配 nameserver-policy 並查詢 ]
  Cache --> |Cache 命中|Get
  Cache --> |FakeIP 未命中,代理域名|Remote

  NS --> |匹配成功| Get[將查詢到的 IP 用於匹配 IP 規則]
  NS --> |沒匹配到| NF[nameserver/fallback 併發查詢]

  NF --> Get[查詢得到 IP]
  Get --> |緩存 DNS 結果|Cache[(Cache)]
  Get --> S[通過 IP 直接/通過代理建立連接]

  DNS --> Redir-host/FakeIP
  Redir-host/FakeIP --> |查詢 DNS 緩存|Cache

其中nameserver-policy的優先級高於nameserver和fallback，指定geosite:cn中的網站以系統 DNS 查詢，也就是使用之前配置好的 SmartDNS 查詢，可以享受到局域網級別的響應速度和自帶測速的 CDN 選擇。而不在geosite:cn中的網站則使用nameserver/fallback查詢，使用國外加密上游就可以確保解析結果的可信並防止 DNS 洩露。

替換 geoip 和 geosite 數據庫

Mihomo 默認使用 V2Ray 官方的 geoip 和 geosite 數據庫，這個數據庫其實不太全，而且更新的頻率也很慢，所以我還是用 Loyalsoldier/v2ray-rules-dat 這個「加強版」數據庫替換了原來的數據庫，只需下載geoip.dat和geosite.dat以後丟進內核目錄即可。當然，也可以新增幾行覆寫配置以實現自動/一鍵更新：

geodata-mode: true
geox-url:
  geoip: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geoip.dat"
  geosite: "https://github.com/Loyalsoldier/v2ray-rules-dat/releases/latest/download/geosite.dat"

Clash Meta For Android

對於手機上的 Clash Meta For Android（以下簡稱 Clash），覆寫設置時需要更加考慮手機的實際情況。

首先手機上的 Clash 覆寫設置選項就不如桌面端的 Clash Verge Rev 這麼靈活，很多鍵值都不能覆寫。另外，手機不像電腦，需要經常切換網絡環境，這就導致系統 DNS 也會換得很頻繁，經測試，在這種情況下，每次更換網絡環境都需要開關一次 Clash 才能讓其更新system所代表的 DNS。於是我們只能退而求其次，固定一個國內加密 DNS 作為國內查詢。

進入 Clash ->「設置」->「覆寫」以下是所有覆寫設置：

「DNS」->「策略」：強制啟用
「DNS」->「Prefer h3」：已啟用
「DNS」->「Name Server」：添加兩個國外加密 DNS
「DNS」->「Name Server 策略」：在「鍵」一欄中填寫geosite:cn，值一欄填寫https://doh.pub/dns-query

提前從 Github 上下載geoip.dat和geosite.dat，最後進入 Clash ->「設置」->「Meta Features」，分別用「導入 GeoIP 數據庫」和「導入 GeoSite 數據庫」功能導入它們。

完成

最後再打開一個 DNS 洩露測試，看一看問題是否解決，如果不再出現國內的 DNS，說明配置正確，好好享受 SmartDNS 和 Clash 帶來的網絡優化和防洩漏吧~

參考自: https://blog.lololowe.com/posts/8f1e/ ↩︎
SmartDNS 在設計時就考慮到了延遲問題，具體機制可以參考「中場休息：SmartDNS 是如何避免因測速導致 DNS 解析過慢的」。 ↩︎
有人整理了 Anti AD 的光榮事蹟。 ↩︎
引用自: https://wiki.metacubex.one/config/dns/diagram/ ↩︎

Windows Hiccup 小日常：處理時間同步服務的問題

Mon, 18 Nov 2024 10:03:47 +0000

不知出了什麼問題，我的電腦的時間從來不會自動和 NTP 服務器同步，雖然短期內並不會對使用造成什麼影響，但倘若放任不管，時鐘的偏移量太多，則可能會造成 SSL 和 TOTP 等依賴時間戳的應用出現問題，再者，手動按同步鍵也很不方便，今天我決定必須要解決這個問題。

SpecialPollInterval

在網上搜索一番之後，我發現有人提到SpecialPollInterval這個鍵值，其具體位置是HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\NtpClient，微軟官方文檔對其的描述如下：

This entry specifies the special poll interval in seconds for manual peers. When the SpecialInterval 0x1 flag is enabled, W32Time uses this poll interval instead of a poll interval determine by the operating system. The default value on domain members is 3,600. The default value on stand-alone clients and servers is 604,800.

對於一般客戶端，這個鍵值的默認值是604800，也就是一個星期同步一次，這個間隔顯然太久，於是我將其設置成了3600令其一小時同步一次。

w32tm

幾天後，當我再次檢查時間時，卻發現時間仍然沒有自動同步，這一次的偏移量已經達到了 15.8 秒。

於是查詢「SpecialPollInterval」想要知道其具體的作用和未及預期目的的原因，卻發現了微軟的一篇疑難解答。這篇疑難解答指出：「每次客戶端輪詢時間樣本到 NTP 服務器時，NTP 客戶端都會進入 SPIKE 狀態。時間服務管理其內部狀態，如果客戶端進入 SPIKE 狀態，則客戶端不會同步其時間。」

為了解決這個問題，需要將 Windows 時間配置為使用 MinPollInterval/MaxPollInterval 作為輪詢間隔。

w32tm /config /update /manualpeerlist:cn.pool.ntp.org /syncfromflags:MANUAL

服務尚未啟動

執行這一行配置時出現了「服務尚未啟動」的提示，這說明用於時間同步的服務根本沒有啟動。如此基礎的服務竟然不會自動開機啟動，我也不知道這是 Windows 的 Bug 還是我後期使用無意間製造的問題，不管怎樣，首先啟動這個服務：

net start w32time
w32tm /register   # 註冊一些基本的註冊表鍵值和相關服務

隨後 Win + R 運行services.msc打開服務管理面板，找到「Windows Time」服務，將其啟動類型設置為「自動」，即可讓其開機自動啟動。

再次重新啟動電腦，這次打開「設置」–>「時間和語言」–>「日期和時間」–>「附加時鐘」，切換到「Internet 時間」選項卡，如果出現了「下次同步」的字樣，說明這套系統終於是正常運作了。

OBS 多路推流折騰記：那些本不必要的麻煩

Wed, 18 Sep 2024 06:16:51 +0000

長話短說，最近我開始直播我的遊戲實況，我並不指望有多少人看，Just, Why not? 再者每個直播平臺都會有直播回放。相當於免費保存我每一次遊戲的錄像，何樂而不為？

扯遠了，如你所見，近期我有了多平臺同時直播的需求，然而 OBS 本身顯然不支持同時推流，同時也因為不支持設置代理的特點和眾所周知的原因，無法推流到 twitch.tv，於是我開始尋找解決方案。

明確需求

多路平臺同時直播
最好對性能影響小
其中一路需要推流需要代理

多路推流

多路推流有現成的插件可用：Github

在 Release 頁面下載.exe安裝包，安裝完成後記得在「停靠窗口」菜單裡勾選「多路推流」。這時候默認會彈出一個獨立窗口，可以趁這個機會順便調整一下 OBS 的佈局。

插件的設置也沒什麼好說的，用在原版 OBS 的填法在這個插件裡如法炮製即可。

Bilibili 直播姬

莫名其妙，B 站小於 50 粉絲的 Up 主只能使用直播姬開播，其他國內平臺做出類似規定者大概也不在少數，啟用第三方推流模式之後，直播面板會顯示推流的配置。此時的不需要按照直播姬給出的推流地址進行配置，因為直播姬莫名其妙的給了一個每次都會變的內網 IP，直接以127.0.0.1或者localhost替換即可。

推流到 Twitch

推流到 Twitch 則會因為 GFW 多出很多不必要的麻煩。

OBS 本身並不支持設置代理，起初我打算用 Clash 的 TAP 模式強制代理 OBS 的流量，而 Clash 的 TAP 並不監聽 rtmp 流量，宣告失敗。我決定直接架設一個轉發服務器，這個服務器需要既可以與 Twitch 通信，又可以不受 GFW 的干擾。

在網上查到一些信息，Caddy 似乎不支持 RTMP 協議，而 nginx-rtmp 插件則專門為 RTMP 協議設計。這幾乎是唯一的選擇。

部署的前提：

熟悉基本的 Linux 命令行操作。
服務器已經安裝好docker和docker compose插件。
有合適的命令行文本編輯器，比如nvim或者絕大部分 distro 自帶的nano。

新建目錄：

mkdir nginx-rtmp && cd nginx-rtmp

創建docker-compose.yml：

services:
  nginx-rtmp:
    image: tiangolo/nginx-rtmp:latest
    container_name: nginx_rtmp
    ports:
      - "1935:1935" # RTMP port
    volumes:
      - ./nginx.conf:/etc/nginx/nginx.conf
    restart: unless-stopped

創建nginx.conf：

worker_processes  auto;

events {
    worker_connections  1024;
}

rtmp {
    server {
        listen 1935;
        chunk_size 4096;

        application live {
            live on;
            push rtmp://live.twitch.tv/app/{Twitch 主直播密鑰};
        }
    }
}

啟動編排：

docker compose up -d
# 老版本 compose 插件則是 docker-compose up

當然，別忘了開放防火牆端口。我的防火牆參考了 To Fix The Docker and UFW Security Flaw Without Disabling Iptables 一文中提到的配置，相應地，開放端口的命令如下：

ufw route allow proto tcp from any to any port 1935

配置完成後，OBS 內的推流目標地址填入rtmp://服務器ip/live，推流碼填寫任意值均可。設置完成後即可開始推流。

Netch

如果沒有服務器，亦可以使用 Netch 代理 OBS 進程進行推流。

首先下載 Netch 1.9.2 版本，注意一定要是 1.9.2 版本。添加一個進程模式，將 OBS 文件夾加入，隨後啟用該進程模式的代理即可。

尾聲

這次為了在同時在 Twitch 和 B 站上推流，遇到了很多原本不必要的麻煩。我可以怪 OBS 沒有內置代理功能，也可以怪 Clash Verge 等代理工具不支持 RTMP，轉來轉去，最終要怪的，還得是 GFW。雖然最後的結果還算令人滿意，僅僅為了推流而折騰這些東西的體驗實在是稱不上良好。也許我今後我應該去研究修改 Mihomo 內核，讓其支持 RTMP 協議，亦或是自己寫一套獨立的實現單獨轉發 OBS 的流量，不論如何，在這片土地上，想要暢快的直播，道阻且長。

最後，歡迎關注我的 Twitch 頻道: https://www.twitch.tv/powerfullz233

docker-mailserver 郵件服務器搭建記錄

Fri, 06 Sep 2024 03:57:18 +0000

某天早上醒來，發現收件箱裡多了封郵件，通知我的郵箱在韓國登錄，當時認為只是偶爾的 IP 誤判，也就沒有多想。可接下來幾天，時不時又有新的郵件進來，而且每次 IP 都不一樣，這下可就有些問題了，再不採取行動，怕不是郵箱真的要被拿去群發郵件。於是趕緊刪掉了域名的 MX、SPF、DMARC 記錄，尋找新的解決方案。

我原本只是想改改密碼，結果呢，騰訊企業郵箱改密碼的入口真的巨能藏，到處都找不到。算了，遷移，何必受這氣。

於是就有了這篇文章，從最開始的開放防火牆端口開始，到最後的優化送達率，我將分享我搭建 docker-mailserver 郵件服務器的經驗，希望能幫你少踩些坑。

搭建 docker-mailserver 郵件服務器前的準備

防火牆的處理

首先先開放防火牆的郵件服務常用端口，分別是25、143、465、587、993，各分支開放端口的操作不同，請自行谷歌或詢問 AI，以 Ubuntu 使用的ufw為例：

ufw allow 25
ufw allow 143
ufw allow 465
ufw allow 587
ufw allow 993

我的防火牆比較特殊，用到了ufw和 To Fix The Docker and UFW Security Flaw Without Disabling Iptables 一文中提到的配置。所以當我想要把 Docker 容器的端口暴露在外時需要做出額外的配置。

# 開放郵件服務器所需的端口
ufw route allow proto tcp from any to any port 25
ufw route allow proto tcp from any to any port 143
ufw route allow proto tcp from any to any port 465
ufw route allow proto tcp from any to any port 587
ufw route allow proto tcp from any to any port 993

驗證你的服務器是否具備搭建條件

很多服務器，尤其是各種廉價的 VPS，並不適合搭建 docker-mailserver，各大郵件服務商為了過濾垃圾郵件，索性將所有曾經有過 Spam 行為的 IP 全部列入黑名單。如果你的 IP 被某個 Spammer 使用過，而恰好又被你的服務器提供商分配給了你，而你折騰了幾個小時的郵件服務器卻愣是收不到郵件，最後發現竟是 IP 被列入黑名單的原因，我不知道你會作何感想。

有的服務器提供商的 IP 乍一看確實不在郵件黑名單中，但實際上搭建好之後還是無法發送郵件，為什麼？因為服務器提供商擔心 IP 被濫用，索性將郵件服務的端口全都封鎖了。

使用如下腳本檢測你的服務器是否具備搭建郵件服務器的條件：

bash <(curl -sL IP.Check.Place)

如果在這一步發現你的服務器不適合搭建甚至不能搭建docker-mailserver，那就趁早打住吧，想辦法換一個更乾淨、限制更少的 IP 再說。

搭建過程

拉取配置文件

docker-mailserver 需要配置的配置文件有兩個，compose.yaml和mailserver.env，分別拉取配置文件：

mkdir mailserver && cd mailserver
sudo apt install wget
wget -O compose.yaml "https://raw.githubusercontent.com/docker-mailserver/docker-mailserver/master/compose.yaml"
wget -O mailserver.env "https://github.com/docker-mailserver/docker-mailserver/blob/master/mailserver.env"

根據需求，可以修改不同的配置，下面是我修改的部分：

POSTMASTER_ADDRESS=webmaster@l3zc.com
TZ=Asia/Shanghai
SSL_TYPE=manual
SSL_CERT_PATH=/certs/cert.crt
SSL_KEY_PATH=/certs/cert.key

用 Caddy 準備和自動維護 TLS 證書¹

因為我已經在使用 Caddy，所以我這次就打算直接使用 Caddy 來自動維護證書。根據項目的官方文檔，我只需要在 Caddyfile 裡新增一個子域名，Caddy 就可以自動幫我維護證書。

mail.example.com {
  tls internal {
    # ?? 這不是直接生成的內部證書麼
    key_type rsa2048
  }

  # Optional, can be useful for troubleshooting
  # connection to Caddy with correct certificate:
  respond "Hello DMS"
}

當我更新完 DNS 記錄，實際操作起來發現，我的情況比較特殊：我這臺服務器上並沒有用到 Caddy 的自動申請證書功能，而是使用了15年有效期的泛域名 Cloudflare Origin Certificate。即使我不為這個子域名指定證書文件，Caddy 也會在加載這張泛域名證書後認為無需再申請新的證書。這就很尷尬了，用 Caddy 的時候 Cloudflare Origin Certificate 和郵件服務器只能二選一。只好安裝了dns.providers.cloudflare，並放棄使用 Cloudflare Origin Certificate，轉而讓 Caddy 自動為每個子域名申請和維護 TLS/SSL 證書，反正都是自動的，眼不見心不煩。

安裝dns.providers.cloudflare後的全局配置：

{
        acme_dns cloudflare {API_KEY}
}

最後把 Caddy 的證書存儲位置映射到 docker-mailserver 容器內。

volumes:
  - /home/user/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/yourdomain.tld/:/certs/

如果 Caddy 以 root 用戶運行，則證書的位置應當為/root/.local/share/caddy/certificates/acme-v02.api.letsencrypt.org-directory/yourdomain.tld/，做出相應的修改即可。

然後就是之前提到過的配置，我將證書存儲位置映射到了容器內的/certs/目錄，所以配置為：

SSL_CERT_PATH=/certs/cert.crt
SSL_KEY_PATH=/certs/cert.key

首次啟動容器

首次啟動容器需要立即（120 秒內）創建新的 Postmaster 賬號。

docker compose up -d
docker exec -it  setup email add

優化送達率

DNS 記錄

一條 A 記錄，名稱隨意（假設為mail），指向服務器 IP（Cloudflare 需使用「僅 DNS」）
一條 MX 記錄，Apex 域（@），指向mail.yourdomain.tld
一條 TXT 記錄（SPF），Apex 域（@），可以在這裡生成(可選)。
一條 TXT 記錄（DMARC），名稱_dmarc，可以在這裡生成（可選）。
一條 TXT 記錄（DKIM），名稱mail._domainkey，具體配置在後文（可選）。

DKIM, SPF 和 DMARC²

什麼是 DKIM，SPF 和 DMARC？簡單來說，DKIM 是一個數字簽名機制；SPF 類似於「員工名單」，記錄所有合法的發件服務器；DMARC 則用於指示收件方的服務器如何處理未通過 DKIM 和 SPF 驗證的郵件。³

首先設置 DKIM，在服務器上生成公私鑰對。

docker exec -it  setup config dkim

生成後的公私鑰對可以在映射的容器目錄./docker-data/dms/config/opendkim/keys/下找到。

下載 mail.txt（複製其內所有內容粘貼到本地文件也可以），將其導入到 Cloudflare Dashboard 即可完成 DKIM 設置。需要注意配置完成 DKIM 後需要重啟容器才能生效。⁴

docker compose up -d --force-recreate

前面提到 SPF 相當於一個「員工名單」，既然我合法的發件服務器只有一臺，那麼 DNS 填寫如下設置即可。

"v=spf1 mx ~all"

再就是 DMARC，可以使用前面提到的模板生成，這裡不再贅述。

如果你的域名服務商擁有自己的設置嚮導（例如 Cloudflare），亦可以使用它們簡化設置流程。

客戶端設置

客戶端設置相對就很簡單了，IMAP 和 SMTP 服務器都是mail.yourdomain.ltd，開啟 SSL 後端口分別是 465 和 993，登錄即可。

善用 MailTester

至此我們已經完成了搭建 docker-mailserver 郵件服務器的整個過程，在開始發送郵件之前，我們可以使用 MailTester 測試我們的配置是否正確。如果測試結果是 10/10，那麼我們的 docker-mailserver 郵件服務器應該會擁有漂亮的送達率，好好享受吧。

如果不是 10/10，也不要著急，認真查看扣分的原因，對症下藥，一項一項解決即可。

TODO-List

配套 WebUI

參考: https://docker-mailserver.github.io/docker-mailserver/latest/config/security/ssl/#caddy ↩︎
參考: https://docker-mailserver.github.io/docker-mailserver/latest/config/best-practices/dkim_dmarc_spf/ ↩︎
更加具體的介紹: https://www.cloudflare.com/learning/email-security/dmarc-dkim-spf/ ↩︎
在官方文檔中有提及。 ↩︎