Clash 設定檔參考

YAML 結構與設定範圍

Clash 設定不是一串依序執行的命令，而是描述監聽、解析、對外連線與路由關係的結構化文件。頂層的 dns、proxies、proxy-groups 和 rules 各有用途，只有名稱引用正確、資料型別符合要求，核心才能將它們串接起來。閱讀不熟悉的設定時，先找出頂層欄位，再依規則中的目標名稱查看策略組，最後檢查組內引用的節點；逐行讀完整份檔案，反而容易忽略這些相依關係。

映射、清單與縮排

YAML 以縮排表示父子關係，建議統一使用兩個空格，不要混用定位字元。冒號後加空格通常表示鍵值分隔，連字號後加空格通常表示清單項目。同樣是 name，放在節點底下和放在策略組底下，意義並不相同。編輯器的自動格式化有助於對齊，但無法判斷引用是否正確。複製片段時要一併確認父層，避免把原本應放在 dns 內的欄位誤置於根層。

# 結構示意：清單中的每個項目都是獨立的策略組
proxy-groups:
  - name: 手動選擇
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,手動選擇

字串、數字與布林值都應明確標示。連接埠通常寫成數字，開關則寫成 true 或 false；若改寫成帶引號的字串，有些解析器會拒絕，有些可能會轉換，不應依賴這種差異。包含特殊符號、前導零或可能遭誤判的文字時，加上引號較穩妥。密碼建議加上引號；內容若含單引號或雙引號，請依 YAML 的跳脫規則處理。一般註解寫在 # 後方，但字串中的井字號是否屬於內容，取決於引號與所在位置。

區分訂閱來源、編輯內容與執行設定

桌面用戶端通常會保存多份檔案：遠端訂閱的原始文字、本機編輯或覆寫內容，以及最後交由核心載入的執行設定。介面顯示的連接埠、系統代理和 TUN 開關，也可能透過用戶端設定寫入最終結果。修改訂閱文字不等於變更目前的執行設定；重新載入、切換訂閱或套用覆寫後，才可能生效。排查時請記下選用的設定名稱與實際載入時間，避免一邊編輯舊檔案，一邊查看另一份設定的連線結果。

頂層欄位的順序通常不影響映射意義，但清單順序可能直接改變行為。例如規則會依清單順序比對，手動選擇組中的第一個項目也可能影響初始顯示。不要將格式整理工具的「依字母排序」套用到所有清單。重複鍵尤其危險：同一層出現兩次 dns 或兩次 rules，不同工具可能報錯，也可能只保留後一項。需要合併時，應在同一個鍵下整理內容，而不是把整段設定直接貼到檔案末尾。

最小結構與設定相容性

建立新設定時，先準備能啟動的最小結構，再逐步加入節點、群組與規則。某份訂閱能匯入一個用戶端，只代表該用戶端接受了輸入內容，不表示其他用戶端也能以相同方式處理欄位。舊版核心可能不支援較新的協定或 DNS 欄位，用戶端也可能會篩除某些選項。遇到未知欄位，請先查閱目前核心的文件與記錄，不要只為了消除提示就任意刪除整段內容；它可能正負責網域解析或對外連線選擇。

YAML 錨點與別名可以減少重複內容，但也會增加覆寫工具、訂閱轉換器與人工檢閱的複雜度。個人維護的小型設定，適度重複也比難以理解好。交由他人協助排查時，請保留階層、欄位型別與引用關係，只替換伺服器位址、密碼及訂閱連結。整段刪除節點或群組名稱會破壞問題現場，讓語法錯誤、欄位不相容與連線失敗混在一起，降低排查效率。

連接埠、代理模式與流量接管範圍

通用欄位決定核心在哪裡接收連線、如何選擇路由，以及允許哪些裝置存取。最常見的誤解是混淆監聽連接埠與伺服器連接埠：mixed-port 是本機應用程式連線到代理時使用的入口，節點中的 port 則是遠端伺服器提供服務的連接埠。兩者數值可以不同，也不必一致。修改本機監聽連接埠後，也要確認系統代理與應用程式內的代理位址已同步，否則即使核心正常運作，應用程式仍可能連到舊連接埠。

