Clash YAML
設定檔參考

CHAPTER / 01

YAML 結構總覽與解析順序

先看頂層，再檢查引用關係

一份能載入的 Clash 設定，不代表能正確分流。YAML 解析器會先處理縮排、清單與鍵值型別，核心接著讀取頂層欄位，再解析節點、策略組、規則提供器與規則之間的引用。校對時應依此順序檢查：先確認檔案是合法 YAML，再確認每個被引用的名稱確實存在，最後觀察執行時行為。直接從某條規則開始排查，往往會漏掉更上游的命名或縮排錯誤。

常見的頂層區域包括監聽連接埠、運作模式、日誌等級、控制介面、DNS、代理節點、節點提供器、策略組、規則提供器與規則。欄位順序通常不會改變語意，但依用途穩定排版能大幅降低維護成本。建議將基礎監聽欄位放在頂部，體積較大的節點與提供器放在中段，策略組放在節點之後，最後放規則。如此閱讀時會形成「原料—排版—付印」的自然順序。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1
    - 8.8.8.8

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

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

rules:
  - DOMAIN-SUFFIX,example.com,節點選擇
  - MATCH,DIRECT

上述設定展示了完整的引用鏈：規則將請求交給「節點選擇」，策略組再引用「範例節點」，節點區段提供實際連線參數。任何一處名稱多出空格、全形符號或大小寫不同，都會使引用中斷。中文名稱可以使用，但長期維護時應保持字面完全一致。若名稱含有冒號、井號、逗號或前後空格，最好使用引號，避免解析器將字元理解為 YAML 語法。

縮排、清單與資料型別

YAML 使用空格表示層級，不能將定位字元當作縮排。建議統一使用兩個空格，並讓同一層級的欄位嚴格對齊。以短橫線開頭的是清單項目；短橫線後的節點物件可以繼續包含多個鍵。最常見的故障是把策略組的 proxies 清單縮排到錯誤層級，結果核心將它視為未知欄位，或認為策略組缺少必要項目。

布林值應寫成 true 或 false，連接埠通常寫成不加引號的整數，名稱與位址則視為字串處理。雖然部分解析器會接受 yes、on 等舊式布林寫法，但跨客戶端移轉時容易產生差異，穩定設定應採用明確的標準寫法。數字型密碼、以零開頭的識別碼，以及含特殊字元的文字應加上引號，避免型別被自動推斷。

使用最小化設定定位錯誤

面對數千行的訂閱檔案時，最有效的排錯方式不是反覆修改原檔，而是另存一份最小設定，只保留一個連接埠、一個節點、一個選擇組與兩條規則。最小設定能載入，表示基礎欄位與客戶端環境正常；接著逐段加入 DNS、提供器與自訂規則，就能定位是哪一段引入錯誤。每次只加入一個邏輯區域，重新載入後立即查看日誌，避免多項變更同時加入而無法判斷因果。

CHAPTER / 02

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

監聽連接埠的職責範圍

port 用於 HTTP 代理監聽，socks-port 用於 SOCKS5 代理監聽，mixed-port 則在同一個連接埠同時接收兩類請求。圖形客戶端通常優先使用 mixed-port，因為系統代理與支援 SOCKS5 的應用程式可以共用一個入口。三者不一定要同時啟用；若同時設定，應確保連接埠不重複，也未被瀏覽器除錯工具、本地開發伺服器或其他代理程式佔用。

系統代理設定只是將作業系統的 HTTP 或 SOCKS 請求指向監聽連接埠，不會自動修正設定中的數字。修改 mixed-port 後，還要檢查客戶端的系統代理開關是否讀取了新連接埠。若瀏覽器顯示連線遭拒，而核心日誌沒有任何請求紀錄，通常應先核對系統代理位址與實際監聽連接埠，而不是修改規則。

port: 7891
socks-port: 7892
mixed-port: 7890
redir-port: 7893
tproxy-port: 7894

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

