Clash 進階設定手冊

01策略群組類型與實戰

策略群組(proxy-groups)是整份設定的調度中樞。規則比對的結果通常不會直接指向某個節點,而是指向一個策略群組;群組再依自身類型決定流量的實際出口。理解每種群組類型的行為差異,是打造一份可長期維護設定的第一步。Clash 核心支援的常用群組類型有四種:select、url-test、fallback 與 load-balance,各自解決不同的調度問題。

select:手動選擇群組

select 是最基礎的群組類型,出口由使用者在用戶端介面手動指定。它不做任何測速與健康檢查,選中哪個就一直使用哪個,直到手動更換或該節點從訂閱中消失。這種「完全聽指揮」的特性使它適合放在設定的最外層,充當總開關:把若干功能群組、地區群組連同 DIRECT 一起收進一個名為「節點選擇」的 select 群組,規則統一指向它,日常切換只需要在介面點一下。

select 群組的必填欄位只有 name、type 與 proxies 三項。proxies 清單裡可以混排具體節點名稱、其他策略群組名稱,以及兩個內建策略:DIRECT 表示直連不走代理,REJECT 表示直接拒絕連線。群組名稱之間互相引用時必須與定義完全一致,包括空格與大小寫,寫錯會在啟動時回報「群組不存在」的錯誤。

url-test 與 fallback:自動化調度

url-test 群組會週期性地對群組內所有節點發起一次輕量 HTTP 請求,選出延遲最低的節點作為目前出口。三個關鍵參數需要理解清楚:url 是測速目標,慣例使用回傳 204 狀態碼、回應內容為空的位址,盡量減少測試本身消耗的流量;interval 是測試週期,單位為秒,常用值 300,設太短會造成頻繁的背景請求;tolerance 是切換容差,單位為毫秒——只有當新的最佳節點比目前節點快出這個差值時才會真正切換。不設 tolerance 時,兩個延遲接近的節點可能因為量測抖動而來回切換,導致出口 IP 頻繁變化。

fallback 群組則依 proxies 清單的書寫順序做可用性檢查,始終使用清單中第一個通過檢查的節點;當它失效時順延到下一個,恢復後自動切回。它與 url-test 的本質差異在於關注點不同:url-test 關心「誰的延遲最低」,fallback 關心「誰排在最前面且還活著」。因此 fallback 適合「主力線路 + 備用線路」的情境——把最穩定、最信任的節點寫在第一位,把保底線路依序排在後面,平時始終走主力,主力故障時無感切換。

load-balance:負載平衡

load-balance 群組把連線分散到群組內多個節點上。strategy 欄位取 consistent-hashing 時,依目標網域做一致性雜湊,同一個網站的請求固定落在同一個節點上,可以避免登入狀態因為出口 IP 反覆變化而失效;取 round-robin 時逐連線輪替出口,流量分散得更均勻,但對會話敏感的站點不友善。實務上,負載平衡更適合大流量下載、大量擷取這類對出口 IP 不敏感的用途,不建議給需要穩定登入狀態的服務使用。

群組巢狀與結構設計

實戰建議採用「功能群組引用地區群組」的兩層結構:先按地區建立若干 url-test 群組(如「香港自動」「日本自動」),再按用途建立若干 select 功能群組(如「串流媒體」「AI 服務」「保底選擇」),功能群組的候選項寫地區群組的名稱而不是具體節點。這樣訂閱節點增減、改名時只會影響地區群組這一層,規則與功能群組完全不需要動;換一家訂閱,也只需重建地區群組即可。唯一要注意的是避免群組之間形成循環引用——A 群組引用 B 群組、B 群組又引用 A 群組,核心會在啟動時回報錯誤並拒絕載入。

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

  - name: 香港自動
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 60
    proxies: [HK-01, HK-02, HK-03]

  - name: 故障轉移
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies: [HK-01, JP-01, SG-01]

  - name: 大量下載
    type: load-balance
    strategy: consistent-hashing
    proxies: [HK-01, HK-02, JP-01]

02規則集訂閱化管理

把幾千條分流規則直接寫進主設定檔,有兩個長期問題:一是主設定檔臃腫難以維護,想調整一條規則要在幾千行裡翻找;二是規則資料(廣告網域、地區 IP 段)本身在持續更新,寫死在設定裡就永遠停在寫入那一天。rule-providers(規則提供器)把規則拆成獨立檔案,按週期自動拉取更新,主設定裡只留一行引用,是規則管理的標準做法。