監聽欄位的用途

只需讓本機應用程式使用代理時，通常保留一個混合連接埠就足夠。HTTP、SOCKS 和混合連接埠不必全部開啟，更不可讓兩個監聽項目使用同一個位址與連接埠。若出現位址已被使用的錯誤，先確認是否有其他代理程式或背景服務仍在執行。允許區域網路存取也不只是開啟一個布林值，還需考量監聽位址、系統防火牆與存取控制；不要將代理連接埠直接暴露在不受信任的網路中。

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

規則、全域與直連

mode: rule 會讓流量進入規則清單，依比對結果選擇對外連線；全域模式通常交由全域選擇項處理；直連模式則不會依自訂規則選擇代理節點。模式決定路由入口，不是流量接管方式。即使選擇全域模式，未經系統代理、應用程式設定或 TUN 接收的流量，也不會自動進入核心。反過來說，規則模式中若某條規則符合 DIRECT，連線依然由核心接收，只是最後選擇直連。

系統代理通常會修改作業系統提供給應用程式的代理設定，應用程式是否遵循則由它自行決定。TUN 透過虛擬網卡與路由接收流量，涵蓋範圍較廣，但會牽涉權限、路由衝突與 DNS 接管。TUN 不是「更強的全域模式」，也不代表啟用後就能解決所有網路問題。遊戲、虛擬機器、容器與企業 VPN 的流量路徑各不相同；啟用前請保存目前狀態，並確認能還原原本的預設路由與解析設定。

TUN 與用戶端設定的分工

# TUN 片段：啟用前確認用戶端權限與路由環境
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

上述範例描述自動路由及接管傳統 DNS 請求的設定意圖，但不保證能涵蓋應用程式內建的加密 DNS 或所有平台的網路堆疊。不同系統對虛擬網卡、服務權限與防火牆的要求各異，用戶端也可能統一管理這些欄位。若介面開關與檔案設定互相覆蓋，請先決定由哪個入口負責管理。具體啟用流程請參閱入門指南；本頁只說明欄位關係，避免在不了解用戶端實作方式時直接替換整段網路設定。

日常使用時，記錄層級適合設為 info，重現故障時再暫時增加詳細程度。除錯記錄可能包含目標網域、連線資訊與設定檔路徑，分享前請先移除敏感資料。根層級的 ipv6 與 DNS 內同名欄位分別影響不同環節，不要只修改其中一項就認定 IPv6 路徑已完整設定。涉及遠端控制介面時，也要分清控制面與代理面的用途：管理介面用來修改狀態，不應作為一般應用程式的代理入口。

開機自動啟動、背景啟動、佈景主題與系統匣行為多半屬於圖形介面用戶端的偏好，不是所有核心都通用的 YAML 欄位。遷移設定時，應分別記錄「網路行為」與「介面行為」。選擇用戶端請前往安裝檔下載頁面；一般使用者可優先考慮 Clash Plus，再依作業系統與設定相容需求選擇 Clash Verge Rev 等用戶端。不要只因介面相似，就認定設定檔可以直接互換。

DNS 欄位與網域解析路徑

DNS 的用途是將網域名稱轉換為位址，但在代理環境中，解析往往不只一個階段。應用程式可能先自行解析，核心可能為規則比對查詢目標位址，連線至代理伺服器時也可能需要解析伺服器網域。先分清這些解析對象，才能理解為什麼某個網域在瀏覽器可以連線，命令列卻失敗，或為什麼節點使用網域名稱時無法連線。設定加密解析伺服器，不代表所有應用程式都會使用它，也不代表路由已選擇代理連線。

監聽、上游與啟動解析

