Clash YAML 設定檔參考

1. YAML 結構與設定載入範圍

設定檔首先是一份具有型別與階層的資料，而不是一組逐行執行的指令。頂層的 mixed-port 用來設定監聽連接埠，dns 是映射，proxies、proxy-groups 與 rules 通常是清單。核心會先解析資料，再建立監聽器、解析代理與策略組，最後才接收連線。因此，欄位在檔案中的排列順序不等於啟動順序；不過，規則清單內的順序會影響比對結果。

縮排、型別與名稱引用

統一使用兩個空格縮排，不要使用定位字元。同一父層的欄位必須對齊；清單項目前的連字號代表新項目，不是裝飾符號。若把 enable 寫在與 dns 相同的層級，欄位所屬位置就會改變；若把 rules 縮排到策略組底下，也不會成為預期的頂層規則。使用編輯器的縮排參考線，比只看文字是否整齊可靠。

布林值寫成 true 或 false，連接埠與時間間隔通常使用整數。節點名稱、密碼及含特殊符號的內容，建議加上引號，尤其是包含冒號後接空格、井字號或前導零的字串。引號無法修正錯誤縮排，也不會將清單自動轉成映射；發生錯誤時，應先確認結構，再檢查值的型別。

代理與策略組會透過名稱互相引用。名稱中的空格、大小寫和中文標點都是實際內容，"手動選擇" 與 "手動 選擇" 是兩個不同的名稱。新增規則前，先確認目標名稱存在；刪除節點前，先搜尋仍引用該節點的策略組。也應清除重複名稱，否則介面顯示可能難以對應實際解析結果。

建立可啟動的本機基準設定

以下設定只建立本機混合代理入口，所有請求最後都會直連。這份設定適合確認檔案路徑、連接埠監聽和規則解析是否正常，不具備遠端代理功能。測試時，讓瀏覽器使用本機混合連接埠，或暫時啟用用戶端的系統代理；不要把「核心成功啟動」誤認為「已連上遠端節點」。

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

proxies: []

proxy-groups:
  - name: "手動選擇"
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選擇

先保留一份已驗證的基準設定，再逐步加入實際節點、自動測試組與 DNS。每完成一類修改，就重新載入並檢查記錄，將故障範圍限縮在最近一次變更。若一次替換整份設定，語法、網路、引用與用戶端覆寫問題可能同時出現，排查成本也會大幅增加。

YAML 映射中不要重複定義相同的鍵。例如檔案前後各出現一次 dns，不代表兩個區塊會自動合併。不同解析器可能拒絕重複鍵，也可能只保留後一個值；依賴這種行為，會讓同一份檔案在不同用戶端產生不同結果。需要合併時，應在產生設定的階段確保頂層欄位唯一。

區分來源檔案與執行檔案

訂閱下載的原始文字、使用者編輯的設定，以及用戶端產生的執行設定，可能是三份不同的檔案。用戶端通常會在啟動前加入管理介面或替換連接埠，因此手動編輯執行目錄中的檔案，下一次更新時可能就會被覆蓋。建議優先使用用戶端提供的本機設定、擴充設定或覆寫入口，並確認該入口的作用範圍。

設定錯誤訊息中的行號指向核心實際讀取的檔案，不一定對應訂閱原文。遇到引用缺漏或欄位不符時，先在用戶端確認目前啟用的設定名稱與執行設定內容。分享排錯資料前，請移除訂閱網址、節點密碼和控制介面金鑰；只保留重現問題所需的結構，不要直接公開完整的執行檔案。

2. 通用欄位、監聽連接埠與執行模式

通用欄位決定流量從哪裡進入核心，以及核心採用哪種處理方式。它們不會建立遠端節點，也不會自動修改所有應用程式的網路設定。排查時，先區分「核心正在監聽」、「系統代理已設定」和「應用程式會使用系統代理」這三種狀態，避免把入口問題誤判為節點故障。圖形化用戶端中的開關可能與 YAML 欄位相關，但兩者所屬層級不同。

