Clash 進階設定手冊

開始之前:手冊定位與設定基礎

先說明本頁與教學頁的分工。訂閱設定入門是主線教學:匯入訂閱、選擇模式、發起連線、驗證生效,跟著做一遍就能把用戶端用起來。本頁不重複那條主線,而是把進階主題拆成九章,哪一塊要調就查哪一塊,適合放在書籤裡當手冊用。還沒完成首次連線的,建議先去教學頁走一遍,或參考部落格《Clash 首次連線教學:選擇節點、測試延遲與驗證代理生效》,再回來按主題查閱。

本頁的設定對象是 mihomo 核心(原 Clash Meta)。用戶端下載頁列出的在維護用戶端——Clash Plus、Clash Verge Rev、FlClash、Clash Meta for Android 等——全部基於這套核心,設定語法一致。本頁所有 YAML 片段都是 mihomo 設定:桌面與行動端的圖形用戶端一般提供設定編輯或覆寫入口,裸跑核心的使用者則直接編輯設定目錄下的 config.yaml。

動手之前先找到"目前生效的那份設定"。Clash Verge Rev 在「訂閱」頁面對某個設定右鍵即可編輯檔案或編寫全域擴充;Clash Plus 在設定管理裡開啟目前訂閱;FlClash 在設定詳情裡編輯覆寫段;裸核心預設讀取設定目錄下的 config.yaml。多份訂閱並存時,改錯檔案是"改了不生效"的第一大原因。

YAML 語法有四條紀律,後續所有範例都遵守:縮排只用空格、不用 Tab,統一兩格;鍵名後的冒號緊跟一個空格再寫值;值裡含冒號、#、萬用字元時整體加英文引號;同層鍵嚴格對齊。第九章附常見語法錯誤對照表。

# config.yaml 最小骨架(mihomo)
mixed-port: 7890        # HTTP 與 SOCKS 混合連接埠
allow-lan: false        # 是否允許區域網路裝置接入
mode: rule              # rule 規則 / global 全域 / direct 直連
log-level: info
dns: {}                 # 第四章展開
proxies: []             # 節點,通常由訂閱或 proxy-providers 提供
proxy-groups: []        # 第二章展開
rules: []               # 第三章展開

策略組類型與實戰

策略組是分流的中樞。rules 裡每條規則的末尾寫的不是具體節點,而是一個策略組名;流量命中規則後交給組,組按自己的類型邏輯挑出實際出口。把"選節點"這件事從規則裡剝離,是 mihomo 設定的核心思想:規則只管分類,組只管挑選。除了引用真實節點,組裡還可以放兩個內建策略:DIRECT 表示直連,REJECT 表示直接拒絕(常用於廣告與追蹤域名)。

五種類型逐個看

select:手動選擇。proxies 列表的第一項是預設出口,之後在面板裡手動切換。最常用,一般作為頂層出口組。

url-test:自動測速選優。對組內節點按 url 發 HTTP 請求測延遲,每 interval 秒測一輪,選延遲最低的節點;tolerance 指定毫秒級容差,新舊節點差距在容差內不切換,避免節點抖動;lazy 設為 true 時,組內沒有流量就不測速,省請求也省電。

fallback:故障轉移。按 proxies 順序取第一個健康檢查通過的節點。適合主備場景——主力節點故障時自動落到備用,主力恢復後切回。

load-balance:負載平衡。strategy 取 consistent-hashing 時,同一目標域名固定雜湊到同一節點,站點登入狀態不因出口 IP 跳變而掉線;取 round-robin 則逐請求輪替,適合多執行緒下載類場景。

relay:鏈式代理。proxies 按順序串聯,流量先經前置節點再到落地節點。可用於"先過入口再落地"的特殊鏈路,但每多一跳就多一倍延遲與故障面,日常分流用不上。

組的巢狀與 use 引用

proxies 裡既可以寫節點名,也可以寫另一個組名——「節點選擇」裡放「自動選擇」和各地區組,使用者在一處切換即可。組還可以用 use 欄位引用 proxy-providers 拉來的整個訂閱節點集合(見第七章),訂閱更新後組內節點自動跟著變,不需要手改組列表。