dns.enable 控制核心的 DNS 功能，listen 指定 DNS 監聽位址，nameserver 指定一般解析的上游伺服器。使用網域名稱形式的 DoH 位址時，必須先取得該上游伺服器的位址，這就是啟動解析問題。default-nameserver 可用於這類基礎解析，建議使用明確的 IP 位址。節點伺服器本身若使用網域名稱，可透過 proxy-server-nameserver 指定解析來源，避免把伺服器解析與目標網域分流混為一談。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 1.1.1.1
  nameserver:
    - https://dns.google/dns-query
  proxy-server-nameserver:
    - https://dns.google/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"

這是欄位關係範例，不是適用於所有網路環境的解析方案。上游伺服器的連線能力會受網路環境影響，選用前應先測試是否可連線。只讓核心監聽 1053 連接埠，不會自動將系統 DNS 請求導向此處；需要由用戶端或系統網路設定負責轉送。TUN 情境則應確認攔截與路由確實生效。若應用程式啟用了自己的安全 DNS，可能會繞過傳統連接埠上的接管路徑，排查時請將這項因素另外記錄。

fake-ip 與真實位址解析

fake-ip 模式會將保留位址範圍內的映射位址回傳給應用程式，再由核心依映射還原網域名稱並安排連線。這有助於保留網域資訊，但前提是相關流量仍經過同一個核心；應用程式取得映射位址後若繞過代理路徑，就可能無法連線。部分區域網路服務、探索協定或對位址有特殊假設的軟體不適用這類回應，可視需要透過排除項目處理。不要只為了解決單一應用程式的問題就排除所有網域，否則會失去選用此模式的原本目的。

redir-host 通常會回傳解析後的真實位址，行為與 fake-ip 不同，但不代表在所有環境中都更穩定。多個網域可能共用同一個真實位址；部分連線進入核心時若缺少網域資訊，規則比對結果便可能改變。切換這兩種模式後，應清除相關應用程式的快取或重新建立連線，否則舊位址仍會影響觀察結果。看到保留位址不代表網路一定異常，也不要將它當成真實網站伺服器位址來判斷地理位置。

依網域選擇解析器

nameserver-policy 可為特定網域指定解析來源，適合企業內部網域、家用裝置名稱或有明確解析需求的服務。它控制的是「向哪裡查詢」，不是「連線走哪個出口」；若要改變業務流量路徑，仍須設定規則。內部解析器通常只能在指定區域網路或 VPN 中使用，離開網路後繼續強制使用便可能逾時。維護這類設定時，請記錄適用的網路環境，並避免將內部網域交由無關的公開解析服務查詢。

# 合併至現有的 dns 映射中，不要重複宣告頂層 dns
dns:
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1

fallback 與過濾條件是另一套選擇機制，不能簡單理解成主要伺服器失敗後才啟用的備援清單。是否接受某個解析結果，也可能取決於位址範圍或相關過濾設定。沒有明確需求時，不必為了讓設定看起來「完整」而加入多組解析器。設定越複雜，越難分辨結果是來自快取、策略還是備援路徑。先保留單一可用的上游，確認接管路徑正常後，再逐項增加策略，通常更容易找出問題所在階段。

檢查 DNS 洩漏時，先說明預期行為：哪些請求應由系統解析、哪些交由核心處理、哪些由代理伺服器處理，再透過實際連線與解析記錄驗證。檢測網站顯示的解析出口只反映單次測試，不能取代對應用程式行為的檢查。若解析正常但 HTTPS 出現錯誤，不要直接修改憑證驗證；可參考代理連線後憑證錯誤排查，檢查系統時間、信任鏈與網路環境，分別處理解析與憑證問題。

代理節點欄位與連線參數

proxies 是靜態對外連線的定義清單，每個項目描述一種具體連線方式。節點名稱供策略組與規則引用，伺服器位址、連接埠、協定與驗證欄位則決定能否建立連線。節點名稱標示某個地區，只是維護者提供的標籤，不能證明伺服器所在地或連線品質。排查連線失敗時，應先確認實際協定與伺服器參數，而不是反覆修改顯示名稱；改名只會影響引用關係，無法修復遠端服務。

共通欄位與協定專用欄位

