Clash 進階設定手冊

策略群組類型與實戰

策略群組是 Clash 設定的中樞。所有流量最終都要回答一個問題:從哪個出口走。rules 負責把流量分進策略群組,策略群組負責在出口之間做選擇。訂閱自帶的策略群組往往只有「節點選擇」與「自動選擇」兩檔,夠用但不順手。把五種類型摸清,才能搭出「影音走香港、下載走日本、失敗自動切備援」這種按用途分流的結構。

五種類型一覽表

五種類型可以互相嵌套:一個策略群組的 proxies 裡可以寫另一個策略群組的名稱。實戰中最穩的結構是三層——業務策略群組(如「影音」「下載」)指向出口策略群組,出口策略群組再指向節點或 url-test 群組,rules 只引用業務群組。這樣換出口不動規則,換節點不動出口,維護成本最低。

select 與 url-test:手動拍板加自動擇優

select 不做任何檢測,前端點哪個用哪個,適合作為最終拍板層。url-test 依 interval 定時對群組內節點發起延遲測試,把出口切到目前最快的一個。兩個參數決定它是否好用:tolerance 是切換門檻,單位毫秒,候選節點只快幾十毫秒時不切換,避免出口在兩條相近線路間來回抖動;lazy 設為 true 後,群組內無流量經過時暫停測速,省去無意義的偵測請求。

proxy-groups:
  - name: "最終出口"
    type: select
    proxies: ["自動擇優", "手動指定", "DIRECT"]

  - name: "自動擇優"
    type: url-test
    use: ["airport-a"]
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80
    lazy: true

  - name: "手動指定"
    type: select
    include-all: true
    filter: "香港|HK"

use 引用 proxy-providers 裡的訂閱,include-all: true 把設定裡全部節點收進來,filter 用正規表示式再篩一次。三個欄位可以疊加:先收全部,再依正規表示式篩選,再併入訂閱。測速位址用 generate_204 這類回應內容極小的偵測位址即可;interval 建議不低於 120 秒——頻繁測速本身就是可觀的流量消耗,部分機場甚至會因此限速。

fallback 與 load-balance:主備與並行

fallback 把清單順序當作優先順序:健康檢查從第一個開始,誰先可用就用誰;主力掛掉自動落到備援,主力恢復後切回。它適合「一條主力專線加一條保底線路」的場景,比 url-test 更尊重人為排序。load-balance 則相反,不追求單線最佳,而是把連線分攤到群組內所有健康節點上。strategy 取 consistent-hashing 時,同一個目標網域固定雜湊到同一節點,登入狀態與會話能保持一致;取 round-robin 時逐連線輪替,吞吐量最大但同一站點可能跳 IP;mihomo 另提供 sticky-sessions,讓同一來源裝置盡量黏在同一節點,是兩者之間的折衷。

  - name: "主備線路"
    type: fallback
    proxies: ["專線入口", "自動擇優"]
    url: "https://www.gstatic.com/generate_204"
    interval: 180

  - name: "多線並行"
    type: load-balance
    use: ["airport-a"]
    strategy: sticky-sessions
    url: "https://www.gstatic.com/generate_204"
    interval: 300

relay:鏈式代理

relay 讓流量依序穿過群組內每一個節點再出站,典型用法是「前置中轉加落地」:本機到前置走最佳化線路,前置到落地走一般國際出口,兼得穩定性與目標地區出口身分。鏈路中每一跳都各自佔用頻寬,總延遲是各跳之和,節點不宜超過兩個。mihomo 中更輕量的等效寫法是在單個節點上宣告 dialer-proxy,指定它經由哪個前置出站,不必單獨建立群組。

  - name: "中轉落地"
    type: relay
    proxies: ["前置中轉", "美國落地"]

規則集訂閱化管理

從 rules 到 rule-providers

早期設定把成百上千條規則直接堆在 rules 欄位裡:難讀、難改,訂閱一更新整份檔案就被覆蓋,自己加的規則跟著消失。rule-providers 把規則從設定中抽出來,變成獨立、可依 URL 訂閱的規則集檔案:核心啟動時下載、本機快取、依週期刷新,rules 裡只留一行引用。設定從此分成兩層——策略結構留在手寫的 YAML 裡,規則資料交給可自動更新的規則集。