一套實戰組合

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies: ["自動選擇", "香港", "日本", "美國", "DIRECT"]

  - name: "自動選擇"
    type: url-test
    use: ["airport-a"]        # 引用第七章的訂閱集合
    url: "http://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80
    lazy: true

  - name: "串流媒體"
    type: select
    proxies: ["香港", "日本", "節點選擇"]

  - name: "下載"
    type: load-balance
    use: ["airport-a"]
    strategy: consistent-hashing
    url: "http://www.gstatic.com/generate_204"
    interval: 600

測速位址怎麼選

url-test 與 fallback 的判斷完全建立在測速位址的回應上,這個位址選得不合適,整套自動選優就會失真。標準做法是選回傳 204 空回應的探測端點:http://www.gstatic.com/generate_204 與 http://cp.cloudflare.com/generate_204 都是專為連通性偵測設計的,回應主體為空、幾乎不產生流量、全球都有接入點,組內幾十個節點一輪測下來負擔也很小。

選位址時注意兩點。第一,測速請求是從被測節點發出去的,拿特定地區的站點當測速位址,量出來的是節點回該地區的鏈路品質,和它訪問其他服務的能力沒有關係,自動選優會因此挑錯節點。第二,204 端點量出的是一次握手往返的延遲,不等於實際業務體驗——延遲低但頻寬小的節點並不少見,看影片、下大檔案照樣卡。對頻寬敏感的場景,與其迷信延遲數字,不如單獨建一個 load-balance 組把請求分攤出去;延遲數字真正可靠的用途,是識別「徹底不通」和「明顯劣化」的節點。

規則集訂閱化管理

規則決定"什麼流量走什麼出口"。把幾十上百條規則寫死在 config.yaml 裡有兩個麻煩:規則會過時,域名清單天天在變;訂閱更新會整份覆蓋手改內容。規則集(rule-providers)把規則拆成獨立的遠端檔案,核心按 interval 定時拉新,主設定裡只留一行引用。

欄位逐項說明

type:http 表示從 URL 拉取,local 表示讀本機檔案。behavior:規則集內容形態——domain 是純域名後綴列表,ipcidr 是純 IP 段列表,classical 是經典規則(檔案裡每行是 DOMAIN-SUFFIX,example.com 這類帶類型前綴的完整規則)。format:檔案格式,支援 yaml、text 與 mrs(mrs 是二進位格式,體積最小,超大列表優先用它)。url / path:遠端位址與本機快取路徑,拉取失敗時用 path 處的快取保底。interval:更新間隔,單位秒。

引用方式與順序原則

rules 裡用 RULE-SET,規則集名,策略組 完成引用。規則比對自上而下、首條命中即停,所以順序就是優先級:廣告拒絕集放最前,區域網路與中國大陸直連放中間,FINAL 保底在最後。RULE-SET 的位置寫錯了,排在它後面的規則永遠輪不到。另外,GEOSITE 規則(如 GEOSITE,cn)由核心內建的 geosite 資料庫提供,與 RULE-SET 的外部檔案是兩套來源,可以混用。

rule-providers:
  reject:
    type: http
    behavior: domain
    format: yaml
    url: "https://example.com/rules/reject.yaml"
    path: ./ruleset/reject.yaml
    interval: 86400
  lan:
    type: http
    behavior: classical
    format: text
    url: "https://example.com/rules/lan.txt"
    path: ./ruleset/lan.txt
    interval: 86400

rules:
  - RULE-SET,reject,REJECT
  - RULE-SET,lan,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

GEO 資料庫:來源與自動更新

GEOIP、GEOSITE 兩類規則背後是核心自帶的兩個資料檔:geoip 按 IP 段標註國家歸屬,geosite 按網域歸類站點集合。它們和規則集一樣會過時,但更新走的是另一套機制,在主設定頂層宣告:

geodata-mode: true        # geoip 用 dat 完整資料(false 則用精簡 mmdb)
geo-auto-update: true     # 自動更新開關
geo-update-interval: 168  # 單位小時,一週一次足夠
geox-url:
  geoip: "https://example-mirror.com/geoip.dat"
  geosite: "https://example-mirror.com/geosite.dat"