多數節點都有 name、type、server 與 port，但驗證與傳輸欄位不能跨協定照抄。Shadowsocks 使用加密方式與密碼，其他協定則可能使用使用者名稱、識別碼或不同的 TLS 參數。同名欄位在不同協定實作中的支援情況也可能不同。請以伺服器提供的參數與目前核心支援範圍為準；尤其不要憑直覺將分享連結中的每段文字填入 YAML，編碼、跳脫與選用參數都有明確規則。

# 結構範例：位址與密碼為教學用假資料
proxies:
  - name: 範例出口
    type: ss
    server: proxy.example.com
    port: 443
    cipher: aes-128-gcm
    password: "your-password"
    udp: true

上述範例展示靜態節點的基本組織方式，無法用於實際連線。udp: true 表示允許此對外連線使用相應能力，不保證整條連線路徑都支援 UDP；伺服器、協定、路由與應用程式的接入方式都可能形成限制。TCP 網頁瀏覽正常，也不能證明語音、遊戲或其他 UDP 服務一定可用。測試時應使用與實際應用程式相同的傳輸路徑，分別確認連線是否進入核心、是否選到預期出口，以及伺服器是否有收到連線。

TLS、伺服器名稱與傳輸層

啟用 TLS 的協定常見 servername 等伺服器名稱欄位，用於交握與憑證名稱比對；它不等於本機顯示名稱，也不一定等於底層連線使用的 IP。伺服器要求特定名稱時，請正確填寫，不要為了繞過錯誤就隨意改成其他網域。憑證錯誤應先檢查系統時間、憑證鏈與參數是否一致。關閉憑證驗證會改變安全性，不應作為一般排查步驟，更不應寫入供所有裝置共用的公開設定。

傳輸類型、路徑與要求標頭等設定屬於另一層交涉。以 WebSocket 類型的傳輸為例，路徑與 Host 可能由反向代理設定決定；底層連接埠能建立 TCP 連線，不代表後續傳輸交握也會成功。若記錄顯示連線重設或交握失敗，請逐項比對伺服器提供的資訊。每次只調整一個變數並保留失敗記錄，比同時更換網域、連接埠與傳輸類型更有助於診斷，也能避免把短暫的網路波動誤判為參數修正。

節點提供器與訂閱格式

節點數量較多時，可透過 proxy-providers 將節點資料與主設定分開。提供器通常回傳包含 proxies 清單的 YAML，不是任意分享連結的集合，也不一定等同完整的 Clash 設定。提供器的類型、路徑與更新週期用來描述資料取得方式，策略組再透過 use 引用提供器。匯入失敗時，先確認回傳內容是否符合預期格式；登入頁面、錯誤訊息或 HTML 頁面即使下載成功，也不是合法的節點資料。

# 本機提供器；paths 請依核心工作目錄與用戶端限制設定
proxy-providers:
  本機節點:
    type: file
    path: ./providers/local.yaml

proxy-groups:
  - name: 提供器選擇
    type: select
    use:
      - 本機節點

本機提供器範例需要事先準備實際資料檔案，路徑通常以核心工作目錄為基準解析，也可能受用戶端的路徑限制影響。不要假設路徑是相對於目前在編輯器中開啟的資料夾。遠端提供器還牽涉更新失敗、快取與存取憑證；訂閱連結本身通常含有存取權限，應視為敏感資訊。分享畫面截圖、記錄或錯誤訊息時，不只要遮蔽密碼，也要移除完整訂閱網址與查詢參數，避免他人取得相同的服務資料。

節點名稱在整份設定中最好保持唯一，並避免與策略組名稱或內建對外連線名稱衝突。批次重新命名後，請同步更新所有靜態引用；使用提供器時則要確認篩選條件仍能符合名稱。部分服務更新時會替換名稱或移除節點，因此長期規則不宜綁定經常變動的特定節點。較穩妥的做法是讓規則指向名稱固定的策略組，由群組負責因應節點變動，將業務路由與伺服器清單分開維護。

策略組類型與引用關係

