Clash 進階設定手冊

設定基礎:檔案結構與生效方式

後面七章講的所有內容,最終都會落到同一個 YAML 設定檔裡。開始之前先花幾分鐘弄清楚:核心讀取的設定到底從哪來、由哪幾部分拼成、改完之後怎麼確認已經生效。這一章是全篇的地基,跳過它直接改設定,很容易出現「改了沒反應」或者「訂閱一更新自訂全丟了」的情況。

設定檔的來源與層級

日常使用中,核心實際載入的設定通常不是單一檔案,而是三層內容的合成結果:最底層是機場訂閱拉取下來的原始 YAML(包含節點清單和機場預設的分組、規則);中間層是客戶端(如 Clash Plus、Clash Verge Rev)提供的本地覆寫(Merge/Script),用來在訂閱之上追加或替換欄位;最上層是客戶端介面裡的開關設定(連接埠、系統代理、TUN 等),部分客戶端會把這些設定也合併進最終設定。理解這個層級的意義在於:凡是想長期保留的自訂,都應該寫在覆寫層,而不是直接編輯訂閱檔——訂閱一更新,直接改在訂閱檔裡的內容會被原樣覆蓋。覆寫的具體做法見第七章。

幾個繞不開的全域欄位

下面這些欄位出現在設定檔頂層,後續章節會反覆引用,先建立印象:

mode 值得多說一句:日常應保持 rule(按規則分流);global 會把全部流量丟給一個策略,只適合暫時排查「是不是規則出了問題」;direct 則等於暫時停用代理。三種模式在客戶端介面上都能一鍵切換,不需要改檔案。

修改後如何確認生效

改完設定有兩種生效方式:客戶端介面裡的「重新載入設定」按鈕(推薦,不中斷現有工作狀態),或者重新啟動核心。確認是否生效最可靠的辦法是看日誌頁——核心啟動或重新載入時會逐條印出監聽連接埠、TUN 狀態、規則條數等資訊;若設定有語法錯誤,重新載入會失敗並在日誌裡給出行號。看不懂日誌欄位的話,可以對照這篇文章:Clash 運行日誌怎麼看。修改 YAML 時還有一個通用建議:縮排一律用空格,不要用 Tab,YAML 對縮排極其敏感,大量「設定載入失敗」其實只是縮排錯位。

策略組類型與實戰

策略組(proxy-groups)是分流體系的中樞:規則命中後並不直接指向某個節點,而是指向一個策略組,由策略組再決定「此刻用哪個節點」。機場訂閱通常自帶一套分組,但理解各類型的行為差異之後,完全可以按自己的使用習慣重新設計。

四種常用類型的行為差異

注意 url-test 與 fallback 的本質區別:前者追求「最快」,節點排名變了就切;後者追求「穩定」,只要清單靠前的節點還活著就絕不切換。日常網頁瀏覽用 url-test 體驗好,而對連線持續性敏感的場景(線上會議、長時間登入狀態)更適合 fallback。

一份可參考的分組設定

proxy-groups:
  - name: 節點選擇
    type: select
    proxies: [自動測速, 故障轉移, 香港-01, 日本-01, DIRECT]

  - name: 自動測速
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    proxies: [香港-01, 香港-02, 日本-01]

  - name: 故障轉移
    type: fallback
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: [香港-01, 日本-01, 新加坡-01]

  - name: 下載專用
    type: load-balance
    strategy: consistent-hashing
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: [香港-01, 香港-02, 香港-03]

幾個關鍵參數:url 是健康檢查的目標位址,慣例用回傳 204 狀態碼的輕量位址;interval 是檢查間隔(秒),不宜低於 120,過於頻繁的測速本身就會消耗節點流量;tolerance 只對 url-test 有效,表示新舊最優節點延遲差超過這個毫秒數才切換,能有效抑制兩個延遲接近的節點來回跳動;load-balance 的 strategy 可選 consistent-hashing(同一目標站點固定走同一節點,對登入狀態友善)或 round-robin(逐連線輪詢,分散更徹底)。此外還可給組加 lazy: true,讓組在未被使用時暫停測速,進一步省流量。