geox-url 用來改資料檔的下載來源,預設來源拉不動時換成鏡像位址即可。geodata-mode 的取捨是體積換精度:dat 完整資料分類更細,配合 geosite 的子類用起來更順手;精簡 mmdb 體積小、載入快,路由器等記憶體吃緊的裝置更合適。要注意 GEO 資料更新失敗不會報致命錯誤,核心只是繼續用舊資料,所以它出問題往往是無聲的:分流突然變得不準、GEOIP 命中怪異,這類現象先懷疑 GEO 資料陳舊,在用戶端設定裡手動觸發一次 GEO 更新再觀察。另外 GEO 資料更新後需要重啟核心才生效,這一點與規則集「拉新即用」不同,別在這裡空等。

DNS 設定優化

DNS 是分流品質的分水嶺。三個典型問題:電信業者 DNS 回傳被污染的結果;系統或瀏覽器繞過代理直接問電信業者,造成 DNS 洩漏;境外域名用中國大陸 DNS 解析,拿到不優的 CDN 節點。mihomo 的 dns 段就是用來接管這三件事的。

建議結構

開啟核心 DNS(enable 加 listen),enhanced-mode 選 fake-ip(原理見第五章);nameserver 填中國大陸公共 DNS 保底;nameserver-policy 按 geosite 把中國大陸域名釘在中國大陸 DNS;fallback 填 DoH 給境外域名;fallback-filter 用 geoip 過濾——解析結果落在 CN 段以外的才採信 fallback,污染結果進不來。

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "*.msftconnecttest.com"
    - "localhost.ptlogin2.qq.com"
  nameserver:
    - 223.5.5.5
    - 119.29.29.29
  fallback:
    - "https://1.1.1.1/dns-query"
    - "https://dns.google/dns-query"
  fallback-filter:
    geoip: true
    geoip-code: CN
  nameserver-policy:
    "geosite:cn":
      - 223.5.5.5
      - 119.29.29.29

DNS 洩漏是什麼

洩漏指應用不經過核心、直接向電信業者 DNS 發查詢,存取記錄對電信業者完全透明。對策是讓核心接管全部 DNS 查詢:TUN 模式用 dns-hijack 攔下整機 53 連接埠(第五章),非 TUN 場景把系統 DNS 指到 127.0.0.1 並確認 listen 監聽了 53 連接埠。洩漏的症狀與驗證方法見疑難解答頁的 DNS 條目。

TUN 模式與 Fake-IP

系統代理只管"聽話"的應用——瀏覽器和遵循系統代理設定的軟體。遊戲、部分命令列工具、UWP 應用不走系統代理,UDP 與 ICMP 流量也管不到。TUN 模式虛擬出一張網卡接管整機流量,是覆蓋面最大的接管方式。日常瀏覽用系統代理就夠,遇到不服從代理設定的應用再開 TUN。

關鍵欄位

stack:協定堆疊實作,差異見下表。dns-hijack:DNS 劫持,any:53 把整機 53 連接埠的查詢全攔給核心 DNS,與第四章的設定聯動。auto-route:自動設定路由表,把流量引進虛擬網卡。auto-detect-interface:自動識別出口網卡,防止流量迴環。mtu:預設即可,個別校園網路或專線環境需要調小。

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

Fake-IP 與 redir-host 的差異

redir-host 模式下,應用先真實解析域名拿到 IP 再發起連線,核心按 IP 反查域名比對規則——多一次真實解析的等待,還可能拿到被污染的 IP。fake-ip 模式在 DNS 階段直接回傳 198.18.0.1/16 段裡的假位址,應用拿著假位址來連,核心按假位址反查域名再比對規則——省掉真實解析,規則比對直接拿到域名,分流更準、首次連線更快。

代價是有些服務不能拿假位址:區域網路域名、NTP 校時、部分中國大陸直連服務。這些寫進 fake-ip-filter,核心對這些域名回傳真實解析結果。第四章的範例裡帶了一份基礎名單,按需往裡補。

域名嗅探

理想情況下,核心從連線裡直接拿到目標域名。但不少應用自己做了 DNS——內建 DoH、硬編碼 IP——到核心這一層只剩一個 IP 位址,域名規則全部落空,只能指望 IP 規則保底,分流精度明顯下降。域名嗅探(sniffer)就是把這個丟掉的域名找回來。