策略組將「某類流量應使用哪個出口」與「目前有哪些節點可選」分開處理。規則可以固定引用一個穩定的組名，組內節點則隨訂閱更新而變動。理解策略組時，應一併查看類型、候選項目及引用位置。自動選擇組只有在流量實際指向它時才會生效；在介面中看到測試結果，不代表所有連線都會使用該組。頂層手動選擇組若仍選用直連，底下的自動組即使正常運作，也不會改變這條業務路徑。

手動選擇、自動測試與故障備援

select 最容易預測，適合對出口變動敏感的登入與辦公業務。url-test 會透過測試網址比較候選項目，但測量的是特定請求的完成情況，不等於實際應用程式的傳輸量。fallback 著重候選順序，適合設定主要與備援出口。負載分配不代表同一個檔案會同時使用所有節點來加總速度；不同分配策略也可能影響工作階段的出口穩定性。請依業務可接受的變動程度選擇，不要把自動化程度當成效能排名。

巢狀結構與可追蹤路徑

# 合併至既有節點設定後使用；範例出口必須實際存在
proxy-groups:
  - name: 業務出口
    type: select
    proxies:
      - 範例出口
      - 自動選擇
      - DIRECT

  - name: 自動選擇
    type: url-test
    proxies:
      - 範例出口
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

rules:
  - MATCH,業務出口

上述範例的連線路徑是由規則指向「業務出口」，再由使用者決定要使用靜態節點、自動選擇組或直連。巢狀結構有助於重複利用，但層級越深越難判斷最終出口。建議讓組名清楚表達用途與職責，不要反覆使用含糊的「預設」或「其他」。也要避免循環引用，例如甲組包含乙組，而乙組又引用甲組。循環不是備援路徑，而是無法判定出口的相依錯誤；核心或用戶端可能會直接拒絕載入。

自動測試的 url、interval 與容許差異參數應依服務行為設定。測試目標無法連線時，多個原本正常的節點可能同時顯示失敗，因此不要只憑一次測試就刪除節點。測試太頻繁會增加連線數與行動裝置的背景耗電；間隔太久則會延遲狀態變化。測試位址最好能提供簡單且可預期的回應，但仍要留意它與實際目標服務的網路路徑不一定相同，不能因此推斷所有網站的使用體驗。

提供器、篩選與選擇狀態保存

群組透過 use 引用節點提供器時，候選項目會隨提供器內容變動。若再使用名稱篩選，請確認條件能符合實際名稱，並考慮更新後候選清單變空的情況。不要讓所有分流群組都依賴同一套脆弱的命名規則；一旦伺服器端更改標籤，整份設定就可能失去候選項目。使用篩選時，可先在測試設定中確認比對結果，再套用到業務群組；保留明確可用的手動入口，有助於故障時恢復。

用戶端可能會記住手動選擇，也可能在切換設定、名稱變動或重建快取後恢復預設項目。不要讓組中的第一個項目承擔未寫入文件的隱含安全約定。業務若要求固定出口，每次更新後都應確認選擇狀態，而不只是確認設定載入成功。現有連線通常也不會因為修改組的選擇就立即全部切換；連線重用、長連線與用戶端行為都會影響觀察結果，驗證時請建立新請求並檢查實際路徑。

為行動裝置維護設定時，應減少不必要的重複健康檢查，讓同一提供器的檢查與組內測試各有用途。若每個業務群組都完整測試同一批節點，背景請求可能大幅增加。電池與背景執行設定可參考手機代理用戶端耗電與背景執行策略。策略組的目標是讓出口選擇更清楚，不是用盡所有類型；兩層結構已能說明的路由，就不必堆疊成多層選擇樹。

規則語法、順序與規則集

規則清單是連線進入核心後的路由決策流程，通常由上而下檢查，第一條符合的規則就會決定目標出口。它不會綜合所有符合的結果評分，也不會自動將較具體的規則移到前面。維護規則時，除了查看單條內容，也必須檢查它前面有哪些規則。常見的「規則沒有生效」，其實是前面的寬泛規則已先符合，或用戶端仍在執行另一份設定。先從連線記錄找出實際符合的規則，再進行修改，比憑對目標網站所在地的印象調整更可靠。