redir-port 與 tproxy-port 主要面向 Linux 閘道器、路由器或透明代理情境。它們需要搭配作業系統轉送規則，單獨寫入 YAML 不會讓流量自動進入核心。桌面使用者通常不需要手動啟用這兩個連接埠；需要接管更多應用程式流量時，更適合在支援的客戶端中設定 TUN 模式。Linux 客戶端與核心入口可在下載頁 Linux 區域核對。

區域網路存取與繫結位址

allow-lan 決定是否接受來自本機以外裝置的連線。設為 false 時，代理主要供目前裝置使用；設為 true 後，還需結合 bind-address、作業系統防火牆與區域網路位址判斷實際可達範圍。啟用區域網路監聽前，應確認家庭或辦公網路的邊界，並避免將控制介面暴露在不受信任的網路中。

bind-address 指定監聽位址。星號表示依核心規則監聽可用介面，實際表現還會受到平台與客戶端實作影響。只需本機使用時，可維持客戶端預設設定；需要讓手機透過電腦代理時，應讓手機與電腦位於同一區域網路，在手機代理設定中填入電腦的區域網路位址與 mixed-port，同時放行對應的防火牆入站規則。

rule、global 與 direct 模式

mode: rule 表示依 rules 由上而下比對，是日常使用最常見的模式。global 會將流量交給全域策略組，適合暫時確認某個節點能否連線，但會繞過原有的分流判斷。direct 則讓流量直接連線，適合確認故障是否由代理路徑造成。排錯時可以短暫切換模式作為對照，得出結論後應恢復規則模式。

切換模式只會改變流量決策入口，不會修復節點參數或 DNS 回應。如果 global 模式也無法連線，應繼續檢查節點、網路與時間設定；如果 global 可用而 rule 不可用，問題更可能位於規則順序、目標策略組或規則提供器。將模式當作診斷開關，比不斷改寫節點欄位更容易得到清楚結論。

日誌與外部控制器

log-level 常用值包括 silent、error、warning、info 與 debug。日常使用保留 info 較便於觀察規則命中；定位複雜問題時可以暫時使用 debug，完成後恢復，避免大量細節淹沒關鍵錯誤。日誌中的「匹配規則—選擇策略—實際節點」是一條完整的校對線索，應沿著三者逐級核對。

external-controller 用於圖形介面與核心通訊，例如監聽在本機回環位址的某個連接埠。客戶端通常會自動管理此欄位，不建議在不了解介面連線方式時任意修改。若面板無法讀取策略組，而代理本身仍能運作，應檢查控制介面位址、連接埠與客戶端設定，而不是先刪除代理節點。

CHAPTER / 03

DNS 欄位、增強模式與解析鏈

DNS 區段處理的不只是單一伺服器位址

Clash 的 DNS 設定負責多項工作：決定向哪些解析器查詢網域名稱、是否接管應用程式發出的 DNS 請求、如何保留網域資訊供規則匹配，以及在建立代理連線前如何解析節點伺服器的網域名稱。只替換一行 nameserver 往往無法解決所有問題，因為代理節點本身的伺服器位址、直連網域與代理網域可能經過不同的解析階段。

dns.enable 控制內建 DNS 模組是否啟用。listen 指定監聽位址與連接埠，圖形客戶端通常會配合 TUN 或系統設定自動管理。ipv6 決定 DNS 模組是否回傳 IPv6 結果，與頂層 ipv6 有關聯但職責不同：前者影響解析結果，後者影響核心整體的 IPv6 使用。網路沒有穩定的 IPv6 路徑時，回傳可用性不明的 AAAA 記錄可能造成連線等待。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query
    - https://dns.google/dns-query
  proxy-server-nameserver:
    - 1.1.1.1
  fake-ip-filter:
    - "*.lan"
    - "localhost.ptlogin2.qq.com"
    - "time.*.com"

default-nameserver 與 nameserver 的分工

