Clash 設定進階手冊

策略組類型與實際組合

先區分「選節點」與「做判斷」

策略組位於規則與代理節點之間。規則只負責將連線交給某個策略名稱，真正決定使用哪條線路的是策略組。將兩者混在一起，常見結果是設定中重複出現大量節點名稱；節點一旦調整，規則也得跟著修改。更穩妥的結構是先依用途建立穩定的策略組，例如「節點選擇」「自動選擇」「串流媒體」「即時通訊」與「漏網之魚」，規則長期引用這些名稱，節點變動則交由訂閱與策略組處理。

select 是手動選擇組，適合需要明確控制出口的情境。使用者可在客戶端介面中選擇節點、另一個策略組或 DIRECT；選項會維持到設定重新載入，或持久化狀態發生變化為止。它不會主動檢測線路品質，因此最適合作為頂層入口：下方可同時放入「自動選擇」「故障轉移」與數個地區組。如此既能保留自動化，也能在特定網站發生相容性問題時快速切換。

url-test 會依指定網址定期進行連通性測試，並選擇結果較佳的節點。它適合網頁瀏覽、軟體更新等對回應時間敏感，且可重新建立連線的流量。測試結果只反映測試目標的連線狀況，不等同於所有網站的實際速度；節點連到測試網址很快，也可能繞路連往目標服務。因此不要把檢測間隔設得過短，更不要把單次測試視為線路品質的永久結論。

fallback 依清單順序選擇第一個可用項目。它重視穩定的優先順序，而不是每次都追求最低延遲。主線路固定、備援線路僅在故障時接手的情境，更適合使用此類型。load-balance 則會將不同連線分配到多個節點，可用於大量並行且彼此獨立的請求；但同一服務若同時看到多個出口位址，可能觸發登入狀態變更或風控。網路銀行、帳號管理與持續性工作階段不應任意交給負載平衡組。

使用 provider 管理動態節點

訂閱節點經常增刪，若直接在每個策略組內寫入完整節點清單，設定很快就會失去可維護性。mihomo 可透過 use 引用 proxy-providers，再使用 filter 或 exclude-filter 依節點名稱篩選。篩選運算式只處理名稱，不會驗證節點的實際位置，因此應以訂閱中穩定的命名規則為基礎。若服務提供者頻繁更名，優先使用一個包含全部節點的自動組，再將少量特殊線路手動放入專用組。

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

proxy-groups:
  - name: 節點選擇
    type: select
    proxies:
      - 自動選擇
      - 故障轉移
      - DIRECT

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

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

tolerance 用於減少小幅波動造成的頻繁切換。兩條線路只有幾毫秒差異時，持續更換出口往往比維持目前線路更糟。檢測網址應回傳輕量、穩定且可存取的回應；若檢測目標本身被規則直連、遭 DNS 錯誤解析，或所在網路無法連達，整組健康狀態都會失真。排查時先確認檢測請求實際經過哪條鏈路，再判斷節點是否真的無法使用。

策略組排序也會影響操作體驗。頂層手動組應放在規則直接引用的位置，地區組與自動組作為下層能力，避免形成循環引用。例如 A 組包含 B，B 又包含 A，核心便無法取得有效出口。修改後先在客戶端的策略頁面確認每個組都有可選項，再查看連線記錄中的「規則名稱—策略組—實際節點」三段資訊。若想進一步理解規則由上而下的匹配順序，可閱讀自訂規則語法與優先順序詳解。

規則集訂閱化管理

從單條規則拆分至 rule-provider

少量自訂規則可以直接寫在 rules 中，但當網域、網段與應用程式分類達到數百條後，主設定會變得難以審閱。規則集的作用是將規則內容拆成獨立檔案，由 rule-providers 負責下載、快取與定期更新，主規則清單只保留引用順序。如此可分別維護廣告過濾、私人網路、特定服務與地區網路規則，也能在某個來源異常時單獨停用，而不必替換整個訂閱。

provider 的 behavior 決定檔案內容的解讀方式。domain 面向網域集合，適合純網域分類；ipcidr 面向 IPv4 與 IPv6 網段；classical 接收帶有類型的完整規則，例如 DOMAIN-SUFFIX、PROCESS-NAME 與 IP-CIDR。三者不能任意互換。若宣告為 domain 的檔案中塞入完整規則語法，載入時可能回報格式錯誤，或內容無法依預期匹配。