運作原理

核心檢查連線的首個握手封包:TLS 的 ClientHello 裡有 SNI 欄位,HTTP 請求裡有 Host 標頭,兩者都寫著目標域名。嗅探把域名提取出來替換掉連線目標,重新走一遍規則比對——原本只能命中 IP 規則的流量,現在能命中域名規則,面板裡按裸 IP 顯示的連線也會明顯變少。

設定範例

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

override-destination 表示用嗅探出的域名覆蓋連線目標,fake-ip 與 TUN 場景建議開啟;純 redir-host 且規則以 IP 段為主的設定可以不開。skip-domain 放嗅探會出問題的服務:蘋果推播、米家這類憑證綁定嚴格的服務,嗅探改寫會導致握手失敗,直接跳過最省事。

本機覆寫與多訂閱合併

訂閱是整份下發的:機場更新設定,用戶端一拉新,手改的策略組和規則全被覆蓋。正確做法是訂閱歸訂閱、本機改動歸本機,兩者在載入時合併,不落進同一個檔案。

Clash Verge Rev:Merge 覆寫

在「訂閱」頁進入全域擴充設定,選 Merge(合併)方式,用固定鍵名描述改動:prepend-rules 與 append-rules 在規則頭部或尾部插入;prepend-proxies 與 append-proxies 追加節點;prepend-proxy-groups 與 append-proxy-groups 追加策略組。處理時機在訂閱載入之後,訂閱怎麼更新,覆寫都會重新套上去。熟悉 JavaScript 的使用者也可以選 Script 方式寫處理函式,自由度更高,但多數需求用 Merge 鍵名就夠。

# Clash Verge Rev 全域擴充設定(Merge)
prepend-rules:
  - "DOMAIN-SUFFIX,internal.example.com,DIRECT"
append-proxy-groups:
  - name: "下載"
    type: select
    proxies: ["節點選擇", "DIRECT"]

其他用戶端的入口

Clash Plus 在設定管理裡對目前訂閱做覆寫;FlClash 在設定詳情裡編輯覆寫段;裸核心使用者沒有覆寫層,建議把主設定握在自己手裡,訂閱只走 proxy-providers 提供節點。

多訂閱合併:proxy-providers

手上有兩個以上機場時,不需要把節點複製進主設定。proxy-providers 把每個訂閱拉成獨立的節點集合,各自定時更新、各自健康檢查;策略組用 use 同時引用多個集合,節點聯集進組,一處切換。

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: "http://www.gstatic.com/generate_204"
      interval: 300
  airport-b:
    type: http
    url: "https://example.com/sub-b.yaml"
    path: ./providers/airport-b.yaml
    interval: 86400
    health-check:
      enable: true
      url: "http://www.gstatic.com/generate_204"
      interval: 300

proxy-groups:
  - name: "自動選擇"
    type: url-test
    use: ["airport-a", "airport-b"]
    url: "http://www.gstatic.com/generate_204"
    interval: 300

外部控制面板

mihomo 內建 RESTful API,桌面用戶端的介面本質上都是它的前端。把 API 暴露出來,瀏覽器裡就能掛一個控制面板——在伺服器、路由器上裸跑核心時沒有圖形介面,這是標準的管理方式。

開啟 API

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

external-controller 是監聽位址;secret 是存取金鑰;external-ui 指向面板靜態檔案目錄,設好之後存取 http://127.0.0.1:9090/ui 直接開啟面板。不想自己託管面板檔案,就用線上面板——metacubexd、zashboard、yacd-meta 都在活躍維護,開啟網頁填 API 位址和金鑰即可使用。

常用介面

# 檢視所有策略組與節點
curl -H "Authorization: Bearer your-password" http://127.0.0.1:9090/proxies

# 把「節點選擇」切到指定節點
curl -X PUT -H "Authorization: Bearer your-password" \
  -d '{"name":"香港 01"}' \
  http://127.0.0.1:9090/proxies/節點選擇

常用介面還有 /connections(活動連線列表,可逐個關閉)、/traffic(即時速率)、/logs(日誌串流)。寫腳本批次切節點、做健康巡檢,都靠這幾個介面。

