Clash 設定檔
完整參考

01 / DOCUMENT MAP

YAML 結構總覽與讀取順序

頂層欄位如何組成一份設定

Clash 設定檔通常命名為 config.yaml，本質上是一棵由映射、列表與純量組成的資料樹。頂層映射負責劃分功能區域：連接埠與執行模式決定流量如何進入核心，dns 控制網域解析，proxies 描述個別代理節點，proxy-groups 將節點組織成可手動選擇或自動測試的策略，rules 則依序將連線送往某個策略組。mihomo 也能使用 proxy-providers、rule-providers、tun、sniffer 等擴充區域。

解析設定時，縮排代表父子關係。同層欄位必須使用一致數量的空格，常見寫法是每層兩個空格。列表項目以連字號開頭，連字號後的物件仍可繼續包含子欄位。YAML 允許字串不加引號，但節點名稱、密碼、正規表示式，以及包含冒號或特殊符號的值容易被誤判，穩妥做法是為這些值加上引號。布林值使用 true 與 false，數字連接埠應維持數字型別，不要寫成附帶其他說明的字串。

mixed-port: 7890
mode: rule
log-level: info
ipv6: false

dns:
  enable: true
  listen: 0.0.0.0:1053
  enhanced-mode: fake-ip
  nameserver:
    - 223.5.5.5
    - 1.1.1.1

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

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

rules:
  - DOMAIN-SUFFIX,example.org,節點選擇
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

映射、列表與名稱引用

dns: 後面是一組映射欄位；proxies: 後面則是物件列表。策略組中的 proxies 同樣是列表，但儲存的是名稱引用，而不是再次宣告節點。名稱必須逐字相符，包括大小寫、空格與符號。若節點名稱為「香港 01」，策略組寫成「香港01」就會變成不存在的引用。規則的最後一段同樣引用策略組名稱或內建策略，例如 DIRECT、REJECT。修改名稱時，必須同步檢查策略組、規則與介面覆寫中的所有引用位置。

YAML 錨點與別名可以減少重複，但並非所有圖形客戶端的儲存、轉換與覆寫流程都能完整保留錨點。用於長期維護的公開設定，優先採用清楚的明確欄位。設定較大時，可將節點與規則拆分至 provider 檔案，再由主設定引用；這比在單一檔案堆疊數千行更容易更新，也能分開維護「節點資料」與「分流邏輯」。

最小設定與載入邊界

一份能啟動的最小設定，不代表能正常連線。只設定連接埠與模式時，核心可能正常監聽，但規則引用的策略不存在、DNS 無法解析節點網域，仍會導致連線失敗。檢查順序應先從語法開始，再確認引用完整，最後驗證網路行為。客戶端提示「設定載入成功」只能表示結構基本可解析，不代表每組節點憑證、遠端集合網址與規則目標都有效。

此外，不同核心維護階段所支援的欄位範圍並不完全相同。原版 Clash、Clash Meta 與目前 mihomo 的名稱演變及相容關係，可參考核心版本差異說明。如果客戶端採用 mihomo 核心，可以使用其擴充欄位；若設定要在多個客戶端之間共用，應先確認各客戶端實際搭載的核心，不要只依據客戶端介面名稱判斷。

02 / RUNTIME

通用欄位：連接埠、模式與控制介面

mixed-port、port 與 socks-port

mixed-port 在同一個監聽連接埠上接受 HTTP 與 SOCKS5 代理連線，適合桌面客戶端及多數手動代理情境。port 只提供 HTTP 代理，socks-port 只提供 SOCKS5。三者可以依需求組合，但不要讓多個欄位佔用同一個連接埠，也不要與本機其他程式的監聽連接埠衝突。若圖形客戶端已接管連接埠設定，介面值可能在啟動時覆蓋設定檔，因此排查時也要查看介面與實際執行記錄。

應用程式填寫代理位址時，執行於同一台裝置上的程式通常連線至 127.0.0.1。區域網路中的其他裝置需要連線至 Clash 所在裝置的區域網路位址，同時開啟 allow-lan，並確認系統防火牆允許對應連接埠。開放區域網路監聽會擴大可存取範圍，應透過 bind-address 限定介面，並在需要時設定驗證資訊。完成連接埠設定後，可透過作業系統的網路連線資訊確認監聽狀態，不必反覆修改連接埠碰運氣。

