Clash YAML 設定檔參考

1. YAML 結構與設定載入流程

先分清來源檔與執行檔

Clash 設定不只是記錄節點的清單。頂層通常還包含監聽連接埠、代理模式、DNS、節點、策略群組與規則。用戶端匯入訂閱後，可能先儲存遠端內容，再套用本機設定，最後產生交由核心讀取的執行檔。因此，編輯器中看到的訂閱內容，不一定與核心目前讀取的內容相同。排查時請記下目前選取的設定名稱，並找出用戶端提供的執行設定檢視入口，避免改到未啟用的檔案後一再重新啟動。

原始訂閱適合保留由伺服器維護的節點與群組，本機擴充則適合存放個人規則。將兩者分開，可減少更新時互相覆蓋的情況。如果用戶端沒有清楚標示擴充設定的適用範圍，請先用一條容易觀察的規則測試，再確認它是否只套用於目前的訂閱。不要只憑檔名推測設定是否已載入；介面上的選取項目、記錄中的載入結果，以及實際請求的規則記錄，應能互相核對。

縮排、型別與引用名稱

YAML 以縮排表示層級，建議統一使用兩個空格，不要混用定位字元。冒號後的空格用來區分鍵與值，短橫線則表示清單項目。同一清單中的各個物件，其屬性應保持對齊。連接埠通常以整數表示，開關則使用小寫布林值；若將布林值加上引號，就會變成字串，部分欄位因此可能發生型別錯誤。節點名稱與策略群組名稱是引用識別字，大小寫、空格與標點都會影響比對，不會自動修正相似名稱。

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

proxies: []

proxy-groups:
  - name: 出口選擇
    type: select
    proxies:
      - DIRECT

rules:
  - MATCH,出口選擇

上例是僅使用直連的基礎設定檔，用來檢查解析結果與引用關係，不提供代理出口。節點清單留空是合法的，策略群組引用的是內建的 DIRECT。之後新增節點時，請先在 proxies 中定義節點，再將其名稱加入策略群組。規則最後引用策略群組，串起請求、規則、策略與出口。理解這條流程，比一次複製大量複雜欄位更重要。

引號與重複鍵

密碼、含特殊符號的名稱，以及可能被解析成其他型別的字串，適合加上引號。如果字串中包含冒號加空格、註解符號或換行，請特別留意解析結果。單引號字串中的單引號須連續輸入兩次；雙引號則可使用跳脫字元，反斜線也須依規則處理。不要把網頁排版產生的彎引號當成 YAML 引號。註解只能說明內容，不會改變欄位意義，也不能代替缺少的必要參數。

同一層級不要重複定義 dns、rules 或 proxy-groups。部分解析器會拒絕重複鍵，另一些流程則可能保留後面的值，結果難以預測。將兩段各自含有 dns 的範例拼在一起，不代表 DNS 設定已合併。請保留一個父鍵，再將需要的子欄位移入其中。清單也一樣：新增規則時，請加入現有的 rules 清單，不要再建立同名的頂層鍵。

如果能使用核心命令列，可執行以下測試命令。請依裝置實際情況調整執行檔名稱與設定路徑；若圖形用戶端提供設定檢查功能，請優先使用該功能。語法檢查通過只代表檔案可供載入，不代表遠端節點可連線，也不代表策略符合預期。啟動後仍須檢查監聽連接埠、規則命中情況與出口選擇；記錄檔的詳細閱讀方式請參考執行記錄排查方法。

mihomo -t -f config.yaml

2. 連接埠、代理模式與通用欄位

監聽連接埠只負責接收請求

port 是 HTTP 代理監聽連接埠，socks-port 是 SOCKS 監聽連接埠，mixed-port 則會在同一個連接埠接收 HTTP 與 SOCKS 請求。這些欄位設定的是應用程式連線至本機核心的入口，不是遠端節點的連接埠。應用程式填入本機位址與 mixed-port 後，請求才會進入核心；遠端節點的連線方式仍由節點欄位決定。初次設定通常保留一個混合連接埠即可，只有確定需要獨立入口時才增加其他連接埠。

連接埠衝突通常是因為兩個用戶端同時執行、舊核心尚未結束，或其他程式已監聽相同位址。遇到位址被占用的錯誤時，請先結束重複的處理程序，再決定是否更換連接埠。修改連接埠後，也要同步更新瀏覽器手動代理、終端機環境變數及區域網路裝置上的設定。用戶端顯示啟動成功，不代表所有應用程式都已改用新連接埠；請從應用程式本身的代理設定反向核對，不要只看用戶端開關。

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