nameserver 是主要解析器清單，可以填寫一般 UDP 位址或核心支援的加密 DNS 位址。使用網域形式的加密 DNS 時，核心必須先知道該解析服務網域所對應的 IP，這個啟動階段通常由 default-nameserver 協助完成。因此，default-nameserver 適合填寫可直接存取的 IP 位址，而不是再填寫一個需要先解析的網域，否則會形成循環依賴。

proxy-server-nameserver 用於解析代理節點的伺服器網域。節點位址若寫成網域，核心需要在建立代理連線前取得其 IP；這一步不能依賴尚未建立的代理通道。不同網路環境對解析器的可達性不同，出現「節點全部逾時，但節點伺服器改用 IP 後恢復」的現象時，應重點檢查此欄位與本地網路的 DNS 可達性。

部分 mihomo 設定還會使用 nameserver-policy，依網域將查詢交給指定解析器。它適合處理不同網路對同一網域回傳不同結果的情境，但策略本身也要保持清楚。若寫入大量重複的網域策略，會讓 DNS 層與規則層同時承擔分流，排錯時很難判斷結果來自哪一側。通常應先讓 DNS 解析穩定，再用規則控制流量去向。

fake-ip 與 redir-host

fake-ip 會向應用程式回傳保留位址池中的對映位址，核心據此保留網域關聯，方便執行網域規則與嗅探後的流量決策。它不代表目標網站實際使用該位址。應用程式連線至假位址時，核心會查回對映並建立實際連線。此模式通常適合現代桌面與行動客戶端，也能減少先解析後匹配造成的資訊遺失。

redir-host 更接近傳統解析流程，應用程式取得真實解析結果後發起連線。某些依賴本地網路設備、區域網路探索或特殊 DNS 行為的程式，在此模式下更容易相容，但核心取得的網域上下文可能少於 fake-ip。兩種模式沒有脫離情境的絕對優先順序；應依客戶端預設值、TUN 實作與應用程式相容性選擇，而不是在不同設定片段間頻繁混用。

fake-ip-filter 用於排除不適合回傳假位址的網域。區域網路裝置、時間同步，以及部分登入與連線檢測網域可能需要真實結果。過濾規則不宜無限制擴張：若將大量一般網域加入過濾表，會削弱 fake-ip 的網域對映優勢。每增加一項都應記錄對應的故障現象，並在應用程式更新或網路變化後重新驗證。

CHAPTER / 04

代理節點欄位與連線參數

所有節點都從四項基礎資訊開始

proxies 是本地節點清單，每個清單項目至少需要名稱、類型、伺服器位址與連接埠，接著再依協定補充驗證、傳輸與 TLS 欄位。節點名稱是設定內部的引用識別碼，策略組透過名稱找到節點；伺服器位址決定實際連線目標；連接埠是遠端服務的監聽連接埠，與本機 mixed-port 完全不同。混淆這兩類連接埠，是手動抄錄設定時最常見的錯誤之一。

節點參數必須與伺服器端設定成組對應。協定類型、加密方式、驗證內容、傳輸層、主機名稱與路徑中任一項不一致，都可能表現為逾時或握手失敗。不能靠反覆更換策略組來修復節點本身的參數錯誤。校對時應從協定基礎欄位開始，逐層加入 TLS、WebSocket 或其他傳輸選項，每次觀察日誌中的失敗階段。

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

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

範例中的位址與驗證文字用於展示結構，實際使用時應由合法的服務設定提供。udp 表示節點是否允許承載 UDP 流量，還會受到協定實作、伺服器端與網路路徑共同影響。即使欄位設為 true，伺服器端沒有相應能力時也不會得到可用的 UDP 轉送。遊戲、語音與部分 DNS 流量出現異常時，應分別確認節點能力與策略組是否選用了該節點。

TLS、SNI 與憑證檢查

使用 TLS 的協定通常需要正確的伺服器名稱。sni 用於握手時傳送目標主機名稱，不一定與連線使用的 server 欄位相同，但必須符合伺服器端憑證與部署方式。日誌出現憑證名稱不符時，應核對服務提供者提供的 SNI，而不是先關閉憑證檢查。