format 常見為 yaml、text 或二進位規則格式。YAML 便於人工審閱，文字格式適合一行一條的簡單來源。無論選擇哪種格式，都要讓宣告與遠端檔案的實際內容一致。path 是本機快取位置，不同 provider 不應共用同一檔案，否則後下載的內容會覆蓋前者。桌面客戶端通常會代管設定目錄，相對路徑比寫死某個使用者目錄更容易移轉。

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

  service-domains:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/service-domains.yaml
    url: "https://example.com/rules/service-domains.yaml"
    interval: 86400

  regional-cidr:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./rules/regional-cidr.yaml
    url: "https://example.com/rules/regional-cidr.yaml"
    interval: 86400

rules:
  - RULE-SET,private-network,DIRECT
  - RULE-SET,service-domains,節點選擇
  - RULE-SET,regional-cidr,DIRECT,no-resolve
  - MATCH,漏網之魚

順序、解析與 no-resolve

Clash 規則依由上而下的順序匹配，命中後便停止繼續檢查。因此「規則集已包含某個網域」不代表一定會使用它：若更前面的規則已命中，後面的 provider 永遠沒有執行機會。一般應將範圍小、意圖明確的本機規則放在前面，業務規則集放在中間，地區網段與兜底規則放在後面。臨時修正某個網站時，也應優先在主設定頂部加入一條清楚的規則，而不是立即修改大型遠端集合。

IP 類規則可能觸發網域解析。當連線最初只有網域，而規則引擎需要判斷目標 IP 是否屬於某個網段時，核心必須先取得位址。no-resolve 表示這條規則不要為了匹配而主動發起解析，適合放在網域規則之後的 IP 規則，可減少額外 DNS 查詢並避免解析過程改變原始判斷。但若流量入口只提供 IP，IP 規則仍可直接匹配；no-resolve 並不是停用這條規則。

遠端規則集無法使用時，要區分「更新失敗」與「本機快取無法使用」。若已有快取仍有效，暫時的網路故障通常不會讓所有規則立即消失；首次載入、快取檔案損壞或格式變更，則可能導致 provider 無法就緒。記錄中應重點查看 provider 名稱、HTTP 狀態、解析錯誤與本機路徑，而不是只看最終連線失敗。遠端 URL 建議使用穩定的 HTTPS 位址，並依更新頻率設定合理間隔。一天才變更一次的集合，沒有必要每幾分鐘下載。

規則訂閱化不代表所有規則都應交由第三方維護。區域網路網域、家庭伺服器、公司測試環境與個人例外項屬於本地事實，最好保留在自己的覆寫檔案中。公共規則集負責廣泛分類，本地規則負責精確修正。每次大規模替換規則來源前，先保留舊快取與主設定副本，再用幾個明確目標驗證直連、代理、拒絕三類結果。能解釋每條測試連線為何走向目前出口，才算完成移轉。

DNS 設定與解析路徑最佳化

理解請求從哪裡發出

DNS 設定的難點不在於填寫更多伺服器，而是釐清每次查詢由誰發起、經過哪條網路路徑，以及回傳結果如何進入規則判斷。系統應用程式可能直接詢問作業系統 DNS，也可能自行使用加密 DNS；啟用 TUN 與 DNS 劫持後，一般 53 埠查詢可以交由 mihomo 處理，但應用程式內建的加密解析仍可能繞過。出現「瀏覽器能開、其他應用程式不行」時，首先比較兩者實際使用的解析方式，而不是反覆更換節點。

nameserver 是主要上游，負責一般網域解析。default-nameserver 用於解析 DoH 或 DoT 上游本身的網域，因此通常填寫可直接存取的 IP 位址。否則會出現「為了連線到網域形式的 DNS 上游，必須先解析這個上游網域；但解析又依賴尚未連線的上游」的循環。proxy-server-nameserver 可專門解析代理伺服器位址，適合節點主機名稱需要透過穩定解析通道取得 IP 的情況。

