Clash 進階設定手冊

CHAPTER 01 / POLICY GROUPS

策略組類型與實戰

策略組位於規則與節點之間。規則的最後一個欄位通常不是具體節點名稱，而是策略組名稱；策略組再依照使用者選擇、健康檢查或故障狀態決定實際出站。將規則直接綁定單一節點雖然寫法簡單，卻會讓節點失效後的切換、不同業務的分流與訂閱更新變得困難。較穩定的設定應先劃分業務意圖，例如「手動選擇」、「自動優選」、「故障轉移」、「串流媒體」、「下載直連」，再讓規則指向這些穩定名稱。訂閱中的節點名稱可以變動，只要透過篩選重新加入對應策略組，規則層就不必跟著修改。

select、url-test、fallback 與 load-balance

select 是明確選擇組，適合需要長期固定出口地區、手動確認帳戶登入位置或暫時排錯的情境。它不會自行改選，目前節點不可用時通常需要使用者介入，因此組內應保留「自動優選」作為選項。url-test 會向固定網址發起連通性測試，並從候選節點中選擇測得延遲較低者。測試延遲只反映探測目標與測試當下，不代表所有網站的實際速度；間隔過短還會產生額外連線，因此桌面日常使用通常將探測間隔設為數分鐘，而非持續重新整理。

fallback 依清單順序選擇第一個可用節點，適合主線路明確、備援線路只在故障時接手的情況。它重視順序與可用性，不追求最低延遲。load-balance 會將不同連線分配給多個節點，適用於無登入狀態、允許出口變動的並行工作；帳戶登入、付款、長連線及對來源位址敏感的服務不宜隨意使用，因為同一業務的連線可能從不同出口發出。採用一致性雜湊策略可降低同一目標頻繁更換出口的機率，但仍應先確認業務能接受這種行為。

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

  - name: 自動優選
    type: url-test
    use:
      - remote-nodes
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80
    lazy: true

  - name: 故障轉移
    type: fallback
    use:
      - remote-nodes
    url: https://www.gstatic.com/generate_204
    interval: 300
    lazy: true

use 引用的是 proxy-providers，適合讓遠端訂閱節點自動加入策略組；proxies 則列出固定節點或其他策略組。兩者可依核心支援情況組合，但維護設定時應盡量保持來源清楚。節點很多時可使用 filter 正規表示式依名稱篩選地區，例如將名稱含「香港」或「HK」的節點納入某個組。反向篩選應謹慎，節點命名不一致時容易排除全部候選。每次修改篩選條件後，都要在用戶端的策略組詳細資訊中確認實際成員，而不是只看 YAML 能否載入。

分層策略避免循環引用

實戰中可建立三層結構：底層是節點提供者，中層是自動優選或故障轉移，上層是使用者可見的業務組。規則只引用上層業務組，上層可以引用中層組與少量固定節點。任何策略組都不能間接引用自身。例如「手動選擇」包含「自動優選」，而「自動優選」又把「手動選擇」列為候選，就會形成循環。部分用戶端會在載入時直接報錯，部分介面只顯示空組。排錯時從報錯組開始逐層展開引用，直到所有葉節點都落到真實節點或 DIRECT、REJECT 等內建策略。

CHAPTER 02 / RULE PROVIDERS

規則集訂閱管理

當規則數量從幾十條增加到數千條後，將全部內容直接寫入主設定會降低可讀性，也會讓訂閱更新覆蓋本機修改。rule-providers 用於將網域、網段或經典規則拆成獨立資源，由核心定期下載並快取。主設定只保留提供者定義、業務策略與規則集引用，規則內容可依廣告攔截、私有網路、工作服務、串流媒體等主題分別維護。如此既能單獨更新某類規則，也能在異常時快速停用對應引用，不必重寫整份設定。

behavior 與 format 的對應關係

behavior 描述規則集內容的語意。domain 適合純網域集合，項目通常是完整網域、網域後綴或核心支援的網域表示式；ipcidr 只處理 IPv4、IPv6 網段；classical 則保存帶有類型與參數的完整規則，例如 DOMAIN-SUFFIX,example.com、PROCESS-NAME,example.exe。選擇錯誤時，檔案可能成功下載卻無法解析，日誌會出現 payload 格式或規則類型錯誤。format 則說明資源是 YAML 文字、純文字還是二進位規則格式，必須與遠端檔案的實際內容一致，不能只依副檔名猜測。

rule-providers:
  private-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./rules/private-domain.yaml
    url: https://rules.example.invalid/private-domain.yaml
    interval: 86400
    health-check:
      enable: true
      interval: 600

  office-classical:
    type: http
    behavior: classical
    format: text
    path: ./rules/office.list
    url: https://rules.example.invalid/office.list
    interval: 43200

  private-network:
    type: file
    behavior: ipcidr
    format: yaml
    path: ./rules/private-network.yaml

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,office-classical,工作服務
  - RULE-SET,private-network,DIRECT,no-resolve
  - MATCH,手動選擇

