設定進階 預計閱讀 14 分鐘

Clash 設定檔結構解析：從連接埠設定到策略組，逐段讀懂 YAML

依設定檔順序解析基礎設定、代理節點、策略組、規則集與 DNS 段落，說明各欄位之間的引用關係。

YAML Structure

先理解 YAML 的層級與資料類型

Clash 設定檔通常使用 YAML。閱讀時不應只搜尋某個節點名稱，而應先確認縮排所表達的父子關係。頂層欄位通常是主要設定段，例如 proxies、proxy-groups、rules 與 dns；向內縮排的欄位則屬於上一層物件。列表項目以連字號開頭，同一縮排深度的列表項目彼此並列。

mode: rule
log-level: info

proxies:
  - name: "範例節點"
    type: ss
    server: example.com
    port: 443

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - "範例節點"
      - DIRECT

這段設定包含兩個純量欄位、一個節點列表與一個策略組列表。name、type、server 都屬於列表中的同一個節點物件；策略組中的 proxies 則是名稱列表，其中的「範例節點」必須能在其他位置找到同名定義。

YAML 對縮排很敏感，建議統一使用空格，不要使用定位字元。包含冒號、井字號、特殊符號，或容易被解析為布林值的名稱，可以放在引號中。註解由 # 開始，只用於說明，不會參與核心運作。設定中的欄位名稱必須採用核心支援的寫法；調整中文顯示名稱不會改變欄位意義，但會影響名稱引用。

General Settings

基礎設定、工作模式與監聽連接埠

檔案開頭常見的是連接埠、區域網路存取、工作模式、日誌層級與控制介面。這些欄位決定程式如何接收流量，以及用戶端介面如何連線至核心，但不負責決定某個網域最終使用哪個節點。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
ipv6: false
external-controller: 127.0.0.1:9090
secret: "請設定獨立的控制密鑰"

如何區分連接埠欄位

  • port 通常表示 HTTP 代理監聽連接埠。
  • socks-port 表示 SOCKS5 代理監聽連接埠。
  • mixed-port 在同一個連接埠接收 HTTP 與 SOCKS 流量，桌面用戶端常採用這種形式。
  • redir-port、tproxy-port 適用於特定的透明代理方案，能否使用仍取決於作業系統與網路規則。

多個監聽連接埠不能與本機其他程式已佔用的連接埠衝突。桌面用戶端往往會在介面設定中管理連接埠，因此直接修改訂閱產生的 YAML 後，還要確認用戶端是否存在覆寫設定。

mode: rule 表示依照 rules 從上到下比對；global 通常會將流量統一交給全域策略；direct 則直接連線。介面中的「規則、全域、直連」切換可能在執行期間修改模式，不一定會回寫原始訂閱檔案。

allow-lan 控制區域網路裝置是否可以存取監聽連接埠。啟用後，還應搭配 bind-address、系統防火牆與實際網路邊界進行限制。external-controller 是控制介面位址，圖形化用戶端依靠它讀取連線、策略與日誌狀態；若介面需要讓非本機位址存取，應設定 secret 並限制可連線的範圍。

Proxy Sources

代理節點與代理提供者

proxies 用來儲存靜態節點定義。每個節點至少包含唯一名稱、協定類型、伺服器位址、連接埠，以及該協定要求的驗證欄位。不同協定的參數不能混用：Shadowsocks 常見 cipher 與 password，Trojan 常見密碼與 TLS 相關設定，VMess 與 VLESS 則各自有不同的身分、傳輸與加密欄位。

proxies:
  - name: "Tokyo-A"
    type: trojan
    server: edge.example.com
    port: 443
    password: "example-password"
    sni: edge.example.com
    udp: true

server 是連線目標，sni 是 TLS 交握時使用的伺服器名稱；兩者可能相同，也可能由服務設定明確指定。不能因為連線失敗就任意互換或刪除 TLS 欄位。協定參數應以訂閱提供方提供的有效設定，以及目前 mihomo 文件為準。

節點數量較多時，設定通常會透過 proxy-providers 引入外部節點集合。提供者負責從指定來源讀取節點並依排程更新，策略組再透過 use 引用它。如此可將「節點來源」與「節點如何參與選擇」分開。

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