mixed-port: 7890
allow-lan: false
bind-address: "*"
mode: rule
log-level: info
ipv6: false
unified-delay: true
tcp-concurrent: true

rule、global 與 direct 模式

mode: rule 會依照 rules 由上到下比對，是日常使用的主要模式。global 將可代理流量統一交給全域策略，適合暫時確認某個節點是否可用，但會繞過原本的分流意圖。direct 則讓流量直接連線，常用於快速判斷問題是否由代理鏈路造成。介面切換模式後，部分客戶端只會修改執行狀態而不改寫 YAML；重新啟動後是否保留，取決於客戶端設定。

定位故障時可以進行對照：規則模式失敗而全域模式成功，通常表示規則目標、規則順序或策略組引用有問題；全域模式也失敗，則應繼續檢查節點、系統代理、TUN、DNS 或網路環境；直連模式仍無法存取本機服務，問題可能與 Clash 設定無關。切換模式只是診斷手段，測試完成後應恢復規則模式，避免長期失去網域與區域分流。

記錄、IPv6 與外部控制器

log-level 常用值包括 silent、error、warning、info 與 debug。日常使用選擇 info 即可；遇到規則命中或連線階段不明確的問題，可暫時切換至 debug，收集資訊後再恢復，避免記錄快速增長。記錄中應重點觀察目標網域、命中的規則、最終策略、DNS 錯誤與連線逾時，不要只看最後一行。

ipv6 控制核心是否處理 IPv6 相關功能，但 DNS 區域也有獨立的 IPv6 選項。網路具備穩定 IPv6 且節點鏈路支援時可以開啟；若本地取得 IPv6 位址卻缺少可用出口，可能出現應用程式優先嘗試 IPv6 後等待逾時的情況。排查時應分別確認系統網路、DNS 回應結果、Clash 頂層開關與 DNS 子項，避免只修改一個欄位。

external-controller 為控制面板與客戶端前端提供 API，例如 127.0.0.1:9090。若監聽範圍超出本機，應設定 secret 並限制防火牆存取。控制介面不是代理連接埠，瀏覽器或應用程式不能將它當作 HTTP 代理使用。external-ui 指向靜態面板檔案目錄，路徑應依執行環境的實際目錄決定，不宜將某台裝置的絕對路徑直接同步至其他系統。

external-controller: 127.0.0.1:9090
secret: "your-controller-secret"
external-ui: ui

profile:
  store-selected: true
  store-fake-ip: true

profile.store-selected 用於儲存策略組的選擇結果，重新啟動時繼續使用上次選項；store-fake-ip 則與 Fake-IP 對映持久化有關。跨裝置同步設定時，不應假設執行狀態也會隨 YAML 一起同步。訂閱、覆寫與私人儲存庫三種同步路徑的界線，可繼續閱讀Clash 多裝置設定同步。

03 / DNS PIPELINE

DNS 設定與 Fake-IP 解析流程

DNS 請求會經過哪些階段

Clash 的 DNS 模組不只是將網域轉送給某台伺服器。啟用後，它會接收應用程式查詢，依據 nameserver-policy、fallback 等規則選擇上游，並將解析結果交給規則比對與連線流程。若節點伺服器本身使用網域，也會涉及 bootstrap 解析：核心必須先取得節點網域的位址，才能建立加密連線。因此 DNS 故障可能表現為網頁無法開啟，也可能表現為所有網域節點同時逾時。

listen 指定 DNS 服務的監聽位址。桌面圖形客戶端通常已處理系統 DNS 或 TUN 劫持，不一定需要使用者手動將系統 DNS 改至該連接埠。路由器或區域網路閘道情境則常會將客戶端查詢轉送至此。若監聽 0.0.0.0，應搭配防火牆限制存取範圍；只在本機使用時，優先監聽回送位址。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  use-hosts: true
  respect-rules: true
  default-nameserver:
    - 223.5.5.5
    - 119.29.29.29
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://doh.pub/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query
  direct-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "+.stun.*.*"

default-nameserver 與 nameserver 的差異

default-nameserver 主要負責解析加密 DNS 上游本身的網域，通常填寫可直接存取的 IP 格式 DNS 位址，避免形成「要存取 DoH，得先解析 DoH 網域，但解析又依賴 DoH」的循環。nameserver 是主要查詢上游，可以填寫 UDP、TCP、DoT 或 DoH 位址。上游數量並非越多越好；混入行為差異很大的解析器會讓結果難以預測，也增加排錯分支。