skip-cert-verify 控制是否跳過憑證驗證。穩定設定應優先保持 false，並修正裝置時間、憑證鏈、SNI 或網路攔截問題。裝置時間偏差會導致尚未生效或已過期的判斷出錯；系統根憑證環境異常也可能影響連線。將此欄位改為 true 只能作為短時間的對照測試，不能取代對根本原因的確認。

傳輸層欄位必須視為一個物件閱讀

WebSocket 等傳輸方式通常會帶有路徑與請求標頭。路徑中的斜線、大小寫與編碼需要與伺服器端一致，Host 請求標頭也可能參與反向代理路由。縮排錯誤會讓 ws-opts 下的欄位脫離節點物件，導致核心忽略設定。遇到「TCP 已連線但隨後中斷」的現象時，應沿著 TLS 握手、HTTP 升級與應用程式協定三個階段閱讀日誌。

  - name: "WS 範例"
    type: vmess
    server: edge.example.net
    port: 443
    uuid: "00000000-0000-4000-8000-000000000000"
    alterId: 0
    cipher: auto
    tls: true
    servername: service.example.net
    network: ws
    ws-opts:
      path: /gateway
      headers:
        Host: service.example.net

不同核心與協定會使用 sni、servername 等不同欄位名稱，不能只因語意相近就互換。移轉至 mihomo 核心前，應對照目前客戶端的支援範圍核對欄位。關於核心關係與相容性界線，可繼續閱讀mihomo 核心與原版 Clash 的差異。

節點名稱、重複項目與健康檢查

節點名稱應保持唯一。兩個節點使用相同名稱時，策略組的引用可能指向非預期物件，客戶端介面也難以區分。訂閱提供器中的重複名稱還可能在更新後再次出現，適合在覆寫階段加入前綴、後綴或篩選規則。名稱應表達地區、線路或用途，不建議將即時延遲寫入名稱，因為更新後容易失真。

節點出現在清單中，只表示 YAML 已被讀取，不代表連線可用。應使用客戶端提供的連線測試，接著透過實際網頁存取或目標應用程式驗證。測試位址、DNS、節點協定與目標網站可能走不同路徑，因此單一測試結果不能涵蓋所有情境。若所有節點同時失敗，應優先排查本地網路、DNS 與系統時間；只有單一節點失敗時，再集中核對該節點欄位。

CHAPTER / 05

策略組類型、引用與選擇邏輯

策略組是節點與規則之間的排版台

proxy-groups 不負責建立新的協定連線，而是將既有節點或其他策略組整理成可選擇、可測試或可故障轉移的邏輯單位。規則的最後一欄通常指向策略組，再由策略組決定使用哪個節點。將「用途」寫入策略組名稱，例如「節點選擇」「串流媒體」「直連服務」，比把協定名稱堆在組名中更便於閱讀。

策略組可以引用節點，也可以引用先前定義的其他策略組。多層引用適合將地區選擇與業務分流分開，但層級過深會增加定位難度。建議維持兩到三層：底層是實際節點或提供器，中層是地區或測試組，上層是業務策略。發生錯誤時，沿著規則目標逐層展開，直到找到最終節點。

proxy-groups:
  - name: "自動選擇"
    type: url-test
    proxies:
      - "節點 A"
      - "節點 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300
    tolerance: 80

  - name: "節點選擇"
    type: select
    proxies:
      - "自動選擇"
      - "節點 A"
      - "節點 B"
      - DIRECT

  - name: "故障轉移"
    type: fallback
    proxies:
      - "節點 A"
      - "節點 B"
    url: "https://www.gstatic.com/generate_204"
    interval: 300

select、url-test 與 fallback 的差異

select 由使用者手動選擇一個成員，結果穩定且容易解釋，適合作為頂層入口。若客戶端會保存選擇狀態，重新載入設定後通常會恢復上次的選擇，但名稱變更或組別重建時可能回到預設項目。將最希望採用的預設成員放在清單前面，可以降低設定首次載入時走上意外路徑的機率。

