Clash 設定欄位參考
YAML 與執行設定

一、YAML 結構與設定範圍

mihomo 讀取的是結構化設定，而非逐行執行的命令。設定檔通常以映射作為根節點，下方分別放置通用欄位、DNS 設定、代理節點清單、策略組清單與規則清單。欄位在檔案中的書寫順序通常不影響生效優先順序，但清單順序可能直接改變運作結果。規則清單尤其如此：核心會由上而下比對，因此不能把它當成可任意排序的說明清單。

映射、清單與縮排

映射以冒號表示欄位和值，清單則以連字號列出多個項目。縮排必須使用空格，建議每層固定兩格；不要混用定位字元。同一層的欄位應對齊，子欄位則縮排至父欄位之下。冒號後需加空格；英文標點不可改成全形冒號或中文逗號。編輯器顯示的行號不一定就是問題根源，前一行缺少的引號也可能讓解析器到下一行才回報錯誤。

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

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

proxies: []

proxy-groups:
  - name: 預設出口
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,預設出口

此範例可作為理解結構的起點，所有流量最終都會選擇直連，不會因此取得代理連線。proxies: [] 表示空清單，與欄位留空不同。根節點下的 dns 是映射，nameserver 則是其中的清單。策略組清單中的每個項目又是映射，因此同一個檔案會交替使用這幾種結構。複製範例時應保留完整層級，不要只複製看似相關的單行設定。

字串型別與引用關係

密碼、名稱、路徑及含特殊字元的值建議加上引號，尤其要留意看起來像數字的密碼、井字號、冒號和反斜線。井字號在一般純量中可能會開始註解；Windows 路徑放在雙引號內也可能觸發跳脫處理。使用正斜線路徑或正確的單引號字串通常更容易檢查。布林欄位應寫成 true 或 false，不要為了格式統一而替所有值加上引號，否則可能會把布林值變成字串。

節點名稱、策略組名稱與規則中的目標名稱彼此引用。規則引用策略組時，名稱必須與該組的 name 完全一致，包括空格與大小寫。名稱中應盡量避免逗號，因為傳統規則格式以逗號分隔參數。刪除節點或重新命名策略組前，先搜尋其他策略組與規則中的引用；解析成功不代表所有引用都能建立，後者通常會在設定驗證或載入時才顯現。

來源檔案與最終執行設定

訂閱原始內容、用戶端本機設定，以及核心實際載入的檔案，是三種不同的對象。用戶端可能在啟動時重新寫入連接埠、DNS 或 TUN 欄位，也可能在訂閱中追加規則。直接編輯暫存的執行檔，下次更新或重新啟動時可能就會被覆蓋。應先找到用戶端的設定管理、覆寫或合併入口，確認修改會儲存在哪一層，再檢查最後產生的設定。若介面沒有匯出執行設定的功能，可透過記錄檔與受保護的控制介面核對重要欄位。

局部範例只說明相關欄位。除了本章的結構範例，後續片段都不可直接當成完整設定啟動；請先確認引用的節點、策略組和提供器已在同一份最終設定中定義。

YAML 錨點可減少重複內容，但合併鍵主要適用於映射，不要預期它會自動串接兩份規則清單。初次維護設定時，明確寫出內容比複雜重用更容易排錯。也不要在同一層重複定義 dns 或 rules 來表示追加：不同解析器對重複鍵的處理方式可能不同。可靠的做法是整理成唯一欄位，再交由明確的合併流程處理。

二、連接埠、模式與網路接管

通用欄位會決定核心如何接收連線、選擇對外連線方式，以及是否開放區域網路存取。修改前先區分三種路徑：應用程式主動連線至代理監聽連接埠、系統代理將遵循系統設定的應用程式導向該連接埠，以及 TUN 透過虛擬網路介面接管路由範圍內的流量。這些方式可以同時使用，但發生異常時應分別驗證，避免同時啟用多種接管機制，反而無法判斷問題出在哪一層。

監聽連接埠與存取範圍