封鎖廣告、分流影音、放行內網,這些成熟需求社群已有維護多年的規則集,直接訂閱遠比自己逐條手寫可靠。本機專屬的規則(公司內網、自建服務)用 file 類型的 provider 放一份本機檔案,同樣走 RULE-SET 引用,管理方式一致。

宣告格式與欄位

rule-providers:
  adblock:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.com/rules/adblock.yaml"
    path: ./ruleset/adblock.yaml
    interval: 86400

  lan-local:
    type: file
    behavior: classical
    path: ./ruleset/lan.yaml

type 取 http 時依 url 訂閱,取 file 時讀本機檔案;path 是本機快取位置,下載成功後規則集落盤,下次啟動先讀快取;interval 是刷新週期,單位秒,86400 即每天一次。format 宣告檔案格式:yaml 是常見的清單式,text 是一行一條的純文字,mrs 是 mihomo 專用的二進位格式,體積最小、載入最快,大型規則集優先選它。

三種 behavior 的差異

behavior 決定核心如何解析這份檔案,寫錯會導致整個規則集載入失敗:domain 檔案裡出現 IP 段、ipcidr 檔案裡出現網域,都會報錯。訂閱第三方規則集時先看發布頁標註的類型,再照抄 behavior 與 format,別憑檔名猜測。

在 rules 中引用與更新機制

rules:
  - RULE-SET,lan-local,DIRECT
  - RULE-SET,adblock,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,最終出口

RULE-SET 的兩個參數依次是 provider 名稱與去向(策略群組或 DIRECT、REJECT)。rules 由上而下逐條比對,第一條命中即生效,順序就是優先順序:本機與封鎖類靠前,分流類居中,GEOSITE、GEOIP 與 MATCH 兜底壓陣。放錯位置是規則不生效的首要原因——排在 MATCH 之後的規則永遠不會被看見。

更新是背景行為:啟動時檢查每個 http provider 快取的存活時間,超過 interval 就非同步抓取;抓取失敗則沿用舊快取,規則不會清空、不會斷線。想立即刷新,在面板裡點對應 provider 的更新按鈕,或刪除 path 指向的快取檔案後重新載入設定。GEOSITE 與 GEOIP 走的是另一套資料庫檔案,更新方法見部落格《Clash GeoIP 與 GeoSite 資料庫更新方法與分流規則搭配》,別與 RULE-SET 混為一談。

DNS 設定最佳化

代理用戶端為什麼要接管 DNS

系統預設 DNS 走電信商的 UDP 53 連接埠,明文、可竄改。兩個問題直接影響代理效果:一是污染,查詢在途中被注入錯誤結果,拿到的 IP 根本連不通;二是外洩,存取過哪些網域電信商一覽無遺,分流也就失去意義。更隱蔽的是第三個問題:DNS 結果決定規則比對——依網域寫的規則,必須先有正確的解析路徑,核心才拿得到網域。

Clash 內建 DNS 伺服器正是為了把解析納入分流體系:中國大陸網域交給大陸的 DoH 直連解析,代理網域由遠端節點代理解析,節點伺服器自身的網域用專門的解析器,避免「要先連上代理才能解析代理位址」的死循環。開啟 dns 欄位後,整條解析鏈路都在核心掌控之中。

欄位分工

一份可直接套用的 dns 設定

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "ntp.*.com"
    - "+.stun.*.*"
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  proxy-server-nameserver:
    - https://doh.pub/dns-query
  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://1.1.1.1/dns-query

這份設定的思路:default-nameserver 用純 IP 兜底,負責先把 doh.pub、dns.alidns.com 這些解析器自身的網域解析出來;nameserver-policy 依 geosite 把網域分成兩路,中國大陸網域走大陸 DoH,非大陸網域走代理側的 DoH,由節點遠端完成解析;proxy-server-nameserver 單獨處理節點網域,與業務解析互不干擾。listen 讓核心在 1053 連接埠對外提供 DNS 服務,TUN 的 dns-hijack 會把系統查詢導向這裡。

enhanced-mode:redir-host 與 fake-ip