實戰:入口—功能—地區的三層巢狀

策略組可以引用策略組,這是設計分流體系時最有用的特性。推薦的組織方式是三層:最上層一個 select 總入口(平時手動停在「自動測速」上);中間層按業務拆分功能組,如「串流媒體」「AI 服務」「下載專用」,每個功能組都是 select,候選項裡放地區組和總入口;最下層是按地區聚合的 url-test 組(香港自動、日本自動等)。這樣日常無需任何操作,想暫時把某項業務釘在特定地區時,只在對應功能組裡點一下即可,不影響其他流量。規則如何指向這些功能組,見下一章。

規則集訂閱化管理

直接把幾千條 DOMAIN-SUFFIX 寫在設定檔的 rules 段裡,既難維護又難更新。規則集(rule-providers)把規則拆成獨立檔案、以訂閱的方式引用:主設定裡只留一行 RULE-SET,規則內容由核心定時從遠端拉取並快取到本地。規則更新與主設定解耦,是進階設定裡效益最高的一步改造。

behavior 與 format:先分清規則檔案的三種「體質」

format 描述檔案格式:yaml 與 text 是人類可讀的文字;mrs 是 mihomo 的二進位格式,載入快、體積小,但僅支援 domain 與 ipcidr 兩種 behavior,且無法直接用編輯器查看。引用別人維護的規則倉庫時,behavior 和 format 必須與檔案實際內容一致,寫錯會導致整個規則集載入失敗。

宣告與引用範例

rule-providers:
  streaming:
    type: http
    behavior: classical
    format: yaml
    url: https://example.com/rules/streaming.yaml
    path: ./rules/streaming.yaml
    interval: 86400
  cn-ip:
    type: http
    behavior: ipcidr
    format: mrs
    url: https://example.com/rules/cn-ip.mrs
    path: ./rules/cn-ip.mrs
    interval: 86400

rules:
  - RULE-SET,streaming,流媒体
  - RULE-SET,cn-ip,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

interval 是自動更新間隔(秒),規則清單變動不頻繁,86400(一天)已經足夠;path 是本地快取路徑,斷網啟動時核心會直接用快取,不會因為拉不到遠端而起不來。

比對順序與 no-resolve

rules 段自上而下逐條比對,命中即停,順序就是優先級。通用的排布原則:精確的、面向具體業務的規則放前面;GEOIP 這類 IP 規則放靠後——因為遇到 IP 規則時,如果目標還是網域,核心需要先做一次 DNS 解析才能判斷歸屬,把它放前面會拖慢所有請求的比對。給 IP 類規則加 no-resolve 後綴,表示「目標不是 IP 就跳過本條,不要為它觸發解析」,是控制解析成本的常用手段。最後一條務必是 MATCH 兜底,否則未命中的流量行為不可預期。

DNS 設定優化

很多「規則明明寫對了卻分流不對」「打開網頁第一下特別慢」的問題,根源都在 DNS。Clash 之所以要內建一套 DNS 模組,是因為分流決策強烈依賴網域解析的結果:解析被污染,IP 規則就會誤判;解析走了慢速鏈路,所有請求都要為它排隊。這一章講清楚 DNS 各欄位的分工,以及境內外網域分開解析的標準做法。

欄位分工:default-nameserver 與 nameserver

最容易混淆的一對欄位:default-nameserver 只做一件事——解析 nameserver 裡那些 DoH/DoT 伺服器自己的網域(比如 doh.pub 這個網域本身也需要先解析成 IP 才能連上),因此它必須填純 IP 的傳統 DNS;nameserver 才是日常查詢真正使用的上游,建議填加密 DNS(DoH/DoT),避免明文查詢在鏈路上被竄改。enhanced-mode 決定解析結果的呈現方式(fake-ip 或 redir-host),與 TUN 關係密切,細節放在第四章展開。