沒有相容性需求時，只設定混合連接埠即可。多個監聽器必須使用不同連接埠，不可讓 port 和 mixed-port 同時使用相同的位址與連接埠。變更連接埠後，手動設定代理的瀏覽器、終端機和其他裝置不會自動同步。若記錄檔顯示位址已被使用，先確認是否有其他 Clash 用戶端、舊版核心程序或本機服務占用監聽端點，不要只是不斷換連接埠來掩蓋程序衝突。

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

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

上例明確關閉 TUN，方便先驗證應用程式明確指定代理的連線方式。需要啟用時，再將 tun.enable 改為 true，並確認用戶端具備建立虛擬網卡及修改路由的權限。stack 的可用值取決於平台與核心能力，不能只憑名稱推斷相容性。用戶端也可能自行管理這些欄位，因此手動設定後仍須檢查最終執行設定。

規則、全域與直連模式

mode: rule 會依規則清單決定流量走向；全域模式會將流量交由全域策略處理；直連模式則主要用於排查代理連線是否故障。切換至全域模式不代表所有流量一定會經過遠端節點，因為全域策略仍可能選擇 DIRECT。變更模式後，也要確認實際選取的群組成員。既有的長連線可能仍沿用原本的出口；驗證時請建立新請求，必要時關閉相關連線後再試。

區域網路共享需要監聽設定、主機防火牆和網路拓樸都允許。只修改 allow-lan 不保證其他裝置一定能連線；對端還必須使用主機的區域網路位址，而不是自己的回送位址。開放監聽前，應評估目前網路是否可信，並視需要設定代理驗證。代理驗證保護的是代理入口，與控制介面的存取憑證不同，兩者不能互相取代，更不應將控制介面直接開放至公用網路。

TUN 與 IPv6 的適用範圍

auto-route 用於自動設定相關路由，auto-detect-interface 則用於協助判斷出口介面。它們無法排除所有多網卡、虛擬機或其他 VPN 的衝突。發生連線迴圈時，應檢查代理伺服器本身的對外連線是否又被接管，以及其他軟體是否持續改寫預設路由。桌面系統的服務權限與行動系統的 VPN 授權是不同機制，不能把某個平台的權限處理步驟直接套用到另一個平台。

頂層 ipv6 和 dns.ipv6 位於不同控制層級：前者影響核心是否使用 IPv6，後者影響 DNS 的 AAAA 查詢行為。排錯時應一併記錄系統是否具備可用的 IPv6 路由、節點是否支援相應出口，以及 DNS 是否回傳 IPv6 位址。只關閉其中一個選項，不能據此判定整條連線路徑已改用 IPv4。調整欄位時，應以連線記錄和實際解析結果為依據。

三、DNS 與 Fake-IP 欄位

DNS 設定會影響目標網域的解析，也可能影響代理伺服器位址的解析。首先要釐清系統向哪裡查詢、核心使用哪個上游、上游網域如何取得初始位址，以及查詢經由哪條出口送出。網頁能否開啟不足以證明 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:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "+.example.com":
      - https://dns.alidns.com/dns-query

enable 用來啟用核心 DNS 模組，listen 則設定服務的監聽端點。範例中的回送位址與非標準連接埠僅供本機呼叫；光是設定這個欄位，系統不會自動將所有 DNS 請求送到此處。實際接管可由用戶端、系統 DNS 設定或 TUN 的 DNS 劫持完成。TUN 中的 any:53 也不代表能接管應用程式自行連往任意加密 DNS 服務的請求，後者通常是一般的加密連線。

nameserver 指定一般查詢使用的上游；default-nameserver 則用於需要初始解析的情況，例如先解析加密 DNS 服務的網域。proxy-server-nameserver 用於解析代理伺服器網域，可避免節點網域依賴代理連線、而代理連線又依賴節點網域的迴圈。範例採用公用 DNS 服務，實際選擇應考量網路連通性與隱私需求；切換上游前，先確認它在目前網路中可正常連線。

Fake-IP 與真實位址解析

