Clash 設定進階手冊

CH-01策略組:設定裡的換擋機構

先分清兩件事。規則負責判斷:這條流量歸誰管。策略組負責回答:歸它管之後,具體走哪個節點。一份耐用的設定,幾乎所有規則出口都不直接指向單個節點,而是指向策略組——節點今天在明天沒,組的名字不會變。把組搭好,後面換機場、換節點都只是換彈匣,不用動槍。

五種類型,一張規格表

挑的原則很樸素:交給機器判斷的用 url-test,需要人做主的用 select,其餘三種是特定場景的專用件。新手把前兩種用熟,已經覆蓋九成需求。

url-test 的三顆旋鈕

url 是測速目標,慣例填一個回傳 204 狀態碼的輕量地址,例如 https://www.gstatic.com/generate_204——它只回一個空回應,測的是純粹的鏈路耗時,不摻網頁載入時間。interval 是測速週期,單位秒,300 表示五分鐘測一輪;調太小會頻繁發測速請求,調太大則節點掛了半天才發現。tolerance 是容忍差值,單位毫秒:新舊最快節點的延遲差不超過這個值就不切換。不設它的話,兩個節點延遲在 80 和 85 之間來回抖,組就跟著來回跳,長連線反覆被掐斷。再補一顆常用旋鈕 lazy: true:組沒被使用時不發起測速,能省掉背景一批無謂請求。

一套耐用的分層結構

實戰裡推薦三層:最上面一個 select 總開關,中間掛自動測速組和各地區組,底層才是具體節點。規則一律指向組名,永遠不點名單個節點。想手動鎖定某個地區,在總開關裡切;想全自動,切回自動測速組。結構如下:

proxy-groups:
  - name: 手動總閘
    type: select
    proxies: [自動測速, 香港節點, 日本節點, DIRECT]

  - name: 自動測速
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
    proxies: [HK-01, HK-02, JP-01, JP-02]

  - name: 香港節點
    type: url-test
    url: https://www.gstatic.com/generate_204
    interval: 300
    proxies: [HK-01, HK-02]

  - name: 日本節點
    type: select
    proxies: [JP-01, JP-02]

用 filter 讓節點自動進組

機場節點動輒上百條,手寫 proxies 清單一次能忍,每月改一次就想砸鍵盤。filter 欄位接受一段正規表示式,配合 use 掛載訂閱彈匣時,只有名字符合的節點才會被收進這個組。於是「香港節點」組寫成 filter: "香港|HK|Hong",機場明天新增五條香港線路,組裡自動就多五條,你一個字都不用改。反過來還有 exclude-filter,把名字裡帶「過期」「剩餘流量」「官網」這類資訊條目排除掉——這些偽節點連不上,留在自動測速組裡只會拖慢每一輪測速。寫正規表示式時優先用豎線列多個關鍵詞,別寫複雜的分組回溯,比對規模大時效能差異很明顯。

還有一個容易被忽略的欄位是 disable-udp。部分節點聲稱支援 UDP,實際轉發不通,遊戲和語音一走上去就掉包。把這類節點單獨歸一組並宣告 disable-udp: true,UDP 流量就會自動落到下一個可用出口,而不是卡死在一條假通道上。搭配 expected-status 校驗測速目標回傳的狀態碼,能進一步篩掉那些「交握成功但被劫持到廣告頁」的節點——延遲數字漂亮,實際不可用,這類節點最會騙人。

三個高頻誤區

第一個誤區是把 fallback 當自動檔用。它只在前一個節點判定為不可用時才換,判定依賴健康檢查,存在延遲;節點沒掛只是變慢,它會一直守著不動。要「哪個快用哪個」,請用 url-test。第二個誤區是給 load-balance 組掛上需要固定 IP 的服務:登入狀態、支付驗證、部分雲端硬碟會因為同一工作階段裡 IP 反覆跳變而直接判定異常,輕則重新登入,重則觸發風控。第三個誤區是層層嵌套:組裡套組、套到第四五層,核心每次選路都要順著鏈條走一遍,面板上也徹底看不出流量最終落在哪。三層封頂是經驗值,再深的結構除了炫技沒有別的收益。