規則、全域與直連模式

mode: rule 會依 rules 順序決定出口；mode: global 會將流量交由全域策略處理；mode: direct 則採用直連。這裡的全域模式只適用於已進入核心的流量，不會自動接管所有應用程式。某些程式不遵循系統代理，即使切換至全域模式，也可能仍然直連。要判斷模式是否生效，請先確認連線記錄中出現了該請求，再檢查對應出口。模式切換的介面操作請參閱代理模式說明。

全域模式適合用來暫時確認分流規則是否造成問題，不應當成解決所有網路故障的按鈕。如果規則模式失敗、全域模式成功，請優先檢查命中規則與所選策略群組；如果兩種模式都失敗，則應檢查節點參數、網路連線與 DNS 解析流程。直連模式也不會自動清除作業系統的代理設定，應用程式仍可能先連至本機監聽連接埠，再由核心直連。因此關閉核心前，請確認系統代理設定可以正常還原。

監聽範圍與管理介面

allow-lan 與 bind-address 需要一併理解。前者用來設定是否允許區域網路使用，後者則限制監聽位址。僅供本機使用時，可限制為迴路位址；確實需要共用時，再依實際網路介面、防火牆與驗證需求開放。將監聽位址設為所有介面，不代表外部裝置一定連得上，還得視路由與系統安全規則而定。也不要為了排查手機連線問題，就直接將服務公開至網際網路。

代理入口與 external-controller 管理介面是兩回事。管理介面用來控制設定、策略與連線狀態，不應填入瀏覽器的代理連接埠。用戶端通常會自行產生介面位址與存取憑證，手動修改可能導致介面無法連線。一般桌面使用不必為了套用範例而額外開放管理介面；若需要遠端管理，請另外規劃存取限制，不要沿用代理監聽連接埠的信任範圍。

log-level 日常使用時設為 info 通常就足夠，排查問題時可暫時切換至 debug，重現一次後再恢復。記錄檔可能包含存取網域、節點名稱與本機路徑，分享前請移除個人資訊。若通用欄位每次啟動都會還原，請先確認用戶端設定頁是否有管理同名選項；如果有，請在設定頁修改，不要一直編輯自動產生的檔案。瀏覽器與終端機行為不一致時，另請參閱系統代理分流排查。

3. 代理節點欄位與外部節點集合

節點物件的共同欄位

proxies 是節點物件清單，每個節點通常都會有 name、type、server 與 port。name 供策略群組引用；type 決定通訊協定及其他欄位的解讀方式；server 是遠端位址；port 是遠端服務的連接埠。不同通訊協定的驗證欄位、加密方式與傳輸設定各不相同。不能只將 type 從一種通訊協定改成另一種，卻保留原有參數並期待自動相容；用戶端能解析物件，也不代表遠端提供相應服務。

請完整保留訂閱提供的節點參數，尤其是 TLS、傳輸層與通訊協定專屬欄位。某些分享連結可由用戶端轉換成節點物件，但轉換結果仍受核心支援範圍限制。用戶端名稱相同或介面相似，不代表內建相同核心。選擇用戶端時，可先查看下載中心，優先考慮 Clash Plus；遷移現有設定前，再透過用戶端比較確認平台與設定的相容方向。

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

proxy-groups:
  - name: 出口選擇
    type: select
    proxies:
      - 範例出口
      - DIRECT

上例展示 Shadowsocks 節點與策略群組的引用關係，網域與密碼僅供說明，必須替換為服務實際提供的參數。cipher 必須與伺服器端一致，並非越複雜越好；udp 表示允許該節點處理相應的 UDP 流量，但無法讓原本不支援 UDP 的服務因此增加此功能。若修改節點名稱，也要同步修改所有直接引用該名稱的策略群組，否則設定可能在檢查引用時失敗。

TLS 與傳輸層不是可任意切換的最佳化選項

對於使用 TLS 的通訊協定，server、servername 與憑證驗證各自負責不同工作。server 決定連線目標；servername 通常用於 TLS 交握時的伺服器名稱指示，以及憑證名稱檢查。兩者可能相同，也可能因部署方式而異，應依服務提供的參數填寫。連線失敗時，不要先啟用略過憑證驗證；請先檢查裝置時間、伺服器名稱、憑證有效性與網路路徑，避免長期掩蓋部署錯誤。