Fake-IP 模式會將位址池中的合成位址回傳給應用程式，核心則保留該位址與網域的對應關係，並在接管後續連線時還原網域資訊、套用規則。這有助於保留依網域進行判斷所需的資訊，但前提是應用程式取得的合成位址與連線流量都經過同一個核心處理。若請求繞過核心直接連線至合成位址，或核心重新啟動後應用程式仍沿用舊快取，就可能導致連線失敗，而不一定是節點本身無法使用。

fake-ip-filter 可指定特定網域不使用合成位址。範例列出常見的區域網路名稱後綴，但篩選項目不會自動讓公用上游知道內網記錄；必要時仍須透過解析策略指定內網 DNS。不要為了修復一台區域網路裝置，就把所有網域都加入篩選清單，否則會改變原本還原網域的路徑。應先確認失敗的網域，再新增範圍最小的項目，最後清除應用程式與系統快取並重新測試。

redir-host 會將真實解析位址回傳給應用程式，並在連線階段結合既有資訊進行分流。它與 Fake-IP 的主要差異在於回傳位址及網域關聯的方式，不能簡單解讀成一種比較快、另一種比較安全。依賴顯示真實位址、特殊區域網路探索或應用程式內部位址檢查的情境，應搭配實際接管方式測試。原理說明請參閱Fake-IP 與 redir-host 的差異。

分開檢查解析策略與流量策略

nameserver-policy 依網域選擇解析上游；規則清單則依連線資訊選擇出口。將某個網域交由指定 DNS 伺服器解析，不代表連線至該網域時也會使用同一條代理策略。若要讓 DNS 上游連線也遵循規則，可進一步了解 respect-rules；但啟用前應確保代理伺服器網域有獨立可用的解析路徑，並檢查上游網域是否造成依賴迴圈。不要一次疊加多種機制，再猜測實際查詢方向。

DNS 結果變更後，既有連線、應用程式快取與系統快取可能仍保留舊狀態。測試時請使用新請求，並記錄查詢網域、回傳位址、命中的解析策略及最終出口，避免將快取差異誤判為設定未生效。

設定 fallback 時，也要詳讀相應的篩選條件；它不是單純依清單順序逐一嘗試的備用伺服器清單。涉及地理位置判斷時，地理資料庫是否可用也會影響結果。剛開始接觸設定時，建議先使用一個明確可連線的一般上游，並設定獨立的節點解析路徑；確認正常後再加入複雜策略。若解析逾時，先分辨是上游無法連線、初始解析失敗，還是流量未被接管，不要直接更換所有 DNS 欄位。

四、代理節點與通訊協定參數

proxies 是內嵌代理節點清單，每個項目都描述一個可供策略組引用的出口。節點至少需要唯一名稱、通訊協定類型，以及該協定要求的伺服器與驗證資訊。不同協定的欄位不可任意互換：即使都使用密碼，Shadowsocks 的加密方式、Trojan 的 TLS 參數，以及其他協定的使用者識別資訊也不是相同結構。請以服務端提供的參數為準，不要從不同教學中拼湊看起來相似的設定行。

基本欄位與完整通訊協定設定

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

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

範例中的保留網域與教學用密碼不能用於實際連線，必須替換成服務提供者給出的完整參數。server 可以是網域或位址，port 是遠端服務的監聽連接埠，與本機的 mixed-port 無關。name 是本機引用用的識別名稱，不參與遠端驗證。修改名稱可以讓組內項目更容易辨識，但必須同步更新引用該名稱的策略組，否則即使節點存在，也無法正確選取。

Shadowsocks 的 cipher 必須與服務端一致，驗證失敗通常無法靠更改 DNS 解決。Trojan 一般以 TLS 為基礎，sni 用於 TLS 交握時的伺服器名稱，不能只因連線逾時就改成任意可連線網站的網域。若透過位址連線，但憑證是簽發給網域，應依實際服務參數填寫名稱。位址、連接埠、驗證和 TLS 身分分屬不同層次，應分別檢查。

TLS、傳輸層與 UDP