proxy-server-nameserver 可專門用於解析代理節點伺服器網域，避免節點網域沿著錯誤路徑查詢。direct-nameserver 用於直連網域解析，適合將本地區域流量交給距離較近的解析器。啟用 respect-rules 後，DNS 查詢會更多參考規則路徑，此時需要確保代理節點網域具有獨立的解析出口，否則可能形成策略依賴循環。

Fake-IP 與 Redir-Host 如何選擇

enhanced-mode: fake-ip 會從保留位址區段為網域分配暫時位址。應用程式先取得這個對映位址，連線到達時核心再還原原始網域並執行網域規則。其優點是在連線階段保留網域資訊，減少「先解析成 IP 後只能命中 IP 規則」的情況。Fake-IP 不代表連線目標真的位於該保留網段，它只是核心內部的網域對映識別。

redir-host 回傳實際解析位址，再由透明代理或嗅探功能補充網域資訊。某些依賴區域網路探索、區域網路網域、特殊驗證或直接檢查解析位址的程式，更適合使用實際位址模式，但規則精確度與快取行為需要依具體平台評估。多數桌面與行動裝置的常規代理情境可以先使用 Fake-IP，再將不相容網域加入 fake-ip-filter，不要一遇到局部問題就整體切換模式。

排除項目應盡量具體。*.lan、*.local 常用於本地裝置探索，時間同步、STUN、遊戲平台與部分企業內網網域也可能需要實際結果。過寬的萬用字元會讓大量網域繞過 Fake-IP，降低規則比對的一致性。有關對映、規則命中與排除項目的完整流程，可查看Fake-IP 模式原理。

DNS 洩漏與解析故障的定位方法

所謂 DNS 路徑異常，通常要拆成三個問題：查詢由哪個元件發出、請求送往哪個上游、最終連線採用哪條策略。瀏覽器可能啟用自己的安全 DNS，系統服務可能繞過應用程式代理，TUN 也可能透過 DNS 劫持接管查詢。只看網頁顯示的解析器名稱，無法直接判定所有流量路徑。應先關閉不參與測試的瀏覽器獨立 DNS，再觀察 Clash 記錄中的查詢與規則記錄。

遇到訂閱可更新但所有節點都顯示網域解析失敗時，先檢查 default-nameserver 與節點網域解析；一般網站失敗但 IP 位址可連線時，再檢查主要 nameserver、監聽連接埠與系統 DNS 接管；少數區域網路裝置失效時，檢查 Fake-IP 排除項目。若出現間歇性逾時，可暫時只保留一個確認可達的上游，排除並行上游差異、網路阻斷與快取影響，再逐項恢復。

04 / PROXY OBJECTS

代理節點欄位與協定物件

所有節點共用的識別欄位

proxies 中的每個物件至少要有 name、type、server 與 port，其他欄位由協定決定。name 是設定內部的唯一識別，也會顯示在客戶端介面。名稱重複時，策略組引用與介面選擇可能產生歧義，因此應在產生設定時確保唯一。server 可以是網域或 IP；使用網域有利於服務端切換位址，但會增加節點網域解析這個前置步驟。

udp 表示節點是否允許承載 UDP，實際可用性還取決於協定、服務端與客戶端入口。遊戲、語音、QUIC 與部分 DNS 流量可能依賴 UDP。啟用欄位不代表鏈路一定支援，若服務端或中間網路不支援，記錄中可能出現握手成功但 UDP 沒有回應。interface-name 與 routing-mark 屬於較偏向多網卡或 Linux 路由的控制欄位，普通桌面設定不必主動加入。

Shadowsocks 與 Trojan 範例

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

  - name: "Trojan-範例"
    type: trojan
    server: trojan.example.com
    port: 443
    password: "your-password"
    sni: service.example.com
    skip-cert-verify: false
    udp: true
    network: tcp

Shadowsocks 的 cipher 必須與服務端一致，密碼也應依原始內容填寫。不要因為欄位名稱相同，就互換不同協定的憑證。Trojan 依賴 TLS，sni 用於指定握手中的伺服器名稱，通常應與服務端憑證涵蓋的網域一致。skip-cert-verify: false 表示執行憑證驗證，是正常設定的優先選擇。若驗證失敗，應檢查裝置時間、憑證網域、SNI 與服務端憑證鏈，而不是長期關閉驗證。