nameserver-policy 可以依網域將請求交給指定上游。例如內部網域走區域網路 DNS，特定服務走另一組解析器。它解決的是「不同網域由誰解析」，不是「解析後的連線走哪個策略組」；後者仍由規則決定。若策略範圍寫得過寬，可能讓大量網域繞過主要 nameserver。調整後應分別測試策略命中的網域、一般網域與節點網域，確認三條路徑都能獨立運作。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://cloudflare-dns.com/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "+.lan":
      - 192.168.1.1
    "+.internal.example":
      - 192.168.1.1
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "time.*.gov"

並行上游不是單純的數量競賽

增加上游數量不一定能提高可靠性。多個解析器可能回傳不同的 CDN 位址、不同的 IPv6 結果或不同地區線路，導致同一網域在短時間內表現不一致。更重要的是，上游之間的查詢路徑若不同，最快回傳的結果未必適合最終出口。例如直連 DNS 回傳的位址適合本地網路，但連線隨後透過遠端節點建立，目標 CDN 可能反而不是最佳選擇。設定時應先確定主要出口，再選擇符合網路模型的上游組合。

ipv6 控制 DNS 模組是否回傳 AAAA 結果，但系統是否真的能透過 IPv6 建立連線，仍取決於實體網路、TUN 堆疊、路由與代理節點。開啟回傳卻沒有可用的 IPv6 路徑，應用程式可能先嘗試一個無法完成的連線，再回退到 IPv4，表現為首次開啟速度緩慢。關閉 IPv6 只是排錯手段，不應取代對鏈路能力的判斷。若家用寬頻、伺服器與節點都支援 IPv6，可以保留並分別驗證直連與代理結果。

解析快取能減少重複請求，但也會讓錯誤結果持續一段時間。修改 hosts、nameserver-policy 或 fake-ip-filter 後，舊快取可能仍被應用程式、系統或核心使用。標準排查順序是重新載入設定、清理客戶端 DNS 快取，必要時再清理作業系統快取，最後重新啟動目標應用程式。只重新整理網頁通常不足以清除所有快取層。瀏覽器還可能維護獨立的連線池與 DNS 快取，測試時使用新視窗或完全退出後重新開啟會更可靠。

本地域名與特殊服務的過濾

Fake-IP 模式下，部分裝置探索、區域網路服務、時間同步，以及依賴真實位址驗證的應用程式不適合接收映射位址，應加入 fake-ip-filter。過濾範圍要盡量小。直接加入過寬的萬用字元，會讓大量網域回到真實 IP 模式，削弱網域規則的穩定性。每增加一個過濾項，都應記錄對應現象，例如投放找不到裝置、區域網路主機名稱無法存取或時間服務拒絕回應，避免日後無法判斷該例外是否仍有必要。

DNS 監聽位址也涉及邊界。桌面客戶端只供本機使用時，不必將埠暴露給整個區域網路；路由器作為閘道服務其他裝置時，則需要監聽可達位址，並配合防火牆限制來源。監聽成功不代表系統已經使用它，仍要檢查系統 DNS、TUN 劫持與埠佔用。若啟動記錄提示 bind 錯誤，可參考埠衝突定位流程，確認現有程序後再修改監聽埠。

TUN 模式與 Fake-IP 協同

TUN 解決系統代理無法涵蓋的連線

系統代理只對主動讀取代理設定的應用程式有效。命令列程式、遊戲、部分商店應用程式與直接發起 UDP 的軟體可能完全忽略它。TUN 模式會建立虛擬網路介面，從 IP 層接管經過系統路由的流量，因此涵蓋範圍更廣。它不是「更強的全域模式」：規則模式、全域模式與直連模式決定接管後的分流方式，TUN 只負責將原本看不到的連線送進核心。

啟用 TUN 通常需要系統管理員權限或系統授權。不同平台對虛擬介面、路由表與 DNS 設定的實作不同，客戶端會盡量完成自動設定，但睡眠喚醒、網路切換、VPN 共存與安全軟體攔截仍可能留下舊路由。啟用後若完全斷網，先關閉 TUN 並確認基礎網路恢復，再檢查記錄中的介面建立、路由寫入與 DNS 劫持錯誤。不要同時連續切換多個相關開關，否則很難判斷是哪一步改變了系統狀態。