網域、位址與最終備援規則

# 業務出口必須是已存在的策略組
rules:
  - DOMAIN,service.example.com,業務出口
  - DOMAIN-SUFFIX,example.net,業務出口
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - 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 依關鍵字比對，涵蓋範圍較廣，也容易誤判包含相同字串的其他網域；已知服務網域時，應優先使用精確比對或後綴規則。同一網站也可能載入多個資源網域，主頁符合規則，不代表圖片、登入與 API 都會走相同出口。

IP-CIDR 與 IP-CIDR6 分別處理 IPv4 與 IPv6 網段。no-resolve 用來避免此類比對主動觸發目標網域解析，不代表強制直連，也不負責封鎖 DNS。若連線已取得目標位址，相關位址規則仍可能參與比對。將大範圍位址規則放在網域規則之前，可能使原本預期按業務名稱處理的連線提早結束路由判斷。規則順序應反映優先層級，而不是依規則類型機械式分組。

規則比對取決於可見資訊

網域規則能否符合，取決於核心是否知道目標網域。應用程式直接連到 IP、使用自己的解析結果，或某些接管路徑遺失網域資訊時，結果可能與瀏覽器代理請求不同。在支援的情境中，嗅探可以補充部分資訊，但無法還原所有協定的原始網域，也不能用來繞過加密保護。排查時先查看記錄中顯示的是網域還是位址，再判斷應使用網域規則、位址規則，或調整 DNS 與接管方式。

MATCH 是最後的備援規則，通常放在清單末尾。它後面的普通規則不會再有比對機會。內建對外連線 DIRECT 代表直連，REJECT 用於拒絕連線，自訂目標則必須與節點或組名完全一致。大小寫錯誤、混入不可見空格或重新命名後漏改引用，都可能造成載入失敗。維護拒絕規則時尤其要限定範圍，先用明確的測試對象驗證，不要將模糊關鍵字直接擴大套用到整份訂閱。

規則提供器與資料內容

rule-providers:
  內部網域:
    type: file
    behavior: domain
    path: ./rules/internal.yaml

rules:
  - RULE-SET,內部網域,DIRECT
  - MATCH,業務出口

# ./rules/internal.yaml 的內容
payload:
  - "+.home.arpa"
  - "+.lan"

規則集將大型清單從主檔分離，方便更新與重複使用。behavior: domain 的資料內容是網域規則；位址類資料與傳統規則資料格式不同，不能只改變行為欄位就繼續沿用原本文字。傳統資料通常只放比對條件，由主設定中的 RULE-SET 規則指定目標出口；請依選用格式檢查，不要將完整的主設定規則不加區分地塞入所有類型的資料中。

遠端規則更新也涉及維護範圍：上游可能增刪內容，快取可能讓舊結果繼續生效，下載失敗時也可能只保留既有檔案。請記錄規則集來源與用途，避免覆蓋範圍高度重疊的兩個集合連續套用相反目標，卻沒有明確的優先順序。與節點訂閱一樣，檔案更新成功只代表取得資料完成，不代表業務結果符合預期。更新後至少抽查一筆應符合及一筆不應符合的請求，確認規則範圍沒有改變。

程序規則仰賴平台與程序識別能力，不宜直接作為跨系統設定的唯一分流依據。應用程式名稱也可能因啟動器、子程序或容器環境而改變。在 Windows 商店應用程式完全沒有連線記錄時，應先確認請求是否能到達代理入口，可參考UWP 迴送豁免設定；若流量根本沒有進入核心，就不要反覆新增路由規則。規則只能處理已接收的連線，無法解決入口層的隔離問題。

訂閱覆寫、合併與更新順序

訂閱更新最容易與本機自訂設定衝突。遠端訂閱負責提供節點、策略組或規則，本機使用者可能希望固定連接埠、增加內部網路直連，或變更特定業務的出口。直接修改已下載的原始訂閱，下次更新時很可能就會被重新產生的內容取代。可靠的維護方式是保留遠端來源，將本機需求寫在用戶端支援的覆寫入口，並確認修改出現在最終執行設定中，而不只是確認編輯器已儲存。