選擇連接埠與監聽範圍

混合連接埠適合讓多個應用程式共用同一入口；使用獨立連接埠則方便區分 HTTP 與 SOCKS 的連線行為。沒有實際需求時，不必啟用所有入口。兩個監聽器不能在相同位址上使用同一連接埠；連接埠衝突也可能來自其他代理軟體、舊的核心程序，或尚未退出的用戶端背景服務，不一定是目前設定有誤。

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

在本機使用時，建議優先限制為迴路位址。確實需要讓手機或其他電腦透過目前裝置轉送流量時，再設定區域網路監聽，並依網路範圍設定防火牆與存取驗證。只把 allow-lan 設為 true，不代表其他裝置一定能連線；只開放防火牆，也無法讓綁定在迴路位址的服務接受外部請求。

規則、全域與直連模式

mode: rule 會依照 rules 從上往下比對，適合日常分流。global 會使用全域策略選擇出站方式，不依一般規則清單決定目標；direct 則用於直連。在介面切換模式後，原始檔案中的 mode 不一定會同步變更，因為用戶端可能透過控制介面修改執行狀態。請以目前介面狀態和連線記錄為準。

全域模式無法修復未經過核心的流量。如果某個應用程式略過系統代理，在規則模式下沒有連線記錄，切換全域模式後通常也不會出現記錄。應先檢查應用程式本身的代理設定，或在確有需要時使用 TUN。反之，若連線已進入核心卻比對到直連規則，才需要進一步分析模式與規則順序。

log-level 會影響記錄的詳細程度，不會改變分流邏輯。日常使用可維持 info；重現疑難問題時，暫時改用 debug，完成後再還原。詳細記錄可能包含網域、目標位址與存取時間，保存或分享時應限制範圍。看到一筆逾時記錄，不能直接認定所有流量都失敗；應確認它對應的是節點交握、DNS 還是健康檢查。

控制介面與持續儲存狀態

external-controller 是控制介面，不是應填入瀏覽器的代理連接埠。它通常用於讀取連線、切換策略組或更新執行設定。若把應用程式的代理位址填成控制介面，會造成協定不符。手動執行核心時，可依需求啟用；圖形化用戶端通常會自行產生並管理相關參數，不建議再透過覆寫強行佔用相同位址。

若要啟用控制介面，建議綁定迴路位址並設定獨立金鑰，不要直接暴露在公開網路上。範例中的金鑰僅用來說明結構，實際使用時請自行產生。若用戶端已有存取憑證管理功能，應使用用戶端提供的入口，不要將範例值長期存放在公開的設定檔儲存庫中。

external-controller: "127.0.0.1:9090"
secret: "replace-with-a-local-random-secret"

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

store-selected 用於保留策略組選擇，store-fake-ip 用於保留假 IP 對應狀態。持續儲存不能取代設定本身：策略組更名後，舊名稱的選擇記錄未必還能套用。修改模式、連接埠與儲存選項後，應分別驗證入口、路由與重新啟動行為；不能只憑介面開關的位置，判斷所有設定都已生效。

3. 代理節點欄位與節點提供者

代理節點定義一項具體的遠端連線能力，策略組則負責從中選擇。節點名稱只是引用標籤；協定、伺服器、連接埠和驗證參數才決定能否建立連線。修改名稱不會改變節點位置，也不會降低網路延遲。來自不同服務的同名節點，應先重新命名再加入同一份設定，避免策略組引用時產生歧義。

依協定填寫必要欄位

proxies 中的每個項目都是一個代理物件，至少要有目前協定可識別的類型與連線參數。不要機械式地複製其他協定的欄位：Shadowsocks 的加密方法、Trojan 的密碼，以及其他協定的使用者識別資訊，作用各不相同。設定成功解析，只代表格式正確，不代表遠端服務會接受這些參數。