skip-cert-verify: false 會維持憑證驗證。遇到憑證錯誤時，應檢查系統時間、憑證鏈、名稱是否相符，以及連線是否確實到達預期伺服器。直接關閉驗證可能讓錯誤表面上消失，卻無法證明連線對象的身分正確。有些協定需要透過 tls 啟用 TLS，另一些協定本身就包含 TLS 語意，不要假設所有類型都接受相同的開關；未知或層級錯誤的欄位也可能被忽略，而非立即回報明顯錯誤。

使用 WebSocket、HTTP/2 或其他傳輸方式時，傳輸選項必須符合服務端部署。WebSocket 路徑通常設定在 ws-opts.path，需要額外請求標頭時則放在相應的 headers 映射中。連線位址、TLS 伺服器名稱、HTTP Host 標頭和請求路徑可能各不相同，但這些差異應來自實際部署，而非任意混用。只改對節點類型，仍不足以滿足傳輸層需求。

udp: true 表示允許節點處理相應的 UDP 流量，不會讓原本不支援 UDP 的服務端因此取得這項能力。若網頁可以正常開啟，但語音、遊戲或 QUIC 連線失敗，應分別檢查應用程式接管路徑、核心協定支援、遠端服務及網路中介設備。關閉特定應用程式的 QUIC 只能作為排查手段，不能證明 UDP 已恢復。測試結果也應區分 UDP 轉送和 DNS 請求，兩者可能走完全不同的出口。

節點匯入與敏感參數處理

訂閱中的節點不一定會直接出現在 proxies 中，也可能透過代理提供器動態載入。原始分享連結、編碼後的節點集合與完整 Clash 設定檔是不同格式，不能只更改副檔名就當成 YAML 使用。若匯入失敗，先確認回傳內容是否為登入頁、錯誤頁或不相容格式，再檢查具體的協定欄位。相關排查順序請參閱訂閱匯入失敗與解析錯誤自我檢查。

分享設定片段前，請移除伺服器身分資訊、密碼、使用者識別資訊、訂閱網址，以及可能附帶的存取參數。即使節點名稱不敏感，完整訂閱連結仍可能具有帳戶存取權限。排錯時保留欄位名稱、層級、協定類型和錯誤文字通常就已足夠，不必公開驗證資訊。對於會自動更新的訂閱，不建議長期維護內嵌節點副本；應保留訂閱作為來源，並在用戶端支援的覆寫層中設定本機規則和策略組選擇需求。

節點名稱重複會讓引用對象變得不明確，在合併多個訂閱時尤其常見。匯入第二個來源前，先檢查是否有同名節點、同名策略組或相同的提供器路徑。若用戶端提供名稱前綴或篩選功能，可在來源層級統一處理，不必逐一手動改名。設定維護的目標是讓來源、驗證參數和策略引用彼此分離，更新其中一項時，不必重新編輯其餘所有部分。

五、策略組與代理提供器

策略組會將節點或其他策略組整理成可供規則引用的出口目標。它負責選擇出口，不負責判斷連線屬於哪種業務。常見架構是：規則指向業務組，業務組再選擇手動組或自動組，自動組則從提供器取得節點。這類層級可降低節點變動對規則的影響，但組別之間不可形成循環，否則無法確定最終出口。

手動選擇與自動測試

proxy-providers:
  本機節點:
    type: file
    path: ./providers/local.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 自動出口
    type: url-test
    use:
      - 本機節點
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 50

  - name: 預設出口
    type: select
    proxies:
      - 自動出口
      - DIRECT
    use:
      - 本機節點

這裡的 providers/local.yaml 必須實際存在，根節點應包含 proxies 清單，並在其中填入實際節點；前一章的教學節點只能用來檢查結構。路徑通常相對於核心工作目錄解析，用戶端也可能進一步限制可存取的檔案範圍。找不到檔案時，應先確認實際工作目錄，不要預設路徑是相對於目前編輯的檔案。檔案提供器適合說明引用關係；遠端訂閱則通常使用 HTTP 類型並提供更新網址。