WebSocket 路徑、要求標頭與其他傳輸參數也必須與遠端設定相符。即使伺服器位址複製正確，漏掉路徑或要求標頭仍可能造成交握失敗。建議由底層往上排查：網域能否解析、目標連接埠是否可連線、TLS 是否成功、通訊協定驗證是否通過，最後再檢查規則與目標網站。如果記錄明確指出驗證失敗，就不必反覆修改 DNS 或策略群組順序，應回頭檢查節點參數與帳戶狀態。

使用 proxy-providers 管理外部節點

proxy-providers 可將節點集合從主檔案中分離，適合需要定期更新節點、又希望規則與策略群組維持穩定的設定。提供器內容必須是核心支援的節點集合格式，不是任意網頁，也不一定等同於完整的用戶端訂閱。主設定中的策略群組透過 use 引用提供器名稱，不是將提供器名稱當成一般節點放入 proxies。兩種清單的引用方式不同，不應混用。

proxy-providers:
  本機節點：
    type: file
    path: ./providers/local.yaml
    health-check:
      enable: false

proxy-groups:
  - name: 出口選擇
    type: select
    use:
      - 本機節點
    proxies:
      - DIRECT

本機檔案可採用以下結構。相對路徑應依實際設定目錄與用戶端執行方式判斷，不要預設它一定相對於桌面捷徑所在目錄。請先確認檔案確實已載入，再檢查節點是否出現。遠端提供器還涉及更新間隔、快取與請求出口；若更新失敗，請分別檢查下載請求與舊快取是否可用，不要立刻刪除所有設定。

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

訂閱連結可能包含帳戶授權資訊，請妥善保管，如同保護其他憑證。分享設定時，除了密碼，也要檢查遠端提供器位址與要求標頭。如果伺服器更新後節點名稱有所變動，手動指定的單一節點引用可能會失效；透過提供器連接的策略群組通常較容易因應集合變更。選擇節點時不只要看測試結果，也要考量用途、地區與流量規則；詳細判斷方式請參閱節點選擇方法。

4. 策略群組類型與引用關係

策略群組是決定出口的層級

策略群組將規則引用與實際節點分開。規則指向穩定的群組名稱，群組內再選擇節點或其他群組，替換節點時通常就不必重寫所有規則。群組名稱與節點名稱應各自保持唯一且容易辨認，避免同名造成混淆。設計時請先畫出請求的單向路徑：規則進入業務群組、業務群組進入選擇群組，選擇群組最後連到節點或 DIRECT。每條路徑都必須有終點，不能繞回自身。

select 用於手動選擇，url-test 依測試結果自動選擇，fallback 依序尋找可用項目，load-balance 則依設定策略分配連線。它們解決的問題各不相同，不是四種效能等級。需要固定出口的登入業務若頻繁自動切換，可能觸發重新驗證；一般瀏覽則可能透過自動選擇減少手動維護。請依業務需求選擇類型，不要把所有節點都套用同一種自動群組。

proxy-groups:
  - name: 出口選擇
    type: select
    proxies:
      - 自動選擇
      - DIRECT

  - name: 自動選擇
    type: url-test
    use:
      - 本機節點
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

rules:
  - MATCH,出口選擇

此片段依賴上一章的本機節點提供器。url 是實際測試目標，interval 是測試間隔秒數，tolerance 是自動切換時採用的延遲容差（毫秒）。測試目標應能代表實際用途，並且允許持續存取；範例網址不是外部頁面資源，不會由本頁瀏覽器自動載入。測試請求成功只代表這條測試路徑可用，不能證明所有網站、影音服務或 UDP 應用程式都能正常運作。

自動選擇與故障備援的適用範圍

url-test 通常會優先選擇測試條件下表現較好的候選項目；fallback 則更重視順序與可用性。如果希望優先使用固定出口，並在失敗時才改用備用出口，fallback 會比單純追求較短測試時間更符合需求。測試失敗也可能是測試位址受到限制、暫時無法解析或網路不穩造成，不應立刻認定節點完全失效。請先以實際用途驗證，再決定是否更換測試目標或延長觀察時間。