proxies:
  - name: "範例 SS"
    type: ss
    server: "proxy.example.com"
    port: 8388
    cipher: chacha20-ietf-poly1305
    password: "your-password"
    udp: true

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

server 是實際連線的伺服器位址，port 是遠端服務的連接埠，不要填入本機混合連接埠。若伺服器使用網域名稱，節點連線前必須先完成解析，這也是 DNS 設定可能影響所有代理的原因。若伺服器改用 IP，而協定需要 TLS，仍應保留服務端要求的正確網域參數，不要混淆連線位址與身分驗證。

udp: true 表示該節點設定允許相應的 UDP 轉送能力，不代表整條連線路徑支援所有 UDP 應用程式。還要檢查協定實作、伺服器設定、網路限制與應用程式的連線方式。若瀏覽正常但語音通訊失敗，應先確認實際使用的傳輸類型，不能只依網頁載入速度推斷 UDP 是否可用。

TLS 身分與傳輸參數

TLS 連線中，伺服器位址與 sni 可以負責不同事項：前者決定連線目標，後者則在交握時宣告目標名稱。憑證驗證還要求名稱、有效期限與信任鏈都符合條件。遇到憑證錯誤時，先檢查裝置時間、節點網域、伺服器憑證，以及網路是否遭到重新導向；不要把停用驗證當成一般修復方式。

skip-cert-verify: false 會保留正常驗證。設為 true 會改變連線的信任邊界，無法解決伺服器無法連線、密碼錯誤或協定不符等問題。若服務設定使用 WebSocket、gRPC 等傳輸方式，還必須與伺服器的路徑、主機名稱或服務名稱一致；只有伺服器位址和連接埠，無法推導出這些參數。

節點欄位是否可用，取決於核心支援範圍。原版 Clash、不同分支與 mihomo 對協定和擴充欄位的支援並不完全相同。匯入時若出現不支援的代理類型，應檢查用戶端實際使用的核心，而不是反覆調整縮排。如需了解核心與介面的分工，請參閱Clash、mihomo 與用戶端關係圖。

使用 proxy-providers 管理外部節點

節點提供者會將外部節點清單作為獨立資源載入，適合讓策略組引用持續更新的節點集合。它不是能匯入任意訂閱格式的通用工具；遠端內容必須符合核心支援的節點提供者格式，常見結構以 proxies: 為根節點。用戶端能匯入的完整訂閱，不一定能直接當作提供者網址使用。

proxy-providers:
  remote-nodes:
    type: http
    url: "https://config.example.com/proxies.yaml"
    path: ./providers/remote-nodes.yaml
    interval: 3600
    health-check:
      enable: true
      url: "https://www.example.com/"
      interval: 600

proxy-groups:
  - name: "訂閱選擇"
    type: select
    use:
      - remote-nodes
    proxies:
      - DIRECT

此處的 interval 控制資源更新頻率，單位為秒；健康檢查中的同名欄位則控制檢測頻率，兩者用途不同。path 用於本機快取，手動執行時需確認工作目錄與寫入權限；不同提供者不要共用同一個快取路徑。遠端更新失敗時，也要區分首次載入且沒有快取，與已有快取仍可繼續使用的情況。

提供者網址通常包含存取憑證，不應出現在截圖或公開儲存庫中。排查時可保留網域並移除路徑中的敏感內容，同時檢查更新記錄、回傳格式與節點數量變化。節點已更新但策略組沒有顯示新名稱時，接著檢查組內的 use、篩選條件與目前啟用的設定；不要只是不斷按下更新按鈕。

4. 策略組類型、測試與選擇狀態

策略組是規則與節點之間的穩定介面。規則可以固定指向「業務出口」，再依需求替換組內節點，這比在每條規則中寫死節點名稱更容易維護。策略組本身不提供遠端服務，最後仍須選擇節點、其他策略組或內建出站。策略組名稱應表達用途，節點名稱則代表連線對象，兩者分開後更容易閱讀連線記錄。

手動選擇與自動測試

