設定進階 預計閱讀 12 分鐘

Clash 設定檔結構解析：從連接埠、DNS 到規則段逐項說明

依 YAML 階層拆解常用欄位，說明代理節點、策略組與規則之間的引用關係。

先理解 Clash 設定的處理鏈路

Clash、Clash Meta（現多稱為 Mihomo）及其圖形化客戶端通常使用 YAML 檔案描述執行參數。設定內容看似由許多彼此獨立的欄位組成，實際執行時卻是一條連續鏈路：應用程式流量先進入本機監聽連接埠或 TUN 網卡，網域請求交由 DNS 模組處理，連線接著依照 rules 由上到下比對，符合的規則會將連線交給策略組，策略組再選擇具體代理節點、直連出口或拒絕動作。

因此，閱讀設定時不應只看某個節點能否連線。一份完整設定至少要回答五個問題：流量從哪裡進入、網域如何解析、有哪些可用出口、出口如何組成策略組，以及連線最後由哪條規則分配。任何一環的名稱引用錯誤，都可能表現為設定載入失敗、策略組為空、網域無法解析或流量走錯出口。

YAML 對縮排十分敏感。通常使用兩個空格表示一個階層，不能用定位字元取代空格。同一階層的鍵必須保持對齊，清單項目則以連字號開頭。布林值建議使用 true 和 false；包含冒號、井字號、星號或特殊符號的名稱，應以引號包住，避免被解析器當成 YAML 語法。

基礎欄位與本機監聽連接埠

設定檔頂層通常會先放置連接埠、區域網路存取、執行模式與日誌等級。這些欄位決定 Clash 如何接收本機或區域網路裝置的連線，但不會直接決定連線使用哪個代理節點。

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false

external-controller: 127.0.0.1:9090
secret: "change-this-controller-secret"

port、socks-port 與 mixed-port

port 提供 HTTP 代理監聽連接埠，socks-port 提供 SOCKS5 代理監聽連接埠，mixed-port 則允許同一個連接埠同時接受 HTTP 與 SOCKS5 請求。桌面客戶端常使用混合連接埠，簡化系統代理設定。若同時宣告多個連接埠，應檢查連接埠號是否已被其他程式占用，並確認系統代理實際指向哪個連接埠。

redir-port 和 tproxy-port 主要用於透明代理情境，依賴作業系統網路堆疊、路由規則與權限設定，並非所有平台都以相同方式支援。一般桌面使用者若透過系統代理或客戶端的 TUN 開關接管流量，通常不需要手動新增這兩個欄位。

區域網路存取與控制介面

allow-lan 控制其他裝置能否透過本機監聽連接埠使用代理。啟用後還要檢查 bind-address、作業系統防火牆，以及裝置之間的網路連通性。僅在本機使用時可維持關閉。若需要為同一區域網路內的手機或平板提供代理，應限制可信任的網路範圍，並避免將監聽連接埠暴露至公網。

external-controller 是控制介面的位址，圖形介面或外部面板可透過它讀取連線、流量與策略組狀態。監聽於 127.0.0.1 時僅供本機存取；若改為區域網路位址，應同時設定強度足夠的 secret，並設定網路存取邊界。控制介面連接埠與代理連接埠用途不同，不能將系統代理指向控制介面。

執行模式與日誌

mode: rule 表示依規則分流，是日常設定最常用的模式。global 模式會將連線統一交給全域策略，direct 模式則讓連線直接存取。圖形化客戶端中的「規則、全域、直連」切換，通常會改變目前的執行模式，但不一定會改寫原始 YAML 檔案。

log-level 可設定為 silent、error、warning、info 或 debug 等等級，實際支援的值以所使用的核心版本為準。排查規則命中與 DNS 請求時，可暫時提高日誌詳細程度；確認問題後再恢復一般等級，避免大量日誌影響閱讀。

DNS 段：解析路徑與 Fake IP

dns 段決定 Clash 是否接管網域解析、向哪些上游伺服器查詢，以及回傳真實位址還是 Fake IP。DNS 設定與代理規則密切相關：規則可能需要先以網域本身完成比對，代理節點的伺服器位址也可能需要先解析；上游設定錯誤，會讓節點在建立代理連線前就失敗。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  nameserver-policy:
    "geosite:cn":
      - https://dns.alidns.com/dns-query

enable、listen 與上游伺服器

enable: true 會啟用核心 DNS 模組。listen 指定 DNS 服務的監聽位址，是否需要填寫取決於客戶端如何接管查詢；部分圖形化客戶端會產生或覆寫這一項。在監聽非本機位址前，應先了解區域網路 DNS 暴露所帶來的存取範圍變化。

default-nameserver 主要用於解析 DoH、DoT 等加密 DNS 伺服器本身的網域，也可能參與代理節點網域的初始解析，因此這裡通常填寫可直接連線的 IP 位址型 DNS。nameserver 是一般查詢的主要上游，可使用一般 DNS 位址或核心支援的加密 DNS 格式。不同 Mihomo 版本對擴充參數與協定寫法的支援可能有所差異，遷移設定時應查閱核心文件與啟動日誌。