範例網域使用無法解析的保留後綴，僅用於說明結構；部署時應替換為實際可存取且來源明確的規則網址。path 是本機快取位置，同一設定中的不同提供者不能共用同一檔案，否則更新時可能互相覆蓋。相對路徑通常以設定工作目錄為基準，而不是圖形化用戶端的安裝目錄。容器或系統服務環境還要確認執行使用者對該目錄具有建立與寫入權限。若日誌顯示下載成功但寫入失敗，應檢查目錄權限、唯讀掛載與路徑層級，而不是反覆修改遠端網址。

規則順序比規則數量更重要

Clash 與 mihomo 通常依照 rules 的順序由上而下比對，第一條命中後即停止。具體網域規則應放在寬泛規則之前，私有位址與本機服務通常應早於公網網段，最後以 MATCH 收尾。若先寫入寬泛的地區網段或萬用網域，後面的細緻規則就不會執行。規則集之間同樣存在覆蓋關係：一個網域同時屬於「工作服務」與「直連網域」時，排在前面的引用會決定結果。除錯規則時不要只確認某個項目存在，還要在連線詳細資訊或日誌中查看實際命中的規則類型、規則內容與目標策略。

no-resolve 常用於 IP 類規則，表示比對時不要為取得目標 IP 而額外解析網域。它能減少不必要的 DNS 查詢，也可避免規則階段改變原始網域處理路徑，但不是所有規則都應機械式加入。網域規則依賴網域本身，不需要此參數；需要依解析結果比對地區或網段時，禁止解析反而會使規則無法命中。正確做法是先確認規則使用的是網域、目標 IP 還是程序資訊，再決定是否跳過解析。

更新失敗與快取回退

遠端規則更新失敗不一定代表現有流量會立即中斷。只要本機快取仍存在且格式有效，核心通常可以繼續使用舊內容；首次載入、快取被清除或路徑變更時則沒有回退基礎。維護前應記錄規則檔案的快取目錄與上次成功更新時間。遇到異常時依序檢查系統時間、DNS 解析、遠端回應狀態、代理出站路徑、憑證錯誤與檔案權限。若規則網址本身需要透過代理存取，而規則又決定代理存取路徑，首次啟動可能形成依賴迴圈。可讓規則下載使用已知可用的代理設定，或先準備本機檔案完成啟動，再恢復遠端更新。

規則集並非越多越好。多個來源可能重複收錄相同網域，維護標準也可能衝突。建議為每個提供者記錄來源、用途、更新頻率與目標策略，並定期刪除不再引用的快取。調整前可先在小型本機規則集驗證行為，再將穩定項目移轉到遠端資源。關於訂閱結構與相容性差異，可繼續閱讀Clash 訂閱格式詳解，避免將節點訂閱、完整設定與規則集訂閱混為一談。

CHAPTER 03 / DNS PIPELINE

DNS 設定最佳化

DNS 設定決定網域如何取得位址，也會影響規則能否看見原始網域、連線是否繞過代理，以及 TUN 模式下的相容性。常見誤區是將所有解析器堆進同一份清單，希望數量越多越穩定。實際運作中，解析器協定、存取路徑、地區回應與規則模式必須互相配合。排錯時應將流程拆成四段：用戶端是否把查詢交給 mihomo、mihomo 選用了哪個 nameserver、查詢透過直連還是代理送出、回傳位址如何參與後續規則比對。只有明確故障位於哪一段，修改才不會擴大變數。

基礎解析器與業務解析器

default-nameserver 用於解析加密 DNS 伺服器本身的網域等引導工作，通常應填入可直接存取的 IP 位址解析器，避免「先解析解析器網域」的循環依賴。nameserver 是主要查詢來源，可以包含一般 UDP/TCP DNS、DoT 或 DoH。加密協定能保護至解析器之間的查詢傳輸，但其連線仍需要正確路由。若 DoH 網址被規則分配至代理，而代理節點網域又等待同一 DoH 解析，就可能在啟動階段卡住，因此節點網域與解析器網域的引導路徑必須分開考量。

proxy-server-nameserver 可專門負責代理節點網域解析，使節點連線不依賴面向業務網域的 Fake-IP 結果。nameserver-policy 則依網域指定解析器，例如讓內部網域使用區域網路 DNS、特定地區網域使用對應的解析服務。策略比對應由具體到寬泛，並留意規則集表示式是否受目前核心支援。企業內網中，內部網域常回傳私有位址；若交給公網解析器，不僅會失敗，還可能將查詢送往不應存取的解析路徑。

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