url-test 定期存取測試位址，根據測得結果自動選擇成員。它反映的是節點到測試目標的連線能力與回應情況，不等同於所有網站的實際速度。interval 控制測試間隔，設定過短會增加背景請求；tolerance 用於減少結果接近時的頻繁切換。自動組適合日常選擇，但關鍵業務仍應觀察實際存取表現。

fallback 依序使用可用成員，目前成員失效時轉向下一個，更重視穩定性而非最低回應時間。因此清單順序具有實際意義，應將優先線路放在前面。若測試位址在目前網路無法存取，所有節點可能被誤判為不可用，因此測試目標必須穩定、回傳內容簡短，且符合節點可存取的網路範圍。

load-balance 與流量連續性

load-balance 會在多個成員之間分配連線，具體策略取決於核心支援與組內參數。它不是將單一下載工作簡單疊加到多個節點，也不能保證每個請求都隨機切換。登入狀態、來源位址敏感的服務可能不適合跨節點分配，因為同一工作階段出現不同出口時，可能觸發重新驗證或連線中斷。

選擇負載平衡前，應先確認業務是否允許出口變動。網頁瀏覽與多連線下載可能因此受益，但遠端管理、付款登入與長連線更需要路徑穩定。策略組設計應從業務限制出發，而不是只按功能數量堆疊。沒有明確需求時，select 搭配一個 url-test 組通常已足夠清楚。

使用 use 引入提供器節點

當節點來自 proxy-providers 時，策略組可用 use 引用整個提供器，不必將每個節點名稱寫入 proxies。訂閱更新後新增或刪除的節點會隨提供器進入組內，更適合長期維護。proxies 與 use 可以依核心能力組合使用，但應注意最終成員是否包含重複節點。

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: 600
    tolerance: 100

策略組為空時，引用它的規則無法取得有效節點。常見原因包括提供器下載失敗、篩選表達式排除了所有節點、提供器名稱拼寫不同，或組別引用了尚不存在的本地節點。客戶端介面出現空組時，應先查看提供器狀態與原始節點數量，再檢查篩選條件，而不是立即修改規則。

CHAPTER / 06

規則語法、順序與匹配邊界

規則由上而下，只採用第一次命中

rules 是有順序的清單。請求進入規則模式後，核心從第一條開始檢查，命中後立即將流量交給指定策略，不再繼續向下尋找更具體的規則。因此，精確範圍應放在寬泛範圍之前，例外項目應放在會覆蓋它的通用項目之前，兜底規則必須位於末尾。規則內容相同但順序不同，最終行為可能完全相反。

每條規則通常由規則類型、匹配內容與目標策略組成，以英文逗號分隔。目標可以是策略組，也可以是 DIRECT、REJECT 等內建動作。中文逗號看似相近，但不會被視為欄位分隔符。複製規則後應檢查標點、前後空格與目標名稱，尤其注意從排版文件複製時可能混入全形字元。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,節點選擇
  - DOMAIN-KEYWORD,example,節點選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - PROCESS-NAME,example.exe,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

網域規則的精確度差異

DOMAIN 只匹配完整網域，適合對單一主機進行例外處理。DOMAIN-SUFFIX 匹配指定網域及其子網域，適合涵蓋完整網站體系。DOMAIN-KEYWORD 只要網域包含指定文字就可能命中，範圍更廣，也更容易誤傷名稱相似但無關的網域。設定應優先使用精確網域與後綴，只有在目標網域變化頻繁且規律明確時，才使用關鍵字。

例如先寫 DOMAIN,internal.example.com,DIRECT，再寫 DOMAIN-SUFFIX,example.com,節點選擇，才能讓內部主機維持直連。若後綴規則位於前面，精確規則永遠沒有執行機會。定位網域誤分流時，應在日誌中找到實際請求網域，然後從規則頂端搜尋第一條可能命中的規則，而不是只查看預期規則是否存在。

IP-CIDR 與 no-resolve

