Clash 進階設定：策略、DNS 與流量接管

01 / 策略組織

策略組類型與實際組合

策略組位於規則與個別代理之間。規則只負責判斷連線屬於哪類流量，真正決定使用哪個代理、是否自動測試，以及失敗後如何切換的是策略組。要讓設定長期易於維護，關鍵不是把所有節點塞進同一組，而是先依用途建立穩定的抽象層。例如規則只引用「中國大陸以外網站」、「串流媒體」、「即時通訊」與「漏網流量」；即使節點名稱隨訂閱變動，規則層也不必同步重寫。

select、url-test、fallback 與 load-balance

select 是手動選擇組，適合需要明確控制出口的情境。它不會自行判斷節點品質，目前成員無法使用時也不會自動切換到其他成員，因此通常會把數個自動策略組放進 select，而不是只放原始節點。url-test 會依指定網址定期測試成員，並選擇測試結果較佳的一項。測試反映的是連往測試網址的連線表現，不等同於所有目標網站的實際速度；間隔過短還會產生額外連線，在行動網路下尤其沒有必要頻繁執行。

fallback 依成員順序選擇第一個可用項目，重點是穩定的主備關係，而不是挑選測試時間最低的項目。固定線路為主、備用線路兜底時，這種類型比 url-test 更容易預測。load-balance 會將不同連線分配給多個成員，適合並行請求較多且服務端允許出口變動的情境。登入、付款及風控嚴格的網站可能將短時間內變動的出口視為異常，因此不應把負載平衡設為所有流量的預設策略。

建立穩定的兩層策略結構

常見結構是第一層依地區或線路特徵自動選擇，第二層依業務用途手動選擇。以下的「自動選擇」會從訂閱提供器篩選節點，「中國大陸以外網站」則可在自動選擇、故障轉移與直連之間切換。這樣的好處是規則只需引用「中國大陸以外網站」，日常調整集中在策略組，不會讓規則檔與某一家訂閱產生過度耦合。

proxy-groups:
  - name: 自動選擇
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

  - name: 故障轉移
    type: fallback
    use:
      - provider-main
      - provider-backup
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: 中國大陸以外網站
    type: select
    proxies:
      - 自動選擇
      - 故障轉移
      - DIRECT

use 引用的是代理提供器，proxies 引用的是明確列出的代理或其他策略組。篩選訂閱節點時可使用 filter，但正規表示式應圍繞穩定關鍵字撰寫，不要依賴訂閱名稱中容易變動的裝飾字元。節點名稱無法穩定區分用途時，寧可保留手動選擇，也不要撰寫可能誤收節點的寬泛表達式。

調整策略組後，應先檢查引用關係：規則目標必須存在，策略組成員也必須存在，組與組之間不能形成循環引用。若客戶端匯入後提示設定解析失敗，可暫時移除新增的組，再逐段恢復。策略組本身沒有命中流量時不會改變連線路徑，因此排查時還要結合日誌，確認最終規則是否確實指向該組。

02 / 規則管理

規則集訂閱化與比對順序

Clash 規則採用由上而下、命中即停止的處理方式。順序比規則數量更重要：精確網域若放在較寬泛的網域後綴之後，就失去意義；區域網路與需要直連的服務若排在大範圍代理規則之後，也可能被提前接管。最後一條通常使用 MATCH 承接未被前面規則涵蓋的連線，確保每筆流量都有明確去向。

內嵌規則與規則提供器

少量且與個人環境密切相關的規則，適合寫在主設定的 rules 中，例如家用儲存設備、開發環境網域，以及某個必須固定直連的網站。規模較大且需要持續更新的公共規則，則適合交給 rule-providers。規則提供器會將規則內容與主設定分離，可設定下載網址、本機快取路徑、格式與更新時間。更新失敗時，核心通常會繼續使用已快取的規則檔，因此快取路徑必須可寫入，多個提供器也不能指向同一個檔案。

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

  service-proxy:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/service-proxy.yaml
    url: https://example.invalid/rules/service-proxy.yaml
    interval: 86400

rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,lan,DIRECT
  - RULE-SET,private-direct,DIRECT
  - RULE-SET,service-proxy,中國大陸以外網站
  - GEOIP,CN,DIRECT
  - MATCH,中國大陸以外網站