network 描述底層傳輸，例如 TCP、WebSocket 或 gRPC。選擇 WebSocket 時還需提供路徑與請求標頭；選擇 gRPC 時通常需要服務名稱。傳輸欄位必須與服務端入口完整對應。常見錯誤是只複製協定、位址與密碼，卻遺漏傳輸層路徑，結果 TCP 可以到達連接埠，但握手持續失敗。

VMess 與 VLESS 的階層欄位

proxies:
  - name: "VLESS-WS-範例"
    type: vless
    server: edge.example.com
    port: 443
    uuid: "00000000-0000-4000-8000-000000000000"
    network: ws
    tls: true
    servername: service.example.com
    udp: true
    ws-opts:
      path: /network-path
      headers:
        Host: service.example.com

  - name: "VMess-gRPC-範例"
    type: vmess
    server: grpc.example.com
    port: 443
    uuid: "00000000-0000-4000-8000-000000000000"
    alterId: 0
    cipher: auto
    tls: true
    servername: grpc.example.com
    network: grpc
    grpc-opts:
      grpc-service-name: proxy-service

VLESS 與 VMess 都使用 UUID 格式的身分資訊，但協定行為與欄位集合不同。ws-opts、grpc-opts 是與 network 對應的巢狀映射，縮排錯位會讓參數落在節點物件的錯誤層級。TLS 情境中，連線位址、SNI 或 servername、HTTP Host 可以不同：連線位址決定實際連往何處，SNI 用於 TLS 憑證與虛擬主機選擇，Host 則屬於 HTTP 或 WebSocket 請求標頭。三者是否相同取決於服務端部署，不能憑經驗互相替換。

範例 UUID 與網域僅用於展示欄位結構，不能直接用來連線。實際節點資料應來自使用者有權使用的服務設定。訂閱產生的節點通常不建議手動逐項重寫，因為遺漏一個傳輸欄位就會造成難以辨識的差異；更適合透過 provider 載入，再使用策略組與規則管理。

Reality、憑證與指紋相關欄位

mihomo 支援的部分 VLESS 設定會包含 Reality 參數，例如公鑰、短識別碼與客戶端指紋。欄位名稱與層級必須遵循目前核心支援的格式，並與服務端設定相符。由於這類功能在舊核心或舊客戶端中可能不存在，將設定同步至其他裝置前應確認核心相容性。遇到「不支援欄位」或「設定解析失敗」時，先查看客戶端使用的核心類型，再決定調整欄位或更換支援該設定的客戶端。

client-fingerprint 會影響 TLS 客戶端指紋模擬，但不是修復所有握手問題的通用開關。憑證名稱錯誤、系統時間偏差、SNI 不相符與網路阻斷仍應分別處理。選擇客戶端時，桌面與行動平台都優先從安裝包頁面選擇 Clash Plus；需要其他介面或系統適配時，再比較 Clash Verge Rev、FlClash、Clash Nyanpasu、Clash Meta for Android、Surfboard、ClashX Meta 與已封存的 Clash for Windows。

05 / POLICY GROUPS

策略組欄位與選擇邏輯

select：將選擇權交給使用者

策略組是規則與節點之間的中介層。規則不宜直接指向可能變動的節點名稱，而應指向穩定的策略組，例如「節點選擇」、「串流媒體」或「下載服務」。節點更新時只需調整策略組成員，規則結構可以維持不變。select 組由使用者手動選擇一個成員，成員可以是節點、另一個策略組或內建策略。

proxy-groups:
  - name: "節點選擇"
    type: select
    proxies:
      - "自動選擇"
      - "故障轉移"
      - "香港節點"
      - "日本節點"
      - DIRECT

  - name: "香港節點"
    type: select
    use:
      - subscription-main
    filter: "(?i)港|hk|hong kong"

proxies 引用靜態節點或其他組，use 引用 proxy-providers。兩者可以依核心能力組合使用。filter 通常以正規表示式篩選 provider 中的節點名稱，命名習慣會直接影響結果。若訂閱將地區名稱改成其他格式，原有篩選可能得到空組。維護設定時，應將篩選表示式視為依賴訂閱命名的資料規則，更新後檢查組內是否仍有成員。

url-test：依探測結果自動選擇