IP-CIDR 使用網段匹配目標 IPv4 位址，IPv6 則使用對應的 IPv6 規則類型。CIDR 後綴表示網路前綴長度，範圍寫得過寬會涵蓋大量位址。區域網路網段通常應在代理規則之前直連，以免存取路由器、印表機或儲存裝置時被送往遠端節點。

no-resolve 表示匹配該 IP 規則時，不要為只有網域的請求額外觸發解析。它適合只需檢查現有目標 IP 的規則，可以減少不必要的 DNS 查詢。是否加入此參數取決於規則目的：若規則必須透過解析網域才能取得目標 IP，就不能機械式加入。理解解析時機比照抄參數更重要。

程序規則與平台差異

PROCESS-NAME、PROCESS-PATH 等程序規則依賴作業系統權限、核心能力與客戶端接管方式。Windows、macOS、Linux 與 Android 取得程序資訊的條件不同；某個平台能命中，不代表另一個平台也會得到相同結果。TUN 模式下是否能辨識程序，也與客戶端實作和權限設定有關。

程序規則失效時，應先在除錯日誌中確認核心看見的程序名稱或路徑，再依實際值編寫規則。可執行檔更新後路徑可能變更，大小寫與副檔名也要依平台核對。對跨平台共用的設定而言，網域規則通常比程序路徑更容易保持一致；程序規則適合作為平台專屬覆寫，而不是直接塞進所有裝置共用的訂閱內容。

GEOIP、規則集與兜底

GEOIP 根據目標 IP 所屬資料庫區域進行匹配，結果會受到資料庫內容與更新時間影響。它適合作為較後位置的區域級判斷，不適合取代明確的網域規則。網域解析得到的位址可能因網路與 CDN 調度而變化，同一服務也可能分布在多個區域，因此關鍵業務應使用更明確的規則集或網域規則。

MATCH 匹配先前未命中的所有請求，只能放在末尾。若位於中段，下面的規則都會失效。兜底選擇直連還是代理，應依設定目標決定：重視依清單代理時，可以讓未分類流量直連；重視預設代理時，可以交給總選擇組。無論採用哪種策略，都應讓組名清楚表達後果。

rules:
  # 本地與明確例外
  - DOMAIN,printer.lan,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

  # 業務規則
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,proxy-domain,節點選擇
  - RULE-SET,private-ip,DIRECT

  # 區域判斷與最終兜底
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

完整排查自訂規則時，可以搭配閱讀Clash 自訂規則語法詳解。修改後不要只看設定是否成功載入，還應選擇幾個能代表精確網域、子網域、IP 與兜底情況的目標，逐項確認日誌中的命中規則與最終策略。

CHAPTER / 07

節點提供器、規則提供器與訂閱更新

proxy-providers 管理可更新的節點來源

proxy-providers 將遠端或本地節點集合從主設定中分離出來。主設定負責策略結構，提供器負責節點內容，兩者的更新節奏可以不同。如此訂閱更新時不必重寫整份規則，也方便多個策略組共用同一批節點。客戶端支援提供器時，優先採用這種分層結構，比將大量節點直接展開到 proxies 更容易維護。

每個提供器需要唯一名稱、類型、來源位址、快取路徑與更新間隔。遠端類型通常透過 HTTP 取得 YAML，path 指定本地快取位置。不同客戶端對相對路徑根目錄的處理可能不同，移轉設定後若出現無法建立檔案或快取不更新，應檢查客戶端工作目錄與檔案權限。

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

提供器的健康檢查會定期測試其中的節點，但它與策略組的 url-test 並非同一層次。前者維護節點可用狀態，後者在組內執行選擇。兩者的間隔都設得過短會產生重複請求，應依節點變化頻率與實際使用需求安排。訂閱位址失效時，客戶端可能繼續使用本地快取，因此「目前仍能連線」不能證明遠端更新正常。

rule-providers 管理成組規則