select 由使用者手動選擇成員；url-test 依測試結果選擇可用出口；fallback 著重依成員順序尋找可用出口；load-balance 則依選定的策略分配連線。自動測試只能反映連線至測試目標的狀況，不代表所有網站、影音串流或業務服務都能使用。測試目標應穩定可連線，也應盡量避免使用需要特定登入狀態的頁面作為健康檢查依據。

間隔、容差與組內成員

interval 範例單位為秒；tolerance 表示自動選擇時的延遲容差，範例值以毫秒計。容差有助於避免結果些微波動時頻繁切換，但無法修復節點不穩定或測試目標選擇不當的問題。健康檢查也會產生實際網路請求，大型訂閱不宜盲目使用太短的間隔。用戶端可能在背景執行或休眠時調整工作排程，不能只憑介面更新時間就認定每次檢測請求都準時發出。

proxies 列出明確指定的成員名稱，use 則引用代理提供器名稱。兩者可同時出現在同一組中，但意義不同：前者引用已知節點或策略組，後者則引入提供器中的節點集合。提供器健康檢查與策略組測試也屬於不同層次；即使使用相同測試網址，仍不應將兩者的結果和執行時機視為完全相同。若策略組沒有成員，先檢查提供器載入結果，再檢查篩選條件，不要直接認定所有節點都失效。

巢狀策略組必須維持有向且無循環的關係。例如業務組可以引用預設出口，預設出口可以引用自動出口，但自動出口不應再引用業務組。巢狀層級過多也會讓介面中的目前選擇難以判讀；維護時可先畫出從規則目標到最終節點的引用鏈。若規則命中正確但流量仍走直連，應檢查鏈上每一層是否允許並選中了 DIRECT，不要只看最外層的組名。

遠端提供器與更新持續性

HTTP 類型的提供器通常需要 url、path 和更新間隔。訂閱網址屬於存取憑證的一部分，不應放進公開儲存庫或公開記錄檔。快取路徑應保持唯一；不同來源共用相同路徑可能互相覆蓋。自動更新失敗時，還要分辨遠端請求是否失敗，以及本機快取是否仍可使用。介面上仍看得到節點，不代表最新訂閱已成功下載，也不代表快取中的節點仍然有效。

若使用名稱篩選，應檢查正規表示式的比對範圍、大小寫，以及提供器更新後名稱是否變動。篩選規則一個項目都沒命中，就會使自動組沒有可選節點；縮短測試間隔也無濟於事。建議先取消篩選，確認節點可以載入後，再逐步縮小範圍。若要保存策略組選擇，需使用用戶端或核心提供的持續性機制，例如 profile.store-selected；它只會保存選擇狀態，不能取代訂閱更新，也不會重新建立已刪除的節點。

策略組名稱保持穩定、節點來源可持續更新，比複製整份訂閱更容易維護。將本機規則指向固定的組名，再透過提供器更新節點，可減少訂閱變動對規則造成的連帶影響。

六、規則語法與比對順序

在規則模式下，rules 是依順序執行的比對清單。每條規則通常包含類型、比對內容與目標，部分類型還支援額外參數。第一條符合條件的規則會決定出口，後續規則不會繼續比對。因此維護規則時，首先要設計順序，其次才是規則數量。加入大量規則集合不會自動讓分流更精準；條件重疊或過早出現的寬泛比對，反而容易蓋過原本較細緻的策略。

網域、位址與預設規則

rules:
  - DOMAIN,printer.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,預設出口
  - DOMAIN-KEYWORD,example,預設出口
  - 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,預設出口

DOMAIN 比對完整網域，DOMAIN-SUFFIX 比對指定網域及其子網域，DOMAIN-KEYWORD 則以關鍵字比對網域。關鍵字的涵蓋範圍通常較廣，容易將不相關網域導向同一策略；業務範圍明確時，應優先使用完整網域或網域後綴。範例將特定完整網域放在前面，避免它先被後續的關鍵字規則攔截。規則目標必須是已存在的節點、策略組或內建出口。

