Clash 設定檔參考大全

一、手冊定位與 YAML 結構總覽

Clash 系客戶端(以及作為執行核心的 mihomo 核心)讀取一個 YAML 格式的設定檔來決定所有行為。訂閱連結的本質就是一個託管在伺服端、隨時可拉取更新的設定檔;客戶端介面上的每一個開關,最終也都會落到這個檔案的某個欄位上。讀懂它的結構,等於同時讀懂了訂閱內容、客戶端設定項與核心日誌三者之間的對應關係,排查問題時不必再逐個介面亂點。

本頁與使用指南的分工是「輕上手、重查閱」:指南負責帶著完成一次從匯入訂閱到驗證連通的完整流程,本頁負責在流程之外系統回答「這個欄位是什麼意思、還能怎麼寫」。兩頁互為補充,遇到指南裡一筆帶過的欄位,按上方目錄跳到對應章節即可。

頂層結構:五大區塊

一份完整的設定檔從上到下大致分成五個區塊。它們在檔案中的書寫順序不影響解析結果,但絕大多數訂閱都按下表順序組織,閱讀他人的設定時可以據此快速定位:

設定檔放在哪、改哪一份

動手之前先弄清自己要改的是哪一份檔案,這一步搞錯會出現「改了半天毫無變化」的典型困惑。客戶端通常把設定分成三層保存:一是從訂閱連結拉取下來的原始檔案,存放在客戶端的設定目錄裡(桌面端多為使用者目錄下的應用資料夾,行動端在應用私有目錄),它會被下一次訂閱更新整體覆蓋,原則上不要直接編輯;二是你自己新建的本地設定檔,完全由自己維護,適合自建節點或純手寫規則的情境;三是覆寫/合併檔案,只寫差異部分,由客戶端在載入時疊加到訂閱內容之上,這才是長期維護訂閱時的正確改法,詳見第八章。判斷目前生效的是哪一份,最直接的辦法是在客戶端的設定清單裡看哪一項處於啟用狀態,再結合日誌開頭列印的設定路徑確認。改完後必須觸發一次「重新載入設定」,核心不會自動監聽檔案變化;部分客戶端在切換設定時會保留舊的執行狀態,遇到反覆無常的表現,完全結束客戶端再啟動是最乾淨的驗證方式。

YAML 語法三條鐵律

YAML 對格式極其敏感,設定報錯裡九成是語法問題而不是欄位問題。寫設定前先記住三條:第一,縮排只能用空格,一個 Tab 字元就足以讓整個檔案解析失敗,而且報錯行號往往指向檔案更靠後的位置,不易察覺;第二,冒號後面必須有一個空格,port:7890 是非法寫法,port: 7890 才對;第三,節點名稱裡含有表情符號、井號、引號或以特殊字元開頭時,整個字串要用雙引號包起來,否則可能被解析成註解或語法結構。行首的 # 表示註解,除錯時想暫時停用某條規則,在行首加井號比直接刪除更穩妥。術語拿不準時可查術語表的「訂閱與設定」分類。

二、通用欄位:埠、模式與執行參數

通用欄位位於檔案頂層,不屬於任何縮排區塊,決定核心以什麼姿態執行。下面是一段可直接作為起點的最小可用設定:

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090

埠族群:mixed-port 與它的兄弟們

mixed-port 是目前最常用的埠欄位,在同一個埠上同時接受 HTTP 與 SOCKS5 兩種協定的連入連線,系統代理指向它即可,無需再分開設定。舊設定裡常見的 port(純 HTTP)與 socks-port(純 SOCKS5)如今仍然有效,適合需要把兩種協定分開給不同軟體使用的場景。此外還有 redir-port 與 tproxy-port,它們面向 Linux 上的透明代理與路由器部署,一般桌面使用者不需要設定。埠號取值避開 1024 以下的系統保留段;如果啟動時日誌報 bind: address already in use,說明埠被其他程式(常見是另一個未結束的代理程序)佔用,換一個埠號或結束佔用程序即可。

mode:三種執行模式

