Clash 設定檔結構逐段拆解:從 port、dns 到 rules 每個區塊都在做什麼

設定檔整體結構概覽

一份 Clash 設定檔本質是一份 YAML 文件,自上而下大致分成四類內容:全域執行參數、節點定義、策略組定義、分流規則。這四類內容彼此獨立又相互引用——節點被策略組引用,策略組被規則引用,規則決定流量最終走哪條路徑。理解這條引用鏈,比死記某個欄位的取值範圍更有用,因為遇到設定錯誤或分流不生效時,排查思路都是沿著這條鏈往回找。

Clash Meta(即 mihomo)在原版 Clash 的欄位基礎上做了擴充,增加了 TUN 模式、DNS 嗅探、地理位置資料庫路徑等設定項,但核心四段結構沒有改變。本文以 Meta 核心的欄位範圍為準,原版欄位是其子集,直接讀也不會遇到理解障礙。

通用欄位:port、mode、log-level、dns

檔案最上方通常是一組獨立的鍵值對,負責客戶端本身的執行方式,不涉及任何具體節點。

• port / socks-port:分別開啟 HTTP 代理埠和 SOCKS5 代理埠,系統或應用程式按需選擇其中一個連線。
• mixed-port:單一埠同時接受 HTTP 與 SOCKS5 請求,大多數客戶端預設只暴露這一個埠,減少設定項。
• allow-lan:是否允許區域網路內其他裝置透過本機代理,配合 bind-address 控制監聽範圍。
• mode:取值 rule(按規則分流,常規使用方式)、global(全部走同一節點,排除故障時用)、direct(全部直連,臨時關閉代理時用)。
• log-level:控制日誌詳細程度,排查問題時常臨時改成 debug,日常使用建議 info 或 warning,避免日誌檔案無限增長。

dns 區塊獨立成段,決定網域解析走什麼路徑。這是很多分流「看起來生效但實際沒生效」問題的根源——如果 DNS 解析階段就把網域解析成了錯誤的 IP,後面規則再怎麼寫都救不回來。一個基礎可用的 dns 段大致如下:

dns:
  enable: true
  ipv6: false
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://doh.pub/dns-query
  fake-ip-range: 198.18.0.1/16
  use-hosts: true

fake-ip-range 是 Meta 核心的常見設定,配合 TUN 模式使用,給網域分配一個假的本地 IP 段,由核心在流量層面完成真正的解析與轉發,避免直接依賴系統 DNS 造成的污染問題。這部分展開講會牽涉 TUN 模式的完整鏈路,不是本文重點,這裡只需要知道 dns 段和 rules 段是兩條獨立又互相影響的流水線。

proxies:節點定義

proxies 是一個清單,清單裡每一項描述一個具體的代理節點。不同協定欄位略有差異,但都遵循相同的結構:name 是節點在後續引用中使用的唯一標識,type 決定協定(如 ss、vmess、trojan、hysteria2),其餘欄位是該協定特有的連線參數。

proxies:
  - name: "HK-01"
    type: ss
    server: hk01.example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"
  - name: "SG-01"
    type: vmess
    server: sg01.example.com
    port: 443
    uuid: 0000-uuid-example
    alterId: 0
    cipher: auto

這裡最容易忽略的一點是:name 只是字串標識,客戶端不會檢查它和真實節點地理位置是否一致,寫錯標籤不會報錯,只會導致後續策略組裡挑選節點時產生誤解。機場提供的訂閱連結本質上就是產生一份完整的 proxies 清單,訂閱轉換服務做的事情,就是把不同格式的節點資訊統一轉換成這種結構。

proxy-groups:策略組

proxy-groups 也是一個清單,但每一項定義的不是節點,而是「如何從若干節點或策略組裡選出一個」。策略組的 proxies 欄位裡可以填節點名稱,也可以填另一個策略組的名稱,這種巢狀結構是建構多層分流(比如「自動選擇」套一層「手動選擇」)的基礎。