IP-CIDR 比對目標 IPv4 位址範圍，IPv6 範圍則使用相應的 IP-CIDR6。no-resolve 用於避免只為判斷這類規則而主動觸發網域解析；它不代表整條連線永遠不需要 DNS，也不表示已有真實目標位址時就無法比對。私有網路直連規則同樣依賴連線資訊；尤其在 Fake-IP 模式下，不應將合成位址直接視為應用程式實際連線的伺服器位址。

規則集合與行為類型

rule-providers:
  本機網域:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,本機網域,DIRECT
  - MATCH,預設出口

此片段需要一個實際存在的規則檔案，其內容可參考下例。網域類型的規則集合只列出網域項目，不要在項目後附加策略組；規則目標應由主設定中的 RULE-SET 規則指定。classical 類型則使用帶有規則類型的項目，ipcidr 類型用於位址區段。行為類型、檔案格式與實際內容必須一致，不能下載一種集合後只改檔名，就交由另一種類型讀取。

payload:
  - "+.example.com"
  - "printer.example.org"

RULE-SET 中的提供器名稱必須與 rule-providers 的鍵名一致，不能填本機路徑或遠端 URL。多個集合的條件重疊時，仍由主規則清單中的順序決定優先權。HTTP 類型的規則提供器還涉及快取與更新；排查時應一併記錄目前載入的規則項目與更新時間。遠端更新成功只代表資源已取得，不能證明業務網域確實包含在集合中。

程序規則與平台差異

與程序名稱、程序路徑及應用程式識別資訊相關的規則，取決於平台、權限，以及核心能否取得連線所屬程序資訊。不能因為桌面系統上的程序規則有命中，就假設行動系統也提供相同資訊。若記錄檔中沒有預期的程序欄位，先檢查執行權限與用戶端支援情況。跨平台設定通常更容易維持網域與位址規則一致；程序規則適合作為實測後的補充條件，不應作為唯一的分流依據。

GEOIP 或地理位置網域集合會依賴相關資料庫及載入方式；資料庫缺失、來源變更或更新失敗都可能影響比對結果。規則沒有命中時，先確認目標資訊與資源狀態，再檢查規則寫法。不要將某個網域解析出的單一位址永久視為該業務的唯一位址；CDN、區域解析和服務搬遷都可能讓位址改變。需要精確控制時，應優先維護網域範圍，並透過連線記錄確認實際請求涉及的其他網域。

MATCH 是預設規則，通常放在最後；若放在前面，後續項目就沒有比對機會。自訂例外應放在會涵蓋它的規則集合之前，但不必死板地永遠放在第一行。每次變更後都建立新連線，查看規則類型、命中內容、策略組和最終節點。若命中結果正確但無法存取，應改查節點或 DNS，而不是繼續新增重複規則。規則判斷與連線可用性是兩個需要分別驗證的問題。

七、訂閱覆寫與設定合併

訂閱通常由外部來源維護，本機需求則可能包括監聽連接埠、區域網路設定、DNS、額外規則和策略組選擇。覆寫機制會將這些本機需求保存在獨立層，並在訂閱更新後重新套用。它不會直接修改訂閱伺服器上的內容，也不是 YAML 內建的統一標準。不同用戶端對映射、清單和空值的處理方式可能不同，因此應先確認合併規則，再決定覆寫片段要寫成完整物件還是局部欄位。

先確認欄位由哪一層管理

連接埠和 TUN 通常由用戶端設定頁面管理，節點和提供器多半來自訂閱，業務規則則可能由訂閱與本機追加內容共同組成。如果同一欄位由兩層管理，最終生效值會取決於設定產生順序。不能只憑介面中的某個開關，就認定來源檔案已修改；也不能只因來源檔案寫了某個值，就認定執行時沒有被覆蓋。應將來源訂閱、本機覆寫與最終執行檔並列比對，記錄每個重要欄位的來源。

映射合併與清單取代