先確認由哪一層決定最終結果

不同用戶端的處理流程並不完全相同，可能依序經過訂閱下載、解析轉換、設定檔覆寫、全域覆寫、GUI 設定注入與核心載入等階段。本頁無法提供適用於所有用戶端的統一執行順序。請在使用的用戶端中查看預覽或執行設定，並透過一個可觀察的欄位驗證實際結果。例如只修改記錄層級，套用後查看最終值；確認該入口確實參與目前訂閱的產生流程後，再移轉較複雜的規則與 DNS 設定。

覆寫不是固定的 YAML 語意，而是用戶端或工具實作的轉換流程。純量可能被取代，映射可能遞迴合併，清單則可能整份取代、附加或移到前面；這些行為取決於具體實作。所謂「深度合併」也不能自動解決規則優先順序，因為規則清單本身就有順序。看到兩段 rules，不要推斷它們會自動串接，更不要把某個用戶端專用的前置鍵當成核心原生欄位複製到其他用戶端。

分別檢查映射與清單

# 預期的最終片段；不是適用於所有用戶端的覆寫語法
dns:
  enable: true
  nameserver:
    - https://dns.google/dns-query
  nameserver-policy:
    "+.home.arpa":
      - 192.168.1.1

rules:
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - MATCH,業務出口

上述範例著重於最終目標結構。如果覆寫工具整體取代 dns，原有的監聽、啟動解析與過濾項目可能一併遭刪除；若將內容附加到 nameserver，也可能留下原本想移除的上游伺服器。規則更需要檢查插入位置：自訂內部網路規則應放在會搶先符合的備援規則之前，而不是加在既有的 MATCH 後面。預覽最終設定時，應同時檢查欄位值與清單順序，不能只用搜尋確認字串存在。

引用穩定性與衝突處理

自訂規則若指向訂閱產生的組名，上游改名就會使引用失效。可使用名稱固定的本機業務組作為規則目標，再讓它引用可更新的節點或提供器；前提是所用的覆寫機制能可靠建立並保留該組。不要只建立一個與訂閱同名的組來「覆蓋」，因為某些合併方式會產生重複名稱，而不是取代原項目。需要取代時，應明確刪除舊物件，或使用工具提供的物件轉換功能，並確認最終清單中名稱唯一。

同一份訂閱可能為不同平台提供不同預設值，跨裝置同步覆寫時不能忽略本機差異。DNS 監聽位址、區域網路網段、TUN 權限與本機檔案路徑通常與裝置環境有關，不適合直接共用。建議將自訂內容分為通用業務規則與裝置設定兩部分，並在註解中說明用途及相依條件。更換電腦或用戶端時，便能保留業務需求，重新調整入口與權限，而不是把整份舊的執行設定當成新的訂閱來源。

使用指令碼覆寫時，應把它視為能修改完整設定的程式碼，而不只是另一種註解格式。指令碼發生例外可能使產生流程中斷，錯誤的物件存取也可能刪除欄位或改錯型別。請縮小轉換範圍，明確處理輸入為空、清單不存在或名稱比對不到等情況。不要只為了新增一條規則就重建所有節點清單；每次不必要的重寫都會擴大訂閱更新後的故障範圍。指令碼與 YAML 應分開備份，方便判斷問題出在哪一層。

更新後的回歸測試與遷移

完成覆寫後，至少執行一次更新測試：先備份，再重新整理訂閱，接著查看執行設定與連線路徑，確認自訂規則、組的選擇與 DNS 欄位仍然存在。手動套用後成功，不代表自動更新流程也正確。更新後若出現異常，先暫時停用本機覆寫，確認原始訂閱是否可正常運作，再逐層恢復。關於從停止維護的用戶端遷移，可閱讀遷移至 Clash Verge Rev 的方案比較；重點是保留設定意圖，而不是舊介面的快取狀態。

設定驗證、故障定位與維護

