Clash 配置檔案參考大全

一、YAML 結構總覽:一份配置由哪幾塊組成

Clash 的配置檔案是一份標準 YAML 文件,預設檔名 config.yaml。YAML 有三條鐵律,先記住再往下讀:第一,層級完全靠縮排表達,約定兩個空格一級,禁止使用 Tab;第二,冒號後面必須跟一個空格,port:7890 是語法錯誤,port: 7890 才合法;第三,值裡含有冒號、井字號、花括號等特殊字元時要用引號包裹,尤其是密碼和 URL。井字號 # 之後到行尾是註解,內核載入時忽略。

一份完整配置從上到下大致分四層:入站與執行參數(埠、模式、日誌)、DNS 段、出站資源(proxies 節點清單、proxy-groups 策略組、兩類 provider),最後是 rules 規則清單。內核按「規則命中 → 策略組決策 → 節點出站」的順序處理每一個連線,配置檔案的組織順序與這條資料通路一一對應。下表是常用頂層欄位速查:

下面是一份能直接跑起來的最小配置,五個部分齊全,後續每章都在這個骨架上擴展:

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxies:
  - name: "節點A"
    type: ss
    server: example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"

proxy-groups:
  - name: "PROXY"
    type: select
    proxies:
      - 節點A
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

二、通用欄位:埠、模式與控制介面

入站埠:mixed-port 一個頂三個

早期配置習慣分開寫 port: 7890(HTTP)與 socks-port: 7891(SOCKS5),現在推薦直接寫 mixed-port: 7890——同一個埠自動識別兩種協定,系統代理與各類應用程式的代理設定都指向它,省去區分協定的麻煩。7890 只是社群慣例,不是保留值;如果啟動日誌出現 "address already in use",說明埠被其他行程佔用,換一個未佔用的埠即可。

allow-lan 與 bind-address

allow-lan: true 會把入站埠暴露給同一區域網路的其他裝置,常見用途是讓電視盒子、遊戲機借用電腦上的 Clash。配合 bind-address 可以限定監聽位址:預設 "*" 監聽所有網卡,改成具體內網 IP 可以只對某個網段開放。開啟前先確認所處網路可信——在公司或公共 Wi-Fi 裡開放 allow-lan,等於把出站通道借給了同網段的任何人。

mode:三種運作模式的邊界

mode: rule 是日常形態,每個連線逐條過規則表;global 跳過規則,所有流量交給全域策略組選定的節點,適合臨時驗證「到底是規則問題還是節點問題」;direct 則全部直連,相當於代理邏輯整體旁路。三種模式可以在客戶端介面即時切換,不需要改檔案,但配置檔案裡寫的值決定內核啟動時的初始模式。

log-level 與 external-controller

log-level 從少到多依次是 silent / error / warning / info / debug。排查「某條規則為什麼沒生效」時切到 debug,日誌會列印每個連線命中的具體規則與最終出口;確認無誤後調回 info,debug 等級的日誌量對長期運行並不友善。external-controller: 127.0.0.1:9090 打開 RESTful 控制介面,客戶端面板的節點切換、延遲測試、連線清單全部透過它完成;secret 欄位為介面加訪問密碼,範例一律寫假值如 secret: "xxxx";external-ui 指向一個本機目錄,可以掛載網頁面板。若把控制介面監聽到 0.0.0.0,必須同時設定 secret,否則區域網路內任何人都能改動你的代理狀態。

mixed-port: 7890
allow-lan: true
bind-address: "*"
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090
secret: "xxxx"

ipv6: false 表示內核不解析、不使用 IPv6 位址。所處網路的 IPv6 連通性不佳時,關掉它可以避免一部分「解析出 v6 位址卻連不上」的逾時;網路與節點都支援 v6 時再打開。這個開關與 DNS 段裡的解析行為連動,改動後建議重啟內核而不是熱重載。

連接埠佔用與設定目錄:兩類最常見的啟動失敗

通用欄位引發的啟動失敗集中在兩處,值得單獨說清。第一處是連接埠佔用:內核啟動時會綁定 mixed-port、DNS 監聽連接埠與控制介面連接埠,任何一個被佔用都會導致啟動中斷。Windows 上用 netstat -ano | findstr 7890 找出佔用連接埠的處理程序編號,再到工作管理員按 PID 定位程式;macOS 與 Linux 用 lsof -i :7890 得到同樣結果。最常見的佔用來源其實是「上一個內核處理程序沒退乾淨」——用戶端異常關閉後殘留背景處理程序,重啟用戶端前先確認處理程序列表裡沒有同名內核在跑。若確實與其他軟體衝突,把連接埠改成 7893、10808 這類不常用值即可,記得同步修改系統代理與各應用裡填的連接埠號碼。