load-balance 不會將多條線路合併成單一下載連線，也不能保證所有連線使用相同的公用 IP 位址。不同分配策略對目標與連線的處理方式不同，使用前請確認出口變動是否可接受。涉及帳戶風險控管、付款或長時間連線的應用程式，通常較適合固定選擇。即使啟用負載平衡，單一連線的速度仍受實際經過的節點、遠端服務與本機網路限制，不能把群組內的節點數量當成頻寬總和。

名稱、循環引用與選擇記憶

群組可以引用其他群組，但不能形成循環。例如業務群組引用出口群組，而出口群組又引用業務群組，就沒有真正的出口終點。增加群組層級前，請先確認這一層是否有獨立用途；過度巢狀會讓介面看似正常，卻難以判斷最後使用哪個節點。排查時請沿著目前選取項目逐層展開，直到看到實際節點、DIRECT 或 REJECT，再搭配連線記錄確認。

用戶端可能會記住手動選擇，重新載入設定後仍會恢復上次選取的群組項目。因此，修改 YAML 中候選項目的排列順序，不一定會改變目前出口。如果新設定已載入但出口沒有變化，請檢查策略群組目前的選擇與選擇記憶行為，不要繼續重排節點。需要重設時，請優先使用用戶端提供的選擇操作，避免直接刪除整個設定目錄，導致訂閱與本機規則一併遺失。

5. DNS 設定與 Fake-IP 的運作方式

先確認應用程式將解析請求交給誰

DNS 設定會決定核心如何解析網域，但應用程式不一定使用核心 DNS。系統解析器、瀏覽器安全 DNS、應用程式內建解析與 TUN 劫持可能同時存在。遇到 Clash DNS 洩漏的疑問時，請先找出哪一類請求繞過了預期入口，再調整設定。只把 nameserver 換成加密位址，不能證明裝置上的所有 DNS 查詢都經過代理；加密處理的是傳輸內容是否可讀，代理出口與請求接管則是另一個層面。

dns.enable 用來啟用核心 DNS 功能，listen 設定監聽位址，nameserver 指定一般上游 DNS。default-nameserver 通常用來解析上游 DNS 位址中的網域，協助完成啟動階段的基本解析；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
  fake-ip-filter:
    - "*.lan"
    - "*.local"
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5

此片段用來說明欄位層級，不代表適用於所有網路。上游位址必須能從目前網路連線；更換網路後，應重新測試解析延遲與回傳結果。監聽於迴路位址的連接埠不會自動成為系統 DNS，仍須由用戶端、TUN 或系統設定將查詢送到這裡。如果電腦只開啟系統 HTTP 代理，而使用 SOCKS 的應用程式在本機自行解析，兩者可能採用不同的 DNS 路徑。

Fake-IP 與真實位址的對應

Fake-IP 會回傳供映射使用的合成位址，核心則記錄該位址對應的原始網域。後續連線再次進入核心時，核心可依映射還原網域並套用規則，而不是將合成位址當成公用網際網路目標。這不是公共 DNS 的另一組真實解析結果，也不應由路由器直接轉送至網際網路。設定正確時，DNS 解析與連線都必須經過同一套能辨識映射的處理流程。

某些區域網路探索、裝置管理或依賴真實位址的程式，可能不適合使用合成位址，可依實際需求透過 fake-ip-filter 排除。排除後通常會取得一般 DNS 解析結果，但不代表該網域因此新增了直連規則；最終出口仍由 rules 決定。不要只為了解決一個應用程式的相容問題，就排除所有網域，否則會失去此模式提供的網域映射功能。請先限定特定網域後綴、清除舊快取，再檢查影響範圍。

依網域指定上游與解析出口

nameserver-policy 可依網域選擇解析上游，適用於企業內部網域、區域網路後綴與公用網域需要使用不同 DNS 服務的情況。以下使用內網 DNS 示意位址；只有在該位址確實是目前網路的解析器時才應使用。套用策略後，仍須確保路由能連上上游，否則即使規則正確也只會逾時。不要將僅能在辦公室網路連線的上游，永久套用到所有網路環境。

dns:
  nameserver-policy:
    "+.corp.example.com":
      - 192.168.1.1

respect-rules 等設定會影響 DNS 上游連線是否遵循路由規則。啟用前請先了解相關依賴，並為節點伺服器網域設定獨立的解析方式。如果所有 DNS 請求都必須先經過代理，而代理伺服器名稱又得依靠同一個 DNS 才能解析，就會卡在初始化階段。依網域解析與代理分流是兩套規則，應分開檢查；不能只看到某個網域使用指定上游，就認定後續連線一定經過相同出口。