redir-host 做真實解析,把查詢轉送給上游再回傳真實 IP,相容性最好,代價是多一次 DNS 往返,且核心看到的是 IP,網域規則要靠快取反查。fake-ip 直接回傳 198.18.0.1/16 段內的假位址,應用程式拿到結果立即發起連線,核心依先前記下的「假位址與網域」對應關係還原出網域再比對規則——省去真實往返,首次連線更快,規則依網域精確命中。絕大多數桌面與行動裝置情境下 fake-ip 是更好的選擇,必須拿到真實 IP 的服務要寫進 fake-ip-filter 排除。ipv6 在寬頻未配發 IPv6 的環境建議關閉,避免 AAAA 查詢拖慢整體解析。

改完 dns 欄位卻沒生效是常見疑問:重新載入設定只是第一步,作業系統與瀏覽器各自快取了舊解析結果,需要清除系統 DNS 快取或重啟瀏覽器,新鏈路才真正接管。

TUN 與 Fake-IP

TUN 解決什麼問題

系統代理的本質是「告訴應用程式代理位址」,應用程式願意遵循才會被接管。瀏覽器、大部分辦公軟體沒問題,但遊戲、命令列工具、不少桌面應用程式直接無視系統代理設定,流量在直連上裸奔。TUN 換了一條路:在核心裡建立一張虛擬網卡,透過路由表把整機 TCP、UDP 流量全部導入進來,應用程式完全無感——不需要它支援代理,也不需要逐一設定。

代價是權限。虛擬網卡與路由表都是系統層級的資源:Windows 需要安裝核心服務,macOS 需要授權一次,Linux 需要 capabilities 或 root。Clash Plus、Clash Verge Rev 等用戶端把這一步做成了設定頁裡的一個開關,依提示完成一次授權即可;Android 用戶端本身就是 VPNService 形態,天生運作在 TUN 層;iOS 由系統網路擴充功能接管,無需使用者操作。各平台用戶端可在下載中心依系統領取。

tun 欄位

tun:
  enable: true
  stack: mixed
  device: Meta
  mtu: 1500
  dns-hijack:
    - any:53
    - tcp://any:53
  auto-route: true
  auto-detect-interface: true

stack 三選一:system 直接借助作業系統協定堆疊轉發,效能最好;gvisor 用使用者態協定堆疊重建連線,相容性最廣,在部分嚴格限制的網路環境下更穩定;mixed 讓 TCP 走 system、UDP 走 gvisor,兼顧兩者,是多數用戶端的預設值。auto-route 與 auto-detect-interface 必須同時開啟:前者把流量導入進來,後者確保核心自身的出站流量走實體網卡,少了後者會形成迴環,表現為開啟 TUN 後整機斷網。

Fake-IP 的運作原理

Fake-IP 與 TUN 是一對搭檔。應用程式查詢網域時,內建 DNS 不做真實解析,而是從 fake-ip-range(198.18.0.1/16)裡配發一個假位址回傳,並記下假位址與網域的對應關係;應用程式隨即向假位址發起連線,TUN 攔截後依對應關係還原網域,依網域比對規則,再決定直連還是交給節點——交給節點時把網域直接傳過去,由遠端解析,本機全程不需要真實 DNS 結果。

這套機制帶來兩個直接好處:首次連線快,省去一次真實 DNS 往返;分流準,規則比對拿到的一定是網域而不是 IP。代價是「看到假位址」的副作用:區域網路服務、NTP 對時、STUN 打洞、部分遊戲防作弊機制與銀行元件都必須拿到真實 IP,這類網域要寫進 fake-ip-filter。filter 支援萬用字元:*.lan 比對所有 .lan 結尾,+.example.com 比對主網域與全部子網域。

各平台落地要點

Windows 下用戶端的服務模式會把核心註冊為系統服務,TUN 開關在設定頁;macOS 首次開啟增強模式時輸入一次密碼授權;Linux 桌面用戶端同樣提供開關,直接以命令列執行 mihomo 時需要 setcap 賦權:

sudo setcap 'cap_net_admin,cap_net_bind_service=+ep' /usr/local/bin/mihomo

賦權後一般使用者即可啟動 TUN,不必全程使用 root。伺服器端的完整部署流程見部落格《Linux 部署 Clash:桌面用戶端安裝與 mihomo 命令列設定》。