監聽位址決定哪些裝置可以使用該 DNS 服務。僅供本機使用時可綁定回環位址；需要區域網路裝置存取時才綁定所有介面，並同時檢查防火牆、區域網路存取許可與連接埠衝突。將 DNS 暴露在可被外部網路存取的介面會增加濫用風險，因此伺服器環境應透過防火牆限制來源。是否啟用 ipv6 應依本地網路與代理節點的 IPv6 能力決定。單純關閉 IPv6 可能掩蓋路由問題，也可能讓僅提供 AAAA 記錄的服務無法連線；啟用後若上游或出口沒有可用 IPv6，則可能出現先嘗試 IPv6、等待失敗後才回退的延遲。

redir-host 與 Fake-IP 的取捨

redir-host 回傳真實位址，傳統相容性較直觀，但在透明接管中，後續連線只攜帶目標 IP 時可能遺失網域資訊，網域規則需要透過映射或嗅探恢復。fake-ip 為網域分配保留位址，核心透過映射表在連線到達時恢復原始網域，因此規則比對通常更穩定，也能減少應用程式繞過核心、自行連線解析結果的情況。代價是少數依賴真實 DNS 回應、區域網路探索、時間同步、遊戲或特殊裝置服務可能不相容，需要加入 fake-ip-filter。

篩選清單不應直接從一份巨大範本複製。項目過寬會讓大量網域退出 Fake-IP 流程，削弱規則一致性；項目過窄則會留下特定應用故障。更可靠的方法是從預設設定開始，在日誌中觀察異常網域，並一次加入一個明確項目。修改後清除作業系統 DNS 快取、應用程式快取與核心映射，再重新建立連線，否則舊結果可能使測試結論失真。瀏覽器還可能啟用自己的安全 DNS，排錯階段應暫時確認其解析入口是否與系統一致。

DNS 洩漏與錯誤歸因

所謂 DNS 路徑異常，通常不是單一開關造成的。系統可能同時存在瀏覽器 DoH、系統 DNS、TUN DNS 劫持、容器內部解析器與區域網路路由器轉發。應先用日誌確認查詢是否進入 mihomo，再檢查解析器的連線方向。若日誌完全看不到目標網域查詢，問題在應用程式或系統層；若看得到查詢但逾時，檢查上游可達性與路由；若解析成功卻連線失敗，再轉向規則、策略組與節點，而不是繼續更換 DNS。比較測試時每輪只更換一個解析器或一種增強模式，並保留時間點，方便與日誌對照。

快取可以降低解析延遲，卻也會延長錯誤記錄與舊位址的影響。網域切換伺服器、規則剛修改或 Fake-IP 模式剛變更時，應同時考量應用程式快取、系統快取與核心快取。不必每次都重新啟動整台裝置，優先使用用戶端提供的 DNS 快取清除功能，再關閉並重新開啟目標應用程式。若故障只發生在某個瀏覽器、某個容器或某台區域網路裝置，應比較它們的 DNS 設定，不要為此將全域設定改到所有裝置都承擔額外複雜度。

CHAPTER 04 / TUN AND FAKE-IP

TUN 與 Fake-IP 的接管邊界

系統代理只會影響遵循代理設定的應用程式，TUN 則透過虛擬網路介面接管更廣泛的 IP 流量。命令列程式、部分遊戲、系統服務與不讀取代理設定的軟體，在系統代理模式下可能直接連線，而 TUN 能將這些連線送入核心規則鏈。接管範圍擴大也意味著路由、DNS、防火牆、虛擬機與其他網路工具之間更容易發生衝突。啟用前應先確認一般系統代理模式可以正常使用，確保訂閱、節點與規則本身有效，再單獨驗證 TUN，否則節點故障與路由故障會疊加在一起。

核心參數與系統差異

stack 決定 TUN 使用的網路堆疊實作。system 傾向使用系統網路堆疊，相容性通常較直觀；gvisor 使用使用者態網路堆疊，在某些環境能改善隔離或特定協定表現，但也可能增加負擔；mixed 會依流量類型組合處理。沒有一種選擇適用所有系統，出現特定應用程式逾時、UDP 異常或吞吐量下降時，可在保持其他設定不變的前提下逐一測試。

auto-route 讓核心自動新增路由，將目標流量導向虛擬介面。auto-detect-interface 用於辨識真實出站網卡，筆記型電腦在有線、無線、熱點與 VPN 之間切換時尤其有用。Windows 上通常還需留意防火牆、網路設定檔與其他虛擬網卡；macOS 可能需要系統授權；Linux 服務環境則涉及執行權限、策略路由與防火牆框架。圖形化用戶端往往會代為處理部分權限，但權限提示被拒絕、服務元件未啟動或舊路由未清除時，介面上的開關仍可能無法真正接管。

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