url-test 會定期存取指定 URL，根據測試結果在組內選擇表現合適的節點。url 應指向容量小、回應穩定且符合使用路徑的測試資源；interval 是測試週期；tolerance 用於減少結果接近時的頻繁切換。測速只能反映探測目標在某個時間點的回應情況，不等同於下載速度、影片傳輸量或所有網站的使用體驗。

  - "自動選擇"
    type: url-test
    use:
      - subscription-main
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true
    expected-status: 204

lazy: true 表示實際使用策略時才依需求進行測試，有助於減少閒置組的探測請求。若測試位址在目前網路遭到重新導向、阻斷或回傳不同狀態，所有節點都可能被誤判為不可用。此時應先直接檢查測試 URL 的可達性，再更換為穩定資源，不要刪除整個自動策略。自動選擇組適合一般網頁流量，但需要固定出口位址的登入工作階段、遠端管理或白名單服務，更適合手動選擇並固定節點。

fallback 與 load-balance

fallback 依列表或探測結果維持可用順序，目前節點失敗時切換至其他成員，重點是持續可用性。它不保證每次都選到延遲最低的節點。load-balance 將不同連線分配至多個節點，適合可接受多個出口的並行請求；如果網站將同一登入流程中的出口變化視為異常，負載平衡反而會影響工作階段。

  - name: "故障轉移"
    type: fallback
    proxies:
      - "香港節點 01"
      - "日本節點 01"
      - "新加坡節點 01"
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: "並行分配"
    type: load-balance
    use:
      - subscription-main
    url: https://www.gstatic.com/generate_204
    interval: 600
    strategy: consistent-hashing

負載平衡策略中，一致性雜湊會盡量讓相同目標維持在穩定節點，輪詢則更重視分散連線。使用前需要確認業務是否允許出口變化，不應將「同時使用多個節點」簡單理解為單一連線頻寬相加。單一 TCP 連線通常仍由一個節點承載，多個節點主要分擔不同連線。

策略組巢狀與避免循環

組可以引用組，因此能建立「業務策略 → 地區策略 → 節點」的層級。例如影片規則指向「串流媒體」，該組再允許選擇「香港節點」或「日本節點」。這種結構能減少重複，但層級過深會增加排查難度。更重要的是不能形成循環引用：A 包含 B，B 又包含 A，會導致設定驗證失敗或執行邏輯無法確定。

命名應表達功能，而非暫時的節點狀態。規則目標使用「即時通訊」、「開發服務」、「兜底代理」等穩定名稱，地區組使用「香港節點」、「日本節點」，具體節點名稱留在最底層。如此一來，訂閱更新、節點增刪或地區篩選變更時，上層規則不必改寫。若策略選擇在重新啟動後遺失，請檢查 profile.store-selected 與客戶端自身的設定持久化方式，不要將選定節點硬編碼至所有規則中。

06 / ROUTING RULES

規則語法、比對順序與兜底

規則依序進行首次比對

rules 是有順序的列表。連線到達後，核心從第一條開始檢查，命中後立即採用該條指定的策略，不會繼續向下尋找「更具體」的規則。因此具體網域、業務規則與特殊直連通常放在前面，較寬的網域後綴、IP 區域規則放在後面，最後使用 MATCH 處理剩餘流量。規則順序顛倒，是「規則看似存在卻從未生效」的主要原因之一。

標準規則通常以逗號分隔：規則類型、比對內容、目標策略，部分類型還可附加參數。例如 DOMAIN-SUFFIX,example.com,節點選擇 會比對該網域及其子網域；DOMAIN,api.example.com,DIRECT 只比對完整網域；DOMAIN-KEYWORD,example,節點選擇 會比對包含關鍵字的網域，範圍較寬，應避免使用過於普通的關鍵字。

rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,example.cn,DIRECT
  - DOMAIN-SUFFIX,example.com,節點選擇
  - DOMAIN-KEYWORD,video,串流媒體
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

網域規則的精確度差異

DOMAIN 精確比對一個完整網域，適合單獨處理 API、下載網域或區域網路主機。DOMAIN-SUFFIX 依網域邊界比對主網域與子網域，是維護網站規則時最常用的形式。DOMAIN-KEYWORD 只要網域中出現指定文字就可能命中，容易誤傷其他網站，應放在精確規則之後，並選擇足夠獨特的關鍵字。

如果同一服務使用多個網域，只加入首頁網域通常不夠。網頁還可能請求登入、介面、圖片、媒體與靜態資源網域。應從連線記錄觀察實際請求，再補充規則，不要根據頁面標題猜測。對於持續變動的大型服務，使用維護良好的 rule-provider 比手動追加大量網域更合理。