客戶端介面上的「規則/全域/直連」切換按鈕改的就是這個欄位。排障時先切到 direct 確認本機網路正常,再切到 global 確認節點可用,最後回到 rule 檢查規則,是最快的三段定位法。

其他高頻欄位

allow-lan 設為 true 時,區域網路內其他裝置可以把閘道代理指向本機埠,讓電視盒、遊戲機共享代理;開啟後建議搭配 bind-address 限定監聽網卡,避免在公共網路上把埠暴露給陌生裝置。log-level 從詳細到安靜依次為 debug、info、warning、error、silent,排查規則命中情況時暫時調到 debug,能在日誌裡看到每條連線命中了哪條規則。external-controller 開放一個 RESTful 介面供面板類工具讀取狀態與切換節點,若填寫了 secret 欄位則存取介面需帶同樣的金鑰,範例一律用假值如 secret: "xxxx"。ipv6 預設關閉,在 IPv6 環境不完整的網路裡貿然開啟反而會引入解析逾時。

三、DNS 段:解析模式與 Fake-IP

很多「規則明明寫對了卻不生效」「部分網站時通時斷」的問題根源都在 DNS。核心之所以要自帶一套 DNS 設定,是因為分流規則裡大量存在基於網域名稱和地理位置的判斷:如果解析這一步被汙染或者繞過了核心,後面的比對就是在錯誤的答案上做決定。下面是一段常見的 DNS 區塊:

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"
  nameserver:
    - https://223.5.5.5/dns-query
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

enhanced-mode:fake-ip 與 redir-host

fake-ip 模式下,核心收到網域查詢時不做真實解析,直接從 fake-ip-range 指定的保留網段(預設 198.18.0.1/16)裡回傳一個「假位址」,並記住網域與假位址的對應;等應用程式真的向這個假位址發起連線時,核心憑對應還原出網域再做規則比對。好處是省掉一次解析等待、網域規則命中率極高;代價是某些依賴真實 IP 的場景(區域網路裝置探索、部分連線對戰遊戲、需要回傳 IP 的驗證服務)會拿到假位址而出錯——這正是 fake-ip-filter 存在的意義:列在其中的網域跳過假位址邏輯,回傳真實解析結果。redir-host 模式則始終回傳真實 IP,相容性更好但解析鏈路更長。兩種模式的完整原理比較,可讀部落格文章《Fake-IP 模式是什麼》。

nameserver 與 fallback 的分工

nameserver 是預設上游,通常填地理位置較近、回應快的伺服器;fallback 是備用上游,當 fallback-filter 判斷預設上游回傳的結果可疑(例如 geoip: true 時,境外網域卻解析出了本地地區的 IP)時改用備用結果。上游位址支援四種寫法:純 IP(UDP 53)、tls://(DoT)、https://(DoH)與 quic://(DoQ),加密寫法可以避免解析請求在鏈路上被竄改。注意 nameserver 裡至少要有一個能直連解析的位址,否則會出現「先有雞還是先有蛋」的問題:解析代理伺服器網域本身也需要 DNS。

四、代理節點欄位:proxies 逐項說明

proxies 是一個列表,每個元素描述一條節點。日常使用訂閱時這一段由訂閱伺服端產生,一般不需要手寫;但讀懂它有兩個實際價值:一是節點連不上時能從欄位層面判斷問題(埠寫錯、傳輸層參數缺失、加密方式不符),二是需要暫時加一條自建節點時不必依賴任何轉換工具。所有協定共享四個基礎欄位:name(組內引用的唯一識別碼,重名會導致解析失敗)、type(協定類型)、server 與 port。udp: true 宣告該節點轉發 UDP 流量,語音通話、遊戲類應用依賴它。

三種常見協定的欄位形態

proxies:
  - name: "範例-SS"
    type: ss
    server: node1.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

  - name: "範例-VMess"
    type: vmess
    server: node2.example.com
    port: 443
    uuid: 00000000-0000-0000-0000-000000000000
    alterId: 0
    cipher: auto
    tls: true
    network: ws
    ws-opts:
      path: /ws
      headers:
        Host: node2.example.com

  - name: "範例-Trojan"
    type: trojan
    server: node3.example.com
    port: 443
    password: "your-password"
    sni: node3.example.com