設定校驗與除錯

改完設定先驗證再重啟。圖形用戶端的日誌頁會直接報出 YAML 錯誤的行號;裸核心用命令列做完整載入測試:

mihomo -t -d /etc/mihomo

-t 表示只測試不執行,-d 指定設定目錄。語法錯誤、引用了不存在的策略組、規則集路徑不存在,都會在這一步報出來,不會帶病上線。

YAML 高頻錯誤對照

快取與狀態檔

核心在設定目錄下維護一份 cache.db,存兩類執行狀態:各 select 組上次選中的節點,以及 Fake-IP 的網域對應表。這份快取由設定裡的 profile 段控制:

profile:
  store-selected: true   # 重啟後記住各組手選的節點
  store-fake-ip: true    # Fake-IP 對應持久化,重啟後對應不變

store-selected 建議保持開啟,否則每次重啟核心,所有 select 組都會跳回列表第一項,之前手選的出口全部作廢。store-fake-ip 決定 Fake-IP 對應是否跨重啟保留,開啟後可以避免重啟瞬間舊對應失效造成的短暫斷流。排錯時這份快取本身也是嫌疑對象——改過組結構、換過訂閱之後如果行為詭異(組裡出現早已刪掉的節點名、切換選項不生效),直接刪掉 cache.db 讓核心重建一份,往往比逐項排查更快。刪快取的代價只是手選節點歸位、Fake-IP 重新分配,沒有其他副作用,可以放心當作常規排錯手段。

排查順序

"改了沒生效"按四步走:一,確認編輯的是目前生效的那份設定,多訂閱並存時最常踩這個坑;二,更新訂閱後確認覆寫仍然在位;三,檢視執行階段設定,確認合併結果符合預期;四,清規則集與節點快取後重啟核心。規則不命中時,在面板或日誌裡看該連線實際命中的規則鏈,多半是順序問題——更具體的報錯問答集中在疑難解答頁,Windows 平台的安裝坑見部落格《Clash Windows 版安裝設定全流程與高頻問題避坑》。

如果問題出在用戶端或核心本身,先確認用的是最新版本。用戶端下載頁彙整了五個平台的用戶端與核心套件,全平台首推 Clash Plus;訂閱層面的更新失敗排查見部落格《Clash 訂閱更新失敗的常見原因與自動更新設定方法》。

把設定養好的幾個習慣

手冊類的內容看完容易忘,真正讓設定長期穩定的是幾個日常習慣。第一,任何改動前先備份目前能用的那份設定,哪怕只是複製一份重新命名加上日期;改壞了能立刻回退,不用憑記憶反推。第二,一次只改一處,改完就驗證——同時動策略群組、規則和 DNS,出了問題根本分不清是哪一處引入的。第三,把常用的本地客製全部收進覆寫入口,而不是直接編輯訂閱下發的檔案,這樣訂閱更新再頻繁也不會衝掉自己的調整。第四,定期看一眼面板裡的連線列表,留意那些長期命中 FINAL 兜底規則的網域,它們往往是該補規則的對象;也留意延遲長期偏高的策略群組,考慮調整測速位址或容差。第五,核心與用戶端保持更新,mihomo 仍在活躍維護,規則集語法、嗅探行為、TUN 實作都在持續改進,舊版本遇到的怪問題常常升級後就消失了。

最後提醒一個認知上的坑:Clash 系用戶端的「系統代理」「TUN」「規則」是三層獨立的東西。系統代理只是把應用的流量交給核心,TUN 是在網路層接管全部流量,規則才決定流量從哪個出口走。很多「開了代理但沒走代理」的困惑,其實是三層裡有一層沒對上——應用沒走系統代理、TUN 沒開、或者規則把它分去了直連。排查時先確認流量確實進了核心(面板裡能看到這條連線),再看它命中了哪條規則、落到了哪個出口,順著這條鏈路查,比盲目改設定快得多。把這條鏈路想清楚了,本手冊九章的內容就串成了一個整體:策略群組與規則負責「往哪走」,DNS 與嗅探負責「認出它是誰」,TUN 與系統代理負責「把它接進來」,覆寫與校驗負責「改得安全」。