第二處是設定目錄與檔案編碼。用戶端讀取的並不是你隨手放在桌面的 YAML,而是自身 profile 目錄下的副本;直接編輯桌面檔案後重載沒有任何變化,十有八九是改錯了對象。正確做法是在用戶端的「設定」頁找到當前訂閱條目,用其自帶的編輯入口打開,或者點「開啟設定目錄」再編輯目錄裡的檔案。另外,設定檔必須儲存為 UTF-8 無 BOM 編碼:帶 BOM 的檔案在部分內核版本上會讓第一行欄位解析失敗,報出令人費解的「line 1」錯誤;Windows 記事本另存時選擇「UTF-8」而非「帶 BOM 的 UTF-8」,或者乾脆用 VS Code 一類編輯器,可以徹底避開這個坑。

三、DNS 配置:fake-ip、分流解析與防污染

DNS 段決定「域名如何變成 IP」,直接影響分流準確性和連線成敗。enable: true 啟用內建 DNS 模組;listen 指定模組自身的監聽位址,TUN 模式下配合 dns-hijack 使用。真正需要理解的是 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,相容性問題多的環境退回 redir-host。

nameserver、fallback 與 fallback-filter

nameserver 是主解析組,建議填電信業者可達、延遲低的伺服器,支援 udp、tls://(DoT)與 https://(DoH)三種寫法;fallback 是備用組,填可信的境外 DoH。兩組並發查詢後,fallback-filter 決定採信哪邊:geoip: true 且 geoip-code: CN 的含義是——主組解析結果若是中國大陸 IP 則採信,否則改用 fallback 的結果,以此規避污染的答案。mihomo 內核額外支援 nameserver-policy,按域名後綴把特定域名指到特定 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"
    - "+.msftconnecttest.com"
  nameserver:
    - https://223.5.5.5/dns-query
    - 119.29.29.29
  fallback:
    - https://1.1.1.1/dns-query
  fallback-filter:
    geoip: true
    geoip-code: CN

四、代理節點欄位:proxies 逐協定拆解

proxies 是一個陣列,每個元素描述一個出站節點。四個欄位是所有協定共有的:name(節點名,全檔案唯一,策略組靠它引用)、type(協定類型)、server(伺服器位址,域名或 IP)、port(埠)。udp: true 聲明該節點轉發 UDP 流量,語音通話與遊戲依賴它。名字裡帶中文、空格或特殊符號時用引號包住,避免解析歧義。

Shadowsocks(ss)

欄位最少的協定:cipher 指定加密方法(常見 aes-128-gcm、chacha20-ietf-poly1305),password 是預共享金鑰。cipher 拼寫必須與伺服端完全一致,寫錯的表現不是報錯而是「連上了但資料全是亂碼級失敗」,延遲測試永遠逾時。

VMess

核心是 uuid(使用者身份標識)與 alterId(現代部署一律為 0)。cipher: auto 讓兩端協商加密;傳輸層透過 network 選擇,裸 TCP 之外最常見的是 ws(WebSocket),此時用 ws-opts 補充路徑與 Host 標頭,再配 tls: true 走 HTTPS 偽裝。ws 路徑、Host、TLS 三者任何一項與伺服端不一致都會握手失敗。

Trojan

設計上就長得像 HTTPS:password 認證,sni 指定 TLS 握手時聲明的域名(缺省時用 server 值)。skip-cert-verify: true 會跳過證書驗證——只應在明確知道伺服端用自簽證書時臨時使用,長期開啟等於放棄了對中間人攻擊的防禦。

mihomo 擴充協定

mihomo(Clash Meta)內核在原版之上增加了 vless(含 reality 傳輸)、hysteria2、tuic 等類型,欄位結構同樣是「通用四件套 + 協定專屬段」。訂閱裡含這些節點時,必須使用 mihomo 內核的客戶端(安裝包頁列出的 Clash Plus、Clash Verge Rev、FlClash 均是),原版內核會因無法識別 type 而拒絕載入整份配置。兩代內核的完整差異對照見《mihomo 內核與原版 Clash 差異對照》。

proxies:
  - name: "SS-香港"
    type: ss
    server: hk.example.com
    port: 8388
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

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

  - name: "Trojan-新加坡"
    type: trojan
    server: sg.example.com
    port: 443
    password: "your-password"
    sni: sg.example.com
    udp: true

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

策略組是節點之上的排程層:規則不直接指向某個節點,而是指向一個組,組再按自己的類型決定用哪個節點。組內成員寫在 proxies 陣列裡,可以是節點名、其他組名,也可以是兩個內建策略——DIRECT(直連)與 REJECT(拒絕連線,常用來封鎖域名)。組套組是常規操作,例如「手動選擇」組裡放一個「自動測速」組,兼得手動與自動。