select 保留人工決策，適合依業務、網路或地區手動選擇。組內順序會影響清單顯示，但啟用選擇持續儲存後，啟動時不一定會回到第一個項目。url-test 會依指定測試網址的結果選擇候選項，適合在一組相近節點中自動調整。自動測試結果取決於測試目標，不能代表所有網站都有相同表現。

proxy-groups:
  - name: "業務出口"
    type: select
    proxies:
      - "自動選擇"
      - "範例 SS"
      - DIRECT

  - name: "自動選擇"
    type: url-test
    proxies:
      - "範例 SS"
      - "範例 Trojan"
    url: "https://www.example.com/"
    interval: 300
    tolerance: 80
    lazy: true

這段設定依賴上一章中名稱相同的節點，單獨複製會缺少引用。interval 是測試間隔，tolerance 是切換容差，兩者不能混用。設定適當的容差，可減少測試結果些微波動時頻繁切換；但它無法保證工作階段不中斷，也不能讓已故障的節點恢復正常傳輸。數值應依節點數量、網路穩定度與測試成本調整。

lazy: true 允許策略組在未實際使用時減少不必要的檢測，因此剛啟動時沒有完整測試結果，不一定代表異常。手動觸發檢測仍失敗時，應確認測試網址可連線、憑證正常，以及節點能否完成請求。測試流量也會經過節點；間隔過短會增加裝置、網路與伺服器的負擔。

故障轉移與負載平衡

fallback 著重於優先順序：通常依候選項順序選擇可用項目，適合設定主要與備援出口。這與追求較低測試延遲的 url-test 不同。若第一個項目長期可用，後續節點可能很少承載流量；這是優先順序策略的正常結果，不代表節點未正確加入策略組。

load-balance 用來在多個候選項之間分配連線，並不會將多個節點的頻寬簡單相加，提供單一下載使用。不同分配策略會影響連往同一目標時的出口穩定度。需要固定登入地區或維持伺服器工作階段的業務，應先評估出口變動的影響；不要只因組內節點多，就認定負載平衡一定比手動選擇合適。

既有連線通常不會因策略組切換而自動轉移到新節點。瀏覽器長連線、串流工作階段或背景通訊可能繼續使用舊出口，只有新建連線才會反映新的選擇。驗證策略組切換時，可關閉相關連線或重新發送請求，但請留意這會中斷正在傳輸的工作。把舊連線沒有變化誤判為設定未載入，是常見的排錯偏差。

提供者引用、篩選與循環依賴

策略組中的 proxies 可引用明確列出的名稱，use 則引用節點提供者。可依需求搭配使用，以保留直連選項或固定節點，同時載入動態節點集合。通常透過 filter 等欄位篩選候選名稱；正規表示式應加上引號，並先確認篩選後至少還有一個預期候選項。

proxy-groups:
  - name: "遠端出口"
    type: select
    use:
      - remote-nodes
    filter: "(?i)office|backup"
    proxies:
      - DIRECT

提供者中的名稱變更會影響篩選結果。若節點清單突然減少，先檢查更新後的原始名稱與正規表示式，再檢查網路。不要為了掩蓋命名問題而放寬條件、匹配所有節點，否則可能把不適用於該業務的出口納入策略組。修改複雜篩選前，先用不含篩選的小型設定確認提供者確實載入成功。

策略組可以引用其他策略組，但不能形成循環，例如甲引用乙、乙又引用甲。分層結構應有明確終點，最後必須落到實際節點或內建出站。自動組再巢狀其他自動組也會增加理解難度；連線失敗時，應逐層確認目前選擇，而不是只看最外層組名。想了解測試數值與實際體驗的差異，可接著閱讀Clash 延遲測試原理。

5. 規則語法、比對順序與規則提供者

規則模式會由上往下比對，第一條符合的規則決定連線交給哪個出站。後續規則通常不會再參與同一連線的目標選擇。因此，規則是否存在不如排列位置重要。將明確的例外放在前面、涵蓋範圍較大的規則放在後面，最後以 MATCH 明確處理其餘流量，連線記錄中的判斷路徑就會更容易理解。