dns-hijack 會將指定連接埠的 DNS 請求導入核心解析流程，是 Fake-IP 正常運作的關鍵環節之一。部分應用程式使用內建 DoH 時不會存取傳統 53 連接埠，因此僅靠劫持無法涵蓋所有查詢。strict-route 可減少流量從其他介面繞行，但在虛擬機、區域網路共享、企業 VPN 或多網卡環境中，也可能阻斷原本需要保留的路徑。啟用後若本地印表機、NAS 或公司內網突然無法存取，應檢查路由排除與私有網段規則，而不是直接將全部私有位址交給代理。

MTU、回環與路由衝突

MTU 不匹配常表現為部分網站能開啟、較大的請求卡住、上傳失敗或特定通道內連線逾時。由於小型封包仍可通過，問題容易被誤判為節點不穩定。可以在固定節點的情況下逐步降低 TUN MTU 進行比較，但不應任意降得過低；過低會增加分片與處理負擔。若只有經過另一個 VPN、行動熱點或 PPPoE 的環境出現問題，應優先考慮底層鏈路額外封裝造成的有效 MTU 減少。

核心自身發出的代理連線必須從真實介面出站，不能再次被 TUN 捕獲，否則會形成回環。自動路由與介面偵測通常會處理這點，但自訂路由、容器網路、策略路由或多個透明代理同時存在時仍可能出錯。典型現象是啟用 TUN 後所有節點同時逾時，關閉後立即恢復。此時應查看路由表與出站介面，確認代理伺服器位址是否已排除、預設路由優先順序是否正確，以及舊用戶端遺留的虛擬介面是否仍在運作。

Fake-IP 映射如何參與規則

應用程式向 DNS 請求網域時，核心回傳 Fake-IP 並記錄網域與該位址的映射。應用程式隨後連線至 Fake-IP，TUN 捕獲連線，核心恢復網域並依網域規則比對，最後透過選定的策略存取真實目標。這個過程中的 Fake-IP 只存在於本機接管鏈路，不是真實的遠端位址。若應用程式快取了舊 Fake-IP，而核心映射因重新啟動或設定切換而遺失，就可能無法還原網域。清除應用程式連線與 DNS 快取通常比繼續增加規則更有效。

區域網路服務、廣播探索與需要回傳真實位址的應用程式可透過 fake-ip-filter 排除，但還要確保對應的私有網段規則位於合理位置。僅排除網域並不會自動保證流量直連；解析得到私有位址後，後續規則仍可能將它送入代理組。反過來，僅新增私有網段直連，也無法修復依賴真實 DNS 回應內容的應用程式。排錯時要將「DNS 回傳什麼」與「連線最後走哪裡」視為兩個獨立問題。

若啟用 TUN 後出現全域無法上網，可按固定順序檢查：先關閉 TUN 驗證基本代理；再開啟 TUN 但保持 DNS 設定不變；查看虛擬介面是否建立；確認預設路由與實體介面；檢查 DNS 查詢日誌；最後測試固定 IP 與網域存取的差異。固定 IP 可通、網域不可通時，重點檢查 DNS；兩者都不可通時，重點檢查路由、權限與回環。更通用的斷網定位流程可參考Clash 執行日誌怎麼看。

CHAPTER 05 / DOMAIN SNIFFING

網域嗅探與目標還原

透明代理接收到的連線有時只包含目標 IP，沒有原始網域。網域嗅探會檢查連線初期的協定特徵，從 HTTP Host、TLS ClientHello 中的伺服器名稱或支援的 QUIC 資訊恢復網域，再讓網域規則參與比對。它主要解決「應用程式已自行解析，核心只看見 IP」的問題，不是 DNS 的替代品，也無法從所有加密或非標準協定中恢復目標。設定時需要明確嗅探對象、連接埠範圍與覆蓋條件，避免將無關流量誤判。

override-destination 的影響

只辨識網域而不覆蓋目標時，核心可用還原出的網域完成規則比對，但連線仍指向應用程式原先解析得到的 IP。啟用 override-destination 後，核心可能依嗅探結果重新決定目標，適合修復應用程式解析結果與代理側存取路徑不一致的情況。不過，CDN、私有解析、分流 DNS 與固定位址服務可能預期連線使用原始 IP；覆蓋後若網域重新解析至另一個位址，可能導致地區差異、憑證問題或無法存取內部服務。因此應優先依協定與連接埠縮小範圍，並為已知不相容網域設定跳過清單。

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
  skip-domain:
    - "Mijia Cloud"
    - "+.push.apple.com"
  skip-src-address:
    - 192.168.0.0/16
  skip-dst-address:
    - 10.0.0.0/8