範例中的網域使用保留測試網域，不代表可直接取得的真實規則網址；實際使用時應替換為自己信任且能維護的規則來源。behavior: domain 只承載網域類規則，檔案可以保持精簡。classical 可容納 DOMAIN-SUFFIX、IP-CIDR、PROCESS-NAME 等經典規則語法，支援範圍更廣，但解析與比對結構也更複雜。選擇行為類型時應與遠端檔案內容一致，不能只修改主設定中的欄位而忽略規則檔格式。

從窄規則排到寬規則

一套可解釋的順序通常是：本機例外規則、區域網路直連、明確需要代理的服務、明確需要直連的服務、地區資料庫規則，最後是 MATCH。若某個網域需要覆蓋公共規則，應將自訂規則放在相應公共規則之前。IP 規則可加入 no-resolve，避免比對過程為取得目標 IP 而主動觸發 DNS 解析，但只有在連線本身已提供 IP，或前置流程能取得 IP 時才有意義。

rules:
  - DOMAIN,api.example.invalid,DIRECT
  - DOMAIN-SUFFIX,example.invalid,中國大陸以外網站
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,中國大陸以外網站

上例先對單一主機執行直連，再讓相同後綴下的其他網域走代理。這體現了「越具體的規則越靠前」原則。實際設定中還要留意 DOMAIN-KEYWORD，它容易誤比對包含相同片段、但用途無關的網域。可以用後綴規則表達時，優先使用 DOMAIN-SUFFIX；必須精確控制單一主機時，使用 DOMAIN。

規則更新與回滾

規則集更新不應與客戶端升級混為一談。客戶端、核心、訂閱節點與規則集各自有不同的變動週期。每次只變更一個層面，觀察日誌中的規則提供器是否成功載入，再驗證幾個代表性網域。更新後若大量網站連線異常，先恢復舊規則快取或暫時停用新的提供器，不要同時修改 DNS、TUN 與策略組。將個人規則保存在獨立檔案中，可避免訂閱重新整理覆蓋本機修改。

日誌出現規則提供器下載失敗時，先確認 URL 是否可存取、檔案格式是否相符，以及快取目錄是否具備寫入權限。若只有啟動階段失敗、之後手動更新卻成功，可能是裝置剛連上網路時尚未準備好。此時可延長自動更新間隔，並保留有效快取。規則相關的基礎術語可在概念速查中對照；不要只憑規則名稱判斷效果，最終依據始終是連線日誌顯示的命中規則與策略組。

03 / 名稱解析

DNS 設定最佳化與解析鏈路

DNS 設定決定網域如何轉換為位址，也會影響規則能否取得足夠資訊。問題常被誤判為節點無法使用：節點連線正常，但網域解析失敗、回傳結果不適合，或查詢走錯網路，同樣會表現為網頁無法開啟。排查時應將「DNS 查詢由誰處理」、「查詢送往哪裡」、「取得的結果如何進入規則比對」拆成三個步驟，而不是反覆切換節點。

基礎監聽與上游分工

enable 控制 mihomo DNS 模組是否啟用，listen 決定監聽位址。僅供本機使用時，應優先監聽迴路位址；Android 客戶端通常由應用程式管理監聽與 VPN 接管，不需要為區域網路裝置開放連接埠。default-nameserver 主要用於解析加密 DNS 上游本身的網域，因此通常填寫可直接存取的 IP 位址解析器。nameserver 負責主要查詢，proxy-server-nameserver 可專門解析代理伺服器網域，避免代理節點網域的解析又依賴尚未建立的代理鏈路。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: true
  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://8.8.8.8/dns-query
  proxy-server-nameserver:
    - 1.1.1.1
    - 8.8.8.8

上游位址應依目前網路的可達性選擇，數量並非越多越好。同時查詢多個解析器可能得到不同結果，也會增加定位難度。先使用一組穩定上游建立基準，再視需要設定分流。若代理伺服器本身使用網域，必須確保其網域能在代理啟動前完成解析；否則會形成「建立代理需要 DNS，而 DNS 又需要代理」的迴圈。

redir-host 與 fake-ip 的差異

redir-host 回傳真實解析位址，連線過程更接近系統原有行為，相容性直觀，但核心在後續階段可能只能看見 IP，網域規則是否生效取決於流量入口與映射資訊。fake-ip 會為網域分配保留網段中的暫時位址，應用程式連線至該位址後，核心依據映射還原原始網域，再執行規則。它通常能讓網域規則在 TUN 情境下保持一致，也減少真實 DNS 結果提前暴露給應用程式的機會。