網域規則與 IP 規則

DOMAIN 比對完整網域，DOMAIN-SUFFIX 比對指定網域及其子網域，DOMAIN-KEYWORD 則依關鍵字比對。關鍵字規則涵蓋範圍較廣，容易把無關網域納入同一策略；維護業務分流時，優先使用明確網域或網域後綴。網域規則只處理主機名稱，不是完整網址，不能加入通訊協定、路徑或查詢參數。

rules:
  - DOMAIN,api.example.com,業務出口
  - DOMAIN-SUFFIX,example.net,業務出口
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - MATCH,業務出口

IP 規則處理目標位址範圍，與網域規則的比對對象不同。no-resolve 用來避免該 IP 規則為了判斷網域請求而主動觸發解析；若請求本身已有目標 IP，仍可參與比對。這不代表整條規則會被略過，也不代表所有 DNS 請求都已停用。應依應用程式交給核心的是網域還是 IP，來理解比對結果。

一項業務可能會使用登入、介面、靜態資源和更新等多個網域。若只分流首頁網域，可能出現頁面能開啟但登入失敗的情況，這通常表示規則涵蓋範圍不足。應透過連線記錄補上實際相依的網域，不要立刻改用寬泛的關鍵字規則或全域模式。若已知網域但只看到 IP，也要檢查應用程式是否自行解析，以及 DNS 是否經過核心。

規則目標與資料相依性

規則末端的目標可以是現有代理、策略組或內建出站，例如 DIRECT、REJECT。若目標使用不存在的組名，可能導致載入錯誤或設定無法使用。建議多數業務規則指向用途穩定的策略組，避免節點更名後必須逐行修改。拒絕規則應盡可能精確；若錯誤攔截驗證或憑證相關請求，可能引發不易察覺的連鎖故障。

GEOIP 等規則需要相應的地理資料，規則提供者則依賴外部資源。即使設定檔語法正確，資料檔案缺失、下載失敗或快取路徑無法寫入，仍可能造成初始化失敗。排查記錄時，應區分「規則字串不合法」和「規則所需資源無法使用」，兩者需要不同的修復方式。

程序相關規則會受到作業系統、權限與連線方式限制，不能假設桌面環境可用的程序規則，在路由器轉送流量時也能辨識原始應用程式。尤其是流量來自區域網路的其他裝置時，核心看到的是轉送連線，不會自然得知遠端裝置上的程序名稱。這類情況應優先依網域、目標位址或可辨識的來源條件安排策略。

將大量規則交由 rule-providers 管理

規則提供者會將較長的規則集合從主要設定中拆出，讓主要設定保留優先順序與出口決策。behavior 用來宣告規則集合的語意，format 則宣告檔案格式，兩者必須符合遠端內容。以下範例採用 YAML 格式的 classical 集合；集合內只寫規則條件，不在每條條件後附加策略組，而是由主要設定中的 RULE-SET 指定目標。

rule-providers:
  work-domains:
    type: http
    behavior: classical
    format: yaml
    url: "https://config.example.com/work-rules.yaml"
    path: ./rules/work-rules.yaml
    interval: 86400

rules:
  - RULE-SET,work-domains,業務出口
  - MATCH,DIRECT

相應的遠端檔案可以採用以下結構。如果提供者宣告為網域集合，就不能把完整的傳統規則字串當成一般網域填入。格式混用可能導致解析失敗，也可能讓規則無法如預期比對；應先檢查內容格式，不要只是一味拉長更新間隔。

payload:
  - DOMAIN,api.example.com
  - DOMAIN-SUFFIX,example.net

規則集也有信任與維護範圍。更新可能擴大或縮小比對範圍，進而改變同一業務的出口，因此應選擇用途明確且內容可檢查的集合。調整前保留快取與已知正常的設定；驗證時各選一個應該命中與不應命中的目標，分別觀察實際規則和最終出站，避免只測試單一成功案例就認定所有分流都正確。