parse-pure-ip 允許對目標為純 IP 的連線嘗試嗅探，正是透明接管中常用的能力，但會增加檢查範圍。force-dns-mapping 與 DNS 映射協同運作，適合需要從既有映射恢復網域的環境。協定連接埠應依真實業務填寫：HTTP 不只運作於 80 連接埠，TLS 也可能使用 8443 等連接埠；反過來，將所有連接埠都交給所有嗅探器會增加誤判與處理成本。應從常用連接埠開始，只有日誌證明某個應用程式運作於其他連接埠時才補充。

嗅探無法解決的情況

加密用戶端問候、ECH、非標準封裝、憑證固定與沒有網域欄位的協定，都可能讓嗅探無法取得有效主機名稱。UDP 協定的資訊也往往少於 HTTP。此時日誌只顯示目標 IP 並不代表功能失效，而是連線本身沒有可讀取的網域。可以改用 IP 規則、程序規則，或讓應用程式 DNS 進入核心，而不是不斷擴大嗅探範圍。程序規則依賴平台權限與核心能力，伺服器或行動系統的可用性可能不同，部署前應以用戶端實際日誌為準。

誤嗅探通常表現為某個區域網路裝置、遊戲、推播服務或特殊用戶端在啟用功能後失敗。先關閉 override-destination 但保留嗅探，判斷問題來自辨識本身還是目標覆蓋；再依來源位址、目標位址或網域加入跳過項目。區域網路網段通常沒有必要全面嗅探，因為內部 DNS 與固定位址更應保持原有路徑。跳過規則也不宜寫成涵蓋所有公網的寬泛網段，否則嗅探功能形同關閉。

與 Fake-IP 和規則比對的協同

Fake-IP 已能透過映射還原大多數由核心 DNS 處理的網域，因此嗅探主要用來補足繞過系統 DNS 的應用程式、既有連線或直接連線真實 IP 的情境。兩者同時啟用時，要觀察日誌中最後使用的是 DNS 映射網域還是嗅探網域。若同一連線得到不同結果，目標覆蓋可能改變存取位址。可先採用「Fake-IP 負責一般網域，嗅探只檢查常見 HTTP/TLS 連接埠且預設不覆蓋」的保守方案，穩定後再為明確應用程式開啟覆蓋。

驗證嗅探不應只看網頁是否開啟。應查看連線詳細資訊中的目標主機、命中規則與策略組：關閉嗅探時記錄一次，開啟後用同一應用程式、同一網域重新建立連線，再比較目標是否從 IP 變為網域、規則是否由 IP 類切換為網域類。既有長連線不會因修改設定而自動重建，需要徹底退出應用程式或等待連線關閉。瀏覽器的連線重用與 QUIC 會延長舊工作階段，因此測試時可使用新的私密視窗並暫時清除網站連線狀態。

網域嗅探屬於補充手段。若 DNS 查詢本來就能穩定進入核心，規則也能依網域命中，就不必為了設定完整而擴大嗅探範圍。每增加一種協定與連接埠，都應有明確問題作為依據，並記錄啟用前後的日誌差異。如此在應用程式更新或網路環境變化後，才能判斷舊的相容性例外是否仍有必要。

CHAPTER 06 / PROFILE MERGE

本機覆寫與多訂閱合併

訂閱更新會重新產生遠端設定，直接在訂閱檔案中修改規則、DNS 或策略組，下次更新時通常會被覆蓋。可維護的做法是將遠端訂閱視為唯讀輸入，把本機長期設定放入覆寫、擴充腳本或獨立主設定。不同用戶端對覆寫格式與合併順序的實作並不完全相同，因此不能將某個用戶端的擴充語法當成 mihomo 原生 YAML。遷移用戶端前，應先區分哪些欄位屬於核心，哪些屬於圖形化用戶端的設定管理層。

覆蓋、追加與刪除是三種操作

純量欄位如 mixed-port、mode 通常可以直接覆蓋；映射欄位如 dns 可能依鍵合併，也可能整段替換；陣列欄位如 rules、proxy-groups 更複雜，單純覆蓋會遺失訂閱內容，單純追加又可能讓兜底規則提前截斷後續項目。尤其 MATCH 必須位於規則末尾，如果將本機規則追加到遠端 MATCH 之後，它們永遠不會命中。可靠的合併器應支援前置、後置、依名稱替換與明確刪除，並在輸出階段檢查最終順序。

策略組依 name 關聯時，同名組可能被替換，也可能形成重複項目。重複名稱會讓規則引用結果不明確，用戶端介面也可能只顯示其中一個。合併前應建立固定命名規範，例如本機業務組使用清楚的中文名稱，遠端自動組保留來源前綴。節點名稱同樣可能衝突：兩份訂閱都含有「香港 01」時，核心可能回報代理名稱重複。解決方式是在匯入層為不同來源新增前綴，而不是手動修改每個節點，因為下次更新仍會再次衝突。