CH-02規則集:把規則做成可換的彈匣

把幾百條規則一條條寫進主設定,等於把所有零件焊死在底板上——想換一顆都得拆整機。rule-providers 的思路是把規則拆成可插拔的彈匣:主設定裡只留一句 RULE-SET 引用,彈匣本體掛在外部位址上,到點自動更新。維護者改彈匣,你這邊什麼都不用動。

槽位規格

每個 provider 有五個關鍵欄位。type 分 http(從 URL 拉取)和 file(讀本機檔案)兩種;behavior 聲明彈匣裡裝的是什麼類型的子彈,見下一節;format 是檔案格式,yaml 或 text;path 是下載後的本機快取路徑;interval 是自動更新週期,單位秒,86400 即一天一換。快取的意義在於:斷網重啟時核心直接讀本機副本,不會因為拉不到規則而起不來。

behavior 三選一怎麼挑

domain 彈匣裡只裝網域,核心會為它建專用索引,比對最快、記憶體最省;ipcidr 只裝 IP 段,同樣走專用比對;classical 什麼類型都能裝(DOMAIN-SUFFIX、IP-CIDR、PROCESS-NAME 混著來),靈活但逐條比對,規則一多就吃效能。選法:純網域清單用 domain,純 IP 段用 ipcidr,混裝才用 classical。拿 classical 裝純網域清單,能跑,但等於用卡車送快遞。

裝配範例與更新節奏

rule-providers:
  streaming:
    type: http
    behavior: classical
    format: yaml
    url: "https://example.com/rulesets/streaming.yaml"
    path: ./rulesets/streaming.yaml
    interval: 86400
  cn-ip:
    type: http
    behavior: ipcidr
    format: text
    url: "https://example.com/rulesets/cn-ip.txt"
    path: ./rulesets/cn-ip.txt
    interval: 86400

rules:
  - RULE-SET,streaming,手動總閘
  - RULE-SET,cn-ip,DIRECT,no-resolve
  - MATCH,手動總閘

更新週期按彈匣性質定:社群維護的分流清單一天一換就夠;自己維護、頻繁調整的清單可以縮到幾小時。規則集拉取失敗的排查思路與訂閱更新失敗一致,可參考說明中心的疑難排解分類。

規則的比對順序就是它的優先權

這是整份設定裡最容易踩的坑:rules 是一個有序清單,核心從第一條往下逐條比對,命中即停,後面的規則連看都不看。所以同一個網域被兩條規則同時涵蓋時,誰寫在前面誰說話。很多人抱怨「我明明寫了讓這個網站直連,它還是走了代理」,翻開設定一看,上面二十行處有一條更寬泛的 DOMAIN-KEYWORD 早就把它兜走了。

推薦的排列順序是:最上面放特例——單個網域的精確放行或強制代理,數量少、優先權最高;接著是行程層級規則 PROCESS-NAME,它比網域判斷更早生效,適合處理某個軟體整體走向;然後是網域類規則,按「精確 DOMAIN → 後綴 DOMAIN-SUFFIX → 關鍵詞 DOMAIN-KEYWORD → 分類 GEOSITE / RULE-SET」由窄到寬排;再往下是 IP 類規則 IP-CIDR 與 GEOIP,統統記得帶 no-resolve;最後一條 MATCH 收尾,把所有漏網流量指向一個明確出口。MATCH 必須存在且必須在最後,缺了它未比對流量的走向就成了未定義行為。

調試順序問題有個笨辦法但極其有效:打開控制面板的連線清單,找到那條流量,看它右側顯示命中的規則是哪一條。是哪條就去改哪條,不要憑記憶猜。規則條數上千時還要留意效能:DOMAIN-KEYWORD 需要對每個網域做子字串掃描,是最貴的一類,能用 DOMAIN-SUFFIX 表達的就別用關鍵詞;而 domain 型規則集走的是專用索引,幾萬條也幾乎不耗時間,這就是前面強調 behavior 要選對的現實理由。