rule-providers 的欄位含義

每個提供器是一個具名條目,核心欄位逐一說明。type 取 http 表示從遠端位址週期拉取,取 file 表示讀取本機檔案、不做自動更新;url 是遠端規則檔案位址;path 指定本機快取路徑,省略時核心會依 url 的雜湊自動命名快取檔案;interval 是更新週期,單位秒,86400 即一天,規則資料更新頻率不高,沒有必要設得更短。

behavior 決定檔案內容的解讀方式,是最容易設錯的欄位:domain 表示檔案是純網域清單,每行一個網域(支援 +. 通配前綴);ipcidr 表示檔案是 IP 網段清單;classical 表示檔案逐行寫入完整規則,可以混合 DOMAIN-SUFFIX、IP-CIDR、PROCESS-NAME 等多種類型。behavior 與檔案實際內容不符時,輕則規則全部失配,重則載入時回報錯誤。format 宣告檔案格式:yaml 與 text 通用性最好;mrs 是 mihomo 核心的二進位格式,體積小、載入快,但只支援 domain 與 ipcidr 兩種 behavior。

在 rules 中引用

提供器定義好後,在 rules 段用 RULE-SET,提供器名稱,策略群組名稱 的格式引用。ipcidr 類規則集建議在末尾附加 no-resolve 參數:IP 類規則要拿到目標 IP 才能比對,如果連線目標是網域,核心會先發起一次 DNS 解析再比對——no-resolve 告訴核心跳過這次解析,網域型連線直接視為不比對、繼續往下走。這既避免了不必要的解析開銷,也防止在 fake-ip 模式下產生多餘的真實解析請求。

rule-providers:
  ad-domains:
    type: http
    behavior: domain
    format: yaml
    url: https://example.com/rulesets/ad-domains.yaml
    path: ./ruleset/ad-domains.yaml
    interval: 86400
  cn-ip:
    type: http
    behavior: ipcidr
    format: mrs
    url: https://example.com/rulesets/cn-ip.mrs
    path: ./ruleset/cn-ip.mrs
    interval: 86400

rules:
  - RULE-SET,ad-domains,REJECT
  - RULE-SET,cn-ip,DIRECT,no-resolve
  - MATCH,節點選擇

比對順序與更新疑難排解

規則自上而下逐條比對,第一條命中即停止,後面的規則不再參與——因此規則集的排列順序就是優先順序:拒絕類(廣告)放最前面,精確的網域類規則在前,寬泛的 IP 類規則在後,最後必須有一條 MATCH 保底,否則未命中的流量行為不可預期。想確認某個網站究竟命中了哪條規則,最直接的方法是開啟第七章介紹的控制面板,在連線頁查看該連線的規則列。

規則集更新失敗是常見問題。排查思路:規則檔案的拉取本身也要經過網路,如果拉取位址在目前網路環境下無法直連,冷啟動(還沒有任何可用代理)時就會拉取失敗——解決辦法是選擇可以直連的鏡像位址,或確保首次啟動前快取檔案已經存在;其次查看核心日誌中 provider 相關的錯誤訊息,常見原因是 behavior 與檔案內容不符、format 宣告錯誤;最後可以手動刪除 path 指向的快取檔案,重新啟動核心強制重新下載。

03DNS 設定最佳化

Clash 的內建 DNS 不是可有可無的附屬功能:網域類規則的比對、fake-ip 對映的產生、DNS 請求是否繞開當地網路汙染,都取決於這一段設定。預設設定在多數情境下能用,但要做到「直連網域解析快、代理網域結果準、全程不洩漏」,需要理解每個欄位的分工。

基本欄位