按網域走不同上游:nameserver-policy

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://doh.pub/dns-query
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://doh.pub/dns-query
    "geosite:geolocation-!cn":
      - https://dns.cloudflare.com/dns-query
      - https://dns.google/dns-query

nameserver-policy 是現代設定裡取代舊式 fallback + fallback-filter 組合的建議寫法:按網域歸屬直接指定上游——中國大陸網域交給大陸公共 DoH,拿到就近 CDN 節點,速度最優;境外網域交給國際 DoH,從源頭避開污染。geosite: 前綴引用的是核心附帶的網域分類資料庫,不需要自己維護網域清單。相比讓所有查詢先問一遍再對結果做過濾的 fallback 機制,policy 方式路徑更短、行為更可預期。

常見誤區與驗證方法

誤區一:把 nameserver 全部填成境外 DNS。境外上游解析中國大陸網域會回傳面向海外的 CDN 節點,大陸直連流量反而變慢,這是「開了代理連本地網站也卡」的高頻原因之一,排查思路可參考網速慢排查清單。誤區二:忽視瀏覽器自帶的 DoH——Chrome/Firefox 的「安全 DNS」開關會跳過客戶端的 DNS 模組,導致 fake-ip 與網域規則雙雙失效,建議在瀏覽器設定裡關閉,或依靠網域嗅探兜底。驗證 DNS 設定是否按預期運作,最直接的方式是開 debug 日誌觀察每個網域實際使用的上游,更多解析類問題可查 FAQ 頁的故障排查分類。

TUN 模式與 Fake-IP

系統代理模式下,只有「願意遵守系統代理設定」的應用程式會把流量交給客戶端——瀏覽器基本都遵守,但相當多的桌面程式、命令列工具、遊戲客戶端會無視這項設定直連出去。TUN 模式透過建立一塊虛擬網卡在網路層接管全部流量,不管應用程式配不配合,統統納入分流,這是它的核心價值。

啟用 TUN 的最小設定

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-route 自動設定系統路由表,把預設路由指向虛擬網卡;auto-detect-interface 自動識別真實實體網卡作為出口,避免流量在虛擬網卡裡打轉形成回圈;dns-hijack 把發往任意位址 53 連接埠的明文 DNS 查詢劫持到核心的 DNS 模組,確保解析統一入口——這一條對 fake-ip 正常運作至關重要。實際使用時通常不必手寫這段:Clash Plus、Clash Verge Rev 等客戶端都提供 TUN 開關,由客戶端注入等效設定。

stack 的三種實作

沒有特殊需求時選 mixed;遇到某類應用程式在 TUN 下異常,把 stack 換一種實作再試,是排查相容性問題的常規步驟。

Fake-IP:原理與例外清單

enhanced-mode: fake-ip 的運作方式:應用程式發起網域查詢時,DNS 模組不做真實解析,立即回傳一個 198.18.0.0/16 保留段內的「假 IP」,並記住這個假 IP 與網域的對應關係;應用程式拿假 IP 發起連線,核心在連線進來時反查出網域,再按網域規則分流,真正需要解析時才由出口側完成。好處非常直接:省掉了本地等待真實解析的一輪往返,規則比對拿到的是可靠網域而非可能被污染的 IP。與之相對的 redir-host 模式回傳真實 IP,相容性更「傳統」,但會帶來解析等待與污染風險,現已不作為建議預設。

fake-ip 的代價是:少數程式會把解析結果拿去做連線之外的用途(校時、區域網路探索、把 IP 上報給伺服器),假 IP 會讓它們出錯。fake-ip-filter 就是例外清單,清單內的網域回傳真實解析:

dns:
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "time.windows.com"
    - "+.ntp.org"
    - "+.stun.*.*"

典型需要加入清單的:NTP 校時網域、區域網路 mDNS 網域、STUN/遊戲對戰類需要真實位址協商的服務。遇到某個應用程式只在開啟 TUN + fake-ip 後異常,優先懷疑它需要進這個清單。