primary 是提供者鍵名，之後會由策略組引用。path 指定本機快取位置，interval 是更新間隔。健康檢查只是在指定條件下測試節點連通性或延遲，不代表實際服務網站必然可用，也不會自動修正驗證參數。

Policy Groups

策略組如何連結節點與規則

proxy-groups 是整份設定的調度層。規則通常不會直接寫入某個伺服器位址，而是將流量交給策略組；策略組再選擇節點、內建策略或另一個策略組。理解這一層，才能說明介面中為何會出現多層選擇。

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - "自動選擇"
      - "Tokyo-A"
      - DIRECT

  - name: "自動選擇"
    type: url-test
    use:
      - primary
    url: "https://www.gstatic.com/generate_204"
    interval: 300

  - name: "媒體服務"
    type: select
    proxies:
      - "節點選擇"
      - DIRECT

第一組使用 select，由使用者在介面中選擇成員。第二組使用 url-test，從提供者 primary 的節點中依測試結果選擇。第三組不直接列出伺服器，而是引用「節點選擇」，因此會沿著引用關係繼續取得最終出口。

proxies 用來列出靜態節點、內建策略或其他策略組；use 用來引用 proxy-providers。兩者都能構成成員來源，但物件類型不同。常見錯誤是把提供者名稱放進 proxies，或把節點名稱寫進 use。

常見策略組類型

select
提供手動選擇入口，適合總出口、應用程式分類，以及需要固定策略的情境。
url-test
依指定的測試位址與週期檢查成員，通常會選擇測試結果較佳的節點。
fallback
依成員順序檢查可用性，前一個成員無法使用時切換至後續成員。
load-balance
依設定的策略在多個成員之間分配連線，適用性取決於業務工作階段的特徵。

DIRECT、REJECT 等是內建策略，不需要在 proxies 中定義。自訂名稱則必須完全一致，包括大小寫、空格與符號。策略組之間可以巢狀，但不能形成循環引用，否則核心無法取得明確出口。

Routing Rules

規則比對順序與規則集引用

rules 決定流量交給哪個策略。在規則模式下，核心通常會由上而下檢查，命中一條後便停止繼續比對。因此，具體網域與明確網段通常應放在較寬泛的規則之前，兜底規則則放在最後。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.net,節點選擇
  - DOMAIN-KEYWORD,media,媒體服務
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

DOMAIN 比對完整網域名稱，DOMAIN-SUFFIX 比對指定網域及其子網域，DOMAIN-KEYWORD 依網域中的關鍵字比對。IP-CIDR 依目標 IPv4 網段判斷，IPv6 可使用對應的 IPv6 規則類型。GEOIP 依賴地理資料庫判斷 IP 所屬區域。MATCH 是最終兜底規則，應放在規則末尾。

規則最後一段通常是目標策略名稱，例如「節點選擇」、「媒體服務」、DIRECT 或 REJECT。如果目標名稱不存在於 proxy-groups 中，即使規則語法看似完整，也會在載入階段報錯，或無法依預期運作。

大量規則可以放入 rule-providers。規則提供者定義來源、快取路徑、行為類型與更新週期，主規則區則使用 RULE-SET 呼叫。

rule-providers:
  private-network:
    type: http
    behavior: ipcidr
    format: yaml
    url: "https://example.com/private-network.yaml"
    path: ./ruleset/private-network.yaml
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - MATCH,節點選擇

behavior 描述規則集內容的比對形式，常見值包括 domain、ipcidr 與 classical。規則檔案的實際內容必須符合該行為。classical 可承載較完整的經典規則表示式；domain 與 ipcidr 則更側重對應類型的資料集合。

DNS Pipeline

DNS 段落如何參與網域解析

DNS 設定並不只是填入兩個伺服器位址。它會影響網域如何解析、規則如何在網域與 IP 之間建立關聯，以及 TUN 情境下流量能否穩定進入核心。mihomo 常見欄位包括啟用狀態、監聽位址、解析模式、預設解析器、主要解析器、備援解析器，以及依網域分流的名稱伺服器策略。

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

default-nameserver 通常用於解析 DoH 或 DoT 伺服器本身的網域，因此一般會填入可直接存取的 IP 位址解析器。nameserver 是主要查詢來源；fallback 是否參與，以及如何篩選結果，仍取決於目前的核心版本與相關篩選設定。