網域嗅探

規則需要網域,連線未必帶網域

Clash 的規則體系以網域為主軸,但抵達核心的連線不一定帶著網域。應用程式自己做了 DNS、內建了 DoH、快取了舊解析結果,甚至直接寫死 IP——這些連線進入核心時只有目標 IP。沒有網域,DOMAIN、DOMAIN-SUFFIX、GEOSITE 全部失效,流量只能一路落到 GEOIP 或 MATCH,分流精準度大打折扣。

網域嗅探從連線本身的交握資料裡把網域讀回來:TLS 連線的 ClientHello 裡有 SNI 欄位,明文 HTTP 請求裡有 Host 標頭,兩者都是未加密的宣告。核心在轉送前先看一眼交握封包,擷取出網域,重新掛回這條連線上,後續規則比對就依網域進行。TUN 接管整機流量之後,繞過系統 DNS 的連線全部暴露在核心面前,嗅探幾乎成了 TUN 的標準搭檔。

設定寫法

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

parse-pure-ip 對純 IP 連線也嘗試嗅探,這是嗅探的主戰場;override-destination 用嗅探到的網域取代連線的目標位址,讓 redir-host 模式下的連線也能依網域分流;sniff 下依協定宣告連接埠範圍,QUIC 獨立列出是因為它的 SNI 擷取方式與 TCP 上的 TLS 不同。skip-domain 是豁免清單:已知嗅探後會異常的服務(如部分推播通道、智慧家庭雲端服務)寫進這裡,核心會對這些網域跳過嗅探。

邊界情況與排錯

嗅探不是萬能的。啟用 ECH(Encrypted Client Hello)的連線把 SNI 加密了,嗅探拿不到網域,只能退回 IP 規則;部分環境的 QUIC 嗅探會導致影音網站載入異常,可以單獨移除 QUIC 一段驗證看看;嗅探只在交握階段讀取幾個欄位,不解密流量,效能開銷可以忽略。

與 Fake-IP 的關係要說清楚:fake-ip 模式下,網域在 DNS 階段就已經在核心手上,嗅探能發揮作用的只剩「應用程式繞過系統 DNS」的少數場景;redir-host 模式或純 IP 直連場景,嗅探是分流精準度的主要保障。開了嗅探後某個服務連不上,先把它的網域加進 skip-domain 驗證,再排查其他方向。

本機覆寫與多訂閱合併

一個避不開的矛盾

機場訂閱是整份 YAML,用戶端依週期刷新,刷新即整體取代。手動加的節點、改過的策略群組、調整過的 DNS,下一次更新全部消失。把本機改動與訂閱內容隔離開,是長期用好 Clash 的前提。手段分兩層:多訂閱用 proxy-providers 聚合,讓節點與訂閱檔案解耦;本機修改走用戶端覆寫機制,補丁與訂閱檔案解耦。有人用線上訂閱轉換服務把多訂閱合併成一份,代價是把訂閱位址交給第三方;proxy-providers 在本機完成同樣的事,位址不會外流。

proxy-providers:把多個訂閱聚成節點池

proxy-providers:
  airport-a:
    type: http
    url: "https://example.com/sub-a.yaml"
    path: ./providers/airport-a.yaml
    interval: 86400
    health-check:
      enable: true
      url: "https://www.gstatic.com/generate_204"
      interval: 300
    override:
      additional-prefix: "[A] "

  airport-b:
    type: http
    url: "https://example.com/sub-b.yaml"
    path: ./providers/airport-b.yaml
    interval: 86400
    override:
      additional-prefix: "[B] "

  self-hosted:
    type: file
    path: ./providers/self.yaml

每個 provider 各自下載、各自快取、各自健康檢查。override.additional-prefix 給該訂閱的所有節點名加上前綴,兩個機場撞名(「香港 01」家家都有)時就不會互相覆蓋,面板裡也能一眼分清歸屬。filter 欄位用正規表示式只收需要的節點,例如只取家用寬頻線路。file 類型的 self-hosted 放本機手寫的自架節點,與訂閱平級進入節點池。