auto-route 讓核心自動寫入路由，適合一般桌面環境。auto-detect-interface 用於辨識目前的預設出口，避免代理連線再次被送回 TUN 形成迴圈。多網卡、虛擬機器、熱點分享，或同時連接有線與無線網路時，自動辨識可能選到非預期介面；此時應查看路由表與記錄中的實際介面，而不是憑介面名稱猜測。strict-route 會更嚴格限制旁路流量，能減少某些繞過情況，但也可能影響區域網路存取與其他虛擬網路。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

Fake-IP 保留網域語意

傳統 redir-host 方式會先取得真實 IP，再將連線交給規則引擎。多個網域共用同一個 CDN 位址時，僅憑 IP 很難判斷原始目標。Fake-IP 會為查詢到的網域分配保留位址中的映射值，應用程式連線到這個映射位址後，核心可以反查原始網域，再執行網域規則與遠端解析。它的核心價值是保留網域語意，而不是加速所有 DNS 查詢。

映射位址通常只在執行中的核心及其快取內有意義。看到應用程式連線至 198.18.0.0/16 類型的位址，不代表目標真的位於該網段。若 DNS 查詢沒有經過 mihomo，應用程式卻取得先前的映射位址，或連線未被 TUN 接管，就可能出現「能解析但連不上」的斷裂。因此 Fake-IP、DNS 劫持與流量接管必須視為同一條鏈路檢查。只開啟 enhanced-mode，卻讓系統繼續使用其他 DNS，設定不會完整生效。

UDP 是 TUN 排錯時容易遺漏的一層。語音、遊戲、QUIC 與部分 DNS 查詢依賴 UDP，節點協定、客戶端設定與目標服務都必須支援相應路徑。網頁能開啟只能證明部分 TCP 流量正常，不能證明 TUN 的 UDP 鏈路完整。排查時可先測試一般 TCP，再測試 DNS UDP、QUIC 或實際應用程式；若只有 UDP 失敗，請檢查節點能力、規則策略與系統防火牆，而不是立即否定整個 TUN 設定。

MTU、區域網路與其他通道

某些網路下，小型請求正常，但上傳、影片或大型頁面卡住，可能與 MTU 和分片有關。TUN 封裝會增加額外負擔，底層網路若不允許相應大小的封包通過，連線會在特定負載下停滯。調整 MTU 應小幅逐步進行，並用可重複的大型檔案請求驗證，不能將任意斷流都歸因於 MTU。若只在某個節點出現，還要比較該節點協定與傳輸層的額外負擔。

區域網路存取失敗時，先確認私人網段規則位於前段並指向 DIRECT，再檢查 strict-route、防火牆及目標裝置是否允許目前介面存取。與其他 VPN 同時執行時，兩個程式都可能修改預設路由與 DNS，最終結果由路由優先順序決定。最可靠的驗證方式是先單獨啟用 Clash，再逐項恢復其他通道；若必須共存，應明確指定哪些網段由哪個介面負責，而不是靠啟動順序碰運氣。

網域嗅探與目標還原

嗅探處理的是「只看得到 IP」的連線

規則引擎最希望取得網域，因為網域通常比共用 IP 更能表達業務意義。但有些連線進入核心時只有目標 IP，例如應用程式使用自己的 DNS、系統快取了真實位址，或透明代理階段沒有攜帶網域。網域嗅探會讀取連線初期可見的協定資訊，從 HTTP Host、TLS SNI 等欄位還原目標網域，再交給網域規則判斷。它補足的是缺失資訊，不是取代 DNS。

嗅探能力受協定本身限制。明文 HTTP 的 Host 通常可見，TLS 交握中的 SNI 在常見情況下也能提供網域；如果應用程式使用不含網域的連線方式、協定內容無法辨識，或加密機制隱藏了交握資訊，嗅探就無法還原。UDP 協定的可見性也各不相同，不能假設所有流量都能取得網域。設定規則時仍應保留合理的 IP 規則與兜底策略。

override-destination 決定辨識出網域後，是否以它取代原始目標參與連線處理。開啟後有助於讓網域規則與遠端解析生效，但在少數依賴固定 IP、憑證行為特殊，或目標網域與連線位址刻意不一致的應用程式中，可能造成相容性問題。更穩妥的方式是先針對常見埠啟用，再透過 skip-domain，或針對來源位址為已知異常的應用程式建立小範圍例外。

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - "Mijia Cloud"
    - "+.push.apple.com"