Shadowsocks(ss)的核心是 cipher 與 password 必須與伺服端完全一致,加密方式差一個字母連線就會靜默失敗。VMess 用 uuid 做身分憑證,alterId 在現行協定下固定填 0;network 決定傳輸層形態,取 ws 時需要搭配 ws-opts 寫明路徑與 Host 標頭,取 grpc 時對應 grpc-opts。Trojan 天生運行在 TLS 上,sni 與憑證網域不一致時握手會被拒絕,自簽憑證的測試環境可加 skip-cert-verify: true,正式使用不建議這麼做。

mihomo 擴充協定

作為目前主流的執行核心,mihomo 在上述經典協定之外還支援 VLESS、Hysteria2、TUIC 等較新的協定類型,各自有獨立的欄位集(如 Hysteria2 的 up/down 頻寬宣告)。是否可用取決於客戶端內建的核心版本,這也是客戶端比較頁建議優先選擇基於 mihomo 核心的客戶端(如全平台的 Clash Plus、桌面端的 Clash Verge Rev)的原因之一:舊核心的客戶端遇到新協定節點會直接報「unsupport proxy type」並拒絕載入整份設定。

五、策略組欄位:proxy-groups 四種類型

如果說 proxies 是原材料,proxy-groups 就是把原材料組織成「可決策單元」的一層:規則不直接指向節點,而是指向策略組,由組內邏輯(手動選擇或自動測速)決定最終出口。這一層設計讓「換節點」不需要動任何規則。四種組類型行為如下:

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - 自動測速
      - 範例-SS
      - 範例-VMess
      - DIRECT

  - name: "自動測速"
    type: url-test
    url: http://cp.example.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
    proxies:
      - 範例-SS
      - 範例-VMess

欄位細節與巢狀技巧

自動類組的 url 應指向一個回傳 204 狀態碼的輕量位址(各客戶端都內建了預設測速位址,不填則用預設值),interval 以秒為單位控制重測週期,300 是常見取值;tolerance 是切換門檻——新舊節點延遲差小於該毫秒數時不切換,避免兩條延遲接近的線路來回橫跳導致連線頻繁重置。lazy: true 讓組在未被使用時跳過測速,節點數多時能明顯減少背景流量。組的成員既可以是節點名,也可以是另一個組名或內建策略 DIRECT(直連)、REJECT(拒絕連線),因此可以搭出「手動組套自動組」的層級:平時選「自動測速」放手不管,特殊時期手動釘住某條節點。唯一要避免的是兩個組互相引用形成環,核心會在啟動時報錯拒絕載入。組名同樣要求全域唯一,且會被規則原文引用,改組名時記得同步改動所有引用它的規則行。

六、規則語法:rules 比對與優先順序

rules 是分流的裁決層。每當有新連線產生,核心從列表第一條開始逐條比對,命中即停止,後面的規則不再參與;因此規則的書寫順序就是優先順序本身,同樣一批規則換個順序,分流結果可能完全不同。每條規則的通用格式是 類型,比對值,策略,策略可以是組名、節點名或內建的 DIRECT/REJECT:

rules:
  - DOMAIN,dl.example.com,節點選擇
  - DOMAIN-SUFFIX,example.org,節點選擇
  - DOMAIN-KEYWORD,tracker,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT
  - RULE-SET,ads,REJECT
  - MATCH,節點選擇

規則類型對照

no-resolve 與排序原則

IP 類規則預設會觸發一次網域解析來取得目標 IP 再比對——如果這條規則本意只想比對「本來就以 IP 直連」的流量(例如區域網路網段),這次解析純屬浪費,還可能拖慢每個連線。在規則末尾追加 no-resolve 參數即可宣告「目標是網域時直接跳過本條」。排序上遵循兩個原則:精確、代價低的放前面(DOMAIN 系),需要解析或查庫的放後面(GEOIP);拒絕類規則盡量靠前,讓廣告請求在進入更重的比對之前就被攔下。GEOSITE 與 GEOIP 的判斷準確度取決於本地資料庫的新舊,資料庫長期不更新會造成分流失準,更新方式詳見《GeoIP 與 GeoSite 資料庫過期怎麼辦》。