聚合之後,策略群組用 use 引用 provider,與 proxies 混排:

  - name: "自動擇優"
    type: url-test
    use: ["airport-a", "airport-b", "self-hosted"]
    url: "https://www.gstatic.com/generate_204"
    interval: 300

用戶端覆寫:給訂閱打補丁

主流用戶端都提供覆寫層,原理一致:訂閱 YAML 下載後先套用使用者定義的補丁,再交給核心生效。Clash Plus 在訂閱設定裡提供覆寫入口;Clash Verge Rev 提供 Merge(依 YAML 路徑合併欄位)與 Script(用腳本任意改寫)兩檔;FlClash 在覆寫設定裡支援追加規則與策略群組。補丁裡能做的事:插入前置規則、追加策略群組、改 dns、關閉 ipv6——訂閱刷新一百次,補丁照樣生效。

覆寫裡最常用的是前置規則。用戶端一般提供「追加到 rules 頂部」的位置,寫在最前面的規則優先順序最高,適合放「公司網域直連」「某站點強制走某出口」這類個人化項目。訂閱自帶規則保持原樣,不讀不改;出問題時把覆寫關掉即可回到訂閱原貌,排錯路徑非常短。基礎的訂閱匯入與模式選擇仍是前提,主要步驟見使用教學。

合併衝突與維護紀律

多訂閱合併的坑集中在三處。命名衝突:不同訂閱的同名節點會被去重或後者覆蓋前者,additional-prefix 是最穩妥的解法。策略群組同名:覆寫裡追加的策略群組若與訂閱自帶群組同名,以覆寫為準,訂閱群組會被取代——有意如此是功能,無意撞名就是事故。規則順序:前置規則會壓過訂閱規則,寫一條過於寬泛的前置規則(如大範圍 IP 直連)會把訂閱分流架空,前置項目務必精確。

維護上建議把本機改動收斂到一份覆寫裡,規則、策略群組、DNS 集中管理,改動留下註解。訂閱更新失敗時舊快取仍在,節點不會突然消失;更新失敗的排查順序與自動更新設定見部落格《Clash 訂閱更新失敗的常見原因與自動更新設定方法》。

外部控制面板

external-controller 是什麼

核心啟動後會依 external-controller 的位址暴露一組 RESTful API 與 WebSocket 介面:查詢代理、切換節點、讀取規則、看目前連線、收即時日誌,用戶端圖形介面本質上就是呼叫這組 API。把它開啟並配上 Web 面板,就能脫離特定用戶端,用任意瀏覽器管理正在運行的核心——路由器上的 mihomo、伺服器上的無人值守實例,都靠這條路管理。

開啟方式

external-controller: 127.0.0.1:9090
external-ui: ui
secret: "your-password"

external-controller 是 API 監聽位址;external-ui 指向面板靜態檔案目錄,設定好後存取 http://127.0.0.1:9090/ui 即是面板;secret 是存取權杖,面板登入與 API 請求都要帶上。面板檔案用社群現成的發布包即可:metacubexd、zashboard、yacd 都是成熟選擇,下載發布包解壓到 ui 目錄;也可以不部署本機檔案,直接開啟面板的線上頁面,填入 API 位址與金鑰,瀏覽器會直連本機 API。

常用 API 一覽

面板的所有功能都建立在這些端點上,自己寫腳本也一樣可以呼叫——定時測速切線、依連線數告警、把流量接進監控系統,都是常見玩法。命令列驗證只需要一個請求標頭:

curl -H "Authorization: Bearer your-password" http://127.0.0.1:9090/proxies

安全邊界

綁定位址先用 127.0.0.1,只允許本機存取,這是預設也是最穩妥的形態。確實需要區域網路存取——比如用手機管理路由器上的核心——把綁定改成內網位址,同時必須設定 secret;沒有權杖保護的 API 等於把代理控制權交給同網段任何人。任何情況下都不要把 9090 連接埠對外映射到公網,也不要在綁定 0.0.0.0 之後仰賴防火牆自覺。

secret 用足夠長的隨機字串,寫進設定後重啟核心即可生效;它透過請求標頭傳遞,面板會記住,日常使用無感。面板的線上版是瀏覽器直連你填入的 API 位址,金鑰不經過第三方伺服器,但仍建議只在可信網路裡操作,用完就關閉分頁。