enable: true 開啟內建 DNS;listen 指定監聽位址與埠號,TUN 模式的 DNS 劫持會把系統查詢轉發到這裡;enhanced-mode 在 fake-ip 與 redir-host 之間二選一,兩者的取捨在下一章展開。default-nameserver 是一個容易被忽略的欄位:後面 nameserver 清單裡如果填的是 DoH 位址(形如 https://…/dns-query),這些位址本身也是網域,需要先被解析出來——default-nameserver 就負責這一步,因此它只能填純 IP 位址,不能再填網域,否則形成解析死循環。

nameserver 是主解析群組,負責大部分網域的解析。建議填寫目前網路環境下可穩定直連的加密 DNS 位址,保證直連流量的解析速度與準確性;明文 53 埠的傳統 DNS 也可以用,但在部分網路下明文查詢可能被中間裝置竄改,優先選 DoH 或 DoT。

fallback 與 fallback-filter

fallback 群組面向「主解析群組結果可能被汙染」的網域。當 nameserver 與 fallback 同時存在時,核心會向兩組並行發起查詢,再由 fallback-filter 決定採信哪邊的結果:geoip: true 且 geoip-code: CN 表示——如果 nameserver 回傳的 IP 屬於中國大陸,就認定這是中國大陸網域、結果可信,採用 nameserver 的答案;否則就認為該網域應該走海外解析,採用 fallback 的答案。ipcidr 子欄位則列出已知的汙染結果網段(如保留段 240.0.0.0/4),nameserver 回傳的 IP 落在這些網段裡時直接判定為汙染、改用 fallback 結果。

這套機制的效果是:中國大陸網域由鄰近的中國大陸 DNS 解析,拿到 CDN 優選 IP;海外網域的解析結果透過 fallback 群組的加密通道取得,不受當地網路汙染影響。需要注意 fallback 裡的加密 DNS 位址應該是在代理可用時能正常存取的,否則並行查詢中 fallback 一側長期逾時,會拖慢整體解析。

nameserver-policy:定向解析

nameserver-policy 允許把特定網域指派給特定上游,優先順序高於 nameserver 與 fallback 的通用邏輯。典型用法有兩類:公司內網網域必須交給內網 DNS 伺服器解析,否則解析不出結果;某些對 CDN 調度敏感的中國大陸大型網站,固定交給某一家中國大陸 DoH,避免並行機制帶來的不確定性。鍵支援 +. 通配前綴,比對自身與全部子網域。

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://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
    ipcidr:
      - 240.0.0.0/4
  nameserver-policy:
    "+.corp.example.com": 10.0.0.53

洩漏驗證

設定完成後應該實際驗證一次:連線代理後存取 DNS 洩漏檢測類網站,觀察檢測出的解析伺服器歸屬地——如果海外網域的解析請求仍顯示由當地電信業者 DNS 發出,說明存在洩漏,常見原因是系統裡殘留了手動指定的 DNS、或瀏覽器內建的 DoH 設定繞開了 Clash。也可以把日誌層級調到 debug,直接觀察每個網域實際走了哪個上游。完整的驗證步驟與兩種 DNS 模式的取捨分析,見部落格文章《Clash DNS 設定與防洩漏設定實作指南》。

04TUN 模式與 Fake-IP

兩種接管方式的差異

系統代理的本質,是向作業系統宣告一個 HTTP/SOCKS 埠,宣告之後是否使用完全取決於應用程式自己:瀏覽器和多數圖形應用程式會遵循,而大量命令列工具、部分遊戲用戶端與系統服務根本不會讀取這項設定,它們的流量會原樣直連。TUN 模式走的是另一條路:核心建立一塊虛擬網路卡,把系統預設路由指向它,所有應用程式的流量在網路層就被截獲,不依賴任何應用程式配合。一句話概括:系統代理是「邀請制」,TUN 是「全量接管」。兩種方式的完整原理對比見《Clash TUN 模式與系統代理的工作原理對比》。

tun 段欄位說明

stack 選擇協定堆疊實作:system 重複使用作業系統協定堆疊,效能最好;gvisor 是使用者態協定堆疊,相容性更好、對系統侵入更小;mixed 混合兩者,TCP 走 system、UDP 走 gvisor,是多數情境的合理預設。auto-route 自動寫入路由表,把預設流量導向虛擬網路卡;auto-detect-interface 自動識別真實的實體出口網路卡——這項非常關鍵,它保證代理節點自身的流量從實體網路卡發出而不是再次進入虛擬網路卡,缺失或識別錯誤會造成流量迴圈,表現為開啟 TUN 後立即斷網。strict-route 收緊路由規則,防止部分流量繞開虛擬網路卡。dns-hijack 劫持發往任意位址 53 埠的查詢並轉交內建 DNS,常寫 any:53,確保系統與應用程式的 DNS 查詢全部納入第三章的解析體系。

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

Fake-IP 原理與 fake-ip-filter

fake-ip 模式下,內建 DNS 收到查詢時並不做真實解析,而是從 fake-ip-range(預設 198.18.0.1/16 保留段)中分配一個虛假 IP 回傳給應用程式,並在內部記錄「虛假 IP ↔ 網域」的對映。應用程式拿著虛假 IP 發起連線,連線到達核心時反查對映立即得到原始網域,直接依網域比對規則——省去了一次真實解析的往返,建立連線更快,網域規則的命中也更可靠。真實解析只在確定要直連、或由代理伺服器遠端完成時才發生。

副作用在於:少數情境依賴拿到真實 IP 才能運作。區域網路裝置探索、NTP 時間同步、某些遊戲登入器、Windows 的網路連通性偵測,拿到 198.18 段的虛假位址會直接異常。fake-ip-filter 就是為此準備的白名單:列在其中的網域回退為真實解析,不參與 fake-ip 對映。

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

各平台的權限差異

05網域嗅探

為什麼需要嗅探

有兩類流量到達核心時是拿不到網域的:一類是應用程式自行完成 DNS 解析後直接對 IP 發起連線(部分瀏覽器開了內建 DoH、不少行動裝置 App 內建解析邏輯,都屬於這種);另一類是 redir-host 鏈路上網域資訊在中途遺失的轉發情境。沒有網域,所有以網域為基礎的規則全部落空,這些連線只能靠 IP 規則或 MATCH 保底,分流精準度明顯下降。網域嗅探(sniffer)從流量本身把網域「讀」回來:TLS 交握中的 SNI 欄位、HTTP 請求的 Host 標頭、QUIC 交握資訊裡都攜帶目標網域,核心在轉發前解析這些協定標頭,還原出網域再參與規則比對。

設定欄位

sniffer.enable 開啟嗅探;sniff 下按協定逐一設定:ports 限定嗅探的目標埠(TLS 常見 443,HTTP 常見 80,支援埠區間寫法),override-destination 為 true 時用嗅探到的網域覆蓋連線目標參與規則比對。force-domain 列出強制嗅探的網域,即使連線已帶網域也重新嗅探確認;skip-domain 列出跳過嗅探的網域——最常見的用途是排除行動裝置推播服務的長連線,嗅探介入可能干擾這類連線的保活,導致推播延遲。

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

與兩種 DNS 模式的配合

fake-ip 模式下,絕大多數網域已經透過對映反查取得,嗅探是補充手段,專門覆蓋「應用程式直連 IP」的漏網流量;redir-host 模式下網域遺失的機率高得多,嗅探幾乎是必要設定,否則規則命中率會大幅下滑。嗅探對每條新連線會引入一次協定標頭解析的開銷,量級很小,一般裝置感知不到;若確實有極端效能需求,可以縮小 ports 範圍只嗅探標準埠。判斷嗅探是否生效,同樣借助第七章的面板連線頁:連線目標顯示為網域而非純 IP,即代表嗅探完成了還原。

06本機覆寫與多訂閱合併

為什麼需要覆寫

訂閱更新的本質是用遠端最新設定整體取代本機檔案——你在設定裡手動加的規則、調好的 DNS、開好的 TUN,下一次更新全部被沖掉。覆寫機制把「個人化調整」與「訂閱內容」分離開來:訂閱只負責提供節點,規則、DNS、TUN 這些本機策略寫在覆寫層,更新訂閱時覆寫自動重新套用,兩邊互不影響。下載頁收錄的主流圖形用戶端(首選的 Clash Plus,以及 Clash Verge Rev 等)都提供圖形化的覆寫入口,通常分為 Merge 與 Script 兩種形式。

Merge 覆寫:宣告式合併

Merge 覆寫是一段 YAML,按固定語意合併進訂閱設定:字典類欄位(如 dns、tun、sniffer)整段覆蓋訂閱中的同名欄位;清單類欄位透過 prepend- 與 append- 前綴控制插入位置——prepend-rules 把規則插到規則清單最前面(優先順序最高),append-rules 附加到最後。個人自用的直連例外、公司內網網域,放 prepend;自己的保底策略放 append。這種方式宣告式、直觀,可覆蓋「加幾條規則、改一段 DNS」的絕大多數需求。

prepend-rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
  - PROCESS-NAME,ssh,DIRECT
append-rules:
  - MATCH,節點選擇
dns:
  enable: true
  enhanced-mode: fake-ip
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

Script 覆寫:程式化修改

Merge 處理不了「按條件批量修改」的需求,這時用 Script 覆寫:用戶端把解析後的設定物件傳給一個 JavaScript 函式,函式回傳修改後的物件。典型場景:依節點名稱正規表示式自動產生地區分組,訂閱加了新地區節點也能自動歸類;給所有 url-test 群組統一補上 interval 與 tolerance;批量刪除訂閱裡夾帶的到期提醒類「假節點」。腳本裡可以使用完整的 JS 語法,但要保證函式最終 return config,並且不破壞欄位結構,否則核心載入會失敗。

function main(config) {
  config["proxy-groups"]
    .filter((g) => g.type === "url-test")
    .forEach((g) => {
      g.interval = 300;
      g.tolerance = 60;
    });
  return config;
}

proxy-providers:多訂閱合併

手上有多家訂閱時,不必在用戶端裡來回切換設定。proxy-providers 與第二章的規則提供器同理:把每家訂閱宣告為一個節點提供器,策略群組透過 use 欄位引用一個或多個提供器,filter 用正規表示式從合併後的節點池裡篩選(比如只留名稱含「香港」的節點)。這樣一份設定調度多家訂閱,任何一家故障都不影響整體;health-check 子欄位讓提供器自行做週期健康檢查,失效節點會被自動跳過。

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

proxy-groups:
  - name: 香港自動
    type: url-test
    use: [provider-a, provider-b]
    filter: "(?i)hk|hong ?kong|香港"

07外部控制介面與面板

開啟外部控制

Clash 核心內建一套 RESTful 控制介面,幾乎所有圖形用戶端的介面、所有網頁控制面板,底層呼叫的都是它。external-controller 指定監聽位址,只在本機使用時寫 127.0.0.1:9090;secret 設定存取口令,所有請求需在 Authorization: Bearer 標頭裡攜帶;external-ui 指向一個靜態面板目錄,核心會直接代管,瀏覽器存取監聽位址即可開啟。

external-controller: 127.0.0.1:9090
secret: "換成足夠長的隨機口令"
external-ui: ./ui

常用 API 一覽

curl -H "Authorization: Bearer <secret>" \
  http://127.0.0.1:9090/proxies

curl -X PUT -H "Authorization: Bearer <secret>" \
  -d '{"name":"香港自動"}' \
  "http://127.0.0.1:9090/proxies/節點選擇"

面板的日常用法

網頁面板最有價值的是連線頁與日誌頁。排查「某個網站為什麼走錯了出口」,在連線頁找到對應連線,查看它的規則列與代理鏈路列,命中了哪條規則、經過哪個群組、最終從哪個節點出去,一目了然——比對著設定檔猜測有效率得多。日誌頁把層級調到 debug,可以看到每個網域的 DNS 解析路徑與規則比對過程,是第三章 DNS 問題的直接觀測手段。

另外要知道一個行為細節:透過面板或用戶端切換代理模式(規則/全域/直連)後,已經建立的舊連線不會自動中斷,仍依建立時的路徑傳輸;如果切換後感覺「沒生效」,到連線頁中斷全部連線,或重新啟動相關應用程式即可。三種模式的流量走向差異,見《Clash 規則模式與全域模式的差異及切換情境》。

08設定驗證與問題速查

啟動前驗證

改完設定先驗證再重新載入,能省下大量反覆試錯的時間。命令列核心提供語法與語意檢查:mihomo -t -f config.yaml,通過則輸出成功提示,不通過會給出出錯的行號與原因。YAML 的幾個高頻陷阱:縮排必須用空格,混入定位字元會解析失敗;冒號後面必須有一個空格;節點名稱或群組名稱包含 :、#、emoji 等特殊字元時要用引號包起來;清單項目的 - 與內容之間也要有空格。圖形用戶端在儲存設定時通常會自動做一次等效驗證,錯誤訊息同樣值得逐字閱讀。

mihomo -t -f config.yaml

常見問題對照

下一步

本頁涵蓋的是設定層面的系統知識。更口語化的高頻問答整理在 FAQ,按基礎認知、安裝設定、使用技巧、故障排查四類組織;文中出現的代理協定、核心、規則類術語,可在術語表逐條查閱;針對單一主題的深度長文持續發布在部落格。從零開始的完整操作路線,回到使用教學按步驟執行即可。