IP-CIDR、GEOIP 與 no-resolve

IP-CIDR 依 IPv4 網段比對，IP-CIDR6 用於 IPv6。內網、回送位址與特定服務位址常透過 CIDR 直連。規則末尾的 no-resolve 表示比對該 IP 規則時，不要為了取得位址而額外觸發 DNS 解析，適合連線本身已具備目標 IP 的情況。若規則需要從網域解析出 IP 才能判斷，就不應機械式加入此參數。

GEOIP 依 IP 資料庫判斷區域。它發生在取得目標 IP 之後，不能完全取代網域規則。CDN 可能依網路環境回傳不同地區的位址，同一網站也可能使用跨區域基礎設施，因此「網域屬於某地區」與「目前 IP 被資料庫歸入某地區」不是同一件事。對明確服務，優先使用網域或規則集合；GEOIP 更適合作為後段的大範圍分流。

程序、連接埠與邏輯組合規則

支援相應功能的平台與核心可以使用 PROCESS-NAME、PROCESS-PATH、DST-PORT、SRC-IP-CIDR 等規則。程序規則依賴系統提供程序資訊，在行動裝置、容器、權限受限環境或 TUN 實作差異下可能無法使用。連接埠規則只說明目標連接埠，不代表應用程式類型；大量服務共用 443 連接埠，單靠連接埠代理會涵蓋過廣。

mihomo 的邏輯規則可以使用 AND、OR、NOT 組合多個條件，適合表達「某個程序存取某個網段」這類條件。但邏輯表示式越複雜，就越需要確認括號、引號與參數分隔方式。實際維護時，應先用普通規則驗證每個條件是否能單獨命中，再進行組合，避免將語法錯誤、平台能力與邏輯結果混在一起排查。

rules:
  - PROCESS-NAME,example-client,節點選擇
  - DST-PORT,22,開發服務
  - AND,((NETWORK,TCP),(DST-PORT,443)),節點選擇
  - OR,((DOMAIN-SUFFIX,example.org),(DOMAIN-SUFFIX,example.net)),開發服務
  - MATCH,兜底代理

規則命中不符合預期時如何定位

第一步查看連線記錄中的目標網域或 IP、命中規則與最終策略。第二步確認命中規則上方是否有更寬的規則提前攔截。第三步檢查規則目標策略組目前選取了什麼成員。第四步確認 DNS 模式是否保留網域資訊；若應用程式直接連線至 IP，網域規則自然不會命中。最後再檢查 rule-provider 是否更新成功、行為類型是否與檔案內容相符。

臨時測試可以將一條精確規則放到列表最前面，重新載入設定後再次建立新連線。既有連線可能繼續重用舊鏈路，因此只重新整理頁面未必足夠，必要時關閉應用程式連線或清除連線列表。驗證完成後，將規則移至合理層級。區域分流的完整 YAML 編排範例可繼續閱讀Clash 規則分流實作。

07 / PROVIDERS

代理集合、規則集合與遠端更新

proxy-providers 將節點資料移出主設定

proxy-providers 用於載入遠端或本機節點集合。主設定只保留 provider 名稱、來源、更新週期與健康檢查，策略組透過 use 引用集合。如此一來，訂閱更新只會改變節點層，連接埠、DNS、策略組與規則仍由本機設定控制。與直接將訂閱當作完整設定相比，這種結構更適合維護固定的分流邏輯。

proxy-providers:
  subscription-main:
    type: http
    url: "https://subscription.example.com/profile.yaml"
    path: ./providers/subscription-main.yaml
    interval: 3600
    proxy: DIRECT
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600
      lazy: true

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

type: http 表示從遠端位址取得，path 是下載後的本機儲存位置，interval 是自動更新間隔。proxy 決定更新請求經過哪個策略；首次啟動時代理策略可能還沒有可用節點，因此通常先使用 DIRECT；若訂閱位址在目前網路無法直連，再搭配客戶端提供的訂閱更新代理功能處理。不要讓 provider 的更新依賴自身尚未載入的節點，否則容易形成啟動依賴。

健康檢查只是在固定 URL 上驗證節點回應，不會修復訂閱下載錯誤。訂閱更新失敗應區分 HTTP 狀態、網路逾時、位址失效、回傳內容不是 YAML、檔案寫入失敗與解析失敗。客戶端顯示相同的「更新失敗」時，記錄中的階段資訊才是定位依據。常見處理方式也可在常見問題中查閱。