rule-providers 將大量網域或網段規則放在獨立檔案中，主設定只透過 RULE-SET 引用。常見的 behavior 包括 domain、ipcidr 與 classical。其中 domain 規則集用於網域類匹配，ipcidr 用於網段，classical 可以容納帶規則類型的傳統項目。提供器內容格式必須與 behavior 相符，否則即使檔案下載成功也可能無法解析。

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

  private-ip:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./rules/private-ip.yaml
    url: "https://example.com/rules/private-ip.yaml"
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,private-ip,DIRECT,no-resolve
  - MATCH,節點選擇

domain 行為的檔案通常只放網域內容，不應再寫入目標策略；策略應在主設定的 RULE-SET 行中指定。classical 格式則可能包含 DOMAIN-SUFFIX 等完整規則前綴。混淆這兩種格式會造成「規則集已下載但沒有命中」的假象。校對時應同時查看提供器狀態、解析項目數量與主規則中的引用名稱。

訂閱更新與本地設定的界線

Profile 通常包含遠端訂閱與本地設定兩類。遠端訂閱適合接收節點變化，本地設定適合保存裝置專屬的連接埠、DNS 與規則。直接編輯訂閱產生的檔案，下一次更新時可能遺失修改；將所有節點複製到本地檔案，又會失去自動更新能力。更穩妥的做法是保留訂閱作為原料，透過客戶端覆寫或獨立主設定組織策略。

管理多份設定時，應為每份 Profile 標明用途，例如「桌面日常」「行動網路」「規則實驗」，避免只用匯入日期命名。切換設定後要確認目前啟用項目、系統代理狀態與策略選擇，因為客戶端可能為不同 Profile 分別儲存狀態。具體的匯入、切換與整理方法請見Clash Profile 設定檔基礎。

更新失敗的分層排查

提供器更新失敗時，先區分網路錯誤、HTTP 狀態錯誤、檔案格式錯誤與快取寫入錯誤。網路錯誤表示無法建立連線；HTTP 錯誤表示遠端回傳了非預期狀態；格式錯誤通常發生在下載完成後的解析階段；快取錯誤則與路徑和權限有關。日誌中的階段資訊比反覆點擊更新更有價值。

若遠端位址需要透過代理存取，還要確認核心更新提供器時採用的網路路徑。首次啟動時策略尚未完整可用，過度依賴代理才能取得核心設定，可能形成啟動閉環。應保留能直接初始化的基礎設定，並確保提供器失敗時仍有清楚日誌與可用的本地快取。

CHAPTER / 08

覆寫、合併與最終設定校對

真正生效的是合併後的結果

許多圖形客戶端允許在遠端訂閱之上套用覆寫、腳本或合併設定。使用者編輯的片段只是其中一項輸入，核心最終讀取的是客戶端處理後的成品。排查時若只看原始訂閱或覆寫檔案，而沒有查看最終設定，就可能誤判欄位已經生效。客戶端能匯出執行設定時，應優先檢查匯出結果，並與預期逐段對照。

合併通常涉及替換、追加與刪除三類動作。純量欄位如 mixed-port 通常採用後值覆蓋前值；映射物件如 dns 可能依鍵合併，也可能整體替換；清單如 rules 與 proxy-groups 的行為差異最大，有些客戶端會追加，有些依名稱處理，有些直接覆蓋。不能假設所有客戶端使用相同演算法，移轉設定時必須先進行小規模測試。

# base.yaml
mode: rule
dns:
  enable: true
  enhanced-mode: fake-ip
  nameserver:
    - 1.1.1.1

rules:
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

# override.yaml
dns:
  ipv6: false

rules:
  - DOMAIN,internal.example.com,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

如果客戶端對 dns 進行深度合併，最終結果可能同時保留 enable、enhanced-mode、nameserver 與新增的 ipv6。若採用整段替換，最終 DNS 區段可能只剩 ipv6，設定自然無法依預期運作。對於規則清單，追加到末尾的精確例外可能被原有 GEOIP 或 MATCH 提前攔截，因此需要明確選擇前置插入或完整重新排序。