驗證設定應分階段進行：先確認文字可解析，再確認核心接受欄位與引用，接著檢查監聽入口，最後驗證解析、路由與實際使用情況。設定測試通過，只代表目前核心能理解檔案，不保證伺服器可連線、密碼正確或目標服務允許存取。網頁能開啟也只證明這次請求成功，不能取代對區域網路、UDP、背景應用程式與訂閱更新等其他路徑的檢查。清楚記下每次測試的輸入、預期與觀察結果，比籠統記錄「正常」更有幫助。

從離線檢查到執行檢查

# 已安裝 Mihomo 且命令可用時，請在設定檔所在目錄執行
mihomo -t -f ./config.yaml

# 在 Windows PowerShell 中，若執行檔位於目前目錄
.\mihomo.exe -t -f .\config.yaml

這些命令只適用於實際安裝核心程式的環境。圖形介面用戶端可能使用自己的工作目錄、受控路徑與產生檔案，不要隨意用外部核心覆蓋正在執行的實例。測試本機提供器時，也要確認相對路徑與工作目錄一致；否則即使主檔語法正確，仍可能因資料檔案不存在而失敗。錯誤訊息通常包含欄位、名稱或行號，請從第一個有意義的錯誤開始處理；後續錯誤可能只是同一個階層問題引起的連鎖反應。

測試通過後，確認目前用戶端是否真的選取並載入這份設定。查看記錄中的載入結果、監聽位址與可能的權限錯誤；連接埠遭占用、建立 TUN 裝置失敗與取得訂閱失敗，屬於不同階段的問題，不應一概歸為節點無法使用。設定載入遭拒時，有些用戶端可能會保留先前的執行狀態，因此「網路仍可使用」不代表新設定已生效。對照一個剛修改且可觀察的欄位，就能避免將舊狀態誤認為新結果。

用最小測試流程驗證請求

# 明確指定 HTTP 代理入口，排除應用程式是否遵循系統代理的差異
curl -I --proxy http://127.0.0.1:7897 https://example.com/

# SOCKS 入口；h 表示將目標網域交由代理端處理
curl -I --proxy socks5h://127.0.0.1:7897 https://example.com/

這些命令用來檢查明確指定的代理入口，範例目標服務不保證永遠回傳特定狀態碼。收到 HTTP 錯誤回應與無法建立代理連線是兩種不同結果：前者表示請求至少已到達某個 HTTP 服務，後者還需檢查監聽、協定與連線路徑。在 Windows 環境中，若 curl 被其他命令別名取代，請確認是否應改用 curl.exe。不要將單一命令成功直接套用到瀏覽器；瀏覽器還可能使用擴充功能、自行解析或既有連線池。

建立可還原的修改流程

每次只修改一個層面，並保留修改前的檔案與簡短說明。備份不只應包含主設定，也要包含本機提供器、規則資料與覆寫指令碼，否則還原主檔後仍可能引用已變動的資料。檔名可標示用途與儲存日期，但不必寫入敏感訂閱位址。變更系統代理、DNS 或 TUN 時，也要記下如何停用並還原；若要在遠端裝置上修改預設路由，尤其應先準備不依賴該代理的復原管道。

重現問題時，先關閉無關的代理程式，使用固定測試目標，分別比較直連與明確指定代理的結果。若問題只出現在特定應用程式，應記錄該應用程式的接管方式、解析方式與程序路徑，不要立刻替換整份訂閱。若所有節點同時失敗，先檢查本機網路、解析上游與測試目標；若只有個別節點失敗，再深入檢查伺服器端與協定參數。依這樣的順序逐步判斷，可減少不必要的修改，也讓記錄與實際故障相互對應。

長期維護也應檢查已失效的自訂內容：不再使用的規則集、舊網段、改名後的組引用，以及為單次故障暫時新增的例外。每次更新訂閱或用戶端後，優先確認這些範圍即可，不必重新測試所有網站。向他人尋求協助時，提供已移除敏感資訊的最小設定、錯誤訊息、接管方式與預期路徑即可；常見入口問題可繼續參閱故障排除，初次連線問題則回到入門指南依照主要步驟逐一驗證。