以下是局部覆寫片段，僅用於調整 DNS 和記錄檔設定。它是否會保留原訂閱中的其他 DNS 欄位，取決於用戶端採用遞迴合併還是整體取代。若採用整體取代，未列出的 nameserver 可能使 DNS 設定不完整。部署前應先匯出或檢視合併結果，不要以是否成功儲存來判斷結果是否正確。有些用戶端提供獨立的 DNS 覆寫選項；啟用後，通用覆寫中的同名欄位也可能不再是最終設定來源。

# 局部覆寫範例；合併方式由用戶端決定。
log-level: info
dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query

清單比映射更需要謹慎。將只包含兩條規則的 rules 清單放進通用覆寫，可能會取代整份訂閱規則，而不是只追加兩條。加入策略組清單也可能刪除訂閱中的原有組別，導致大量規則引用失效。優先使用用戶端明確區分的前置規則、後置規則或專用合併入口；若只有整體取代機制，就必須維護完整清單，並負責在訂閱結構變更後同步更新。

追加規則也有位置問題。原訂閱的末尾通常已有 MATCH，直接在它後面加入網域例外不會執行。若要新增例外，通常應將項目插入相關的廣泛規則之前。同時，例外的目標若是新建的本機組別，必須先確保該組和成員來源都能產生。規則、組別和提供器構成完整的引用鏈，只保存其中一段，無法組成本機可執行的自訂設定。

用戶端差異與更新後檢查

Clash Plus、Clash Verge Rev、FlClash 等用戶端管理訂閱設定的入口各不相同，同一片段不能未經檢查就跨用戶端沿用。請尋找與設定管理、覆寫、追加規則或執行設定相關的入口，先閱讀其說明，再用不影響連線的欄位測試合併方式。例如先只調整記錄檔等級，確認執行時有變化後，再加入一條可觀察的網域規則，最後才修改 DNS 和接管路徑，才能清楚判斷差異來自哪一層。

更新訂閱前，先保存本機覆寫和可用的設定副本，但不要將含有憑證的副本上傳至公開位置。更新後，應重點確認固定的組名是否仍存在、提供器是否改名、節點篩選結果是否為空，以及規則目標是否有效。訂閱內容的變動不只涉及節點新增或刪除，也可能改變組別層級和規則資源。更新後若設定失效，比對前後結構通常比反覆重新匯入更有效；首次啟動相關檢查請參閱首次安裝與初始設定檢查清單。

不要直接維護用戶端產生的暫存執行檔。將需要長期保留的設定放在用戶端支援的覆寫層，保留可復原的副本，並在訂閱重新整理後再次確認修改仍然存在。

YAML 中的 & 錨點、別名和映射合併，不能取代用戶端的跨檔案合併流程。它們只會在解析目前 YAML 文件時重用結構，不會自動知道外部訂閱應如何更新。也不要依賴重複的頂層鍵來覆蓋設定，或假設空物件一定能清除舊設定。容易維護的覆寫應盡量精簡，明確列出要變更的欄位，並為每項變更保留可觀察的驗證步驟。

八、設定驗證與故障排查

設定排錯應依序檢查檔案解析、引用建立、監聽啟動、DNS、對外連線與規則判斷。每一層都有不同的故障訊號，不要把所有問題都歸因於訂閱失效。載入失敗時先處理語法和欄位；載入成功但沒有流量時檢查接管；有流量但解析失敗時檢查 DNS；解析成功但遠端連線失敗時檢查節點；連線可用但出口不如預期時檢查規則與組別選擇。依照這個順序排查，可減少不必要的修改。

靜態檢查與核心驗證

在用戶端之外維護檔案時，先使用編輯器的 YAML 檢查功能找出縮排、引號和重複鍵問題。一般 YAML 解析成功，只代表語法正確，不代表協定欄位和引用都有效。還需要使用實際執行的 mihomo 核心驗證設定，並盡量與用戶端使用的核心版本一致。若改用其他核心驗證，欄位支援差異可能造成誤判。用戶端若沒有提供核心命令入口，不要只為了驗證而隨意替換程式檔案。