6. DNS 解析、fake-ip 與引導流程

DNS 同時負責解析目標網域、節點伺服器，以及部分規則判斷。網頁無法存取時，問題可能出在任何一個環節：應用程式沒有取得解析結果、核心無法解析節點網域，或解析路徑與連線出口不一致。先確認是哪個網域、由哪個元件、透過哪條路徑解析，再決定要修改哪些欄位；直接替換所有解析器，會讓原有問題更難重現。

解析入口與位址增強模式

dns.enable 用來啟用核心 DNS 功能，listen 指定接收 DNS 請求的位址，但不會自動修改作業系統的 DNS 設定。顯式系統代理、應用程式內建的加密 DNS，以及 TUN 連線方式，處理 DNS 的方法各不相同。只有請求實際送到核心，相關 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"
    - "*.local"
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - "https://cloudflare-dns.com/dns-query"

fake-ip 會使用虛擬位址建立網域與後續連線之間的關聯，再由核心依據網域和規則處理請求。該位址不是網站的真實伺服器位址，看到測試網段時，不要直接判定解析遭到污染。需要真實位址進行區域網路探索或特定驗證的應用程式，可能需要加入過濾範圍；但不應為了避開相容性分析而過濾所有網域。

redir-host 通常會回傳實際解析位址，適用於不同的相容性需求。它與 fake-ip 的差異主要在位址關聯方式，不是簡單的「快」或「慢」。選擇哪種方式，應依據流量入口、應用程式行為與規則需求；切換後也要考量系統 DNS 快取、應用程式快取與舊連線，不能只看切換後第一次請求的結果。

引導解析與節點網域解析

default-nameserver 用於解析 DNS 伺服器本身的網域等引導需求，不是為所有一般流量額外增加一個同等優先的解析器。使用網域形式的加密 DNS 位址時，用戶端必須先知道該解析服務的位址。如果引導解析依賴尚未建立的代理，而代理節點又依賴同一個解析服務，就可能形成啟動循環。

proxy-server-nameserver 可單獨指定節點伺服器網域的解析路徑，減少與一般業務解析混用時產生的相依性。此處需要使用能在目前網路環境中完成解析的服務。不要因為某個位址在其他網路可用，就認定它在目前網路也一定能連線；防火牆、電信網路與裝置的 DNS 策略都會影響結果。

respect-rules 會讓 DNS 連線的路由考量分流規則，適合確實需要統一出口策略的情況，但也會增加對規則和節點解析的相依性。啟用前應先規劃節點網域的獨立解析方式，避免 DNS 請求等待代理，而代理又等待 DNS。初次排錯時，先採用較簡單的解析路徑，確認基本連線正常後再加入策略分流。

依網域選擇解析器與檢查快取

nameserver-policy 可為特定網域指定解析器，例如讓內網網域使用辦公室網路的 DNS。內網解析器位址是環境參數，離開該網路後可能無法連線，因此相應的網域策略也應隨環境調整。將內網名稱交給公共解析器，通常無法取得預期位址，還會暴露不必要的內部名稱查詢。

dns:
  enable: true
  enhanced-mode: fake-ip
  default-nameserver:
    - 1.1.1.1
  proxy-server-nameserver:
    - 1.1.1.1
  nameserver:
    - "https://cloudflare-dns.com/dns-query"
  nameserver-policy:
    "+.corp.example.com":
      - 192.168.1.53

這段內容應合併到實際的 DNS 設定中，不要在同一檔案再次加入第二個 dns。公司內網範例位址必須換成目前環境實際使用的解析器。若同時使用 fallback 與過濾條件，還要分別了解主要解析結果與備用結果的選擇邏輯；增加備用解析器不會自動依網域分流，也無法保證每次請求都使用相同來源。