依名稱合併策略組的風險

部分覆寫工具會將同名策略組視為同一個物件，再合併其中的成員。這樣可以向現有的「節點選擇」加入本地組，也可能造成重複成員或保留不需要的舊欄位。另一類工具會用新物件完全替換舊組，若覆寫片段沒有寫完整 type、proxies 或 use，最終組別就會殘缺。

處理策略組時，覆寫片段最好明確說明目標：是完整替換組別，還是只增加成員。無法確認客戶端語意時，可使用新的組名，先驗證規則能否正確引用，再決定是否接管原組。名稱變更也會影響客戶端儲存的手動選擇，更新後若選擇突然恢復預設，應檢查組名是否在合併過程中被改變。

規則覆寫應保留順序意圖

本地規則通常用於加入裝置專屬直連、程序規則或業務例外。它們需要位於訂閱的寬泛規則之前，因此簡單追加通常無效。穩定的做法是將規則分為「本地例外、遠端規則集、區域判斷、最終兜底」四段，在最終設定中確保順序固定。若客戶端提供規則前置與後置兩個入口，應將例外放前置，額外兜底放後置，但全域只能保留一個真正的最終 MATCH。

規則去重不能只比較整行文字。兩條規則可能匹配重疊範圍但目標不同，例如精確網域直連與後綴代理必須同時保留，並透過順序表達例外。自動去重腳本若只保留後出現的項目，可能改變原意。每次調整規則產生邏輯後，都應選取代表性網域讀取日誌，而不是只比較檔案行數。

從解析錯誤到執行錯誤的檢查清單

第一層是 YAML 語法：檢查縮排、冒號、短橫線、引號與資料型別。第二層是結構引用：檢查策略組、節點、代理提供器與規則提供器名稱。第三層是資源載入：確認遠端檔案下載成功、快取可寫，且格式與 behavior 一致。第四層是執行環境：確認連接埠未被佔用、權限符合要求，系統代理或 TUN 已指向目前核心。第五層才是請求決策：查看 DNS 結果、規則命中、策略組選擇與最終節點。

這種分層能避免用下游變更掩蓋上游錯誤。例如連接埠衝突時，修改 DNS 不會有幫助；策略組為空時，增加更多規則只會將更多流量送進空組；節點 TLS 參數錯誤時，切換為 global 模式仍會失敗。每次只擷取與目前層級相關的日誌資訊，確認通過後再進入下一層，故障範圍會逐步縮小。

建立可回復的修改流程

每次修改前保留上一份可正常運作的設定，並記錄本次只要解決的問題。檔名可以包含用途與修訂序號，但不要在多個目錄中保存名稱相同、內容不同的副本。修改後先進行語法載入，再測試一個直連目標、一個代理目標、一個區域網路目標，以及一個需要特殊規則的目標。四類樣本涵蓋大多數設定鏈路。

如果客戶端更新後出現行為差異，應先比較最終設定與核心日誌，不要立即認定訂閱內容發生變化。客戶端可能調整預設 DNS、TUN 堆疊、合併語意或設定目錄。將關鍵欄位明確寫入本地覆寫，並記錄其用途，可以降低預設值變化帶來的不確定性；但也要定期刪除已失去情境依據的舊例外。

完成設定校對後，建議回到使用教學中的連線驗證步驟，從系統代理、策略選擇到網頁存取走完一次完整流程。需要更換圖形客戶端時，下載頁列出的 Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等客戶端對 YAML 的支援範圍並不完全相同，移轉前應先確認目前設定依賴的核心欄位；桌面與行動平台的首選入口可在Clash 下載中心查閱。

一份可靠的 Clash YAML 不是欄位越多越好，而是每個欄位都有明確用途，每條引用都能追溯，每次更新都能得到可解釋的最終結果。依照結構、通用欄位、DNS、節點、策略組、規則、提供器與覆寫的順序檢查，就像從字粒到版面逐層校對：先確保字元正確，再確保組合正確，最後確認實際付印結果與預期一致。