# 本機維護的主設定片段
proxy-providers:
  provider-a:
    type: http
    url: https://subscription.example.invalid/a
    path: ./providers/a.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 300

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

proxy-groups:
  - name: 所有來源
    type: select
    use:
      - provider-a
      - provider-b
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,corp.example.invalid,DIRECT
  - RULE-SET,private-domain,DIRECT
  - MATCH,所有來源

使用 proxy-providers 彙整多個節點訂閱，通常比直接拼接多份完整設定更清楚。完整設定可能各自包含連接埠、DNS、規則與同名策略組，機械式拼接極易衝突；節點提供者只提供代理項目，主設定統一控制其他部分。若上游回傳的是完整 Clash 設定而不是 provider 格式，應先確認用戶端能否提取節點，或在可信的本機流程中轉換。不要將包含存取憑據的訂閱交給來源不明的線上轉換頁面。

覆寫層級與回退檔案

建議保留四層：原始訂閱、本機覆寫、合併後的最終設定、最近一次可用設定。原始訂閱用於確認上游內容；本機覆寫進入版本管理時應移除訂閱網址與存取憑據；最終設定用於定位合併結果；可用設定用於故障回退。每次修改只變更本機覆寫，產生後先進行語法檢查，再讓核心載入。若用戶端沒有匯出最終設定的功能，可從執行目錄找到實際載入的檔案，但要注意該檔案可能被用戶端自動重寫，不適合作為編輯入口。

本機覆寫最適合維護穩定意圖：自訂規則、固定策略組架構、DNS 選擇與區域網路例外。節點清單、驗證欄位與上游隨時變動的屬性應繼續由訂閱提供。如此更新時既能取得新節點，又不會覆蓋本機分流。若某個上游開始提供不相容欄位，應在覆寫層進行最小化刪除或轉換，並記錄原因；不要長期複製整份舊設定並凍結，否則節點與協定能力會逐漸失去更新。

多訂閱的可用性與故障隔離

多個提供者不應共用相同快取路徑，健康檢查也應獨立。某個來源更新失敗時，其他來源仍可載入；若所有組都只引用失敗來源，表面上設定載入成功，策略組卻會沒有可用成員。可在上層手動組中保留多個自動組，並明確標示來源。自動選擇組若混入不同用途、不同地區的所有節點，探測結果可能頻繁變動；更合適的方式是先依來源或地區分組，再在業務層選擇這些子組。

合併後的驗證重點包括：策略組名稱是否唯一、每個引用是否存在、提供者路徑是否不同、規則末尾是否只有預期的兜底規則、DNS 映射是否完整、敏感欄位是否意外寫入日誌或匯出檔案。更新訂閱前後可對最終設定進行結構化比較，關注欄位變化，而不是只比較文字行。若一次更新後無法啟動，先恢復最近可用設定，再比較上游新增欄位，避免在不可用狀態下連續修改多個覆寫規則。

圖形化用戶端的覆寫入口與儲存位置各不相同。Clash Plus 適合需要以圖形介面管理設定與策略組的桌面使用者；Clash Verge Rev、FlClash、Clash Nyanpasu 等用戶端也可能提供擴充或腳本能力，但語法應以其目前介面說明為準。需要重新選擇時可查看用戶端選擇指南，不要只憑某段可複製腳本決定用戶端。

CHAPTER 07 / EXTERNAL CONTROLLER

外部控制面板與 API 邊界

mihomo 的外部控制介面允許圖形介面或 Web 控制面板讀取執行狀態、切換策略、查看連線並更新設定。它是管理介面，不是代理連接埠。將 external-controller 設為監聽位址後，用戶端會透過 HTTP 與 WebSocket 連線至該連接埠。控制面板通常只包含靜態前端檔案，真正的資料與操作能力來自核心介面。因此頁面打不開、能開啟但沒有資料、能查看卻無法操作，分別對應靜態資源、介面連線與驗證權限等不同問題。

監聽位址與存取範圍

僅在本機使用時綁定 127.0.0.1 最穩妥，其他裝置無法直接存取。需要從區域網路管理伺服器或路由器時，才綁定 0.0.0.0 或指定區域網路位址，並透過防火牆只允許可信網段。監聽所有介面不代表應開放至公網。控制介面可以切換節點、讀取連線目標並重新載入設定，暴露範圍應小於一般代理連接埠。遠端維護優先使用 SSH 通道或受控的反向代理存取本機介面，而不是直接開放控制連接埠。

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./ui
external-ui-name: dashboard