rule-providers 與 behavior

rule-providers 將大量規則拆成獨立檔案，主規則列表使用 RULE-SET 引用。關鍵欄位 behavior 描述集合內容的形式。domain 適合網域類項目，ipcidr 適合 IP 網段，classical 則儲存完整的經典規則表示式。behavior 與檔案內容不相符時，集合可能載入失敗或無法按預期命中。

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

  private-networks:
    type: file
    behavior: ipcidr
    format: yaml
    path: ./ruleset/private-networks.yaml

rules:
  - RULE-SET,private-networks,DIRECT
  - RULE-SET,local-services,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

domain behavior 的 YAML 檔案通常使用 payload 儲存網域項目；ipcidr 檔案儲存網段；classical 檔案中的每個項目則類似主設定中的完整規則，但通常不在項目中寫入最終策略，因為策略由主設定的 RULE-SET 行指定。引用層負責決定去向，集合檔案負責描述比對對象，這種分工能讓同一集合在不同設定中指向不同策略。

payload:
  - "+.example.cn"
  - "api.example.net"
  - "download.example.org"

更新週期、快取與失敗回退

更新間隔應依資料變化頻率設定。節點訂閱可能需要較短週期，穩定的規則集合則可每日更新。間隔過短會增加遠端請求與設定重新載入頻率，也會在網路不穩定時產生大量錯誤記錄。遠端更新失敗時，核心通常會嘗試繼續使用本機快取檔案，因此 path 所在目錄需要可寫入，且不能被系統清理工具頻繁刪除。

如果首次載入就失敗，本機尚無快取，引用該 provider 的組或規則集可能無法使用。部署到新裝置前，應測試遠端位址可達、回傳格式正確且儲存目錄可建立。跨平台同步設定時，優先使用相對路徑；Windows、macOS、Android、iOS 與 Linux 的設定根目錄不同，寫死某個平台的絕對路徑會讓其他裝置載入失敗。

訂閱憑證與設定分層

訂閱位址通常包含存取憑證，不應放入公開儲存庫、公開記錄或公開截圖。需要多裝置同步時，可以將不含憑證的主設定、策略組與規則放入私人維護路徑，再透過客戶端本機覆寫或裝置專用檔案加入訂閱位址。如此既能共用分流邏輯，也能避免所有裝置被迫使用完全相同的執行參數。

設定分層可分成四部分理解：主設定負責執行方式，provider 負責節點或規則資料，策略組負責可選出口，裝置覆寫負責本機差異。任何更新都應盡量只修改所屬層。若將連接埠、節點、規則與裝置路徑全部塞進一份訂閱產生檔案，更新衝突與排錯成本會明顯增加。

08 / OVERRIDE & DEBUG

覆寫、合併、驗證與故障定位

為什麼訂閱更新會覆蓋手動修改

許多圖形客戶端會將遠端訂閱轉換成執行設定。使用者直接編輯轉換後的檔案，下一次更新時客戶端會重新產生內容，因此新增的規則、連接埠與 DNS 設定可能消失。覆寫功能的目的，是在訂閱更新後、核心載入前，重新套用本機調整至產生結果。不同客戶端可能稱為覆寫、擴充、腳本、混入或設定合併，實際支援的合併規則也各不相同。

簡單純量欄位通常採用後值覆蓋前值，例如本機 mixed-port 取代訂閱中的連接埠。映射欄位可能遞迴合併，例如只修改 dns.ipv6 而保留其他 DNS 項目。列表最容易產生差異：有些實作會整體取代 rules，有些支援前置、後置與刪除操作，有些則需要腳本回傳完整陣列。使用前應查看客戶端的覆寫說明，並透過最終產生的設定驗證結果。

# 本機覆寫示意：具體檔案入口由客戶端決定
mixed-port: 7890
mode: rule
log-level: info

dns:
  enable: true
  ipv6: false

profile:
  store-selected: true
  store-fake-ip: true

規則合併應明確前置或後置

由於規則採用首次比對，加入位置會改變意義。區域網路直連、單一網域修正以及需要壓過訂閱預設行為的規則，通常應前置；作為補充但不希望影響既有精確規則的項目，可以放在訂閱規則之後、最終 MATCH 之前。直接將新規則追加到 MATCH 後方不會生效，因為所有剩餘連線已被 MATCH 攔截。