enhanced-mode: fake-ip 會向應用程式回傳保留位址範圍內的映射位址，核心據此保留網域資訊並完成後續轉發。這有利於網域規則判斷，但部分區域網路服務、裝置探索、遊戲平台，或依賴真實位址的程式，可能需要加入 fake-ip-filter。另一種常見模式是 redir-host，其處理路徑不同，具體選擇應配合作業系統、用戶端實作與應用程式相容性。

DNS 失敗不一定會表現為「無法解析」。有時瀏覽器已取得結果，但連線被錯誤規則送往無法使用的策略；也可能同時存在系統 DNS、瀏覽器安全 DNS 與核心 DNS，導致實際查詢沒有經過預期的連線路徑。排查時應分別確認應用程式請求入口、DNS 監聽狀態、解析日誌與最終命中的規則。

Traffic Capture

TUN 模式與系統代理的設定界線

系統代理只會影響遵循作業系統代理設定的應用程式。部分命令列工具、遊戲、獨立網路堆疊程式或 UDP 流量可能繞過系統代理。TUN 模式透過虛擬網路介面接收更多系統流量，再交由 DNS、規則與策略組處理。

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

stack 決定 TUN 網路堆疊的實作，可用值與建議選擇會隨平台及 mihomo 版本變化。auto-route 嘗試自動設定路由，auto-detect-interface 用於識別預設網路介面。啟用 TUN 通常需要相應的系統權限，用戶端可能透過服務模式或輔助元件完成權限操作。

TUN 只是流量入口，不會取代規則與策略組。流量進入核心後，仍須經過網域解析、嗅探設定、規則比對與策略選擇。若啟用 TUN 後區域網路裝置無法存取，應檢查私有網段直連規則、路由排除設定及 DNS 劫持範圍，而不是直接刪除所有分流規則。

系統代理與 TUN 可以由用戶端統一管理。實際使用時應避免同時執行多個接管網路的工具，也要留意休眠喚醒、網路切換及 VPN 介面變更後預設路由是否更新。關閉 TUN 後若網路仍異常，可以檢查用戶端是否已還原系統代理與路由狀態。

Validation

修改設定後的驗證與疑難排解流程

設定檔能由文字編輯器開啟，不代表核心就能載入。較可靠的調整方式是一次只修改一個邏輯單元，並保留可還原的版本。若用戶端提供設定檢查、核心日誌或覆寫預覽，應先確認合併後的最終 YAML，而不是只檢查某個片段。

  1. 檢查 YAML 結構：確認縮排、列表連字號、引號與冒號位置，且沒有重複覆寫重要的頂層欄位。
  2. 檢查名稱引用：逐一核對規則目標、策略組成員、use 提供者名稱與 RULE-SET 名稱。
  3. 檢查外部資源：確認代理提供者與規則提供者可以更新、本機快取路徑可寫入，且下載內容格式符合宣告。
  4. 檢查執行日誌：載入錯誤通常會指出欄位或物件名稱；連線錯誤則需要結合 DNS、規則命中與節點交握資訊判斷。
  5. 進行最小測試：先測試 DIRECT，再測試單一靜態節點，接著測試策略組與規則集，逐層縮小問題範圍。

幾類常見錯誤

  • 策略組引用了已重新命名，或已在訂閱更新時刪除的節點。
  • 規則指向不存在的策略組，或名稱中多了空格。
  • proxy-providers 已定義，但策略組沒有透過 use 引入。
  • RULE-SET 名稱與 rule-providers 的鍵名不一致。
  • 寬泛規則排在具體規則之前，導致後面的規則永遠沒有機會命中。
  • DNS 監聽連接埠衝突，或應用程式請求沒有進入由核心管理的解析路徑。
  • 直接編輯訂閱快取，更新後自訂內容被新的訂閱結果取代。

完整設定可以理解為一條引用鏈：應用程式流量先由系統代理、透明代理或 TUN 進入核心；DNS 段落處理網域解析；rules 與規則提供者決定目標策略；proxy-groups 從靜態節點或代理提供者中選出出口；最後由具體協定節點建立連線。依照這條路徑閱讀，比逐一背誦欄位更容易找出設定中的斷點。

下載Clash