nameserver-policy 可依網域或規則集合指定 DNS 上游，例如讓特定網域使用指定的解析服務。它處理的是「向哪個 DNS 查詢」，不等同於代理規則中的「連線走哪個出口」。DNS 查詢路徑與後續連線路徑需要分開設定。

fake-ip 與 redir-host

Fake IP 模式會先向應用程式回傳保留位址範圍內的暫時位址，並在應用程式發起連線時將該位址映射回原始網域。如此可讓核心更穩定地保留網域資訊，便於執行 DOMAIN、DOMAIN-SUFFIX 與 GeoSite 等網域規則。在 TUN 情境中，Fake IP 也常用於統一接管不同應用程式的 DNS 與連線。

某些區域網路服務、遊戲平台、列印裝置，或依賴真實 DNS 結果的應用程式，可能不適合 Fake IP。這類網域可加入 fake-ip-filter，讓它回傳真實解析結果。過濾範圍不宜盲目擴大，否則大量網域會繞過 Fake IP 映射，降低網域規則的可觀察性。redir-host 模式會回傳真實 IP，相容性思路較直接，但規則比對效果會受到 DNS 快取、連線方式與應用程式行為影響。

代理節點與代理提供者

proxies 是靜態節點清單，每一項描述一個可供策略組引用的代理出口。常見欄位包括節點名稱、協定類型、伺服器位址、伺服器連接埠及協定驗證參數。不同協定需要不同欄位，不能只透過修改 type 將一種節點轉換成另一種節點。

proxies:
  - name: "範例節點 A"
    type: socks5
    server: 192.0.2.10
    port: 1080
    username: "example-user"
    password: "example-password"
    udp: true

name 是節點在設定內部的引用識別名稱。策略組中的名稱必須與這裡完全一致，包括空格、大小寫與符號。節點名稱重複時，不同核心或客戶端可能拒絕載入，也可能使引用結果難以判斷，因此應維持唯一。

訂閱通常包含大量節點，直接展開至 proxies 後不便維護。Mihomo 支援透過 proxy-providers 定義代理提供者，由提供者讀取本機檔案或遠端內容，再將節點集合交給策略組。提供者通常包含 type、url、path、更新間隔與健康檢查等欄位。訂閱位址屬於存取憑證，應避免寫入公開儲存庫、截圖或公開日誌。

proxy-providers:
  provider-main:
    type: http
    url: "訂閱服務提供的完整位址"
    path: ./providers/provider-main.yaml
    interval: 86400
    health-check:
      enable: true
      interval: 600
      url: https://www.gstatic.com/generate_204

提供者的健康檢查用於定期測試節點連通性，不代表策略組會自動選擇最低延遲節點。是否自動選擇由策略組類型決定。健康檢查位址也只反映目標位址的回應情況，延遲數值可能受到目標伺服器、DNS、網路壅塞與節點出口位置影響。

策略組：將節點組織成可引用的出口

proxy-groups 位於節點與規則之間。規則通常不會直接綁定容易變動的節點，而是指向穩定的策略組名稱。如此一來，節點更新或失效時，只需在客戶端切換組內選項，無須重寫整套規則。

proxy-groups:
  - name: "節點選擇"
    type: select
    use:
      - provider-main
    proxies:
      - DIRECT

  - name: "自動測速"
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: "預設出口"
    type: select
    proxies:
      - "節點選擇"
      - "自動測速"
      - DIRECT

常見策略組類型

  • select：由使用者手動選擇組內節點、其他策略組或內建動作，適合主入口及需要固定出口的服務。
  • url-test：依指定測試位址定期測量，並自動選擇符合條件的低延遲節點。它著重於探測結果，不代表所有業務連線都具有相同速度。
  • fallback：優先使用清單中可用的前置節點，目前節點無法使用時切換至後續節點，適合強調固定優先順序的情境。
  • load-balance：依核心支援的策略將連線分配至多個節點。它不會簡單疊加單一 TCP 連線的頻寬，而且出口頻繁變動可能影響依賴工作階段或位址一致性的服務。

proxies 用於列出靜態節點、其他策略組，以及 DIRECT、REJECT 等內建動作；use 用於引用 proxy-providers。兩者可在同一個策略組內依需求組合。策略組也能引用另一個策略組，但應避免形成循環引用，例如 A 引用 B，而 B 又引用 A，這會導致設定驗證失敗。

組名同樣屬於嚴格引用。若規則寫著 預設出口，設定中就必須存在完全同名的策略組、節點或內建策略。重新命名策略組後，應同步搜尋並修改 rules、其他策略組及覆寫腳本中的引用。

規則段：順序比對決定最終出口

rules 是連線分流的決策表。核心通常會從第一條開始逐條向下檢查，命中後停止繼續比對，並將連線交給規則末尾指定的策略。因此，規則順序比規則數量更重要：範圍較窄、優先級較高的規則應放在前面，通用規則與兜底規則放在後面。