# 從另一台裝置暫時透過 SSH 轉發本機介面
ssh -L 9090:127.0.0.1:9090 [email protected]

secret 用於控制介面驗證，應設定為獨立且難以猜測的值。範例中的字串只是明顯的教學值，部署時需要自行替換。控制面板通常要求在設定中填寫 API 位址與金鑰；API 位址應指向核心的監聽位置，而不是代理的 mixed-port。若頁面透過 HTTPS 載入，卻嘗試存取 HTTP 控制介面，瀏覽器可能因混合內容政策阻擋請求。此時應透過同源反向代理或安全通道統一存取方式，而不是關閉瀏覽器安全限制。

external-ui 與靜態資源目錄

external-ui 指向控制面板靜態檔案目錄，目錄中應存在入口 HTML 與配套資源。此欄位不負責下載面板，路徑也以核心執行工作目錄為基準。系統服務與手動執行命令的工作目錄可能不同，因此「終端機啟動看得到、服務啟動一片空白」通常是相對路徑解析差異。可改用明確的絕對路徑，或確認服務單元的工作目錄與檔案權限。唯讀檔案系統中，面板檔案應預先部署到可讀取的位置。

部分設定支援透過外部 UI 下載網址維護靜態資源，但生產環境仍應記錄來源並固定更新流程。面板更新與核心更新是兩個獨立過程，新面板可能呼叫舊核心不支援的介面，舊面板也可能無法顯示新欄位。遇到介面按鈕失效時，先在瀏覽器開發者工具中查看請求狀態與介面回應，再對照核心日誌；不要先刪除主設定，因為控制面板異常通常不會改變代理核心是否能運作。

CORS、驗證與反向代理

控制面板與 API 位於不同來源時，瀏覽器會執行跨來源檢查。mihomo 可透過允許來源相關設定限制可存取的頁面來源。為了省事允許任意來源，會擴大瀏覽器端攻擊面；更合理的做法是只列出實際控制面板網址。即使設定了來源限制，也不能取代金鑰與網路層限制。三者職責不同：防火牆限制誰能連接埠，驗證決定請求是否具備操作權限，來源策略限制哪些網頁可以由瀏覽器發起呼叫。

使用反向代理時應正確轉發 WebSocket 升級請求，否則一般狀態介面可能可用，實時日誌與連線清單卻持續中斷。代理層還要保留驗證標頭，並限制請求本文大小與存取路徑。不要讓反向代理同時將代理連接埠、控制介面與靜態面板混在沒有區分的路徑下。若只需要區域網路存取，直接綁定區域網路位址並設定防火牆，往往比複雜的公網代理更容易維護。

介面故障的分層檢查

先用系統工具確認連接埠是否正在監聽，再請求基礎介面驗證身分，接著檢查瀏覽器主控台。連線被拒絕表示核心未監聽、位址錯誤或防火牆阻擋；回傳未授權表示介面可達但金鑰不匹配；一般請求成功而即時內容失敗，重點檢查 WebSocket；面板資源回傳找不到，則檢查 external-ui 路徑。若控制面板顯示策略組為空，應直接查看 API 回傳與核心設定，判斷是面板渲染問題還是策略組本身沒有成員。

外部控制介面也適合自動化健康檢查，但腳本不應高頻輪詢所有連線，更不應將金鑰寫入公開儲存庫、命令歷史或前端頁面。自動化只讀取必要端點，並為失敗設定逾時與退避。設定重載屬於有狀態操作，執行前應保留目前可用檔案，重載後確認核心回傳成功並重新檢查策略組。控制面板提供便利入口，但最終判斷仍以設定檔、介面回應與核心日誌為準。

CHAPTER 08 / VALIDATION

設定驗證、日誌定位與安全回退

進階設定的難點通常不在某個欄位本身，而在多個子系統同時變動後無法定位因果。有效的維護流程應將語法驗證、靜態引用檢查、啟動日誌、執行連線與業務結果分開觀察。網頁能開啟只代表某條路徑可用，不代表 DNS、規則與 TUN 都依預期運作；反過來，某個網站失敗也不等於節點不可用。每次修改前記錄基線，修改後使用固定目標與固定策略測試，才能得到可比較的結論。

載入前的靜態檢查

首先檢查 YAML 縮排、冒號、清單層級與重複鍵。YAML 使用空格縮排，定位字元可能導致解析錯誤；包含冒號、井字號或特殊字元的名稱可加上引號，避免被解釋為結構或註解。語法通過後再檢查語意引用：規則指向的策略組是否存在，策略組引用的節點或 provider 是否存在，規則集名稱是否一致，快取路徑是否衝突，控制介面連接埠是否與 mixed-port、DNS 監聽連接埠重複。