Fake-IP 不是遠端伺服器位址，不能將它視為解析錯誤。看到 198.18.0.0/16 範圍的結果，通常表示增強模式正在運作。真正需要關注的是連線是否由核心接管，以及對應映射是否仍然存在。部分區域網路探索、裝置投放、網路連通性檢查，以及依賴特殊 DNS 回傳值的應用程式不適合 Fake-IP，可透過過濾清單讓這些網域回傳真實結果。

dns:
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "+.stun.*.*"
    - "connectivitycheck.gstatic.com"

過濾項目應根據實際日誌逐步增加。將過多後綴放入過濾清單，會削弱 Fake-IP 的網域識別作用；過濾太少則可能導致區域網路服務探索失敗。修改後需要清除舊 DNS 快取或重新啟動核心，避免舊映射影響判斷。

依網域選擇解析器

nameserver-policy 可讓特定網域或規則集使用指定解析器。例如將內部網域交給家用路由器，公共網域交給加密 DNS。策略應保持單向且容易解釋：內部解析器只服務內部網域，不要作為所有查詢的隨機候選。行動裝置在 Wi-Fi 與行動網路之間切換時，區域網路解析器可能突然無法連線，因此依賴區域網路位址的策略應考量網路變化後的失敗情況。

dns:
  nameserver-policy:
    "router.local": 192.168.1.1
    "+.home.arpa": 192.168.1.1
    "+.example.invalid":
      - https://1.1.1.1/dns-query

DNS 故障的驗證順序應固定：先確認網域是否產生查詢日誌，再確認上游是否回傳結果，接著確認規則命中，最後檢查連線是否透過預期的策略組建立。若 IP 位址可存取而網域無法存取，問題更可能位於解析層；若網域已完成解析且日誌顯示建立連線失敗，則應轉向節點、路由或 TUN 檢查，而不是繼續更換 DNS。

04 / 流量接管

TUN、Fake-IP 與 Android VPN 介面

TUN 模式透過虛擬網路介面接收系統流量，讓不讀取系統代理設定的應用程式也能進入 mihomo。Android 客戶端使用系統 VPN 權限建立此介面，因此狀態列出現 VPN 標誌屬於正常現象。TUN 解決的是流量入口問題，Fake-IP 解決的是網域映射與識別問題；兩者經常搭配使用，但不是同一項功能。

自動路由與嚴格路由

auto-route 讓核心自動設定路由，將目標流量導向 TUN 介面。strict-route 會進一步限制未按預期進入介面的路徑，減少流量從其他路由繞過，但也可能放大與熱點分享、區域網路存取、企業 VPN 或特殊系統路由的衝突。首次啟用時應先使用自動路由，確認基本存取正常，再依洩漏控制與應用程式相容性需求評估嚴格路由。

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

stack 決定 TUN 網路堆疊的實作。mixed 通常用於兼顧相容性與效能；不同系統、不同客戶端封裝所支援的值可能有所差異，應以客戶端目前可接受的設定為準。切換網路堆疊屬於診斷手段，沒有故障證據時不應頻繁修改。auto-detect-interface 用於識別實際出站介面，裝置在 Wi-Fi 與行動網路之間切換時相當實用。

DNS 劫持的範圍

dns-hijack 會將發往常見 DNS 連接埠的查詢交給 mihomo DNS 模組處理，讓應用程式不易繞過統一解析策略。它不一定能接管應用程式內建的加密 DNS，因為後者會表現為一般 HTTPS 或 TLS 連線。若瀏覽器自行啟用安全 DNS，相關網域解析可能不會出現在 mihomo 的一般 DNS 日誌中。需要統一行為時，應在應用程式設定中關閉獨立解析功能，或明確接受兩條解析路徑並分別診斷。

劫持範圍也不應無限擴大。區域網路裝置探索、電信商認證頁面或企業網路內部網域可能依賴本機 DNS。遇到連線 Wi-Fi 後認證頁面不跳出、印表機名稱無法解析等問題，可先暫停 TUN 進行驗證，再決定使用直連規則、真實 IP 過濾或區域網路 DNS 策略，而不是直接刪除全部 DNS 設定。