force-dns-mapping 與 parse-pure-ip

force-dns-mapping 會讓嗅探器關注與 DNS 映射相關的連線，適合 Fake-IP 鏈路。parse-pure-ip 則允許嘗試分析目標呈現為純 IP 的流量。兩者開啟後涵蓋範圍更大，也代表更多連線會進入辨識流程。現代裝置通常能負擔這部分開銷，但路由器等資源有限的環境仍應觀察連線數、CPU 與記錄量，不應只因參數存在就全部開啟。

埠範圍是控制嗅探準確度的重要界線。HTTP 嗅探若涵蓋所有埠，非 HTTP 協定的初始資料可能被反覆嘗試解析，既增加開銷，也提高誤判機會。應從明確的 80、8080 與常見 Web 埠開始；TLS 通常集中在 443 與少量自訂埠。某個應用程式確實使用特殊埠時，再依連線記錄補充。設定越具體，後續解釋一次匹配結果就越容易。

嗅探與 Fake-IP 都能協助恢復網域，但觸發階段不同。Fake-IP 在 DNS 查詢時建立映射，應用程式隨後連線到映射位址；嗅探則在連線已抵達後，從協定交握中擷取資訊。前者通常更穩定，後者是繞過核心 DNS、以真實 IP 連線與透明代理情境的重要補充。若同一連線存在映射網域與嗅探網域，應查看記錄中最終採用哪一個，尤其留意 CDN 轉址或憑證使用通用網域的情況。

發生誤判時不要直接關閉全部嗅探

某個應用程式啟用嗅探後出現異常，先定位具體連線。檢查記錄中的原始目標 IP、還原網域、命中規則與最終策略。如果還原出的網域明顯不屬於目標業務，可將該網域加入跳過清單，或縮小對應協定的埠範圍。若只有一個區域網路服務異常，可以針對其網域或網段設定例外；直接關閉全域嗅探會讓其他依賴網域辨識的連線退回 IP 規則，可能引入更多難以察覺的分流變化。

測試嗅探時應選擇規則結果明確的網域。準備一個應直連、另一個應代理的服務，清除應用程式連線快取後分別存取，再查看連線詳細資訊是否顯示網域。如果只看到 IP，檢查流量是否經過 TUN、協定是否可辨識，以及埠是否包含在 sniff 範圍內。若網域已顯示但策略錯誤，問題在規則順序或策略組，而不在嗅探。將「辨識目標」與「選擇出口」拆開判斷，可以避免在錯誤層面反覆修改參數。

網域嗅探也無法修正錯誤的 DNS。若應用程式在連線前已取得無法連達的位址，嗅探雖可能辨識出網域，但底層路由、憑證或目標服務仍可能受到影響。穩定的設定通常以正確的 DNS 接管為主，以嗅探補充純 IP 連線，再用 IP 規則涵蓋無法還原的流量。三個層次各自負責一個問題，疊加後才形成完整的判斷鏈。

本機覆寫與多訂閱合併

將上游設定視為可更新的輸入

訂閱設定由服務提供者維護，更新時可能替換代理節點、策略組與規則。如果直接修改訂閱產生的檔案，下一次更新通常會覆蓋本機內容。正確做法是將訂閱視為輸入，將本機需求放在獨立的覆寫層：訂閱負責節點與基礎結構，本機層負責埠、DNS、TUN、規則優先順序與專用策略組。Clash Plus 等圖形客戶端通常提供設定覆寫、腳本或合併入口，具體名稱可能不同，但目標都是讓本機修改能重複套用。

覆寫有「取代」與「合併」兩種語意。純量欄位如 mixed-port、mode 通常直接取代；映射欄位如 dns 可以依鍵合併，也可能整體覆蓋；陣列欄位如 rules 與 proxy-groups 最容易產生歧義。有些客戶端會將新陣列附加到尾端，有些會依名稱合併，另一些則會完整取代。因此使用任何合併腳本前，先匯出最終設定，確認實際結果，而不是只檢查輸入片段。