rules:
  - DOMAIN,example.org,DIRECT
  - DOMAIN-SUFFIX,example.com,節點選擇
  - DOMAIN-KEYWORD,service,預設出口
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,預設出口

常見規則類型

DOMAIN 精確比對完整網域；DOMAIN-SUFFIX 比對指定網域及其子網域；DOMAIN-KEYWORD 依網域中的關鍵字比對，範圍較廣，使用時要避免誤命中。IP-CIDR 與 IP-CIDR6 依目標 IP 網段比對，適合區域網路、固定服務位址及明確的網路範圍。

GEOIP 依 IP 地理資料庫比對目標位址。Mihomo 也可透過 GeoSite 或規則集合處理大量網域，實際規則類型與資料庫格式取決於核心版本及設定方式。地理規則依賴本機資料庫，資料庫缺失、路徑錯誤或格式不相容時，核心會在載入階段或執行日誌中提示。

no-resolve 常用於 IP 類規則，表示比對該規則時不因網域額外觸發 DNS 解析。它可以減少不必要的解析，但如果目前連線只有網域、沒有可供比對的目標 IP，這條 IP 規則可能就無法命中。是否加入應依 DNS 模式與規則目的判斷。

MATCH 是最終兜底項，應放在規則清單末尾，負責處理先前未命中的連線。缺少合理兜底時，不同核心版本或客戶端的產生邏輯可能導致難以預期的結果；手寫設定中明確寫出 MATCH，能讓預設出口更清楚。

規則提供者與大規模規則集

當規則數量較多時，可使用 rule-providers 將規則集拆分至獨立檔案，再透過 RULE-SET 引用。規則提供者通常會宣告行為類型、來源、儲存路徑、更新間隔與格式。引用名稱必須與提供者鍵名一致，規則集的內容格式也要符合 behavior。

rule-providers:
  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./rules/private-network.yaml
    url: "規則維護方提供的完整位址"
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - MATCH,預設出口

規則集更新成功不代表順序一定合理。若在 RULE-SET 前已放置範圍更廣的規則，連線可能提前命中，後面的規則集便不會生效。排查時應查看連線詳細資訊中的規則類型、命中內容與最終策略，而不是只確認規則檔案已下載。

TUN 模式與流量入口的關係

系統代理只會影響遵循作業系統代理設定的程式。終端機工具、遊戲、虛擬機器或自行實作網路堆疊的應用程式，可能會忽略系統代理。TUN 模式透過虛擬網路介面接管更廣泛的 IP 流量，再將連線送入 Clash 的 DNS、規則與策略鏈路。

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

auto-route 讓核心嘗試自動設定路由，auto-detect-interface 用於識別預設出站介面，dns-hijack 則會將指定的 DNS 流量交給核心處理。stack 的可選值及預設行為會隨核心與平台變化，常見實作包括 system、gVisor 與 mixed。圖形化客戶端通常會依作業系統提供合適的預設值，除非正在定位相容性問題，否則不必頻繁切換。

TUN 啟動失敗時，應依序檢查客戶端權限、虛擬網卡狀態、其他 VPN 或網路過濾軟體、路由表，以及 DNS 接管衝突。TUN 已啟用卻仍有應用程式直連時，還要檢查路由排除項目、介面選擇，以及應用程式本身是否使用獨立 VPN。TUN 負責將流量送入核心，最終走直連還是代理，仍由規則與策略組決定。

設定載入失敗與規則未生效的檢查順序

  1. 先檢查 YAML 語法。確認縮排、冒號後的空格、清單連字號與引號是否閉合。解析器提示的行號有時只是發現錯誤的位置，真正問題可能出現在前幾行。
  2. 再檢查名稱引用。核對規則末尾的策略名稱、策略組中的節點名稱、use 引用的代理提供者，以及 RULE-SET 引用的規則提供者。
  3. 確認遠端資源狀態。檢查訂閱、代理提供者與規則提供者是否更新成功，儲存目錄是否可寫入，遠端內容是否符合核心要求的格式。
  4. 核對流量入口。系統代理連接埠必須與目前監聽連接埠一致；使用 TUN 時確認虛擬網卡與路由已建立；區域網路裝置還要檢查監聽位址與防火牆。
  5. 查看 DNS 與規則日誌。先判斷網域是否成功解析，再確認連線命中了哪條規則、進入哪個策略組，以及最後選用了哪個節點。
  6. 縮小設定範圍。複雜設定可暫時只保留一個可用節點、一個手動策略組與少量規則，確認基礎鏈路後，再逐段恢復 DNS 策略、規則集與自動測速。

一份便於維護的 Clash 設定，應讓引用關係保持清楚：連接埠與 TUN 負責接收流量，DNS 負責網域解析，節點與代理提供者提供出口，策略組組織出口，規則負責選擇策略。修改時沿著這條鏈路逐層驗證，比同時更換核心、訂閱、DNS 與規則集更容易定位問題。

下載Clash