Android 上的應用程式分流

Android 的 VPN 介面通常同一時間只能由一個應用程式佔用。系統中的其他 VPN、工作設定檔管理工具、基於 VPN 的防火牆或過濾工具，可能與 Clash Plus、Clash Meta for Android、FlClash、Surfboard 產生衝突。介面顯示已啟動但系統沒有建立 VPN 介面時，應檢查是否仍有其他應用程式持有權限，以及系統是否撤銷了背景執行許可。

若客戶端支援依應用程式納入或排除，可以只接管指定應用程式，也可以讓少數區域網路工具繞過。納入模式便於測試：先選一個瀏覽器確認路徑，再逐步加入其他應用程式。排除模式適合大多數應用程式都需要接管、只有銀行應用程式或區域網路控制工具例外的情況。同時疊加兩種模式容易造成理解偏差，應只選擇一套清晰規則，並記錄哪些應用程式由系統直接連網。

若需要先了解 TUN 的基本運作機制，可閱讀Android 版 Clash TUN 模式原理與啟用方法。本章更著重參數之間的關係。最終判斷不以開關是否顯示為啟用，而以系統 VPN 介面、DNS 日誌、連線日誌與規則命中是否形成完整鏈路為準。

05 / 網域還原

網域嗅探的用途、覆蓋範圍與限制

某些連線進入核心時只攜帶目標 IP，規則系統無法直接知道原始網域。網域嗅探會讀取連線早期可見的協定中繼資料，例如 TLS 交握中的伺服器名稱或 HTTP 請求中的主機欄位，藉此還原網域並重新參與規則比對。它不是讀取網頁正文，也無法從所有加密連線取得網域；協定是否提供可見中繼資料，以及連線是否在交握階段被接管，都會影響結果。

TLS、HTTP 與 QUIC 嗅探

TLS 嗅探常用於讀取 ClientHello 中的 SNI，HTTP 嗅探讀取 Host，QUIC 嗅探則處理基於 UDP 的相關交握。啟用的協定越多，覆蓋範圍越廣，但誤判與相容性問題也會增加。初始設定可以只啟用實際需要的連接埠範圍，並保留略過清單。若某個應用程式連線後立即重試、影片啟動失敗，或日誌中的網域與實際服務不符，應針對該網域或目標網段停用嗅探，而不是關閉整套規則系統。

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - "+.lan"
    - "+.local"

parse-pure-ip 允許對純 IP 目標嘗試還原網域。force-dns-mapping 會結合 DNS 映射資訊輔助識別，特別適合 Fake-IP 與核心 DNS 已掌握網域映射的情況。override-destination 決定嗅探到網域後，是否以其覆蓋原始目標供後續連線使用。覆蓋能提升部分網域規則的一致性，但對依賴固定 IP、特殊憑證行為或私有協定的服務可能造成差異，因此較適合確認需求後再啟用。

嗅探與 Fake-IP 的搭配

在 Fake-IP 情境下，核心通常已能透過虛擬位址映射取得原始網域，嗅探主要用於補足繞過核心 DNS、直接連線至真實 IP 的流量。在 redir-host 或部分透明代理情境中，嗅探對還原網域更為重要。兩種機制同時啟用時，應理解網域的來源：日誌中的網域可能來自 DNS 映射，也可能來自協定交握。若兩者不一致，覆蓋策略會決定最終用於規則比對與連線的名稱。

設定網域規則後仍命中 IP 規則，不一定表示嗅探失效。連線可能沒有可嗅探欄位，可能使用加密的客戶端問候擴充，可能在嗅探完成前已依 IP 規則處理，也可能是目標應用程式直接使用自訂協定。排查時選擇一般 HTTPS 網站作為基準，確認日誌能顯示 SNI，再測試發生問題的應用程式。不要用不支援嗅探的協定否定整項功能。

略過清單與風險控管

skip-domain 適合區域網路網域、裝置探索服務，以及已知嗅探後出現異常的業務網域。部分設定也支援依目標位址或來源位址略過，可用於內部網路。略過規則應盡量具體，避免使用過寬的後綴。若將整個常見頂級網域加入略過清單，就等同讓大量公網連線失去網域還原能力。