CH-03DNS 設定優化:一半的鍋在解析

「代理開了但網頁打不開」「規則明明寫了卻不命中」——這類問題一半出在 DNS。核心內建一台 DNS 解析器,設定得當,解析又快又穩;設定混亂,污染和洩漏輪著來。這一章把解析鏈路上的每個槽位講清楚。

先看懂解析鏈路

解析器有三層。default-nameserver 是引導層:當你的主力解析器本身是個網域(比如 DoH 位址 https://doh.pub/dns-query),得先有人把這個網域解析成 IP,幹這活的就是引導層,所以它只能填純 IP,填網域會陷入先有雞還是先有蛋的死循環。nameserver 是主力層,日常查詢都從這裡走。fallback 是備胎層,專門應對主力層可能被污染的場景。三層各司其職,別把 DoH 位址塞進引導層,也別把主力層留空。

nameserver 與 fallback 的分工

工作方式是並發:一次查詢同時發給主力和備胎,然後由 fallback-filter 裁決用誰的答案。最常用的裁決器是 geoip: true 加 geoip-code: CN:主力層回傳的 IP 落在中國大陸網段,就採信主力(表示是正常的中國大陸境內解析);落在境外網段,則改用備胎的答案(中國大陸解析器給出境外 IP,有被污染的嫌疑)。這套機制的代價是每次查詢多發一份請求,換來的是抗污染能力。如果你的主力層本身走加密通道(DoH/DoT),污染風險已經很低,fallback 可以從簡。

nameserver-policy:給網域指定專屬解析器

有些網域你明確知道該在哪解析:中國大陸服務用中國大陸解析器,取得就近的 CDN 節點;測速、區域網路網域各有專屬去處。nameserver-policy 就是這張定向分揀表,支援通配和 geosite 分類。完整範例:

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
  fallback:
    - https://1.1.1.1/dns-query
    - https://8.8.8.8/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN
  nameserver-policy:
    "geosite:cn": https://doh.pub/dns-query
    "+.lan": 223.5.5.5

DoH、DoT 與明文解析怎麼選

明文 DNS 走 UDP 53,封包全程裸奔,鏈路上任何一跳都能看到你查了什麼,也能偽造一個假答案搶先回傳——這就是污染的技術原理。DoT 把解析封進 TLS 走 853 埠,加密了,但通訊埠特徵明顯。DoH 把解析偽裝成普通 HTTPS 請求走 443,和網頁流量混在一起,最不容易被單獨針對,代價是每次建立連線要多一次 TLS 交握,首次查詢稍慢。實用組合是:主力層填兩個 DoH,引導層填兩個純 IP 的明文解析器(它只負責把 DoH 的網域解析出來,查詢量極小),這樣既有加密保護,又不會陷入循環依賴。

另外兩個值得設的欄位:use-hosts: true 讓核心讀取設定裡的 hosts 段,方便臨時把某個網域釘死到指定 IP 做驗證;respect-rules 讓 DNS 查詢本身也遵守分流規則,避免境外解析器的查詢封包從直連出口發出去而被攔。ipv6 欄位建議按實際網路環境定:上游沒有 IPv6 卻打開它,會讓每次查詢多等一份必然失敗的 AAAA 回應,表現就是「打開網頁前先卡半秒」。

CH-04TUN 與 Fake-IP:系統層兜底與假位址號牌

TUN:接管不聽話的流量

系統代理是個君子協定:只有「願意讀取系統代理設定」的應用程式會走它。命令列工具、部分遊戲用戶端、一些桌面軟體對這份設定視而不見,流量直接出門。TUN 模式的做法是插一塊虛擬網卡,把整台裝置的出站流量在網路層截下來交給核心——應用程式配不配合都一樣,想溜的也得過安檢。

順帶說清 Android 上的情況:用戶端點「啟動」時向系統申請的 VPN 通道,本質就是一塊 TUN 網卡。所以 Android 使用者天生就在 TUN 模式裡,不需要手動配這一段;需要明確開啟 TUN 的是桌面平台。各平台用戶端的取得方式見下載頁,橫向差異見橫向評測。桌面端的關鍵欄位:stack 是協定堆疊實作,system 效能好但依賴系統能力,gvisor 使用者態實作相容性穩,mixed 取兩者所長,不確定就選 mixed;auto-route 自動接管路由表;dns-hijack 把發往任意 53 埠的明文 DNS 請求劫回核心,防止應用程式自帶的解析繞過分流。

Fake-IP:先發號牌,後辦業務

銀行叫號的邏輯。應用程式問「這個網域的 IP 是多少」,核心不去真解析,立刻從 198.18.0.1/16 這個保留段裡發一個假位址當號牌,零延遲。應用程式拿號牌發起連線,連線到達核心時,核心憑號牌反查出網域,按網域規則分流;需要走代理的,真實解析交給出口那頭去做。好處有兩個:省掉本機一次真實解析的等待,起連快;網域規則的命中率也高,因為核心始終知道每條連線背後的網域。

代價是號牌不能拿出營業廳用。區域網路裝置探索、印表機、部分遊戲連線、需要把 IP 回傳給伺服器的場景,拿到假位址就抓瞎。解藥是 fake-ip-filter:名單裡的網域不發號牌,老老實實真解析。

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

dns:
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "+.local"
    - "+.msftconnecttest.com"
    - "+.stun.*.*"

fake-ip 與 redir-host 對照

CH-05網域嗅探:貼在入站口的讀碼器

Fake-IP 打好了補丁,鏈路上還剩一條縫:有些流量到達核心時手裡只有 IP,沒有網域。典型元兇是應用程式自帶的加密解析(應用程式內建 DoH,不經過核心的 DNS),或者寫死 IP 直連的用戶端。網域規則對這種流量集體失明,只能靠 IP 規則或 MATCH 兜底,分流精度直線下降。

sniffer 是貼在入站口的條碼讀取器:流量進來時,從 TLS 交握的 SNI 欄位、HTTP 請求標頭的 Host 欄位裡把網域重新讀出來,貼回這條連線,再送去規則比對。網域找回來了,規則就能正常運作。

設定項規格

sniff 下按協定聲明要掃描的埠:TLS 通常掃 443 和 8443,HTTP 掃 80 與常見代理埠段。override-destination 決定嗅探出的網域是否覆蓋原目標位址,HTTP 場景建議開啟。force-domain 是強制嗅探名單,列出的網域即使已有解析結果也重新嗅一遍;skip-domain 是免檢名單——對憑證驗證嚴格、或對 SNI 改動敏感的服務(蘋果推播是常客),嗅探反而會把連線弄斷,列進去直接放行。

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

CH-06本機覆寫與多訂閱合併:改動不怕更新沖

為什麼不直接改訂閱檔案

直接在訂閱下發的設定檔裡改規則、加節點,手感是順的,結局是慘的:訂閱一更新,整個檔案被伺服端的新版本覆蓋,你的改動全部歸零。正確姿勢是覆寫——訂閱原文永遠保持唯讀,你的改動記在本機另一層,每次訂閱更新完成後自動重放到新檔案上。改動和訂閱從此互不干涉。

用戶端裡的覆寫入口

主流用戶端都內建了這層機制,名稱各異,思路一致。以 Clash Verge Rev 為例,提供兩級:Merge 用宣告式片段做合併,適合追加規則、追加策略組這類結構化改動;Script 用腳本對整份設定做程式化改寫,適合批量重新命名節點、按條件過濾這類複雜操作。能用 Merge 解決的別上 Script——宣告式片段一眼能看懂,腳本出錯時排查成本高得多。各用戶端覆寫能力的差異,橫向評測裡有專門一節。

用 proxy-providers 合併多訂閱

手裡有兩家以上機場時,別來回切換設定檔。proxy-providers 與規則集的 provider 是同一個思路:每份訂閱是一個節點彈匣,策略組用 use 欄位同時掛載多個彈匣,兩家的節點就混編進同一個自動測速組,誰快用誰。

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

proxy-groups:
  - name: 全部節點
    type: url-test
    use: [airport-a, airport-b]
    url: https://www.gstatic.com/generate_204
    interval: 300

health-check 給彈匣裡的節點做定期體檢,掛掉的節點會被自動測速組跳過;interval: 43200 表示訂閱本體半天拉取一次新版。訂閱連結的格式識別與匯入入口,可以先讀這篇:Clash 訂閱連結匯入教學。

CH-07外部控制面板:給核心裝一個遙控介面

三個欄位開啟遙控

external-controller 聲明 RESTful API 的監聽位址,慣例是 127.0.0.1:9090;secret 是存取口令,所有請求都要帶它;external-ui 指向一個本機目錄,把網頁面板的靜態檔案放進去,瀏覽器直接存取監聽位址就能開啟圖形介面。市面上的網頁面板(metacubexd、yacd 一系)本質都是這套 API 的前端外皮,換皮不換芯。

external-controller: 127.0.0.1:9090
secret: "your-strong-password"
external-ui: ./ui

不開面板也能用:三條常用命令

API 本身就是可用的工具,寫腳本、做自動化時直接呼叫:

# 查看全部策略組與節點狀態
curl -H "Authorization: Bearer your-strong-password" \
  http://127.0.0.1:9090/proxies

# 把「手動總閘」組切到 HK-01
curl -X PUT -H "Authorization: Bearer your-strong-password" \
  -d '{"name":"HK-01"}' \
  http://127.0.0.1:9090/proxies/手動總閘

# 給單個節點測一次延遲
curl -H "Authorization: Bearer your-strong-password" \
  "http://127.0.0.1:9090/proxies/HK-01/delay?timeout=5000&url=https://www.gstatic.com/generate_204"

面板上值得常用的三塊

連線清單:即時看每條連線命中了哪條規則、走了哪個出口——「這條流量為什麼直連了」這類問題在這裡一眼見底。日誌:把層級暫時調到 debug,規則比對的完整過程逐條印出,排查完記得調回,debug 日誌量很大。Provider 管理:手動觸發某個訂閱或規則集立即更新,不用等 interval 到點。

CH-08設定故障速查表

症狀對號入座,先查最常見的原因,再順著連結跳到對應章節或文章。多數問題在前兩步就能解決。

一套通用的排查手法

不管症狀是什麼,按這五步走一遍,絕大多數問題會自己浮出水面。第一步,分層定位:先在面板的連線清單裡確認這條流量到底有沒有進核心。沒進,問題在系統代理或 TUN 這一層,和規則無關;進了但出口不對,問題在規則或策略組。第二步,看命中規則:面板會直接告訴你它比對了哪一條,對照 CH-02 的順序原則去改那一條。第三步,單點驗證:把總開關臨時切成 DIRECT 再切成某個具體節點,分別試一次——直連通、代理不通,表示是節點或鏈路問題;兩個都不通,回去查 DNS。第四步,清快取重新連線:改過 DNS 段、切過 enhanced-mode 之後必須做,否則你驗證的是舊狀態。第五步,二分法回退:把最近的改動逐段註解掉,找出到底是哪一行引起的,比盯著整份設定猜要快得多。

還有兩個好習慣值得從第一天就養成。一是改設定前先複製一份備份,檔名帶上日期;設定檔是純文字,一份不到幾十 KB,留十個版本也不佔空間,但能在改壞的時候救你一次。二是把日誌等級在排查時調到 debug、排查完立刻調回 info:debug 會把每次規則比對、每次 DNS 查詢都印出來,資訊量足夠定位問題,但長期開著既刷屏又白耗磁碟。

表裡沒覆蓋的問題,去說明中心按「基礎認知 / 安裝設定 / 使用技巧 / 疑難排解」四個分類翻;懷疑是用戶端本身的問題,先在橫向評測裡確認它的能力邊界,必要時到下載頁換一台首推的 Clash Plus 再試。基礎操作忘了的,隨時回快速上手補課。