修改 DNS 後，請關閉舊連線、清除用戶端與系統快取，必要時重新啟動使用內建快取的應用程式，再進行一次完整請求。測試時記錄應用程式採用的解析方式、回傳位址類型與命中規則。IPv6 也須另外驗證：關閉核心相關選項，不代表系統其他入口不再傳送 IPv6 請求。如果問題仍未解決，請依常見問題中的網路排查順序縮小範圍，不要同時關閉多個安全與解析設定。

6. 規則語法、規則集與比對順序

規則由上而下比對，命中後即停止

rules 是有順序的清單，不是會依精確程度自動排序的集合。最先命中的規則會決定出口，後續規則不再處理該請求。因此，具體網域通常應排在範圍較廣的地區規則前面，MATCH 則放在最後作為預設規則。如果前面已有涵蓋所有請求的規則，再往下新增例外就不會生效。排查網站走錯出口時，應先從連線詳細資料確認實際命中項目，再由該位置往上檢查，不要只搜尋預期命中的那一行。

常見規則格式為類型、比對內容與策略；MATCH 則只需要指定策略。策略可以是節點名稱、群組名稱或內建動作，但必須存在且可用。建議業務規則引用穩定的群組名稱，不要直接依賴經常變動的節點名稱。DOMAIN 比對完整網域，DOMAIN-SUFFIX 比對網域後綴及其子網域，DOMAIN-KEYWORD 則比對關鍵字；關鍵字涵蓋範圍較廣，不適合取代需要明確邊界的後綴比對。

rules:
  - DOMAIN,login.example.com,出口選擇
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,出口選擇

上例依賴名稱為「出口選擇」的策略群組。第一行只處理指定的登入網域，第二行處理示例網域後綴，第三行則處理目的位址屬於指定網段的連線。GEOIP 會使用本機地理資料判斷目的位址所屬區域，不是判斷訪客所在的地區。最後一行接收先前未命中的請求。實際設定還須涵蓋目前網路使用的其他私有位址範圍，不要將範例中的單一網段視為所有區域網路範圍。

解析時機與 no-resolve

網域規則需要核心取得網域資訊；若應用程式只提交位址，且沒有可用映射或其他網域識別來源，單靠網域規則可能無法命中。處理網域目標時，IP 類規則可能會觸發解析。no-resolve 表示不要只為了這條規則主動解析網域，不代表整個請求完全不會發生 DNS 查詢。請求已有目的位址時，仍可進行位址比對；若沒有可用位址，則會繼續檢查後續規則。

規則中的 REJECT 是拒絕動作，DIRECT 是直連動作，兩者都不是節點類型。暫時以精確網域規則拒絕請求，有助於確認規則是否確實載入，但測試後應恢復預期設定。不要使用範圍過廣的關鍵字拒絕規則進行診斷，以免影響登入、更新或資源網域。單一網頁也會建立多條連線，主站、靜態資源與驗證服務可能套用不同策略；請逐項查看，不要把頁面標題當成所有請求的代表。

以規則集拆分維護內容

rule-providers 用來管理外部規則集合，與管理節點集合的 proxy-providers 不同。規則集必須選擇正確的 behavior，常見類型有 domain、ipcidr 與 classical；檔案內容也必須符合所選類型。domain 集合以網域模式為主，ipcidr 集合以網段為主，classical 則包含規則類型與比對內容。引用規則集時，由主設定指定策略，方便在不同設定中讓同一個集合套用不同出口。

rule-providers:
  業務網域：
    type: file
    behavior: classical
    format: yaml
    path: ./rules/business.yaml

rules:
  - RULE-SET,業務網域,出口選擇
  - MATCH,DIRECT

對應的本機規則集如下。這裡不在 payload 的每一行加上出口策略，因為策略已在主設定的 RULE-SET 引用處指定。檔案路徑、編碼、清單縮排或 behavior 任一項不符，都可能導致載入失敗。遠端規則集還須檢查下載是否成功、快取是否更新，以及提供的內容是否符合宣告格式；網址即使以 YAML 為副檔名，若回傳的是錯誤頁面，也不會自動成為規則集。

payload:
  - DOMAIN,login.example.com
  - DOMAIN-SUFFIX,example.org