網域嗅探不能取代正確的 DNS 設定。DNS 已失敗時，應用程式可能根本無法發起可供嗅探的連線；連線使用 IP 時，嗅探也不保證一定能還原名稱。合理順序是先讓 DNS 與 TUN 鏈路穩定，再啟用嗅探補足純 IP 流量。每次修改後查看日誌中的目標、嗅探結果、命中規則與最終策略組，四者一致才算達到預期。

在行動網路上，UDP 與 QUIC 的路徑可能不同於 TCP。若網頁可以開啟，但影片或即時通訊異常，可暫時停用 QUIC 嗅探，或透過規則阻擋 UDP 443 進行對照，讓應用程式退回 TCP。此操作用於定位問題，不應預設長期阻擋所有 UDP。確認具體服務與網路條件後，再決定保留哪種協定範圍。

06 / 設定編排

本機覆寫與多訂閱合併

訂閱通常由服務提供者維護，重新整理時會替換節點、策略組或規則。若直接編輯訂閱產生的主設定，本機修改很容易在下次更新後消失。覆寫的目標是將「遠端經常變動的部分」與「本機希望長期保留的部分」分離。節點清單可以來自訂閱，DNS、TUN、個人規則與策略結構則由本機覆寫穩定控制。

覆寫優先順序與最小修改範圍

不同客戶端對覆寫的實作名稱有所差異，可能稱為覆寫、混入、設定修補或腳本處理。無論介面如何命名，都應先確認合併方向：是本機欄位覆蓋遠端欄位，還是將陣列附加到遠端陣列。映射欄位通常可以依鍵合併，陣列欄位則可能整體取代。規則與策略組都是陣列，誤以為是「附加」但實際發生「取代」，會導致訂閱原有規則全部消失。

最穩妥的做法是讓覆寫範圍保持精簡。只修改明確需要控制的欄位，例如 DNS 增強模式、TUN 開關、外部控制監聽，以及位於規則頂端的個人例外。若策略組由本機完全接管，就應同步檢查遠端規則是否引用已不存在的組名。名稱是引用關係的一部分，中文空格、大小寫與全形符號的變化，都可能造成找不到目標。

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

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

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true

store-selected 用於保留策略組選擇，訂閱重新整理或核心重新啟動後，不必每次重新選擇。store-fake-ip 可儲存 Fake-IP 映射，減少重新啟動後既有連線對應關係遺失的影響。是否啟用應結合客戶端儲存權限與問題表現；發生映射異常時，可以清除快取後重新建立，而不是持續疊加舊狀態。

透過 proxy-providers 匯入多個訂閱

多個訂閱不應簡單複製貼上成一個龐大的節點陣列。使用 proxy-providers 可讓每個來源獨立更新、獨立快取，並在策略組中依需求引用。主訂閱與備用訂閱使用不同檔案路徑，更新失敗時也不會互相覆蓋。健康檢查可以放在提供器層，讓引用該提供器的多個策略組共用檢查結果。

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

  provider-backup:
    type: http
    url: https://example.invalid/subscription/backup
    path: ./providers/backup.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900

範例位址為保留測試網域，實際訂閱網址屬於敏感設定，不應放入公開檔案、截圖或共用日誌。多個來源的節點可能重名，核心或客戶端合併時可能覆蓋、重新命名或拒絕載入。可在提供器中使用前綴、後綴或過濾機制區分來源，例如為備用來源統一加上「備用」前綴。策略組篩選時再依前綴與地區關鍵字組合，避免同名節點造成來源難以判斷。

更新失敗與回滾策略

訂閱自動更新間隔不宜過短。節點變動通常不需要以分鐘為單位重新整理，頻繁請求會增加失敗機會，也可能在暫時性網路異常時用不完整內容取代目前設定。客戶端提供「設定自動更新 · 間隔 1440 分鐘」這類選項時，每日更新通常足以涵蓋一般變化。每次更新後應先完成語法驗證，再切換正在執行的設定；支援保留舊設定的客戶端，至少應保存上一份可啟動版本。

若合併多個訂閱後無法啟動，請分層拆分：先只保留本機基礎設定，再加入主要提供器，接著加入備用提供器，最後恢復策略組與規則。解析錯誤通常能定位到欄位或行號；邏輯錯誤則需依序檢查「節點是否載入、組是否包含成員、規則目標是否存在」。不要在失敗狀態下繼續加入轉換腳本，這會把原始錯誤包裹在更多處理層中。

