Clash 進階設定手冊
面向已完成基礎安裝的使用者,依七大主題整理策略組、規則分流、DNS、TUN 與 Fake-IP、網域嗅探、覆寫合併與控制面板的欄位含義、參數取捨與可重複使用的設定範例。
設定檔骨架與閱讀慣例
Clash 的全部行為都由一份 YAML 設定檔驅動。客戶端介面上的每一個開關——代理模式、區域網路共用、TUN、面板連接埠——最終都會落到這份檔案的某個欄位上。理解頂層欄位的分工,是讀懂後續所有章節的前提:入站部分決定流量從哪裡進來(連接埠、TUN 虛擬網卡),出站部分決定流量從哪裡出去(節點、策略組),規則部分決定「哪些流量走哪個出口」,DNS 與嗅探部分則決定核心如何辨認出一條連線的真實目標。
頂層欄位總覽
| 欄位 | 作用域 | 一句話說明 |
|---|---|---|
mixed-port | 入站 | HTTP 與 SOCKS5 合一的混合監聽連接埠,系統代理指向它 |
allow-lan | 入站 | 是否允許區域網路內其他裝置連入本機連接埠 |
tun | 入站 | 虛擬網卡設定,接管系統代理覆蓋不到的流量 |
mode | 調度 | rule / global / direct 三種執行模式 |
proxies | 出站 | 節點定義清單,通常由訂閱提供 |
proxy-groups | 出站 | 策略組,把節點組織成可選擇、可測速的集合 |
proxy-providers | 出站 | 節點提供者,把多份訂閱按 URL 外部化管理 |
rules | 調度 | 分流規則,自上而下比對,決定流量出口 |
rule-providers | 調度 | 規則提供者,把大量規則外部化為可更新的規則集 |
dns | 解析 | 內建 DNS 模組,含 Fake-IP、分流解析與防洩漏設定 |
sniffer | 解析 | 網域嗅探,從流量中還原真實網域 |
external-controller | 管理 | RESTful API 監聽位址,外部控制面板依賴它 |
log-level | 管理 | 日誌等級,排查問題時暫時調為 debug |
閱讀慣例
後續所有 YAML 範例遵循三條慣例:縮排一律兩個空格,不使用 Tab;布林值一律小寫 true / false;範例片段都可以直接貼到客戶端的覆寫區(見覆寫章節)驗證效果,不必修改訂閱原文。欄位名的完整清單與逐條釋義收錄在概念速查的設定檔欄位分類,本頁只展開進階使用中真正需要動手改的部分。
原版 Clash 核心倉庫已封存,本頁涉及的 sniffer、nameserver-policy 部分語法、format: mrs 等能力僅 mihomo 核心支援。兩代核心的完整差異對照可讀部落格文章《mihomo 核心與原版 Clash 核心差異全覽》。
策略組類型與實戰
策略組(proxy-groups)是節點與規則之間的調度層。規則不直接指向某個具體節點,而是指向一個策略組;組內再決定目前實際使用哪個節點。這一層間接性帶來兩個好處:訂閱節點增刪改名時規則不需要跟著改,以及可以按「自動測速」「故障轉移」「手動指定」等不同策略管理不同用途的流量。
四種常用類型
| 類型 | 選擇邏輯 | 典型用途 |
|---|---|---|
select | 完全由使用者手動選擇,不自動切換 | 頂層總開關組、需要固定出口的業務組 |
url-test | 週期性測延遲,自動選用最快節點 | 日常瀏覽等對速度敏感的通用流量 |
fallback | 按清單順序偵測可用性,首個存活者生效 | 主備結構:平時走主力節點,故障時自動落到備用 |
load-balance | 按雜湊或輪詢把連線分散到多個節點 | 大量並行下載、避免單節點觸發限速 |
此外還有 relay(鏈式中轉)類型,mihomo 已不再推薦,鏈式需求建議改用節點層級的 dialer-proxy 欄位實現,行為更可控。理解這四種類型的差異,關鍵是想清楚「切換的決策權交給誰」:select 把決策權完全交給人,內核只忠實執行你手選的結果,適合放在最頂層做總開關,因為你永遠知道當前流量的確切出口;url-test 與 fallback 把決策權交給延遲探測,區別在於前者追求「最快」、後者追求「可用」,前者會為了幾十毫秒的優勢頻繁切換,後者只在當前節點徹底失聯時才動;load-balance 則把決策權交給雜湊演算法,它不關心哪個節點更快,只關心把並發連線盡量攤開。選型時一句話概括:要穩定可預期用 select,要日常最快用 url-test,要容災兜底用 fallback,要壓榨多節點頻寬用 load-balance。很多使用者把所有組都設成 url-test,結果觀看串流媒體時因為節點被自動切走而反覆卡頓——串流媒體這類需要工作階段保持的場景,恰恰應該用 select 固定一個出口。
關鍵參數取捨
自動型策略組的行為由四個參數決定。url 是健康檢查的目標位址,應選一個輕量且穩定的探測端點,常用 https://www.gstatic.com/generate_204;interval 是檢查週期(秒),設得太短會頻繁發起探測浪費流量,設得太長又會讓故障切換遲鈍,日常 300 秒是均衡值;tolerance 只對 url-test 生效,表示新舊節點延遲差超過該毫秒數才切換,設為 50~100 可以避免兩個延遲接近的節點來回抖動;lazy 設為 true 時,未被使用的組不發起健康檢查,能顯著減少背景探測量。
proxy-groups:
- name: 節點選擇
type: select
proxies:
- 自動測速
- 故障轉移
- 香港節點
- 日本節點
- DIRECT
- name: 自動測速
type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
tolerance: 60
lazy: true
proxies:
- 香港節點
- 日本節點
- name: 香港節點
type: url-test
url: https://www.gstatic.com/generate_204
interval: 300
include-all: true
filter: "(?i)hk|hong|港"
巢狀分組實戰
規模化管理的常見做法是兩層結構:底層按地區建自動組(香港、日本、新加坡各一個 url-test 組,用 filter 正規表達式從全部節點中篩選),上層按用途建手動組(串流媒體、開發工具、總出口各一個 select 組,候選項是地區組而不是零散節點)。這樣訂閱換節點時地區組自動重新收納,使用者日常只在上層組之間切換,面板清單也不會被上百個節點名淹沒。include-all: true 配合 filter 是 mihomo 提供的篩選語法,正規表達式不區分大小寫建議加 (?i) 前綴。寫完分組後,記得讓 rules 裡的出口名與組名逐字一致,YAML 中組名含空格或特殊字元時用引號包裹更穩妥。
規則分流基礎與比對順序
規則(rules)是 Clash 的核心調度表,只有 mode: rule 時才會生效。每條規則由「類型,比對值,出口」三段組成,核心對每一條新連線自上而下逐條比對,命中第一條即停止,後面的規則不再參與。這個「首條命中」原則意味著規則順序本身就是優先順序:同一個網域如果同時能被第 10 條和第 200 條比對到,生效的永遠是第 10 條。排查「某網站為什麼走錯出口」時,第一步永遠是在日誌或面板的連線頁裡看它命中了哪一條。
常用規則類型
DOMAIN:完整網域精確比對,僅命中一模一樣的主機名稱。DOMAIN-SUFFIX:後綴比對,example.com同時命中自身與全部子網域,是最常用的類型。DOMAIN-KEYWORD:關鍵字比對,網域中任意位置包含即命中,誤傷面大,慎用。IP-CIDR/IP-CIDR6:按目標 IP 網段比對,常用於內網直連與特定服務的 IP 段。GEOIP:按 IP 地理資料庫比對,GEOIP,CN,DIRECT是中國大陸 IP 直連的標準寫法。GEOSITE:按內建網域分類庫比對(mihomo 特性),一條規則覆蓋一整類網站。PROCESS-NAME:按發起連線的行程名稱比對,適合讓某個應用整體直連或整體走代理,桌面端與 TUN 模式下可用。RULE-SET:引用一個外部規則集,見下一章。MATCH:兜底規則,比對一切剩餘流量,必須且只能放在最後一條。
no-resolve 與排序建議
IP 類規則(IP-CIDR、GEOIP)有一個隱蔽的副作用:當連線目標是網域時,核心必須先把網域解析成 IP 才能比對,這次解析可能走本地 DNS,既拖慢比對又可能造成不必要的解析請求。在 IP 規則末尾追加 no-resolve 參數,可以讓該條規則跳過純網域連線、只比對本身就是 IP 的目標。實務上的排序建議是:行程規則與精確網域規則放最前,網域後綴與規則集居中,GEOIP,CN 這類 IP 規則放在所有網域規則之後,MATCH 收尾。這樣絕大多數連線在網域階段就完成分流,不觸發解析。
rules:
- PROCESS-NAME,Telegram,節點選擇
- DOMAIN,dl.google.com,節點選擇
- DOMAIN-SUFFIX,openai.com,節點選擇
- RULE-SET,ads-block,REJECT
- RULE-SET,cn-sites,DIRECT
- GEOSITE,category-games,DIRECT
- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- GEOIP,CN,DIRECT
- MATCH,節點選擇
MATCH 之後的任何規則都是死代碼;缺少 MATCH 則未命中流量的去向取決於核心預設行為,排查問題時容易困惑。寫完規則務必確認最後一條是 MATCH,且出口指向一個真實存在的策略組。自訂規則的更多組織思路可參考教學頁的模式選擇一節。
規則集訂閱化管理
把幾千條網域規則直接寫進主設定,會帶來兩個長期成本:設定檔臃腫難讀,以及規則庫更新時必須整體替換設定。rule-providers(規則提供者)把規則外部化成獨立檔案,核心按週期自動下載更新,主設定裡只留一條 RULE-SET 引用——規則內容的維護從此與主設定解耦,這是社群維護的大型分流規則庫的標準接入方式。
欄位結構
rule-providers:
cn-sites:
type: http
behavior: domain
format: yaml
url: "https://example.com/rules/cn-domains.yaml"
path: ./rules/cn-sites.yaml
interval: 86400
ads-block:
type: http
behavior: domain
format: mrs
url: "https://example.com/rules/reject.mrs"
path: ./rules/ads-block.mrs
interval: 86400
type 取 http 表示遠端下載(另有 file 引用本地檔案);path 是本地快取路徑,下載失敗時核心繼續使用快取,不會因為一次網路波動丟掉整套規則;interval 是自動更新週期(秒),規則庫通常一天更新一次,86400 足夠。format 支援 yaml、text 與 mihomo 特有的二進位格式 mrs,後者體積小、載入快,大型規則集優先選它。
behavior 三種取值
| 取值 | 檔案內容 | 比對語意 |
|---|---|---|
domain | 純網域清單,+.example.com 表示含子網域 | 整個集合按網域後綴比對,效能最好 |
ipcidr | 純 IP 網段清單 | 整個集合按 CIDR 比對,引用時可加 no-resolve |
classical | 完整規則行,類型混排 | 等同於把規則逐條內嵌,靈活但開銷最大 |
behavior 必須與檔案實際內容一致,寫錯會導致規則集載入後全部不命中——這是規則集不生效最常見的原因,其次是 RULE-SET 引用名與 provider 鍵名不一致。另外注意:規則集本身的下載請求也是一條流量,如果規則庫來源站需要代理才能存取,可在 provider 裡加 proxy: 節點選擇 指定下載出口,避免初次啟動時因為「規則沒下載到所以沒規則可用」的死結。
DNS 設定優化與防洩漏
DNS 是進階設定裡投入產出比最高、也最容易被忽視的一塊。預設情況下,作業系統的 DNS 查詢並不經過代理:即使流量本身已經加密轉送,網域解析請求仍可能以明文發往本地電信業者的 DNS 伺服器——這就是「Clash DNS 洩漏」的由來,解析記錄會完整暴露曾造訪哪些網站。啟用核心的 dns 模組並正確分層設定,才能把解析行為也納入管控。
解析器的三個層次
mihomo 的 DNS 設定分三層。default-nameserver 只做一件事:解析後續 DoH/DoT 伺服器自身的網域,因此必須填純 IP 位址;nameserver 是主解析組,承擔絕大多數查詢,建議填寫支援加密傳輸的 DoH 位址;fallback 是可選的備用組,配合 fallback-filter 使用——當主組回傳的結果命中過濾條件(例如解析結果落在 GEOIP CN 之外)時,改用備用組的結果。這套機制的目的,是讓境內網域由回應快的本地解析器處理、境外網域由不受汙染的加密解析器處理,兼顧速度與準確性。
dns:
enable: true
listen: 0.0.0.0:1053
ipv6: false
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
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 精細分流
如果 fallback 的「按結果二選一」還不夠精細,nameserver-policy 允許按查詢的網域直接指定解析器:鍵可以是網域後綴、geosite: 分類甚至 rule-set: 引用,值是解析器清單。典型用法是讓 geosite:cn 走本地 DoH、其餘走境外 DoH,從查詢入口就完成分流,而不是等拿到結果再補救。
dns:
nameserver-policy:
"geosite:cn":
- https://doh.pub/dns-query
"+.internal.corp":
- 10.0.0.53
初次設定 DNS 模組時,有幾個反直覺的坑值得提前知道。其一是 enhanced-mode: fake-ip 下 fallback-filter 的意義會弱化:因為回傳給應用的本就是假 IP,真正的解析發生在連線建立、內核反查網域之後,此時分流已經由網域規則接管,fallback 的「按結果國別二選一」更多服務於那些繞過 Fake-IP 直接用真實 IP 的連線。其二是 respect-rules 欄位:開啟後,DNS 查詢本身也會按 rules 走分流,讓境外解析器的查詢走代理出口,進一步降低解析被污染或被觀測的機率,但代價是解析鏈路變長,首次建連略慢,是否開啟取決於你對隱私與速度的權衡。其三是不要在 nameserver 裡混填國內外解析器卻不做任何策略——那樣每次查詢會向所有解析器並發請求、採信最先回傳者,境內網域很可能被境外解析器搶答到一個次優 IP,反而拖慢造訪。正確姿勢始終是用 nameserver-policy 或 fallback 機制把境內外解析明確分開。最後,ipv6: false 在多數純 IPv4 代理環境下是省心的預設值,若你的網路與節點都完整支援 IPv6,再開啟並同步補齊 IPv6 的規則與 DNS,否則容易出現「AAAA 記錄解析成功但連線逾時」的間歇性故障。
設定完成後應實際驗證:在瀏覽器造訪任一 DNS 洩漏偵測網站,觀察列出的解析伺服器是否還包含本地電信業者位址。若使用系統代理模式,注意瀏覽器自身的安全 DNS(DoH)設定可能繞開 Clash 直連解析器,測試時先關閉瀏覽器內建 DoH 再判斷。TUN 模式下配合 dns-hijack 可以強制劫持全部明文解析,見下一章。
TUN 模式與 Fake-IP 機制
系統代理的本質是「告知」:作業系統把代理位址寫進環境設定,遵守約定的應用程式(瀏覽器、多數桌面軟體)主動把流量交給 Clash。但命令列工具、部分遊戲客戶端以及幾乎所有 UDP 流量並不理會這份約定,它們的連線會直接繞過代理。TUN 模式換了一種思路——在系統裡建立一塊虛擬網卡並接管預設路由,所有流量在網路層就被截獲,應用程式無從繞過。兩種機制的完整對比與情境選擇,可讀部落格文章《Clash TUN 模式和系統代理有什麼區別》。
tun 欄位設定
tun:
enable: true
stack: mixed
auto-route: true
auto-detect-interface: true
dns-hijack:
- any:53
- tcp://any:53
stack 決定 TUN 封包的處理協定堆疊:system 直接複用作業系統網路堆疊,效能好但對系統環境敏感;gvisor 是使用者態實現,相容性最穩;mixed 取兩者之長(TCP 走 system、UDP 走 gvisor),是目前多數情境的推薦值。auto-route 自動寫入路由表讓流量導向虛擬網卡,auto-detect-interface 自動辨識實體出口網卡防止回圈;這兩項一般保持開啟,除非你在路由器等複雜網路拓撲下需要手動控制路由。dns-hijack 把發往任意位址 53 連接埠的明文 DNS 查詢強制劫持給核心解析,是 TUN 模式下堵死 DNS 洩漏的關鍵一環。桌面端啟用 TUN 需要管理員權限或已安裝的系統服務,Clash Plus 與 Clash Verge Rev 首次開啟時都會引導授權。
Fake-IP:為什麼解析結果是 198.18 開頭
enhanced-mode: fake-ip 是與 TUN 配合最好的解析模式。它的機制是:應用程式發起網域查詢時,核心不做真實解析,而是立刻從保留網段 198.18.0.0/16 裡分配一個「假 IP」回傳,並記住這個 IP 與網域的映射;當應用程式拿著假 IP 發起連線時,核心反查映射還原出網域,再按網域規則分流。好處有二:省掉一次真實解析的等待,建立連線更快;網域資訊保留到了規則比對階段,分流精度不受解析影響。代價是個別依賴真實 IP 的程式會異常——區域網路探索、NTP 時間同步、部分遊戲登入器等,這類網域應加入 fake-ip-filter 白名單,讓它們走真實解析:
dns:
fake-ip-filter:
- "*.lan"
- "*.local"
- "time.*.com"
- "ntp.*.com"
- "+.stun.*.*"
如果你的使用情境以瀏覽器為主、且經常需要把解析結果交給第三方程式使用,也可以退回 enhanced-mode: redir-host(真實 IP 模式),代價是每次連線都要等待真實解析完成。兩種模式可隨時切換,切換後建議清空一次 DNS 快取再觀察。
網域嗅探:把 IP 還原成網域
規則分流的理想輸入是網域,但有兩類流量到達核心時只剩下 IP:一是應用程式自帶 DNS(比如瀏覽器內建 DoH)繞開了核心解析,連線目標直接是真實 IP;二是 Fake-IP 白名單之外仍有程式快取了歷史解析結果。目標只剩 IP 時,所有網域規則全部失效,流量只能落到 GEOIP 或 MATCH 兜底——分流精度大打折扣。網域嗅探(sniffer)就是補救手段:核心檢查連線標頭的明文特徵(HTTP 請求的 Host 標頭、TLS 交握的 SNI 欄位、QUIC 初始封包),把真實網域「嗅」出來,再用它重新走一遍規則比對。
設定範例
sniffer:
enable: true
sniff:
HTTP:
ports: [80, 8080-8880]
override-destination: true
TLS:
ports: [443, 8443]
QUIC:
ports: [443, 8443]
force-domain:
- "+.v2ex.com"
skip-domain:
- "+.push.apple.com"
- "Mijia Cloud"
三個協定區塊分別宣告在哪些連接埠上嘗試嗅探;override-destination 為 true 時,用嗅探到的網域覆蓋連線的目標位址,使後續規則與日誌都以網域呈現。force-domain 列出的網域即使已經有解析結果也強制用嗅探值覆蓋,適合處理 CDN 網域與解析結果對不上的網站;skip-domain 則相反,列出的目標跳過嗅探——蘋果推播、部分廠商的長連線對連線標頭被檢查很敏感,列入跳過名單可避免莫名斷線。嗅探只讀取協定交握階段本就明文的欄位,不解密任何加密載荷;它的開銷集中在每條新連線的首個封包,日常使用幾乎無感。TUN + Fake-IP + 嗅探三件套同時啟用,是目前分流精度最高的組合。
本地覆寫與多訂閱合併
訂閱檔由伺服端產生,每次更新都會整體覆蓋本地內容——直接在訂閱檔裡手動改 DNS、加規則,下次更新就全部遺失。正確的做法是把個人客製化放進「覆寫」層:客戶端在每次載入訂閱後,自動把你的覆寫內容合併進最終設定,訂閱歸訂閱、客製化歸客製化,互不干擾。這是長期使用 Clash 最值得建立的習慣。
各客戶端的覆寫能力
下載頁首推的 Clash Plus 內建覆寫編輯器,支援以 YAML 片段的形式追加或取代欄位,適合本頁所有範例的落地;Clash Verge Rev 提供 Merge(宣告式合併)與 Script(JavaScript 程式化修改)兩種全域擴充,Merge 裡 dns、tun 等鍵直接整塊取代訂閱同名欄位,前綴寫法可實現清單追加,複雜邏輯再用 Script;FlClash 也支援設定覆寫,行動端上同樣能保住自訂規則。從停更客戶端遷移覆寫設定的完整路徑,見部落格《Clash for Windows 停止更新後用什麼》。一段典型的 Merge 覆寫如下:
dns:
enable: true
enhanced-mode: fake-ip
prepend-rules:
- DOMAIN-SUFFIX,corp.example.com,DIRECT
append-rules:
- GEOIP,CN,DIRECT
proxy-providers 合併多份訂閱
手上有多家機場訂閱時,不必在客戶端裡來回切換設定。proxy-providers 允許把每份訂閱宣告為一個節點提供者,再在策略組裡用 use 引用,多份訂閱的節點匯入同一套分組體系統一測速、統一分流:
proxy-providers:
provider-a:
type: http
url: "https://example.com/sub-a?token=xxxx"
path: ./providers/a.yaml
interval: 3600
health-check:
enable: true
url: https://www.gstatic.com/generate_204
interval: 300
provider-b:
type: http
url: "https://example.net/sub-b?token=xxxx"
path: ./providers/b.yaml
interval: 3600
proxy-groups:
- name: 全部節點
type: url-test
use:
- provider-a
- provider-b
url: https://www.gstatic.com/generate_204
interval: 300
provider 層級的 health-check 讓節點在被任何組使用前就有健康狀態;filter、exclude-filter 欄位可以在 provider 層先過濾掉到期提示、流量播報這類非節點條目。注意兩家訂閱出現同名節點會導致載入衝突,可用 override.additional-prefix 給每個 provider 的節點統一加前綴區分來源。多裝置共用這套合併設定的區域網路玩法,另見部落格《Clash 混合連接埠與允許區域網路連線設定》。
外部控制面板接入
核心在執行時暴露一套 RESTful API,策略組切換、延遲測試、連線檢視、設定重新載入都可以透過它完成——桌面客戶端的圖形介面本質上就是這套 API 的封裝。當 Clash 跑在路由器、NAS 或無頭伺服器上時(部署思路見部落格《路由器直跑 Clash 核心方案概覽》),外部控制面板就是唯一順手的管理入口。
開啟 API 與面板
external-controller: 127.0.0.1:9090
secret: "your-strong-secret"
external-ui: ./ui
external-ui-url: "https://example.com/dashboard/dist.zip"
external-controller 指定 API 監聽位址,僅本機管理保持 127.0.0.1,需要區域網路內其他裝置存取才改 0.0.0.0;secret 是 API 存取權杖,面板連線時以 Authorization: Bearer 標頭攜帶。external-ui 指向本地靜態面板目錄,配合 external-ui-url 可以讓核心自動下載面板發行包,之後瀏覽器造訪 http://127.0.0.1:9090/ui 即可開啟。社群常用面板有 metacubexd、zashboard 與 yacd 系列,均為純靜態頁面,選一個順眼的即可;桌面使用者通常不需要單獨部署,Clash Plus 與 Clash Verge Rev 已內嵌面板檢視。
直接呼叫 API
# 查看核心版本
curl -H "Authorization: Bearer your-strong-secret" \
http://127.0.0.1:9090/version
# 把「節點選擇」組切換到「香港節點」
curl -X PUT -H "Authorization: Bearer your-strong-secret" \
-d '{"name":"香港節點"}' \
http://127.0.0.1:9090/proxies/節點選擇
# 觸發指定組延遲測試
curl -H "Authorization: Bearer your-strong-secret" \
"http://127.0.0.1:9090/group/自動測速/delay?url=https://www.gstatic.com/generate_204&timeout=3000"
API 擁有對核心的完全控制權。把 external-controller 暴露到 0.0.0.0 而不設 secret,等於把代理調度權交給區域網路內任何裝置;若裝置本身有公網位址,風險進一步放大。原則:能 127.0.0.1 就不監聽全網,監聽全網就必須配強密碼,並確認防火牆沒有把 9090 連接埠開放到公網。
至此,七大主題的進階設定已經涵蓋完畢。建議的實踐路徑是:先在教學頁確認基礎鏈路連通,再從 DNS 與策略組兩章入手逐塊套用範例,每改一塊就用面板的連線檢視驗證效果;欄位含義隨時查概念速查,客戶端選擇與取得見下載頁,網站定位與維護原則見專案介紹。