• select:手動選擇,客戶端介面上顯示為一個可點擊切換的清單,適合需要手動挑節點的場景。
• url-test:按延遲自動選擇,客戶端定期用設定的 URL 測速,自動切到延遲最低的節點。
• fallback:故障轉移,按清單順序依次嘗試,目前節點不可用時自動切到下一個。
• load-balance:多節點負載平衡,按策略(如一致性雜湊)把不同連線分散到多個節點。

proxy-groups:
  - name: "自动选择"
    type: url-test
    proxies:
      - HK-01
      - SG-01
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: "节点选择"
    type: select
    proxies:
      - 自动选择
      - HK-01
      - SG-01
      - DIRECT

注意最後一個策略組裡出現的 DIRECT 和 REJECT,這是兩個內建的特殊標識,不需要在 proxies 裡定義:DIRECT 表示直連不走代理,REJECT 表示直接拒絕連線。它們可以出現在任何策略組的候選清單裡,也可以直接出現在 rules 段作為目標策略,這是很多人容易忽略的一個細節。

rules:分流規則

rules 段決定每一條網路請求最終交給哪個策略組處理,是整份設定裡逐行比對、按順序生效的部分——寫在前面的規則優先度更高,一旦某條規則命中,後面的規則不再檢查。規則的基本格式是「比對類型,比對內容,目標策略」,常見比對類型包括:

• DOMAIN-SUFFIX:按網域後綴比對,覆蓋某個網域及其所有子網域。
• DOMAIN-KEYWORD:網域包含指定關鍵字即比對,比對範圍比後綴更寬,容易誤傷。
• IP-CIDR / IP-CIDR6:按 IP 段比對,常用於中國大陸 IP 段直連。
• GEOIP:按 IP 所屬地理位置比對,依賴本地的 GeoIP 資料庫。
• MATCH:兜底規則,放在最後一條,比對所有未被前面規則命中的流量。

rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - DOMAIN-KEYWORD,google,节点选择
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

規則裡的第三段填的是策略組名稱(或 DIRECT/REJECT),不能直接填節點名稱——這是初學者最常踩的坑之一。如果在 rules 裡寫了一個只在 proxies 裡存在、沒有出現在任何策略組的名稱,客戶端載入設定時會直接報錯。想快速定位某條規則是否生效,可以把 log-level 臨時調到 debug,日誌裡會印出每條請求比對到的具體規則。

最小可用範例:四段如何拼在一起

把前面四段按順序拼接起來,就是一份可以直接執行的最小設定。它沒有覆蓋所有場景,但足夠說明各區塊的協作關係——dns 決定網域怎麼解析,proxies 提供可用節點,proxy-groups 把節點組織成可切換的策略,rules 把具體流量分配給某個策略組。

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

dns:
  enable: true
  nameserver:
    - https://doh.pub/dns-query

proxies:
  - name: "HK-01"
    type: ss
    server: hk01.example.com
    port: 443
    cipher: aes-256-gcm
    password: "your-password"

proxy-groups:
  - name: "节点选择"
    type: select
    proxies:
      - HK-01
      - DIRECT

rules:
  - DOMAIN-SUFFIX,cn,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,节点选择

把這份設定放進任意一個 Clash Meta 核心客戶端,替換掉伺服器地址和密碼就能直接執行。絕大多數機場提供的完整設定或訂閱連結,展開後本質上都是這四段內容的擴充版本——策略組數量更多、規則條數更長、可能額外接入了規則集和分組測速地址,但骨架不會變。

常見排查思路

設定檔報錯或分流異常,基本可以按以下順序檢查:

1. YAML 語法層面

   縮排是否統一(禁止混用 Tab 和空格),冒號後是否留了空格,含特殊字元的密碼是否用引號包住。多數客戶端載入失敗時會在日誌裡指出具體行號。

2. 引用是否存在

   檢查 rules 裡的目標策略組名稱、proxy-groups 裡引用的節點名稱,是否在對應區塊裡真實存在,拼寫要完全一致,包括大小寫。

3. 規則順序是否合理

   確認沒有把寬泛比對的規則(如某個 DOMAIN-KEYWORD)放在精確規則前面,導致後面更具體的規則永遠比對不到。

4. DNS 是否單獨測試

   把 mode 臨時切到 global,排除是分流規則的問題還是 DNS 解析階段的問題,再逐段縮小排查範圍。