需要在桌面與 Android 之間遷移時，優先遷移不含裝置路徑的通用欄位。Windows 與 Android 對檔案路徑、監聽權限、TUN 實作與應用程式分流的處理方式不同，不能假設同一份完整設定能在所有平台直接重複使用。關於停止維護客戶端的遷移，可參考遷移至 mihomo 核心客戶端的設定方案。

07 / 控制介面

外部控制面板與介面安全範圍

mihomo 的外部控制介面允許相容面板讀取策略組、切換成員、查看連線與日誌。它提供的是管理能力，而不是代理連接埠。控制介面與 mixed-port、HTTP 代理連接埠或 SOCKS 連接埠應分別規劃。僅在本機使用時監聽迴路位址，可減少區域網路中其他裝置存取控制面的機會。

監聽位址與存取密碼

external-controller: 127.0.0.1:9090
secret: "replace-with-a-local-password"
external-ui: ./ui
external-ui-name: dashboard

external-controller 指定監聽位址與連接埠。127.0.0.1 只接受本機連線，適合客戶端內嵌面板或同一裝置上的瀏覽器。若確實需要從區域網路管理，可以改為區域網路可達的監聽位址，但必須同時設定存取密碼，並透過系統防火牆限制來源。控制介面能修改執行狀態並查看連線資訊，不應直接暴露在公網。

external-ui 指向靜態面板檔案目錄。面板只是控制介面的前端，成功載入不代表已連線至核心。頁面空白、策略組不顯示時，要分別檢查靜態檔案是否存在、瀏覽器是否能存取控制位址、密碼是否一致，以及面板填寫的協定與連接埠是否正確。若客戶端自帶面板入口，優先使用客戶端管理的路徑，減少手動設定目錄差異。

從其他裝置存取區域網路控制面

跨裝置存取需要同時滿足四層條件：核心監聽非迴路位址、作業系統防火牆允許該連接埠、存取裝置能到達主機的區域網路位址，以及控制密碼正確。任一層不符合，都會表現為面板連線失敗。先在執行核心的裝置上存取本機位址，再從同一區域網路的另一台裝置測試。不要一開始就更改代理連接埠、TUN 路由與控制介面，因為這些設定解決的是不同問題。

啟用 allow-lan 主要影響代理連接埠是否接受區域網路連線，不應將它視為外部控制介面的唯一開關。控制介面由自身的監聽位址決定。若只想讓其他裝置使用代理而不允許管理核心，可以開放代理連接埠，同時將控制介面限制在迴路位址。反過來，只開放控制介面也不會自動讓區域網路裝置取得代理能力。

使用介面讀取狀態

除錯時可以從本機請求控制介面，確認核心是否回應。以下範例只請求版本資訊與代理組清單，不包含真實密碼。實際設定密碼時，需要在請求標頭中提供相應的授權資訊。命令應在執行核心的同一裝置上執行。

curl http://127.0.0.1:9090/version
curl http://127.0.0.1:9090/proxies

第一個請求確認控制服務是否已啟動，第二個請求確認策略組是否成功載入。若連接埠拒絕連線，優先檢查監聽位址、連接埠占用與核心啟動日誌；若回傳未授權，表示介面存在但存取密碼不相符；若回傳資料但面板不顯示，問題位於面板設定、瀏覽器限制或靜態資源，而不是策略組本身。

日誌層級與連線觀察

log-level: info 適合日常排查，可看到規則命中與連線建立資訊。更詳細的除錯層級會產生大量紀錄，只應在重現問題時短時間啟用。日誌可能包含存取網域、區域網路位址與策略名稱，分享前應刪除個人訂閱網址、認證欄位及無關連線。排查完成後恢復一般層級，避免長時間記錄造成儲存壓力。

外部面板適合用於觀察，不應取代設定檔本身的版本管理。策略組切換屬於執行狀態，規則、DNS 與 TUN 參數仍應回到設定來源中修改。否則重新啟動、訂閱重新整理或更換客戶端後，面板中的臨時操作無法還原完整意圖。

08 / 故障定位

設定診斷順序與長期維護

複雜設定出現問題時，最有效的方法是縮小變數，而不是連續切換所有開關。將鏈路分為設定解析、代理提供器、DNS、規則比對、策略選擇、流量接管與目標連線七層，每次確認一層是否正常。日誌中的第一條錯誤通常比後續連鎖錯誤更有價值；先處理設定無法載入、提供器無法讀取等上游問題，再查看具體網站連線。