規則陣列尤其需要區分前置與後置。自訂直連規則放在 MATCH 之後不會生效；修正某個業務分流的規則，通常應插入遠端通用規則之前。若合併工具支援 prepend 與 append，應明確選擇。策略組依名稱合併時，也要避免本機組與上游組同名卻類型不同，否則更新後可能保留舊欄位，形成難以理解的混合結構。

# 本機覆寫示意：具體合併入口由客戶端提供
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

dns:
  enable: true
  enhanced-mode: fake-ip

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

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve

多訂閱不等於簡單拼接

合併多個訂閱時，最先遇到的是名稱衝突。不同來源可能都包含「自動選擇」「節點選擇」或完全相同的節點名稱。若客戶端依名稱去重，後加入的項目可能覆蓋前者；若不去重，介面上會出現難以區分的重複項目。可以在 provider 層保留不同來源名稱，再建立自己的統一策略組，透過 use 同時引用多個 provider。如此不必將所有節點展開成靜態陣列，也能單獨暫停某個來源。

第二個問題是更新週期。多個訂閱若同時頻繁更新，會增加請求量，並在設定重新載入時中斷現有連線。節點資訊通常不需要以分鐘為單位重新整理。可以讓 provider 依較長週期更新，手動更新則用於服務方明確變更或節點異常後的驗證。健康檢查與訂閱下載是兩回事：前者測試現有節點，後者取得新的節點清單。不要用極短的訂閱更新間隔取代健康檢查。

第三個問題是來源之間的能力差異。有些節點支援 UDP，有些不支援；部分線路適合固定地區業務，另一些適合一般瀏覽。單一自動組將全部節點混在一起，可能選到不符合業務要求的出口。應依可驗證的命名或來源建立專用組，例如「來源 A 自動」「來源 B 備用」，頂層「節點選擇」再引用這些組。若節點名稱無法穩定表達能力，只能透過實際連線測試與手動分組維護。

建立可回復的修改流程

每次修改前保留上一份可正常運作的最終設定，而不只是儲存覆寫片段。最終設定能反映合併後的真實順序，也便於比較哪一段發生變化。建議一次只調整一個模組：先策略組，再規則，再 DNS，最後啟用 TUN 與嗅探。每一步至少驗證設定可載入、基本網頁可存取、一個直連目標與一個代理目標符合預期。多項同時修改雖然省事，但失敗時無法快速定位。

訂閱更新後若出現異常，先比較 provider 是否成功、策略組是否為空，以及規則引用的名稱是否仍然存在。許多問題並非節點失效，而是上游更改了策略名稱，本機規則仍引用舊名稱。核心載入時通常會回報找不到策略或 provider；若客戶端只顯示「設定失敗」，應開啟詳細記錄查看具體鍵名。不要為了恢復連線就立即刪除所有本機覆寫，這會失去最有價值的差異線索。

本機覆寫應保持精簡且附有說明。可以依模組撰寫註解，記錄某項規則解決的具體問題，但不要讓長期失效的測試參數一直留在檔案中。每隔一段時間檢視例外項：確認目標服務仍存在、遠端規則集是否已涵蓋，以及舊網路環境是否已更換。設定維護的目標不是欄位越來越多，而是每個保留欄位都能說明用途與界線。

外部控制面板與 API 邊界

控制埠可以做什麼

mihomo 的外部控制介面允許圖形客戶端或 Web 面板讀取策略組、切換節點、查看連線、觸發 provider 更新，以及調整部分執行狀態。桌面客戶端中的策略頁面、連線清單與記錄視窗，許多都建立在這套介面之上。它是控制面，不是代理入口；mixed-port、HTTP 埠與 SOCKS 埠負責轉送流量，external-controller 只處理管理請求。

只在本機使用時，將控制位址綁定到迴路介面最穩妥。綁定 127.0.0.1 後，區域網路中的其他裝置無法直接存取。若需要從另一台裝置管理路由器上的核心，可以監聽區域網路位址，但必須同時設定存取憑據、限制防火牆來源，並避免將埠映射到公網。管理介面能查看連線目標並改變出口，權限應等同於本機管理權限。

external-controller: 127.0.0.1:9090
secret: "your-password"

# 可選：由核心託管本機控制面板檔案
external-ui: ./ui