修改後，請以相同網域、相同應用程式與相同連線方式重新測試。終端機查詢工具可能直接使用系統解析器，與瀏覽器的加密 DNS 路徑不同；兩者結果不同，不一定代表核心異常。確認解析路徑後，再清除相關快取並重新建立連線。若涉及 fake-ip 對應，也應檢查持續儲存狀態，避免新舊位址與設定混用造成間歇性故障。

7. TUN 連線、系統路由與平台差異

TUN 會在作業系統中建立虛擬網路介面，讓部分原本未使用顯式代理的流量進入核心。它負責流量接入，不會取代策略組、節點或規則。啟用後，核心仍須決定每條連線要直連、拒絕或透過代理；若節點本身無法使用，TUN 只會讓更多應用程式遇到相同故障，不會修復遠端連線。

最低限度設定與權限條件

桌面用戶端通常需要安裝服務或取得相應權限，才能建立介面並修改路由。手動執行核心時，則須自行處理系統授權。若設定中寫了 enable: true，但記錄顯示介面建立失敗，應先處理權限、驅動程式或服務狀態，而不是繼續修改規則。圖形介面顯示開關已開啟，也不能取代對實際介面與路由的檢查。

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

auto-route 會要求核心設定流量接入所需的路由，auto-detect-interface 則協助選擇出站介面。裝置同時具有有線、無線、虛擬機或其他通道介面時，自動選擇可能受到預設路由變更影響。若問題只在切換網路後出現，應檢查目前的預設路由與實際出站介面，不必先懷疑訂閱內容。

stack 決定虛擬介面流量由哪種網路堆疊處理；具體支援的選項與行為應以目前核心為準。不要照搬所謂的通用最佳組合：同一應用程式的 UDP、區域網路存取與大量傳輸，可能有不同表現。更換網路堆疊時，應維持其他設定不變，並用相同業務重新測試，才能確認變化是否確實來自此欄位。

DNS 攔截與流量接入範圍

dns-hijack 會將符合條件的一般 DNS 流量交給核心 DNS。它無法直接解密應用程式內建的 HTTPS DNS，也無法保證接管所有不在 TUN 路由範圍內的請求。若應用程式仍使用自己的解析通道，規則看到的目標資訊可能與預期不同；應先確認應用程式的 DNS 設定與實際連線，再判斷是否需要調整。

接管路由時，也要考量區域網路印表機、網路儲存、開發環境與虛擬機網段。規則中的直連設定，決定流量進入核心後要從哪裡出去；系統路由排除則決定該流量是否進入核心，兩者控制的層級不同。若本機服務無法連線，應先確認請求有沒有進入核心，再檢查目標位址規則，避免在錯誤的層級反覆新增例外。

嚴格路由等設定或許能協助限制旁路路徑，但也可能影響系統元件、其他通道與區域網路通訊。只有了解其在目前平台上的行為後，才應啟用。尤其是遠端管理裝置或伺服器時，修改路由可能中斷目前的管理連線；應保留現場存取方式或回復方案，不要在沒有復原路徑的情況下直接套用桌面設定。

依平台檢查實際生效狀態

在 Windows 上，先確認顯式代理運作正常，再關閉系統代理並單獨測試 TUN，較容易區分兩種流量接入方式。UWP 應用程式在顯式代理情境下的迴路限制，與 TUN 接管不是同一個問題；不能把所有無法連線的情況都歸咎於防火牆。安裝與服務排錯的詳細說明，請參閱Clash Verge Rev Windows 安裝與 TUN 排錯。

在 Linux 上，還要檢查轉送、防火牆與策略路由是否由其他服務管理；網路管理器重新載入後，既有設定可能改變。macOS 與行動平台則應使用目前用戶端提供的授權入口，不要直接用桌面設定檔覆蓋。Clash Plus、Clash Verge Rev 與 FlClash 的介面各不相同，操作入口請以目前平台的用戶端為準。

發生所有網路都無法連線時，先關閉 TUN，確認系統原有網路是否恢復，再檢查核心啟動記錄、DNS 與節點。若關閉後仍有異常，接著檢查殘留的系統代理與路由，不要一直切換節點。測試完成後，只保留目前需要的接入方式；排錯期間同時執行多套代理或通道，會讓流量路徑更難確認。