mihomo 可透過命令列指定設定目錄並執行檢查，不同部署套件的可執行檔名稱與參數入口可能由用戶端封裝。直接使用核心時，可在實際執行環境中執行設定測試，確保相對路徑、權限與資源檔案和服務環境一致。只在個人終端機驗證，而服務使用另一個帳戶，可能漏掉路徑與權限問題。

# 進入實際設定目錄後執行
mihomo -t -d /path/to/config-directory

# 在前景啟動以觀察完整日誌
mihomo -d /path/to/config-directory

# Linux 查看路由與監聽連接埠
ip route
ss -lntup

設定測試通過不代表遠端資源一定可下載，也不代表節點可連線。它主要確認本機結構與部分資源是否可讀取。首次啟動時繼續觀察 provider 更新、DNS 監聽、TUN 介面、控制連接埠與代理連接埠的日誌。日誌中的第一個錯誤往往比後續連鎖錯誤更接近根因。例如 DNS 監聽連接埠衝突會導致解析不可用，隨後出現的大量節點網域解析失敗只是結果。

依執行鏈建立測試矩陣

測試應從最小鏈路逐步增加功能。第一輪關閉 TUN，使用系統代理與固定手動節點，驗證基本 TCP 連線；第二輪保持節點不變，驗證網域解析與規則命中；第三輪切換自動策略組，確認健康檢查；第四輪啟用 TUN；第五輪再啟用嗅探、覆寫或複雜規則集。每輪只增加一個變數。若在第三輪失敗，就不必繼續懷疑第五輪的嗅探參數。

讀取日誌時區分階段

啟動階段關注設定解析、連接埠綁定、資源載入與虛擬介面建立；訂閱階段關注 HTTP 狀態、逾時、格式解析與快取寫入；DNS 階段關注查詢來源、上游選擇與回傳結果；連線階段關注目標、規則、策略組與實際節點；執行階段再觀察健康檢查與連線關閉原因。不要看到「timeout」就立即更換節點，同一個詞可能來自規則下載、DNS 查詢、代理握手或業務伺服器，每種逾時的處理方向都不同。

連線詳細資訊通常能提供來源位址、目標網域或 IP、網路類型、命中規則、策略鏈與出站節點。依序讀過這些欄位，可以判斷請求在哪一層偏離預期。例如目標網域正確但命中 MATCH，表示前面的規則沒有涵蓋；命中規則正確但策略組落到意外節點，檢查組內選擇與自動測試；策略與節點都正確仍失敗，再檢查節點連線、目標服務與 MTU。這樣的順序比反覆切換模式更容易排除問題。

回退不是單純恢復一個檔案

設定故障可能同時留下路由、虛擬介面、DNS 快取與遠端資源快取。恢復 YAML 後若現象仍然存在，需要確認核心已重新載入該檔案、舊程序已經退出、TUN 路由已清除、系統代理已恢復、DNS 快取已刷新。圖形化用戶端可能保存一份介面設定與一份實際執行設定，恢復錯誤檔案不會改變核心行為。完成回退後應重新查看啟動日誌中的設定路徑。

建議每次穩定變更形成一個可回退節點，至少保存設定檔、相關規則集版本、用戶端使用的設定目錄與變更說明。說明應寫清楚「解決什麼問題、修改哪些欄位、如何驗證、如何撤銷」，而不是只記錄「最佳化 DNS」。訂閱網址與控制金鑰不應進入公開版本庫；可以使用獨立的本機私密檔案或由執行環境注入，再讓設定引用。分享日誌時也要移除訂閱參數、節點驗證資訊、控制金鑰與內部網域。

建立可重複的維護順序

一次完整調整可依以下順序執行：複製目前可用設定；匯出或記錄最終合併結果；只修改一個主題；執行靜態檢查；在前景載入並觀察第一個錯誤；固定節點驗證系統代理；檢查 DNS 查詢與規則命中；最後啟用 TUN 與嗅探；穩定後再恢復自動策略與遠端更新。若任一步驟失敗，回到上一份可用設定，並清除該步驟產生的執行狀態。這個流程看似較慢，卻能避免多個變數疊加後進行更長時間的盲目排錯。

對於日誌量較大的環境，可依目標網域、來源程序或時間範圍篩選，不必長期使用最詳細的日誌等級。詳細日誌適合短時間定位，持續啟用會產生大量記錄並增加敏感資訊暴露範圍。問題解決後恢復一般等級，並保留精簡的故障摘要。若需要理解啟動、訂閱、DNS、連線與規則階段的典型錯誤，可結合執行日誌定位順序逐項核對；區域網路共享涉及 mixed-port、監聽位址與防火牆時，可閱讀混合連接埠與區域網路代理設定。