secret 為空時，能存取控制埠的程式可能不需要驗證即可呼叫介面。本機迴路環境仍應考慮同機其他程序的存取風險；區域網路監聽則必須設定憑據。範例中的值只是明顯的教學值，實際使用時應替換為獨立憑據，不要與訂閱網址、系統帳戶或其他服務共用。面板連線失敗時，檢查位址、埠、協定與憑據是否完全一致。

external-ui 指向靜態面板檔案目錄。核心託管這些檔案後，可以透過控制位址開啟介面；也可以使用客戶端內建的控制面板。介面檔案與核心 API 必須相容，若頁面能載入但策略組為空，先查看瀏覽器網路請求與控制介面回應，而不是重新下載節點訂閱。靜態檔案載入成功只代表 Web 資源可達，不代表 API 驗證已通過。

區域網路存取與反向代理

在家庭伺服器或路由器上使用時，常見結構是控制埠只監聽本機，再由受控的反向代理提供 HTTPS 入口。如此可以集中處理存取控制與憑證，也能避免直接暴露管理埠。但反向代理設定錯誤可能遺失 WebSocket 或驗證標頭，表現為面板首頁正常、連線清單無法即時更新。排查時分別測試靜態頁面、一般 API 請求與即時連線通道，確認問題位於哪一層。

若直接監聽 0.0.0.0，必須檢查裝置防火牆。allow-lan 主要控制代理埠是否允許區域網路裝置使用，不應誤認為是控制介面的防火牆。控制介面是否可達，取決於自身的監聽位址與系統網路規則。可以從區域網路中的另一台裝置測試埠，但測試完成後仍應限制來源網段，不要把「暫時方便存取」變成長期開放狀態。

控制面板顯示的連線資訊來自核心目前狀態。切換策略通常只影響新建立的連線，已建立的 TCP 工作階段可能繼續使用舊節點，直到連線關閉。測試節點切換時，應在面板中關閉舊連線或重新啟動目標應用程式，再觀察新連線的鏈路。只查看策略組目前選項，無法證明正在傳輸的工作階段已經遷移。

API 排錯順序

面板無法連線時，先在執行核心的裝置上確認控制埠正在監聽，再從存取端確認網路可達性，最後檢查驗證。三個步驟不能顛倒：埠未監聽時修改瀏覽器設定沒有意義，網路遭防火牆攔截時反覆更換憑據也不會成功。若埠與其他程式衝突，修改控制埠後還要同步更新客戶端或面板位址。

面板可以提高觀察效率，但不應成為唯一的設定來源。重要修改仍應寫入可備份的 YAML、覆寫檔案或客戶端設定中。只在執行期間透過 API 切換的狀態，重新啟動或載入後可能恢復預設值。長期使用的策略選擇可以依賴客戶端持久化，結構性變更則應回到設定檔。區分臨時操作與持久設定，才能避免「在介面中改過，但重啟後消失」的問題。

遠端管理還要控制記錄範圍。連線清單可能包含目標網域、來源位址與流量資訊，不適合在不受控的網路中公開。日常執行使用能滿足排錯需求的記錄層級即可，遇到問題時短期提高詳細度，完成後恢復。外部控制面板的價值在於看清規則與連線，而不是長期保存所有存取記錄。

設定驗證、聯調與故障定位

先驗證語法，再驗證行為

設定排錯分為兩個層次。第一層是結構是否能被核心讀取，包括 YAML 縮排、欄位類型、策略引用與 provider 格式；第二層是載入成功後，實際連線是否依預期經過 DNS、規則與策略組。語法通過只代表檔案可解析，不代表分流正確。反過來，應用程式無法連網也不一定是設定語法錯誤，可能只是某條規則選中了無法使用的節點。

YAML 使用空格表達層級，Tab、錯誤縮排與冒號後的格式都會改變結構。清單項目前的短橫線必須位於正確層級，布林值與數字不需要引號，包含特殊字元的名稱或 URL 則可以加上引號。策略組名稱屬於精確引用，「節點選擇」與「節點選擇 」看似接近，但尾端空格會形成兩個不同字串。設定較長時，先從記錄回報的行附近檢查，再向上尋找所屬模組。