# 在獨立測試目錄中檢查；路徑請依實際檔案位置填寫。
mihomo -t -d ./mihomo-check -f ./config.yaml

# 使用明確指定的 HTTP 代理，檢查監聽與基本請求路徑。
curl -I --proxy http://127.0.0.1:7890 https://example.com

# 由代理端解析目標網域，檢查 SOCKS 請求路徑。
curl -I --proxy socks5h://127.0.0.1:7890 https://example.com

# 檢查本文範例中的本機 DNS 監聽。
nslookup example.com 127.0.0.1

最後一條 DNS 命令使用系統工具的預設 DNS 連接埠，並未直接查詢前文的 1053。如果本機標準連接埠上沒有部署 DNS 服務，請改用支援指定連接埠的工具，例如下例。這項差異很重要：向錯誤連接埠發出查詢後逾時，不能證明核心設定的上游無法連線。命令能否使用取決於作業系統和已安裝的工具；在終端機中也應確認執行的是實際的 curl 程式。

dig @127.0.0.1 -p 1053 example.com A

-t 用於測試設定，-d 指定工作目錄，-f 指定設定檔。設定引用的相對路徑資源必須能在指定工作目錄中存取；測試時缺少提供器檔案，不等於 YAML 語法錯誤。正式執行用戶端時，也要檢查其工作目錄是否不同。不要同時啟動另一個占用相同代理連接埠的核心進行測試，否則會造成新的連接埠衝突，掩蓋原本的問題。

透過新連線檢查判斷流程

先用明確指定的代理請求驗證監聽和基本對外連線，再啟用系統代理，最後測試 TUN。這樣可以分別確認應用程式是否遵循系統代理，以及核心本身是否正常。HTTP 請求成功也不代表 UDP、IPv6 或所有應用程式都正常，仍須依實際用途分別測試。SOCKS 網域由本機解析還是代理端解析，會影響排查結果；範例中的 socks5h 會讓代理端處理目標網域，方便與本機解析路徑比較。

查看連線記錄時，依序核對目標網域或位址、命中的規則、外層策略組、巢狀組選擇與最終節點。修改規則或組別選擇後，請建立新連線，不要只重新整理可能沿用既有連線的頁面。若用戶端提供關閉連線的功能，可針對測試連線重新建立；但若尚未儲存工作，不要一次中斷所有連線。DNS 變更也要考慮快取；Fake-IP 位址變動後，應用程式若仍使用舊快取，可能會出現與新設定不一致的情況。

記錄檔等級與最小幅度復原

日常使用時維持適中的記錄檔詳細程度，排查問題時再暫時提高。先查看第一個導致失敗的錯誤，再檢查後續連帶訊息；例如遠端網域解析失敗，可能使後續所有連線都逾時。連接埠占用通常發生在啟動階段，TLS 身分錯誤則出現在遠端交握階段，兩者的處理方式不同。欄位解讀可參閱mihomo 常見記錄檔錯誤與排查順序；分享記錄檔前，請先移除驗證資訊和訂閱內容。

每次只修改一類變數，並記錄修改前的值、修改原因與測試結果。發生問題時先復原最近一次變更，不要同時重裝用戶端、更換訂閱並修改 DNS。若最精簡的直連設定能運作、完整設定卻不行，可逐步恢復提供器、策略組、規則和接管功能；最先失敗的模組通常就是接下來應調查的範圍。最精簡設定能運作，只能證明基本環境正常，不代表移除的遠端節點一定可用。

最終驗收至少應包含重新載入一次、重新啟動用戶端一次，以及重新整理訂閱一次，分別確認設定可正常解析、持續性設定能還原，以及覆寫不會因更新而消失。接著檢查區域網路監聽範圍、控制介面存取範圍，以及記錄檔等級是否恢復預期狀態。若要重新整理操作順序，請返回入門指南；若要更換用戶端，請前往安裝檔下載頁面並依作業系統選擇。將可正常使用的設定保存為本機基準，日後維護才有明確的復原起點。