從最小可執行設定開始

建立一份最小設定作為診斷基準，只保留一個可用代理、一個手動策略組、基礎 DNS 與最終規則。確認能啟動後，再依策略組、規則提供器、TUN、Fake-IP、嗅探、覆寫的順序逐層恢復。每恢復一層就測試同一組目標：一個直連網站、一個應走代理的網站、一個區域網路位址，以及一個有問題的應用程式。固定測試對象能避免將網站本身的波動誤判為設定變更。

mixed-port: 7890
mode: rule
log-level: info

proxies:
  - name: local-test
    type: socks5
    server: 127.0.0.1
    port: 1080

proxy-groups:
  - name: 測試策略
    type: select
    proxies:
      - local-test
      - DIRECT

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,測試策略

範例中的本機 SOCKS 服務只有在裝置確實執行對應連接埠時才可用，這裡用於展示最小結構，不是公共節點。實際診斷時可以換成已確認可用的訂閱節點。最小設定的目的，是證明客戶端、核心與基礎網路路徑可以運作；若仍無法啟動，應先檢查 YAML 縮排、欄位支援範圍與連接埠衝突。

依現象選擇檢查層

「已連線但無法上網」先查看預設策略是否選擇了可用成員，再看 DNS 是否回傳結果，接著檢查 TUN 是否接管。完整清單可參考Android 端逐項排查清單。「只有部分網站失敗」更可能與規則、IPv6、DNS 結果、UDP 或目標服務的出口限制有關。「所有節點都很慢」應先排除本機 Wi-Fi、行動網路與系統省電限制；「只有一個節點很慢」則優先檢查節點與線路。速度問題可繼續閱讀節點、線路與本機設定三層定位法。

若日誌顯示 DIRECT，但預期應走代理，請檢查規則順序與網域是否成功還原；顯示正確策略組但連線失敗，請檢查該組目前的成員；完全沒有連線日誌，請檢查應用程式是否進入系統代理或 TUN；有 DNS 日誌但沒有後續連線，可能是應用程式快取、解析結果不符合預期，或連線遭系統層阻擋。每種現象都對應不同層次，不要只用「更換節點」處理。

YAML 結構與常見解析錯誤

YAML 使用空格表達層級，不能混用定位字元。清單項目的短橫線應與同層條目對齊，包含冒號、井號或特殊字元的名稱可使用引號。重複鍵可能被解析器覆蓋，也可能直接報錯；合併多份設定時尤其要檢查是否出現兩個 dns、兩個 rules 或多個同名提供器。設定能解析不代表引用關係正確，仍需檢查策略組、規則集與提供器名稱。

遇到錯誤行號時，應同時查看前幾行。真正缺少縮排或引號的位置經常位於報錯行之前。可以先刪除最近加入的完整區塊確認是否恢復，再將區塊分半加入，以二分法定位。不要只刪除報錯行，因為那一行可能只是解析器第一次無法繼續理解的位置。

變更紀錄、備份與更新節奏

建議保留三種狀態：最後確認可用的設定、目前的測試設定，以及訂閱或規則更新前的快照。檔名可使用日期與用途，但不要在公開位置保存訂閱網址。每次變更記錄「為什麼修改、修改了哪些欄位、如何驗證」，比單純保存大量副本更容易回滾。客戶端升級、核心變更、訂閱更新與規則集更新應分開執行，避免一次變更同時影響四個層面。

更新客戶端時，優先選擇仍在維護且適合目前平台的套件。Android 可在安裝套件頁面的 Android 分區查看 Clash Plus、Clash Meta for Android、FlClash 與 Surfboard；桌面端應依對應平台選擇。Clash for Windows 與 ClashX Meta 已停止維護，遷移時應先匯出通用設定，再處理平台特有欄位，而不是繼續圍繞舊客戶端增加修補。

長期穩定的設定通常不複雜。它具備清晰的策略層、有限且可信的規則來源、可解釋的 DNS 路徑、受控的 TUN 範圍，以及可回滾的覆寫。自動化應建立在這些關係已經明確之後。設定目標不是啟用所有選項，而是讓每筆連線的入口、名稱解析、規則命中與出口選擇都能從日誌中獲得解釋。