mihomo 可透過命令列檢查設定目錄，具體執行檔名稱取決於平台與安裝方式。以下命令呈現常見的檢查方式：指定設定目錄後進行測試，不直接啟動長期服務。圖形客戶端使用者也可以使用其設定檢查功能，並查看核心記錄中的第一個錯誤。後續錯誤常由第一個結構錯誤連鎖產生，應從最早出現的一項開始修正。

mihomo -t -d /path/to/config-directory

# 若需要以前景方式觀察載入過程
mihomo -d /path/to/config-directory

建立最小驗證矩陣

每次修改後至少驗證四類目標：區域網路位址應直連，一個明確的一般網站依預期策略連線，一個只有透過代理出口才能使用的目標經由代理，以及一個未被專用規則涵蓋的目標落入兜底組。若啟用 TUN，再增加一個忽略系統代理的應用程式；若啟用 IPv6，再分別驗證 A 與 AAAA 連線。固定測試對象能讓不同設定之間具有可比性。

連線記錄應依處理鏈閱讀。先看入站類型，確認連線來自 HTTP、SOCKS 還是 TUN；再看目標是網域還是 IP，判斷 DNS 映射或嗅探是否正常；接著看命中的規則與策略組；最後查看實際節點或 DIRECT。若入口就不正確，繼續調整規則沒有意義。若規則正確但節點錯誤，問題在策略組選擇。若節點正確仍無法連線，再檢查節點能力、目標服務與底層網路。

DNS 問題應單獨驗證。記錄查詢網域、上游、回傳類型與連線目標，避免只憑「網頁打不開」推斷 DNS 錯誤。可以暫時使用簡單的 nameserver 設定建立基線，再逐步恢復 policy、Fake-IP 過濾與多上游。每恢復一項就重複相同測試。複雜 DNS 設定一次整體替換，很容易將上游不可達、策略範圍過寬與快取殘留混成同一個問題。

一次只變更一個變數

有效排錯依賴可重複性。關閉所有進階功能後恢復基礎連線，再依序啟用 DNS、Fake-IP、TUN、嗅探與規則 provider，比隨機切換開關更快。每一步記錄變更與結果，失敗時回到上一份可用設定。若客戶端支援設定副本，可以建立「基礎」「TUN 測試」「完整規則」三個獨立設定，避免持續覆蓋同一檔案。

埠類錯誤應確認具體的監聽者。mixed-port、DNS 監聽與 external-controller 都可能與其他程式衝突，錯誤記錄中的埠號決定要檢查哪一項。修改埠後，系統代理、面板位址或其他依賴端也要同步更新。詳細命令與平台差異可參考Clash 埠被佔用的定位流程。

節點全部逾時時，先判斷健康檢查網址是否可達，再手動測試一個節點。若所有 provider 同時失敗，問題更可能位於本地網路、DNS、訂閱更新或系統時間，而不是所有節點剛好同時失效。若只有某個來源失敗，則檢查該 provider 的 URL、快取與節點協定。首次連線的基礎驗證可回到選擇節點、測試延遲並確認代理生效逐項核對。

效能調整建立在正確性之後

縮短健康檢查間隔、增加 DNS 上游、擴大嗅探範圍與啟用更多規則集都會增加工作量，但不一定改善體驗。先用預設或保守參數取得正確、穩定的處理鏈，再根據明確現象調整。網頁首次開啟緩慢，可以分別測量 DNS 時間與連線時間；節點頻繁切換可以提高 tolerance 或延長檢測間隔；路由器負載過高可以減少規則集數量、降低檢查頻率並縮小嗅探埠範圍。

記錄層級同樣會影響觀察與開銷。日常使用保留一般資訊即可，重現問題期間暫時提高詳細度，完成後恢復。長期輸出大量連線細節會增加磁碟寫入，也會累積不必要的存取記錄。排錯記錄應包含問題發生前後的完整鏈路，但不需要無限期保留。

一份成熟的設定不以欄位數量衡量。更重要的是，入口、解析、匹配、決策與出口五個階段都能被解釋，而且任何進階功能都可以獨立關閉，不會破壞基礎連線。完成本頁的模組化設定後，建議匯出最終 YAML 與覆寫檔案，記錄客戶端中的關鍵開關。需要更換裝置時，可先從下載頁選擇對應平台客戶端，首推支援多平台的 Clash Plus，再按模組逐項恢復，而不是直接複製一份無法解釋的龐大設定。