自動類型的組依賴三個參數:url 是測活位址,慣用回傳 204 的輕量端點;interval 是測試週期(秒),300 是常見值,調太小會產生大量探測流量;tolerance(僅 url-test)是切換容差(毫秒)——新舊節點延遲差距超過這個值才切換,避免兩個延遲接近的節點來回抖動。lazy: true 讓組在被規則實際用到之前不發起測試,節點很多時能明顯減少背景請求。load-balance 透過 strategy 選擇分配方式,consistent-hashing 讓同一目標網站固定走同一節點,對登入狀態友善;round-robin 則輪流分發。

proxy-groups:
  - name: "手動選擇"
    type: select
    proxies:
      - 自動測速
      - SS-香港
      - VMess-日本
      - Trojan-新加坡
      - DIRECT

  - name: "自動測速"
    type: url-test
    url: http://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
    proxies:
      - SS-香港
      - VMess-日本
      - Trojan-新加坡

  - name: "故障轉移"
    type: fallback
    url: http://www.gstatic.com/generate_204
    interval: 300
    proxies:
      - SS-香港
      - VMess-日本

常見報錯 "proxy not found" 幾乎都出在引用一致性上:組裡寫的名字與 proxies 段的 name 差一個空格、一對引號或全半角字元,載入即失敗。改名時記得全文搜尋舊名,把所有引用處一起改掉。

六、providers:訂閱節點與外部規則集合

proxy-providers:把節點來源externalize

把節點直接寫進 proxies 的問題是:訂閱更新一次,整份檔案被覆蓋一次,你的本機修改隨之消失。proxy-providers 把「節點來源」抽出去:type: http 按 interval(秒)週期拉取 url 指向的訂閱,快取到 path;type: file 則讀取本機檔案。health-check 子段為這批節點配獨立的存活檢測。策略組透過 use 欄位引用 provider,provider 裡的全部節點自動注入該組,與 proxies 陣列可以同時存在。

rule-providers:規則集合的三種 behavior

rule-providers 是規則版的同一思路,讓 rules 段保持短小,大批量域名/IP 交給外部集合維護。關鍵欄位 behavior 有三種取值,決定集合內容的解讀方式:domain(純域名清單)、ipcidr(純 CIDR 清單)、classical(每行都是完整 Clash 規則)。format 聲明檔案格式(yaml 或 text),behavior 與集合實際內容不匹配時,規則會整組靜默失效——這是「RULE-SET 明明寫了卻不生效」的頭號原因。

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

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

proxy-groups:
  - name: "訂閱節點"
    type: select
    use:
      - main

訂閱本身有多種發行形態——完整 YAML、Base64 節點清單、通用分享連結,並非都能直接餵給 provider。各格式的結構差異與互轉方法見《Clash 訂閱格式詳解》;在客戶端裡匯入訂閱的操作步驟見使用文件。更新失敗時先看 path 快取檔案是否生成、時間戳記是否變化,再看日誌裡 provider 拉取的 HTTP 狀態碼,定位比盲目重試快得多。

七、規則語法:自上而下、首條命中

每條規則是逗號分隔的三段式:類型,匹配值,策略,策略可以是節點名、組名、DIRECT 或 REJECT。比對引擎自上而下掃描,第一條命中即定案,後面的規則不再看——所以順序就是優先順序:精確規則(DOMAIN、PROCESS-NAME)放最前,大範圍規則(GEOIP)靠後,MATCH 兜底必須是最後一條,且匹配值留空。

no-resolve 是 IP 類規則的可選第四段,含義是「目標還是域名、尚未解析時,跳過本條,不要為了匹配它專門發起一次 DNS 解析」。給內網網段、保留位址網段的規則統一加上 no-resolve,能避免大量無意義的解析請求。mihomo 內核額外提供 GEOSITE 類型,直接引用按網站分類維護的域名資料庫(如 GEOSITE,category-ads-all,REJECT),粒度介於手寫規則與 RULE-SET 之間。

rules:
  - PROCESS-NAME,Telegram.exe,手動選擇
  - DOMAIN,ad.example.com,REJECT
  - DOMAIN-SUFFIX,github.com,手動選擇
  - RULE-SET,cn-domains,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,手動選擇

規則排序的四段式模板

規則表寫亂最常見的後果是「改了半天沒反應」——你新加的那條永遠排在一條更寬泛的規則後面,根本輪不到它。穩妥辦法是把規則表固定成四段結構:第一段放攔截類規則,廣告網域、遙測網域統一 REJECT,放最前面才能保證不被後面的代理規則截走;第二段放本機與內網直連,包括 IP-CIDR,127.0.0.0/8、IP-CIDR,192.168.0.0/16、DOMAIN-SUFFIX,lan 這類條目,全部帶 no-resolve;第三段放業務分流,按網域或處理程序把需要代理的服務指到對應策略組,同時把國內網站指到 DIRECT;第四段是兜底,先 GEOIP,CN,DIRECT 兜住漏網的國內 IP,最後一條 MATCH 把剩餘流量交給主策略組。四段之間用註解行分隔,後續增刪規則時明確知道該往哪一段插。