維護規則時，先處理可觀察到的問題，再逐步擴大涵蓋範圍。記下目標網域、目前命中項目、預期策略與修改理由，可避免例外規則長期累積並互相覆蓋。地理資料、規則集快取與主設定各自有更新週期，修改其中一項不代表其他項目也同步更新。如果規則檔正確但行為始終不變，請回到執行設定檢查覆寫位置，再確認舊連線是否仍沿用原有出口；更新規則通常不會讓既有連線自動切換。

7. TUN、系統代理與 DNS 接管範圍

先選擇入口，再設定分流

系統代理會通知遵循系統設定的應用程式，將請求送往本機代理入口；TUN 則透過虛擬網路介面與路由處理更多網路流量。兩者都屬於入口層，不會改變節點驗證參數，也不會自動修正錯誤規則。命令列工具、遊戲或自帶網路堆疊的程式可能不讀取系統代理，因此用戶端沒有連線記錄時，應先確認入口是否涵蓋該應用程式，再考慮是否需要 TUN，而不是一再更換遠端節點。

TUN 的實際功能取決於作業系統、權限、用戶端整合與核心實作。桌面用戶端可能透過服務元件申請權限，行動裝置通常則需透過系統 VPN 授權建立網路入口。權限尚未授予、虛擬網卡建立失敗或路由寫入失敗，都可能發生在節點連線之前。Clash Plus、Clash Verge Rev、FlClash 等用戶端的操作入口不盡相同，不要直接將某個用戶端的服務安裝步驟套用到另一個用戶端。

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

此片段展示常見欄位的關係，不保證無須調整即可在所有平台執行。enable 用來啟用功能，stack 用來選擇通訊協定堆疊實作，auto-route 會嘗試設定路由，auto-detect-interface 則會嘗試辨識出口網卡。若系統有多張網卡、虛擬網路、企業 VPN 或容器橋接，系統自動辨識的結果未必符合預期。調整通訊協定堆疊前，請先確認記錄中是否有明確錯誤；不要把切換 stack 當成無需說明的固定最佳化步驟。

DNS 劫持不代表接管所有解析

dns-hijack 會將符合條件的 DNS 流量送入核心解析流程，範例主要針對使用傳統 DNS 對應連接埠的流量。若應用程式透過加密協定自行連線至解析服務，其流量型態不同，不會只因為設定了這個欄位就自動變成一般 DNS 查詢。請分別檢查瀏覽器安全 DNS、應用程式私有解析與系統解析。若希望某個應用程式遵循統一解析策略，請優先調整該應用程式的解析設定，並確認請求最後進入哪條流程。

Fake-IP 與 TUN 搭配使用時，必須確保合成位址的連線也會進入同一個核心。若應用程式快取了合成位址，之後關閉 TUN 或切換至另一套設定，舊位址可能因失去對應映射而無法使用，造成部分網站突然無法連線。此時請先清除相關快取並重新建立連線，不要立刻更換上游 DNS。也請記下重新啟動用戶端、還原設定與重新啟動應用程式的順序，否則很難判斷是哪個動作讓問題恢復。

路由衝突與區域網路連線

企業 VPN、其他代理用戶端、虛擬機網路與安全軟體都可能變更路由。多個程式同時嘗試接管預設路由時，可能造成流量來回轉送、出口錯誤或本機服務無法連線。排查時請先保留一套網路接管方案，關閉其他接管入口，再重現問題；這不代表必須永久解除安裝其他工具。確認單獨執行時正常後，再確認是否支援共存，並為需要直連的網段設定排除或分流。

區域網路印表機、網路儲存裝置或開發服務無法連線時，請先確認網域解析，再確認目標位址與路由。替網域設定直連規則，不一定能解決系統路由層將流量送往錯誤介面的問題；反過來說，路由可達也不代表網域能正確解析。請分別以名稱與已知位址測試，判斷故障出在解析還是連線，再做最小範圍的調整，避免為了單一內網服務就將所有流量排除在接管之外。

遠端維護伺服器時，不要直接套用桌面 TUN 設定來接管所有路由。請先準備好主控台或可還原的連線方式，確認管理連線不受影響後，再逐項啟用。一般使用者可從圖形用戶端下載入口選擇適合的平台；獨立核心較適合能自行維護服務、權限與網路規則的使用情境。首次安裝遇到權限問題時，可參考跨平台初始設定進行檢查。

8. 訂閱覆寫、合併與變更驗證

先確認各層設定由誰管理