網域嗅探

分流規則大部分是圍繞網域寫的,但總有一些連線到達核心時只有 IP、沒有網域:應用程式自己內建了 DNS(比如瀏覽器開了 DoH)跳過了客戶端的解析,或者程式直接硬編碼 IP 連線。這類連線只能退化到 GEOIP 和兜底規則,分流精度大打折扣。網域嗅探(sniffer)的作用就是把網域「找回來」:從 TLS 交握的 SNI 欄位、HTTP 請求的 Host 標頭、QUIC 初始封包這些明文元資料裡讀出目標網域,再用它重新參與規則比對。

啟用與連接埠範圍

sniffer:
  enable: true
  sniff:
    HTTP:
      ports: [80, 8080-8880]
      override-destination: true
    TLS:
      ports: [443, 8443]
    QUIC:
      ports: [443]
  force-domain:
    - "+.example.com"
  skip-domain:
    - "Mijia Cloud"

sniff 下按協定宣告要嗅探的連接埠範圍——嗅探需要讀取連線的前幾個資料封包,限定在常見連接埠能把成本控制在可忽略的水平。需要說明的是,嗅探讀取的只是協定交握階段本就明文傳輸的元資料(SNI、Host),並不涉及解開加密內容。

override-destination、force-domain 與 skip-domain

override-destination 決定嗅探出網域後是否用它替換連線的目標位址:開啟後,後續比對與出站都以嗅探到的網域為準,能修正「假 IP 對應過期」「應用程式拿舊 IP 連新服務」之類的錯位,一般建議開啟。force-domain 是強制嗅探清單,清單內的網域即使已有解析紀錄也重新嗅探核對,適合那些 CDN 網域與實際服務網域經常不一致的站點。skip-domain 則是跳過清單——個別裝置雲端服務(如範例中的米家)會在 TLS 交握裡放非標準識別碼,嗅探替換後反而連不上,把它們排除即可。這三個參數組合起來,可以把嗅探的介入範圍控制得很精細。

什麼時候應該開嗅探

兩個信號說明你需要它:一是日誌裡出現大量目標為純 IP 的連線、最終全靠 GEOIP 或 MATCH 收尾;二是明明寫了網域規則,某些應用程式的流量卻總是不命中。開啟嗅探後,再回看日誌會發現這些連線重新帶上了網域,規則命中情況立刻改善。配合上一章的 fake-ip 使用時,嗅探還是瀏覽器 DoH 跳過客戶端 DNS 後的最後一道兜底。順帶一提,若開啟嗅探前後瀏覽器出現證書警告,兩者通常無關,具體成因見這篇分析:開啟 Clash 後 HTTPS 證書報錯的原因。

本地覆寫與多訂閱合併

第一章提到過原則:自訂寫在覆寫層,不動訂閱原文。這一章展開講兩件事——怎麼用客戶端的覆寫機制持久化自己的修改,以及怎麼把多家機場的訂閱合併進同一套分組體系。

本地覆寫:讓自訂在訂閱更新後存活

主流客戶端(Clash Plus、Clash Verge Rev 等)都提供「覆寫/Override」能力,常見形態有兩種:宣告式的 Merge——寫一段 YAML 片段,客戶端在每次載入訂閱後把它合併進去;程式式的 Script——寫一小段腳本函式,接收解析後的設定物件,加工後回傳。Merge 適合追加 DNS 段、前置幾條自訂規則這類結構化修改;Script 適合「給所有分組批量插入一個節點」「按名稱過濾節點」這類需要遍歷邏輯的場景。一個典型的 Merge 片段:

dns:
  enable: true
  enhanced-mode: fake-ip

rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
  - PROCESS-NAME,Steam.exe,DIRECT

不同客戶端對 Merge 的合併語義略有差別(整段替換還是逐項追加、規則是前置還是後置),第一次使用時務必在客戶端裡預覽合併後的最終設定確認符合預期,再儲存啟用。各客戶端覆寫入口的位置,可參考部落格的介面功能速覽。