還有兩個容易踩的細節。一是策略名拼寫:規則第三段引用的組名必須與 proxy-groups 裡的 name 完全一致,包括中英文標點與空格,寫錯會直接導致設定載入失敗而不是「這條規則不生效」。二是規則數量與效能:純網域規則的匹配成本極低,幾萬條也無所謂;真正拖慢連線建立的是需要解析後才能判斷的 IP 類規則,把它們盡量往後放並加 no-resolve,再把大批量網域交給 RULE-SET 遠端維護,規則表就能長期保持在可讀的幾十行規模。

八、TUN 模式:虛擬網卡接管全域流量

系統代理只對「尊重代理設定」的應用程式生效,命令列工具、遊戲客戶端、部分桌面軟體會繞過它直接發封包。TUN 模式的解法是建立一塊虛擬網卡,把整台裝置的出站流量在網路層截下來交給內核處理——應用程式無感知,規則照常生效。代價是需要更高的系統權限,以及對 DNS 的額外接管。

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

欄位逐個說:stack 選擇協定堆疊實作,system 用作業系統原生堆疊,吞吐好;gvisor 是使用者態堆疊,相容性情境備用;mixed 二者混合。auto-route 自動寫入路由表,把預設路由指向虛擬網卡,關掉就得手動配路由,一般保持 true。auto-detect-interface 自動識別真實實體出口網卡,防止內核自己的出站流量也被虛擬網卡截住形成迴圈——TUN 開啟後完全斷網,九成是這一環出了問題。dns-hijack 把發往任意位址 53 埠的查詢劫持給內建 DNS 模組,保證 fake-ip 體系在 TUN 下依然成立。

macOS 的授權流程彎路最多:網路擴充功能核准入口藏得深,鑰匙圈彈出視窗處理不當會反覆出現,逐步截圖說明見《macOS 安裝 Clash 提示權限問題?網路擴充功能與鑰匙圈授權全步驟》。另外,mihomo 內核還提供 sniffer 域名嗅探段,在 TUN 情境下從 TLS 握手中還原目標域名,彌補「只有 IP 沒有域名」導致的規則漏判,進階使用者可按需開啟。

九、覆寫與合併:讓修改在訂閱更新後存活

直接編輯訂閱生成的 config.yaml 是最常見的維護陷阱:下一次訂閱更新,整份檔案被伺服端版本覆蓋,手動加的規則、改的策略組全部歸零。正確做法是把「訂閱原文」與「本機修改」分離,讓客戶端在載入時合併兩者。

YAML 錨點:檔案內部去重

先說 YAML 自帶的複用語法。&name 定義錨點,*name 引用,<<: 合併鍵把整個映射展開進來。多個策略組共享同一套測活參數時,錨點能把重複段收斂成一處:

check-common: &check
  url: http://www.gstatic.com/generate_204
  interval: 300

proxy-groups:
  - name: "自動測速"
    type: url-test
    <<: *check
    tolerance: 50
    proxies:
      - SS-香港
      - VMess-日本

  - name: "故障轉移"
    type: fallback
    <<: *check
    proxies:
      - SS-香港
      - VMess-日本

錨點只在同一份檔案內生效,解決的是「重複」,不是「覆蓋」。跨檔案的合併要靠客戶端的覆寫機制。

客戶端覆寫:訂閱之上疊一層

主流客戶端普遍提供覆寫入口,思路一致:訂閱原文保持只讀,你的修改寫在獨立的覆寫層,每次載入時先取訂閱、再疊覆寫,更新訂閱不會沖掉修改。以 Clash Verge Rev 為例,提供 Merge(聲明式合併,常見 prepend-rules / append-rules 語義,把自訂規則插到訂閱規則之前或之後)與 Script(用腳本對配置物件做任意加工)兩類方式;Clash Plus 等客戶端也有各自的覆寫編輯入口,操作路徑見使用文件對應章節。聲明式合併能滿足九成需求且不易寫壞,優先用它;腳本方式留給「按名稱批量過濾節點、動態改組」這類複雜加工。

prepend-rules:
  - DOMAIN-SUFFIX,internal.example.com,DIRECT
  - PROCESS-NAME,ssh,DIRECT

append-rules:
  - GEOIP,CN,DIRECT

推薦的長期維護結構是三層:訂閱負責節點(透過 proxy-provider 或訂閱連結引入),規則集合交給 rule-providers 遠端維護,個人差異全部寫進覆寫層。任何一層更新都不影響另外兩層,配置從「一次性產物」變成「可持續維護的工程」。做到這一步,本頁前八章的欄位就都有了各自的歸宿。