設定來源通常可分為遠端訂閱、本機擴充、用戶端全域設定與最終執行檔。遠端訂閱負責伺服器發布的內容，本機擴充負責個人規則，用戶端設定負責監聽、權限或網路入口，執行檔則是這些來源處理後的結果。不同用戶端的處理順序與細節不盡相同，因此不能將某種覆寫語法視為 YAML 標準。遷移用戶端時，應搬移設定意圖與實際欄位，而不只是複製某個擴充檔案。

直接修改訂閱來源檔，可能在下次更新時被覆蓋；直接修改執行檔，則可能在重新載入或切換設定時重新產生。較穩妥的做法是將長期自訂內容放入用戶端明確支援的擴充入口，並另外保留備份。若用戶端只支援完整的本機設定檔，就必須自行維護更新流程。一次修改立即生效，不代表該位置能長期保留；至少要驗證一次重新載入與一次訂閱更新。

物件合併與清單合併並不相同

物件欄位可能依鍵遞迴合併，也可能整段取代；清單則可能插入前方、插入後方、取代，或採用專用處理方式。以 rules 為例，若將例外規則附加在 MATCH 之後，文字雖然存在，仍不會命中；整段取代則可能刪除訂閱原有的分流規則。以 nameserver 為例，新增上游可能擴大並行查詢範圍，而不是取代舊上游。使用擴充前，請先確認用戶端分別如何處理物件與清單。

# 目標是將例外規則放在現有規則之前，
# 而不是將此片段原樣視為所有用戶端都適用的覆寫語法。
rules:
  - DOMAIN,dev.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,出口選擇
  - MATCH,出口選擇

上例表示預期的最終順序。實際操作時，應使用該用戶端支援的前置規則、擴充設定或指令碼機制來實現，不要未經確認就貼到訂閱末尾。最後請確認執行檔只有一個頂層 rules 鍵、例外規則確實位於預設規則之前，且引用的策略群組仍然存在。也要確認擴充設定適用的設定範圍，避免個人開發規則意外套用至其他訂閱或裝置。

分別驗證訂閱更新與手動選擇

訂閱更新成功，只能表示某個更新步驟已完成，不一定代表目前的執行設定已重新產生並啟用。有些用戶端會分開執行下載、解析、儲存與重新載入，任何一步失敗都可能讓舊內容繼續生效。請檢查更新時間對應的記錄、節點集合變化與目前選取的設定，再確認核心重新載入結果。更新失敗時，請依訂閱常見問題區分網路連線失敗、內容格式錯誤與授權問題。

還原備份時，也要留意用戶端儲存的選擇狀態。即使檔案已還原，策略群組仍可能沿用上次手動選擇，DNS 快取與既有連線也可能尚未清除。重現測試時，請固定模式、策略群組出口、請求目標與應用程式入口，必要時先關閉舊連線再送出請求。每次只改變一個變數並記錄結果，才能判斷還原設定是否真的解決問題，而不是剛好遇到遠端服務恢復。

依四個層級完成變更驗證

第一層檢查語法與型別，確認縮排、引號、布林值與重複鍵。第二層檢查引用，確認規則指向的群組、群組內節點與提供器都存在，且沒有循環引用。第三層檢查執行狀態，確認核心已讀取新設定、連接埠監聽成功，且 DNS 與 TUN 沒有初始化錯誤。第四層才是業務驗證：使用目標應用程式存取明確位址，並查看命中規則與出口。上一層尚未通過前，不應跳到下一層盲目修改。

備份至少應包含本機規則、策略群組結構與用戶端相關擴充，不能只匯出節點清單。敏感節點參數應存放在受控位置，分享給他人時則改用僅供說明的範例值。清除舊檔案前，請先確認哪些是來源檔、哪些是快取、哪些由用戶端產生；隨意刪除快取目錄可能導致離線時無法啟動，刪除來源檔則可能遺失尚未同步的個人設定。

最後應能回答三個問題：應用程式的請求從哪個入口進入、哪條規則決定出口，以及哪一層設定負責這條規則。若無法清楚回答，請回到最基本的設定逐層增加功能，比繼續堆疊覆寫更容易找出問題。若要快速完成連線，請依照快速入門操作；需要查詢名詞時請參閱名詞解釋，需要分析具體錯誤時請查看執行記錄說明，不要把查閱手冊當成必須一次啟用所有功能的清單。