如果客戶端只支援整體取代列表，就需要在覆寫中保留完整規則順序，或改用 rule-provider，將自訂集合放在主設定中穩定引用。不要依賴「合併工具會自動判斷更具體的規則」；YAML 合併只處理資料結構，不理解分流語意。每次合併後都應開啟最終設定，搜尋自訂規則的位置，並確認只有一個合理的兜底項目。

rules:
  # 本機服務與區域網路規則前置
  - DOMAIN,router.local,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

  # 自訂規則集合
  - RULE-SET,development-services,開發服務

  # 通用區域與兜底規則
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

載入前的語法與引用驗證

語法驗證先確認 YAML 能否解析，再檢查 Clash 欄位是否合法。通用 YAML 工具可以找出縮排、冒號與引號錯誤，卻不了解 proxy-groups 是否引用了不存在的節點。核心的設定測試則能繼續檢查欄位型別、策略引用、provider 定義與規則格式。圖形客戶端通常會在匯入或重新載入時顯示錯誤位置；Linux 命令列部署可使用所安裝核心提供的設定測試參數，實際命令以該核心的說明資訊為準。

看到行號時，不要只檢查該行。YAML 解析器常在「發現結構無法繼續」時回報位置，真正原因可能是前幾行少了引號、縮排或列表連字號。排查方法是從錯誤行往上找到最近的同層欄位，比較縮排；對較長的設定，可以二分註解最近新增的區域，快速判斷錯誤落在哪一段。

# Linux 環境示意：先查看實際安裝的核心參數
mihomo -h

# 常見設定測試形式，路徑依本機目錄調整
mihomo -t -f ./config.yaml

一套可重複的故障定位流程

第一階段確認核心是否啟動。查看設定載入結果、監聽連接埠與控制介面；若在啟動前就失敗，集中處理 YAML、欄位相容性與檔案權限。第二階段確認流量是否進入 Clash：檢查系統代理、應用程式代理、TUN 狀態，以及記錄中是否出現對應請求。沒有請求記錄時，不應先修改節點或規則，因為流量尚未抵達核心。

第三階段確認 DNS 與節點。透過記錄判斷目標網域是否解析、節點伺服器是否可達，以及 TLS 或協定握手在哪個階段失敗。將模式暫時切換至全域並選擇一個確認可用的節點，可以將規則問題與節點問題分開。第四階段檢查策略與規則：記錄命中的規則、目標策略組、組內目前選擇與 provider 狀態。第五階段才處理應用程式特例，例如瀏覽器獨立代理、安全 DNS、QUIC、程序識別與區域網路探索。

安全回退與變更記錄

每次只修改一個功能區域，並保留一份能夠載入的設定。連接埠、DNS、TUN 與規則同時變更時，故障出現後很難確認來源。較穩妥的流程是：複製原始設定，記錄修改目標，完成一組變更，執行語法測試，重新載入後觀察新連線；確認穩定後再進行下一組。設定進入私人版本庫時，提交說明應寫清楚行為變化，例如「區域網路網域改用實際解析」或「開發服務規則前置」，而不是只寫「更新設定」。

回退時不只要恢復 YAML，還要考慮客戶端儲存的策略選擇、Fake-IP 快取、provider 快取與系統代理狀態。若恢復檔案後現象不變，可重新載入設定並建立新連線，必要時重新啟動核心，以排除舊連線仍佔用原策略。不要先清空所有快取與設定；保留現場資訊更有助於判斷究竟是哪一層發生變化。

從手冊回到實際設定

首次建置建議採用小步驟結構：先設定 mixed-port、規則模式與一個可用節點，再建立「節點選擇」策略組，加入基礎直連與 MATCH 規則；確認流量正常後，再啟用 DNS 增強模式、引入 provider 與業務規則集合。如此每一步都有明確的驗證結果，也能避免同時引入訂閱、DNS、TUN 與複雜規則。

需要安裝或更換客戶端時，請從Clash 安裝包頁面依作業系統選擇，桌面與行動平台優先使用 Clash Plus；只想完成訂閱匯入、模式選擇與連線驗證時，請回到Clash 使用教學。遇到連接埠占用、訂閱更新失敗、系統代理未恢復或特定平台權限問題，可在常見問題依故障類別查找。Linux 桌面、命令列與 systemd 服務部署，則可參考Linux 部署 Clash。