8. 用戶端覆寫、設定合併與驗證流程

最終生效的設定通常由訂閱原文、本機擴充、用戶端設定與執行狀態共同決定。訂閱更新負責更新來源內容，覆寫負責保留本機差異，控制介面則可能修改目前的選擇。三者同時存在時，只看編輯器中的檔案，無法解釋所有行為。排查的重點應是「核心實際讀取了哪些內容，以及連線實際經過哪裡」，而不是「某個欄位已經儲存」。

確認合併規則與持續儲存位置

合併時，映射、清單與純量可能採用不同策略。映射可能遞迴覆蓋，清單可能整份取代，也可能由用戶端附加；具體行為取決於用戶端的擴充機制，並非 YAML 統一規定。尤其是 rules，即使所有內容都保留下來，附加位置不同仍會改變優先順序，因此必須檢查合併後的排列。

例如訂閱結尾已有 MATCH，用戶端卻把自訂網域規則加在它後面，該規則就不會有機會命中。正確做法是使用用戶端支援的前置規則入口，或在產生設定時將自訂例外插入兜底規則之前。不要只因介面顯示「新增成功」就結束驗證；應實際發出對應請求，並查看命中的規則。

# 合併後預期的規則順序
rules:
  - DOMAIN,api.example.com,業務出口
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,業務出口

連接埠、控制介面與 TUN 通常由用戶端管理；覆寫相同名稱的欄位後，可能又會被用戶端替換。應先確認每個欄位由哪一層負責，再集中修改，避免介面設定與檔案覆寫互相覆蓋。Clash Plus 可作為選擇起點；使用其他用戶端時，也應透過其本機擴充機制儲存修改，不要把特定用戶端的指令語法當成核心通用欄位。

訂閱更新後修改內容消失，通常表示編輯位置不正確，或覆寫沒有套用到目前的設定。先比較更新前後的原始文字，再確認擴充功能已啟用且適用範圍正確。有些擴充只套用於單一設定，有些則會套用到所有設定；範圍選錯可能讓測試設定影響日常使用。長期維護時，應保留本機差異說明，記錄每項覆寫的用途與移除條件。

先進行靜態驗證，再驗證實際執行

手動執行 mihomo 時，可先測試準備啟用的設定檔。以下指令會檢查指定檔案是否能被目前核心接受，但不代表遠端節點、外部規則資源與所有業務都已通過端對端測試。圖形化用戶端可能使用內建核心和獨立工作目錄；即使終端機中的另一個 mihomo 測試成功，也不能證明用戶端使用的是同一份檔案。

mihomo -t -f ./config.yaml

靜態驗證階段依序處理四類錯誤：縮排或型別錯誤、名稱引用缺漏、目前核心不支援的欄位，以及外部資源載入問題。發生錯誤時，保留第一則有實質意義的訊息；後續錯誤可能只是連鎖結果。每次修改一處後重新測試；不要在不了解欄位用途時一次刪除多個欄位，否則即使成功啟動，也可能失去原有策略。

執行驗證時，先確認監聽成功，再確認測試請求已進入核心，接著檢查模式、規則、策略組與最終節點。最後才確認出口位址和實際業務結果。建議分別驗證一個明確直連的請求，以及一個明確經過代理的請求，必要時重新建立連線。首次連線的完整驗證步驟，請參閱選擇節點、測試延遲並確認代理生效。

依症狀回到正確的排查層級

復原步驟應與變更一樣明確：先回到已知正常的設定，再停用最近新增的覆寫或 TUN 設定，並確認系統代理與 DNS 狀態。不要為了解決單一欄位問題就刪除整個用戶端目錄，因為其中可能存有節點選擇、快取與本機擴充。若需要重新安裝，請先透過平台下載入口選擇相應安裝套件，並備份必要的本機設定。