一份規則表的推薦骨架

不同人的規則表內容差別很大,但骨架大體一致,按下面的順序組織可以避免多數排序陷阱:最前面放區域網路與本機網段的直連規則,並帶上 no-resolve,保證內網存取不受任何後續規則干擾;其次放廣告與追蹤類的拒絕規則,越早攔下越省資源;第三段放你自己的例外規則,例如公司內網網域強制直連、某個下載工具強制走特定節點;第四段放依分類庫書寫的大批量規則,如 GEOSITE 系;第五段放 GEOIP 一類需要查庫的 IP 規則;最後一條固定是 MATCH 兜底。需要提醒的是,兜底策略指向哪個組決定了「未被任何規則命中的流量」的預設走向:指向代理組意味著預設走代理、白名單式思路,指向 DIRECT 則是預設直連、黑名單式思路,兩種取向沒有優劣,但要與前面的規則內容保持一致,否則會出現大量意料之外的分流結果。

七、訂閱與規則集:proxy-providers 與 rule-providers

把幾百條節點和上萬條規則直接寫進主設定檔,既臃腫又難更新。Provider 機制把它們抽成可獨立拉取、獨立快取、按週期自動刷新的外部資源:主設定只負責「引用」,內容託管在遠端。這也是現代訂閱生態的標準形態——你的訂閱連結,通常就是一個 proxy-providers 意義上的節點清單。

proxy-providers:節點來源託管

proxy-providers:
  main:
    type: http
    url: "https://sub.example.com/subscribe?token=xxxx"
    path: ./providers/main.yaml
    interval: 3600
    health-check:
      enable: true
      url: http://cp.example.com/generate_204
      interval: 600

type: http 表示從遠端拉取,搭配 url 與本地快取路徑 path;type: file 則直接讀本地檔案,適合手動維護的自建節點清單。interval 控制自動重新拉取的秒數;health-check 讓核心週期性對清單裡的節點測活,供策略組篩選。策略組要使用 Provider 裡的節點時,用 use 欄位取代(或搭配)proxies 欄位:

proxy-groups:
  - name: "訂閱節點"
    type: url-test
    use:
      - main
    url: http://cp.example.com/generate_204
    interval: 300

rule-providers:規則集託管

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

規則集最容易踩的坑是 behavior 與檔案內容不符。它有三個取值:domain(檔案裡全是網域)、ipcidr(全是網段)、classical(每行都是完整的「類型,值」規則)。遠端檔案明明是網域清單卻宣告成 classical,載入不會報錯,但一條也比對不上,排查時極具迷惑性。format 支援 yaml 與 text,mihomo 還支援體積更小、載入更快的二進位 mrs 格式。宣告好的集合透過 RULE-SET,ads,REJECT 這樣的規則行接入主規則表,更新規則集不再需要改主設定,這正是它對長期維護最大的價值。範例裡的 token=xxxx 是佔位假值,實際以訂閱服務提供的完整連結為準。

八、覆寫與合併:讓訂閱更新不蓋掉本地修改

直接編輯訂閱下發的設定檔有一個致命問題:下一次訂閱自動更新時,遠端內容會整份覆蓋本地檔案,你手動加的規則、改的 DNS 全部歸零。覆寫(Override)與合併(Merge)機制解決的就是這件事——把「你的修改」與「訂閱的內容」分開存放,每次訂閱更新後由客戶端自動把修改重新疊加上去。改設定之前先確認自己用的客戶端支援哪種機制:

宣告式合併的寫法

以 Clash Verge Rev 的 Merge 為例,合併檔案本身也是一段 YAML:頂層直接寫出的欄位(如 mixed-port)會整體取代訂閱裡的同名欄位;帶 prepend-/append- 前綴的欄位則把內容插入到訂閱對應列表的開頭或結尾,常用於在訂閱規則之前加自己的高優先順序規則:

mixed-port: 7893

prepend-rules:
  - DOMAIN-SUFFIX,corp.example.com,DIRECT
  - PROCESS-NAME,steam.exe,節點選擇

append-proxies:
  - name: "自建-備用"
    type: ss
    server: node9.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

「prepend 進規則表開頭」這一點尤其重要:規則命中即停,只有排在訂閱規則之前,你的私有規則才有機會先被比對到。字典類欄位(如 dns)的合併粒度是整塊取代還是逐鍵合併,不同客戶端實作略有差異,寫完務必用一條已知流量驗證效果。各客戶端覆寫入口的位置與操作差異,客戶端比較頁有橫向整理;Windows 端從安裝到服務模式的完整流程可參考《在 Windows 上使用 Clash Verge Rev》。

九、常見錯誤與設定自檢清單

設定載入失敗時,核心日誌給出的錯誤通常已經點名了問題類別,先讀日誌再改檔案,能省下大量盲試時間。幾類高頻錯誤的對號入座:yaml: line N 開頭的是語法錯誤,回到第 N 行附近檢查縮排(重點排查混入的 Tab)與冒號後的空格;proxy not found 或 proxy group ... not found 表示策略組或規則引用了一個不存在的名字,多半是節點改名後引用沒同步,或名字裡的空格、表情符號不完全一致;unsupport proxy type 說明設定裡出現了目前核心不認識的協定,要麼升級客戶端要麼移除該節點;bind: address already in use 是埠被佔用,見第二章;規則集「載入成功但從不命中」,優先懷疑第七章講的 behavior 宣告與內容不符。

另有幾類問題不體現在錯誤訊息裡,只表現為「行為不對」,更需要方法定位。比如全部網站都打不開但節點測速正常,通常是 DNS 段設定有誤或系統 DNS 快取未刷新,而不是節點問題;又比如只有個別應用不走代理,大概率是這些應用不讀系統代理設定(命令列工具、部分遊戲客戶端),需要改用 TUN 模式接管;再比如速度忽快忽慢、連線頻繁重置,可以先把自動測速組的 tolerance 提高一些,減少線路來回切換帶來的中斷。定位這類問題的通用思路是「縮小變數」:每次只改一處,改完立刻用同一個測試目標複驗,並把每次改動記在備註裡,避免連續疊加多處改動後無法判斷哪一處起了作用。

動手改設定前後的七步自檢

1. 改前備份:複製一份目前能正常運作的設定檔,任何改動出問題都能一步復原,這是成本最低的保險。
2. 過語法關:儲存後立即在客戶端裡重新載入設定,載入成功再談效果;載入失敗先按日誌行號修語法,不要帶著語法錯誤繼續疊加改動。
3. 查名字一致性:全文搜尋被引用的節點名與組名,確認 proxies、proxy-groups、rules 三處寫法逐字一致,包括引號內的空格。
4. 驗證規則順序:確認 MATCH 在最後一條、拒絕類規則足夠靠前、私有規則排在訂閱規則之前(用覆寫時確認走的是 prepend)。
5. 驗證 DNS 行為:開啟 Fake-IP 後測試區域網路印表機、投影等本地服務是否正常,不正常就把對應網域加入 fake-ip-filter。
6. 三模式定位:遇到「連不上」先切到 direct 排除本機網路,再切到 global 排除節點,最後回到 rule 查規則,一次只變一個變數。
7. 觀察一個更新週期:確認訂閱自動更新之後,覆寫內容仍然生效、埠與 DNS 設定沒有被沖回預設值。

如果按清單走完仍未定位,回到使用指南核對上手主線是否有遺漏步驟;初次安裝階段的通用檢查項可參考《Clash 第一次安裝要做的 7 項初始設定》。客戶端本身版本過舊也會放大各種相容性問題,到下載頁更新到目前版本後再複測,是排障流程裡效益很高的一步。