proxy-providers:多訂閱合併的正確做法

同時持有多家機場訂閱時,不要在多個設定檔之間來回切換——用 proxy-providers 把每份訂閱宣告成一個節點提供者,再在策略組裡用 use 欄位引用,所有節點便匯入同一套分組與規則體系:

proxy-providers:
  airport-a:
    type: http
    url: https://example.com/sub/airport-a
    path: ./providers/airport-a.yaml
    interval: 43200
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
  airport-b:
    type: http
    url: https://example.com/sub/airport-b
    path: ./providers/airport-b.yaml
    interval: 43200
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 全部节点
    type: select
    use: [airport-a, airport-b]
  - name: 香港自动
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    use: [airport-a, airport-b]
    filter: "(?i)香港|HK|Hong Kong"

filter 用正規表示式按節點名稱篩選,是建立地區組的關鍵——兩家機場的香港節點會被自動收進同一個「香港自動」組裡測速競爭。use 與 proxies 可以在同一個組裡並存,手動節點與訂閱節點混編沒有問題。

更新策略與容錯

interval: 43200(12 小時)對訂閱來說已經足夠勤快;path 快取確保拉取失敗時沿用上一份節點清單,核心不會因為某家機場介面出問題而整體罷工。health-check 建議對每個 provider 都開啟,否則 url-test 組拿不到延遲數據、無法完成自動選擇。另外注意:provider 的 url 由核心直接發起請求,若訂閱位址本身需要代理才能存取,需在 provider 上設定代理路徑或先確保有可用的直連線路,避免「雞生蛋」死結。

外部控制與管理面板

核心自帶一套 RESTful 控制介面(external controller),客戶端圖形介面本質上就是這套介面的消費者。理解它之後能解鎖不少玩法:用瀏覽器面板管理跑在軟體路由器/伺服器上的裸核心、寫腳本定時切換策略、把連線數據接進自己的監控系統。

開啟介面與存取控制

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./ui
external-ui-url: https://example.com/ui.zip

external-controller 監聽在 127.0.0.1 時只有本機能存取,這是桌面環境的安全預設;改成 0.0.0.0:9090 才能從區域網路其他裝置存取,此時 secret 必須設定且足夠複雜——這個介面能讀連線、改策略、重新載入設定,權限等同於完全控制客戶端。請求方透過 Authorization: Bearer 標頭攜帶金鑰。

幾個常用 API

# 查看所有策略组与节点状态
curl -H "Authorization: Bearer your-password" http://127.0.0.1:9090/proxies

# 把「节点选择」组切换到指定候选
curl -X PUT -H "Authorization: Bearer your-password" \
  -d '{"name":"香港自动"}' \
  http://127.0.0.1:9090/proxies/节点选择

# 查看当前活动连接
curl -H "Authorization: Bearer your-password" http://127.0.0.1:9090/connections

# 触发指定节点的延迟测试
curl -H "Authorization: Bearer your-password" \
  "http://127.0.0.1:9090/proxies/香港-01/delay?timeout=5000&url=https://www.gstatic.com/generate_204"

此外 /logs 與 /traffic 是串流介面,持續推送日誌與即時流量,面板裡滾動的日誌和速率曲線就來自它們;PATCH /configs 可以在不重新啟動的情況下切換 mode、改連接埠。

Web 面板:給裸核心一張臉

external-ui 指向一個靜態網頁目錄,核心會把它託管在控制連接埠的 /ui 路徑下;external-ui-url 則讓核心自動下載並解壓面板資源包。社群常用的面板有 metacubexd、yacd 及其衍生版本,功能大同小異:分組切換、延遲測試、連線清單、規則與日誌查看。這套玩法最適合「伺服器或路由器上跑裸 mihomo 核心」的場景——核心安裝包可在下載頁的核心區取得;桌面使用者則一般用不到,Clash Plus、Clash Verge Rev 等客戶端已經把同樣的能力做進了本地介面。