Clash 進階用法：策略、規則與流量接管

設定閱讀方法與變更順序

先分清設定的五個處理層級

一條連線進入 mihomo 後，並不會直接連到某個節點。核心會先取得目標位址；如果應用程式只提交 IP，網域嗅探可能補回網域名稱；DNS 模組決定解析方式，並維護真實位址或 Fake-IP 對應；規則系統按照由上而下的順序尋找第一個符合項目；匹配結果再指向策略組，由策略組選擇具體代理、直連或拒絕。TUN 位於更接近系統網路的一側，負責將原本不會進入系統代理的流量送入核心。理解這條鏈路後，排錯就能依照「是否已接管、是否有網域、是否完成解析、命中哪條規則、策略最後選了誰」的順序進行。

設定檔通常由連接埠、執行模式、DNS、TUN、代理提供者、策略組、規則提供者與規則組成。欄位位置本身不代表執行順序，但 YAML 的層級與縮排會決定欄位是否隸屬於正確模組。兩個空格是常見的縮排方式，清單項目使用短橫線。布林值寫成 true 或 false，不要加引號；連接埠寫整數；包含冒號、井字號或特殊字元的一般字串適合加上引號。儲存前可利用客戶端的設定檢查功能，先排除格式錯誤，再判斷網路行為。

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

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

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

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,節點選擇

上面的骨架只說明層級關係，不構成完整訂閱。mixed-port 同時接受 HTTP 與 SOCKS 連線，適合讓本機應用程式統一填寫一個連接埠；mode: rule 表示依規則處理；store-selected 用於記住策略組選擇；MATCH 是最後的兜底規則。若客戶端已從訂閱產生代理與策略組，不要為了套用範例而刪除原有內容，只需在覆寫區加入需要調整的欄位。

建立可回退的變更流程

穩定的設定修改應保留三個狀態：訂閱原始設定、目前可用設定、正在測試的修改。訂閱原始設定用於確認上游內容；目前可用設定是回退點；測試設定只負責一個明確目標，例如「讓開發網域直連」或「使用 TUN 接管命令列工具」。客戶端支援覆寫時，優先將本機變更寫入覆寫檔案，不要直接編輯訂閱下載結果。訂閱更新通常會替換主要設定，直接修改的內容可能隨更新消失，而獨立覆寫更容易檢視與遷移。

每次變更後先進行低成本驗證：設定能否載入、日誌是否出現解析錯誤、系統代理或 TUN 是否成功啟動，以及一個直連目標和一個代理目標能否分別運作。接著再驗證規則命中與 DNS。不要只以「網頁打開了」作為成功標準，因為瀏覽器快取、既有連線和系統 DNS 快取都可能掩蓋問題。測試規則時可改用新的網域或重新啟動目標應用程式；測試 DNS 時可清理應用程式連線，並觀察核心日誌中的查詢與匹配記錄。

日誌層級建議日常使用 info。需要追蹤規則與 DNS 時，暫時切換到 debug，完成後再恢復，避免大量日誌影響定位。遇到介面提示與核心日誌不一致時，應以核心是否載入設定、實際連線是否出現為判斷依據。仍無法確認問題時，可前往 FAQ 對照基礎故障分類；若是系統代理與 TUN 的選擇問題，可繼續閱讀 TUN 模式與系統代理的運作機制比較。

策略組類型與實際組合

選擇、自動測試與故障轉移

策略組是規則結果與具體代理之間的中間層。規則最好指向具有業務意義的組名，例如「節點選擇」「串流媒體」「開發服務」，而不是直接指向會隨訂閱變動的節點。如此更新訂閱、刪除節點或臨時更換線路時，只需調整策略組，不必修改大量規則。最常用的 select 由使用者明確選擇成員，行為穩定，適合總入口與需要固定出口的服務。組內可以放入具體代理，也可以引用其他策略組，因此能構成「業務組 → 地區組 → 自動測速組」的層級。

url-test 會依設定的網址定期測試組內代理，選擇測試結果較佳的成員。它適合日常自動選擇，但測試結果只代表該代理到測試網址的連通狀況，不保證目標網站一定採用相同路徑。fallback 更強調可用性順序，通常由前往後選擇第一個可用成員，適合準備主要線路與備用線路。load-balance 會將連線分配給多個成員，適用於確實需要分散連線的情境；它可能讓同一項服務在短時間內出現不同出口，因此登入、付款或依賴工作階段一致性的服務不應隨意使用。

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

  - name: 自動選擇
    type: url-test
    use:
      - provider-main
    url: https://www.example.com/
    interval: 600
    tolerance: 80
    lazy: true

  - name: 故障轉移
    type: fallback
    use:
      - provider-main
    url: https://www.example.com/
    interval: 600
    lazy: true

use 用於引用代理提供者，適合訂閱節點會動態變化的情況；proxies 則列出固定成員或其他組名。interval 是測試間隔，設定過短會增加網路請求與行動裝置耗電，過長則可能延遲發現不可用線路。tolerance 用於減少數值輕微波動造成的頻繁切換：只有新結果達到足夠差異時，才會觸發選擇變更。啟用 lazy 後，策略組長時間未使用時可減少不必要的主動測試。

按業務建立群組，不要按規則數量建立群組

策略組名稱應描述決策，而不是描述規則來源。名為「影片規則集」的組會讓規則與策略緊密耦合；改成「串流媒體」後，無論匹配來自網域規則還是規則集，出口意義都很清楚。基礎結構通常只需總入口、自動選擇、故障轉移與直連，再按確實有差異的業務增加組別。組越多，更新訂閱後需要檢查的選項越多，也更容易形成循環引用。mihomo 無法從循環策略中取得最終代理，例如 A 引用 B、B 又只引用 A；這類結構應在設計階段避免。

地區組可以透過代理提供者篩選取得，但篩選依賴節點名稱。名稱來自訂閱上游，可能包含地區中文名、英文縮寫或圖形符號。只寫過窄的運算式會漏掉節點，寫得過寬又可能誤收。設定完成後應在客戶端中開啟該組，確認成員清單，而不只是確認語法通過。對於需要固定首選出口的服務，應使用 select 並手動鎖定；一般瀏覽則可讓總入口預設指向自動選擇。

proxy-groups:
  - name: 開發服務
    type: select
    proxies:
      - 節點選擇
      - 故障轉移
      - DIRECT

  - name: 本地直連
    type: select
    proxies:
      - DIRECT
      - 節點選擇

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - RULE-SET,development,開發服務
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,節點選擇

DIRECT 與 REJECT 也是可作為規則目標的內建策略。直連不等於繞過核心：在規則模式下，連線仍可能先進入 Clash，再由核心建立直連。若區域網路裝置存取異常，要同時檢查規則是否直連、TUN 是否產生衝突路由，以及作業系統防火牆。拒絕策略適合明確不需要的網域，但規則集過寬時可能導致頁面資源缺失；修改後要測試主頁、登入、圖片與 API 請求，不能只確認首頁能開啟。

排查策略組時，先確認組內是否有成員，再確認目前成員是否能建立連線，最後檢查規則是否確實指向該組。若訂閱更新後群組變空，常見原因是代理提供者載入失敗，或篩選條件沒有匹配新的名稱。若群組能運作但每次重新啟動都恢復預設，請檢查 profile.store-selected 是否啟用，以及客戶端是否使用暫存設定覆蓋持久化目錄。客戶端選擇可在下載頁按平台比較；圖形介面使用者可優先選用 Clash Plus，再依系統需求選擇 Clash Verge Rev 或 FlClash。

規則集訂閱化管理

規則順序決定最終結果

Clash 規則採用由上而下、首次命中即停止的處理方式。規則數量不是首要問題，優先順序才是。通常將範圍最明確的自訂規則放在前面，例如單一網域、特定後綴與區域網路位址；接著放置業務規則集；後方再處理地區 IP、一般直連與最後兜底。若將 MATCH 放在中間，後續規則永遠不會執行。若寬泛的網域後綴排在精確規則之前，精確規則也會失去覆蓋機會。

DOMAIN 匹配完整網域，適合單一主機；DOMAIN-SUFFIX 匹配網域及其子網域，適合一個網站體系；DOMAIN-KEYWORD 範圍更寬，容易誤匹配，只有在網域結構確實不固定時才使用。IP-CIDR 與 IP-CIDR6 用於處理位址段。IP 規則可能觸發解析；若前面已透過網域完成判斷，或規則目標只關心現有目標 IP，可依情境加入 no-resolve，減少額外查詢。

rule-providers 的行為類型

規則提供者將外部規則檔案獨立於主要設定維護。behavior: domain 適合只包含網域類項目的集合；behavior: ipcidr 用於位址段集合；behavior: classical 支援帶有規則類型與參數的完整項目，表達能力最強。行為類型必須與檔案內容一致。將 DOMAIN-SUFFIX,example.com 放入只接受網域載荷的檔案，或將純位址段以 classical 使用，都會造成載入失敗或無法命中的結果。

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

  local-network:
    type: file
    behavior: ipcidr
    format: yaml
    path: ./ruleset/local-network.yaml

rules:
  - DOMAIN,build.internal.example,DIRECT
  - RULE-SET,development,開發服務
  - RULE-SET,local-network,DIRECT,no-resolve
  - MATCH,節點選擇

type: http 表示從 URL 更新，type: file 表示只讀取本機檔案。path 是快取或本機檔案位置，建議為每個提供者設定獨立檔名，避免多個規則來源互相覆蓋。interval 使用秒作為更新週期。規則內容變更不頻繁時，沒有必要設定過短週期；每天更新一次更容易控制請求量。遠端網址應使用穩定的 HTTPS 來源，組織內部規則可放在受控服務中，避免依賴臨時連結。

payload:
  - DOMAIN,api.example.com
  - DOMAIN-SUFFIX,developer.example
  - PROCESS-NAME,git
  - IP-CIDR,192.0.2.0/24,no-resolve

這是 classical YAML 規則檔案的常見結構。提供者檔案只寫匹配條件，不寫最終策略；策略在主要設定的 RULE-SET,development,開發服務 中指定。如此同一規則集可以在不同裝置上指向不同策略，例如桌面端交給「開發服務」，伺服器上交給固定出口。若需要更換策略，只需修改主要設定，不必複製與維護第二份規則資料。

訂閱化規則的維護邊界

規則集不應無限拆分。每個提供者都會帶來下載、解析、快取與故障定位成本。適合獨立成集的內容通常具有明確責任邊界：由不同人員維護、更新頻率不同、需要在多份設定間重複使用，或需要單獨啟用與停用。只有三、四條且長期穩定的本地規則，直接放在主要規則頂部會更清楚。命名要表達用途，例如 work-services、private-network，不要使用意義不明的 rules1。

更新失敗時，先區分「遠端下載失敗」與「檔案解析失敗」。前者檢查 URL 是否可達、DNS 是否正常、代理提供者是否需要透過代理更新；後者查看行為類型、格式、縮排與載荷結構。已有快取時，部分客戶端可能繼續使用舊檔案，因此頁面暫時仍能存取並不代表更新成功。查看日誌中的提供者名稱與更新時間，手動更新後確認是否出現新錯誤。若 GeoIP 或 GeoSite 資料相關規則異常，可繼續閱讀 GeoIP 與 GeoSite 資料庫更新方法。

完成規則維護後，應建立固定測試集：一個明確直連的網域、一個明確代理的網域、一個區域網路位址、一個只有 IP 的連線，以及一個最終兜底目標。每次更新規則來源後執行同一組測試，便能快速發現順序變更、規則來源失效與誤匹配。測試結果應查看命中的規則與策略名稱，不要以網頁觀感取代。如此即使規則集持續增加，仍能保持可解釋性。

DNS 設定最佳化與分流

先釐清 mihomo DNS 的職責

啟用 mihomo DNS 後，核心可以依規則處理網域查詢，並將查詢結果與後續連線關聯起來。它解決的不只是「更換 DNS 位址」，而是讓網域解析與代理決策處於同一條鏈路。若應用程式自行使用加密 DNS、直接連線固定位址或讀取獨立 hosts 檔案，查詢可能繞過核心；此時僅修改 nameserver 不一定能改變應用程式行為，還需結合 TUN 的 DNS 劫持、瀏覽器設定與網域嗅探判斷。

default-nameserver 主要用於解析其他 DNS 伺服器本身的網域，通常使用可直接存取的 IP 位址，避免出現「要存取加密 DNS，必須先解析它；但目前又沒有可用 DNS」的循環。nameserver 處理一般查詢。proxy-server-nameserver 可專門解析代理伺服器網域，減少代理節點網域解析對一般分流的依賴。nameserver-policy 依網域指定解析伺服器，適合內部網域、區域網路網域或確實存在解析差異的服務。

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

範例中的位址應依所在網路替換。只有確實需要讓本機其他程式查詢時，才設定 listen；若繫結至所有介面，還要確認系統防火牆與區域網路存取邊界。桌面客戶端通常會自動管理監聽位址，不必為了複製設定而強行開放。ipv6: false 表示 DNS 模組不回傳 IPv6 結果，適合目前網路沒有穩定 IPv6 路徑的情況；若網路與代理都完整支援 IPv6，可啟用後分別驗證直連與代理目標。

Fake-IP 與 redir-host 的取捨

fake-ip 模式會先回傳一個對應位址給應用程式；應用程式連線至該位址時，核心再還原原始網域並執行網域規則。這能讓規則匹配更直接，也可減少「先解析到某個 IP，之後只能依位址判斷」的資訊損失。對應位址只在本機核心內有意義，不應視為目標的真實位址。在封包擷取、日誌或應用程式診斷介面看到 198.18.0.0/16 類型的位址時，應先確認是否來自 Fake-IP 對應，而不是直接判定為異常 DNS 結果。

部分區域網路服務、裝置探索、網路連通性檢測、時間同步或依賴真實位址的應用程式不適合 Fake-IP，應加入 fake-ip-filter。篩選後，這些網域會回傳真實解析結果。篩選範圍不宜一開始寫得過寬，例如直接排除大量頂級網域會削弱 Fake-IP 的網域關聯優勢。遇到相容性問題時，先從具體網域開始，查看日誌確認後再加入後綴。redir-host 回傳真實 IP，相容性思路更接近傳統解析，但網域與連線的關聯方式不同；只有在明確遇到 Fake-IP 相容性問題且篩選無法解決時，才整體切換。

nameserver-policy 與解析路徑

內部服務通常要求透過路由器或企業 DNS 解析，公開 DNS 並不知道其記錄。可用 nameserver-policy 將指定後綴送往內部伺服器，同時在規則頂部將對應網域設為直連。DNS 分流與連線分流必須一致：網域由內部 DNS 取得私有位址，卻被規則送往外部代理，通常無法存取；網域由公開 DNS 解析為公網位址，卻被預期視為內部服務，也會產生錯誤。設定時應將「由誰解析」與「連線採用哪條策略」作為一組檢查。

使用 respect-rules 讓 DNS 連線遵循規則時，必須確保解析代理節點網域的路徑不會依賴尚未建立的代理。為此應設定可直接運作的 proxy-server-nameserver，並避免 DNS 規則形成循環。若啟動後所有連線都卡在解析階段，可暫時改用可直連的基礎 DNS，確認代理伺服器網域能解析，再逐步恢復加密 DNS 與依規則分流。

排錯時先用日誌確認查詢是否抵達 mihomo。如果完全沒有查詢記錄，檢查系統 DNS 是否已指向核心、TUN 的 DNS 劫持是否生效，以及應用程式是否啟用獨立 DNS。若有查詢但失敗，檢查上游伺服器是否可存取，以及網域型 DNS 位址能否由 default-nameserver 解析。若解析成功但連線仍失敗，繼續查看規則策略與實際目標，不要停留在 DNS 層。若只有區域網路裝置名稱解析失敗，檢查搜尋網域、路由器 DNS 與 Fake-IP 篩選，不要把所有網域都改成直連。

DNS 最佳化沒有單一通用答案。穩定的設定通常具備三點：基礎解析路徑可獨立啟動；內部網域的解析與連線策略一致；Fake-IP 例外具有具體原因與明確範圍。完成設定後，分別測試一般網頁、區域網路網域、代理伺服器網域與只支援 IPv6 的目標。記錄每類目標預期使用的解析伺服器與策略，之後更換網路時便能快速判斷是本地網路變更還是設定退化。

TUN 與 Fake-IP協同設定

何時需要 TUN

系統代理只對主動讀取作業系統代理設定的應用程式生效。命令列程式、部分遊戲、虛擬機器、固定使用直連套接字的軟體可能繞過系統代理。TUN 在作業系統網路層建立虛擬介面，透過路由將更多 TCP、UDP 流量送入核心，因此更適合需要統一接管的情境。它不一定比系統代理更快，也不應作為所有問題的預設修復方式。瀏覽器與一般桌面應用程式已穩定使用系統代理時，保持簡單設定通常更容易維護。

TUN 啟動涉及虛擬網卡、路由表、DNS 與系統權限。桌面客戶端通常會要求安裝服務或授予網路延伸功能權限；行動裝置則使用系統 VPN 介面。開關顯示已啟用，不代表所有流量都成功進入核心。應查看日誌中的 TUN 介面、路由與 DNS 劫持是否建立成功，並檢查目標連線是否出現。macOS 若遇到網路延伸功能或鑰匙圈授權問題，可閱讀 macOS 網路延伸功能與鑰匙圈處理步驟。

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

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

auto-route 讓核心自動寫入必要路由；auto-detect-interface 依目前網路選擇出口介面，適合在有線、無線與行動熱點之間切換的裝置；strict-route 用於減少流量繞過，但可能與虛擬機器、容器及其他 VPN 的路由發生衝突。啟用後若區域網路或公司網路突然無法存取，應先查看路由衝突，再決定是否關閉嚴格路由或增加明確排除，不要直接更換代理節點。

stack、MTU 與 UDP 行為

TUN 網路堆疊由核心版本與平台能力決定，常見選項包括 system、gvisor 與 mixed。系統堆疊通常利用作業系統的網路實作，相容性與效能表現受平台影響；gVisor 使用者態堆疊提供另一條處理路徑，遇到特定系統堆疊問題時可用於比較；mixed 混合處理不同流量，是許多桌面情境的起點。不要只根據名稱判斷優劣，應在同一網路、同一目標下分別測試 TCP、UDP、區域網路與休眠恢復。

MTU 過大時，某些鏈路上的分片或路徑探索異常會表現為「小頁面可以開啟，大檔案或特定請求卡住」；設定過小則會增加封包數量與額外開銷。預設值運作正常時不必修改。懷疑 MTU 時，應先確認問題是否只發生在 TUN，切回系統代理進行比較，再逐步降低數值測試，不要同時切換網路堆疊與 DNS。UDP 異常也要確認所選代理是否支援對應傳輸；TUN 只負責接管，不會替不支援 UDP 的代理增加能力。

Fake-IP 為什麼常與 TUN 搭配

TUN 會接收到大量原本不經過系統代理的連線。如果連線建立前的 DNS 查詢也被劫持到 mihomo，Fake-IP 可以保留網域資訊，讓這些連線繼續使用網域規則。若 DNS 查詢在核心外完成，TUN 只會看到真實 IP，規則可能退化為 IP 匹配或最終兜底。因此 TUN、DNS 劫持與 Fake-IP 應視為同一條鏈路檢查：應用程式查詢是否進入核心、回傳的對應是否被保存、應用程式連線至對應位址後是否還原網域，以及規則是否命中預期項目。

有些應用程式會自行連線至硬編碼 IP，從源頭就沒有網域。此時 Fake-IP 無法創造網域，需要依賴 IP 規則、程序規則，或網域嗅探能否從協定內容中識別目標。程序規則在不同平台上的可用程度不同，行動端限制通常更多。設定應保留最終兜底，並根據日誌中實際可見的資訊選擇規則類型，不要假定每條連線都能還原網域。

常見衝突來源包括其他 VPN、虛擬機器橋接、容器網路、區域網路代理工具與安全軟體。多個程式同時修改預設路由或 DNS 時，後啟動者可能覆蓋先啟動者。排查時記錄啟動順序，暫時關閉其他網路工具，再單獨啟用 Clash。若休眠恢復後失效，可先重新啟動 TUN 介面；若切換 Wi-Fi 後失效，檢查出口介面自動偵測。只有確認路由建立正常後，才繼續分析規則與代理。

行動裝置持續啟用 TUN 會讓核心常駐，測速週期、複雜規則與頻繁 DNS 查詢都會影響耗電。可降低自動測試頻率、精簡不使用的規則提供者，並允許客戶端在系統背景策略中穩定執行，避免反覆被停止與重建連線。Android 端的具體檢查順序可參考 Android 背景策略與耗電排查清單。

網域嗅探與規則補全

嗅探解決的是資訊缺失

當連線進入 mihomo 時，目標有時只有 IP。網域嗅探會檢查連線初期的協定資訊，從 HTTP Host、TLS ClientHello 中的伺服器名稱等位置還原網域，再讓網域規則參與決策。它不是讀取所有應用程式內容，也不是 DNS 的替代品。加密連線中可識別的是握手階段公開的目標名稱；如果協定不包含網域、握手被進一步加密，或連線直接使用 IP，嗅探就無法取得結果。

嗅探適合補足「DNS 在核心外完成，但連線仍攜帶網域資訊」的情境。例如應用程式使用自己的 DNS 取得真實位址，之後發起 TLS 連線，核心可能從握手中還原伺服器名稱。還原後仍需依規則順序判斷。若嗅探取得的網域與原目標 IP 之間具有特殊對應關係，貿然覆蓋目的位址可能造成連線異常，因此設定應從常見 HTTP 與 TLS 連接埠開始，不要一開始就覆蓋所有連接埠與協定。

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
  force-domain:
    - "+.example.com"
  skip-domain:
    - "Mijia Cloud"
    - "+.push.example"
  skip-src-address:
    - 192.168.0.0/16

parse-pure-ip 允許對只有 IP 目標的連線嘗試解析協定網域；force-dns-mapping 會結合 DNS 對應資訊；override-destination 控制是否使用嗅探結果改寫原始目標。初次啟用時可先保持目的位址不改寫，只觀察日誌中的網域還原結果。確認特定服務需要依賴嗅探網域路由後，再評估是否啟用覆蓋。欄位支援情況會隨客戶端核心而異，載入設定後應檢查日誌是否接受這些參數。

force-domain 與 skip-domain 的邊界

force-domain 適合明確需要嗅探處理的網域，skip-domain 用於已知相容性不佳或不應改寫的目標。兩者都應根據日誌與重現結果維護，不要複製來源不明的大型排除表。裝置探索、區域網路服務、推播長連線與某些使用特殊憑證驗證的應用程式可能需要跳過；但出現連線失敗時，仍要先排除 DNS、規則與代理本身，不能把所有失敗都歸因於嗅探。

來源位址排除適合區域網路裝置透過本機轉發，且不希望進行網域識別的情境。設定網段時要確認實際區域網路範圍，過寬會讓大量連線失去網域規則。連接埠範圍同樣要適度：HTTP 嗅探放在典型明文連接埠，TLS 放在常見加密連接埠，QUIC 主要處理 UDP。將所有連接埠同時交給所有協定嘗試，會增加不必要的判斷，也會讓日誌變得難以閱讀。

判斷嗅探是否真正生效

驗證時選擇一個已知網域，先在日誌中確認連線初始目標是否為 IP，再檢查嗅探後是否出現網域，以及最終命中的是網域規則還是 IP 規則。若連線一開始就有網域，成功命中不能證明嗅探發揮了作用。可以比較關閉嗅探後同一應用程式的行為，但要清除既有連線，避免重用舊工作階段。瀏覽器通常有連線池，單純重新整理頁面不一定會建立新連線。

若日誌沒有嗅探結果，確認流量是否進入 mihomo、連接埠是否在設定範圍內，以及協定是否屬於 HTTP、TLS 或 QUIC。若能還原網域卻沒有依預期分流，檢查規則順序與網域寫法。若啟用 override-destination 後連線失敗，先關閉覆蓋並保留解析，確認問題來自目的位址改寫，再將目標加入跳過清單。排除項應寫下具體網域或後綴，並註明原因，方便日後複查。

長期維護時，將嗅探例外與對應應用程式、協定及故障表現一併記錄。只保留網域而不寫原因，幾個月後很難判斷排除項是否仍有必要。客戶端或核心遷移後，先以較小範圍重新驗證，而不是原樣複製所有歷史排除項。依照「觀察資訊缺失 → 啟用有限協定 → 驗證網域還原 → 決定是否覆蓋」的順序，嗅探才能成為可控工具，而不是增加另一層不確定性。

本地覆寫與多訂閱合併

將訂閱視為輸入，不要直接當成最終設定

遠端訂閱通常負責提供代理節點、基礎策略與部分規則，但不一定了解本機區域網路、內部網域、應用程式習慣與平台權限。將訂閱內容作為輸入，再透過本地覆寫形成最終設定，更適合長期維護。訂閱更新可以替換節點清單，本地覆寫則保留 DNS、TUN、自訂規則與策略組調整。支援覆寫的客戶端可能提供 YAML 覆寫、腳本處理或合併介面，具體入口各不相同，但目標都是避免直接編輯會被更新覆蓋的主要設定。

覆寫應盡量只包含需要變更的鍵。整份複製主要設定雖然直觀，卻會阻擋上游新增欄位，也容易保留已失效的節點名稱。對映射欄位可依鍵合併；對陣列欄位則要特別小心，因為不同客戶端可能採用替換、前置、後置或腳本化處理。rules 是最典型的順序陣列：簡單替換會遺失訂閱規則，簡單追加又可能落在 MATCH 後方而永遠不生效。請使用客戶端的「規則前置」功能，或在合併腳本中明確插入最終兜底之前。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-filter:
    - "+.internal.example"

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

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

這類本地覆寫不包含訂閱代理，適合將節點更新與本機網路設定分離。儲存後要查看最終生效的設定，而不只是檢查覆寫檔案。若客戶端提供「預覽合併結果」或「開啟執行設定」，應確認 DNS 與 TUN 欄位只出現一次、縮排正確，規則插入位置符合預期。遇到同名鍵時，應明確哪一層優先，不要靠反覆嘗試猜測。

多訂閱合併的結構設計

多訂閱不等於將所有節點文字串接在一起。更穩妥的做法是為每個來源建立獨立的 proxy-providers，設定不同的快取路徑，再由策略組透過 use 引用。如此某個來源更新失敗時，不會影響另一個來源的快取，也方便查看成員來自哪裡。提供者名稱要保持穩定，策略組只引用提供者，不直接列舉會變動的節點名稱。

proxy-providers:
  provider-main:
    type: http
    url: https://subscription.example.com/main.yaml
    path: ./providers/main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.example.com/
      interval: 900

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

proxy-groups:
  - name: 節點選擇
    type: select
    use:
      - provider-main
      - provider-backup
    proxies:
      - 自動選擇
      - DIRECT

  - name: 自動選擇
    type: url-test
    use:
      - provider-main
      - provider-backup
    url: https://www.example.com/
    interval: 600
    tolerance: 80

範例 URL 只是結構示意，實際應使用自己的訂閱網址，並將訂閱網址視為敏感資訊管理。不同提供者必須使用不同的 path。如果路徑相同，後更新的內容可能覆蓋前一個快取。健康檢查與策略組測速是兩個層次：提供者健康檢查標示成員可用性，url-test 決定組內選擇。兩者週期都設定過短會產生重複測試；行動裝置尤其應放寬間隔。

多個來源可能包含同名節點。介面只顯示名稱時，很難判斷選中了哪一份。可在合併階段加入來源前綴，或按提供者拆成「主要訂閱」「備用訂閱」兩個中間組，再由總入口引用。不要依賴節點排列順序，因為訂閱更新可能重新排序。篩選規則也要按來源驗證，確保某個來源的命名變更後，不會讓地區組突然變空。

更新、失敗與回退

更新訂閱前先確認目前快取可用。更新失敗時，客戶端通常可能繼續使用舊快取，此時不應刪除快取後反覆重試；先檢查訂閱網址解析、網路路徑與回傳格式。若遠端內容能下載卻無法載入，查看它是完整 Clash 設定還是僅代理提供者格式，兩者結構不同。完整設定不能直接當作 provider 檔案使用，除非客戶端提供轉換功能。

升級本地覆寫時採用小步驟遷移：先合併基礎 profile 與 DNS，確認載入；再加入規則前置；最後啟用 TUN 與嗅探。若一次複製舊裝置的完整設定，平台專屬欄位、路徑與介面名稱可能不相容。Windows、macOS、Android 與 Linux 的權限及網路堆疊不同，同一邏輯可以保留，但具體監聽位址、TUN 權限與本機路徑應重新確認。

遷移客戶端時，先匯出訂閱網址與自訂覆寫，再記錄策略組目前的選擇。不要把客戶端內部快取目錄視為長期備份，因為目錄結構可能隨平台改變。原版客戶端停止維護後的遷移思路，可參考 FlClash 與 Clash Verge Rev 遷移方案比較。新安裝優先從客戶端下載頁選擇 Clash Plus，依系統與處理器架構安裝，再逐層匯入上述設定。

外部控制面板與安全邊界

控制介面能做什麼

mihomo 的外部控制介面用於讀取執行狀態、切換策略組、更新提供者、查看連線與日誌。圖形客戶端本身也可能透過此介面與核心通訊。獨立控制面板只是介面的前端展示，不會取代核心，也不會改變設定檔的權限邊界。介面是否可存取，取決於 external-controller 的監聽位址、系統防火牆與驗證密鑰。

只在本機使用時，應監聽回環位址，例如 127.0.0.1:9090。如此其他區域網路裝置便無法直接連線。需要從另一台裝置管理時，才考慮監聽區域網路位址，並同時設定強驗證、限制防火牆來源，確認目前網路可信。將介面監聽於所有網卡會擴大存取範圍，不能只依賴控制面板頁面「看起來需要輸入密鑰」來判斷安全；真正的保護必須發生在 API 連線層。

external-controller: 127.0.0.1:9090
secret: "your-control-secret"
external-ui: ./ui

log-level: info
allow-lan: false

secret 範例必須替換為本機獨立值，不要與訂閱網址或其他帳號憑證共用。若客戶端已自動產生控制介面設定，應優先在客戶端設定中修改，避免手動覆寫與介面設定互相覆蓋。external-ui 指向本地靜態面板目錄；部分客戶端會自動下載並管理面板資源，另一些只提供 API，需要自行準備相容前端。路徑應位於客戶端可讀取的設定目錄內。

連線面板的檢查順序

面板無法開啟時，先區分靜態頁面與 API。瀏覽器無法開啟面板檔案，請檢查 external-ui 路徑與客戶端資源管理；頁面可以開啟但顯示無法連線，請檢查控制位址、連接埠、密鑰與瀏覽器存取來源。若控制介面監聽在回環位址，從另一台裝置輸入本機區域網路 IP 仍無法連線，這是預期的邊界。若改為區域網路監聽，應確認作業系統防火牆允許指定來源，而不是開放給整個網路。

控制面板網址使用 HTTP 或 HTTPS，取決於部署方式。回環位址上的本機使用與區域網路遠端管理具有不同風險。需要跨裝置管理時，較穩妥的方式是透過受控的本地網路或既有安全通道存取，不要將控制連接埠直接映射到公網。介面能切換策略、讀取連線目標並修改執行狀態，因此應按管理介面看待，而不是一般狀態頁面。

curl -H "Authorization: Bearer your-control-secret" \
  http://127.0.0.1:9090/version

curl -H "Authorization: Bearer your-control-secret" \
  http://127.0.0.1:9090/proxies

命令用於驗證本機 API 是否回應。第一條可確認介面與驗證是否運作，第二條讀取策略與代理結構。若回傳未授權，檢查密鑰是否一致；若連線遭拒，檢查核心是否執行、連接埠是否監聽；若能連線但路徑無回應，確認目前核心介面的相容性。除錯完成後，不要將含有驗證資訊的命令儲存於共用腳本或公開日誌。

正確使用連線資訊與日誌

控制面板中的連線清單適合回答三個問題：流量是否進入核心、目標資訊是網域還是 IP，以及最終採用哪條規則與策略。看到大量連線不代表異常，現代網頁會並行請求多個資源。排錯時按目標應用程式或網域篩選，關閉舊連線後重新發起一次請求，比盯著不斷捲動的完整清單更有效。

切換策略組後，既有 TCP 連線通常不會自動遷移到新代理。若測試結果沒有變化，應關閉對應連線或重新啟動目標應用程式，再觀察新連線使用的策略。更新規則提供者後也要確認新連線已命中，不能只看更新按鈕顯示完成。面板顯示的是執行狀態，設定檔則決定下次載入的狀態；臨時切換是否在重新啟動後保留，取決於 profile.store-selected 與客戶端持久化機制。

當控制面板與客戶端介面顯示不同狀態時，先確認兩者是否連線至同一個核心實例與連接埠。裝置上可能同時執行舊客戶端服務、命令列核心與新客戶端，面板連到另一個實例會產生「策略切換沒有生效」的錯覺。查看程序、監聽連接埠與設定目錄，關閉不需要的實例，再重新連線。完成後將控制位址、面板路徑與設定檔位置記錄在裝置說明中，日後遷移會更直接。

設定驗證、排錯與長期維護

依固定順序驗證完整鏈路

複雜設定完成後，不要直接用多個應用程式同時測試。先確認核心載入設定且沒有 YAML 或欄位錯誤；再確認系統代理或 TUN 接管成功；接著驗證 DNS 查詢、網域嗅探、規則命中、策略組選擇與代理連線。每一層只回答一個問題。若第一層已經失敗，後續網頁錯誤便沒有分析價值。固定順序能避免在策略組中切換節點，實際問題卻是 TUN 路由尚未建立。

建議準備一張本地測試表，包含目標、預期規則、預期策略與驗證結果。目標至少涵蓋區域網路直連、一般直連、需要代理的網域、只提供 IP 的連線、UDP 應用程式與最終兜底。測試時在控制面板或日誌中記錄實際命中項目。更新訂閱、規則集、DNS 或客戶端後，重複同一組測試，結果便具有可比性，也能快速發現是內容更新還是客戶端環境造成變化。

# 檢查本地混合代理連接埠是否正在監聽
curl -x http://127.0.0.1:7890 https://www.example.com/

# 檢查外部控制介面
curl -H "Authorization: Bearer your-control-secret" \
  http://127.0.0.1:9090/version

命令只驗證連接埠與請求路徑，不代表所有規則都正確。第一條成功表示應用程式能透過本地代理發起請求；若瀏覽器仍無法運作，應檢查瀏覽器代理來源與既有連線。命令失敗時，依錯誤區分連線遭拒、DNS 失敗、驗證失敗或請求逾時。不要把所有錯誤都歸納為「節點不可用」，因為本地連接埠未監聽與遠端代理故障的處理方式完全不同。

按現象建立排錯分支

「所有目標都失敗」優先檢查核心、連接埠、權限、DNS 基礎路徑與目前策略成員；「只有一個網域失敗」優先查看網域解析、規則命中與該服務的出口要求；「只有某個應用程式失敗」檢查它是否進入系統代理、是否使用獨立 DNS、是否只走 UDP；「切換網路後失敗」檢查出口介面、路由與區域網路 DNS；「訂閱更新後失敗」檢查提供者格式、策略組成員與規則順序。

日誌中的第一個錯誤通常比後續連鎖錯誤更有價值。DNS 初始化失敗可能繼續造成節點網域解析失敗、提供者更新失敗與所有代理逾時。如果只看最後一條，會誤以為多個訂閱同時失效。暫時啟用 debug 後，從核心啟動階段開始閱讀，找出第一個與本次修改相關的錯誤。修復後重新啟動並確認它消失，再繼續處理下一項。

升級與遷移時控制變數

不要同時進行客戶端升級、核心替換與設定遷移。先在現有客戶端中匯出可用設定與本地覆寫；安裝新客戶端後，只匯入訂閱並完成基礎連線；再加入策略組、規則提供者與 DNS；最後啟用 TUN、嗅探與外部控制面板。如此某一步出現問題時，便能明確判斷是欄位支援、平台權限還是設定內容。跨平台遷移還要重新確認路徑分隔符號、服務權限、網路延伸功能與防火牆。

不要依賴某個介面名稱永久不變。長期維護記錄應以設定欄位與行為為主，例如「啟用 profile.store-selected 儲存組選擇」，而不是只寫「開啟第三頁第二個開關」。介面升級後按鈕位置可能改變，但欄位含義更穩定。對於必須透過介面完成的系統授權，可以補充平台路徑與驗證現象。

遇到問題時先保留日誌、目前設定與重現步驟，再進行回退。只保留一張錯誤截圖，通常不足以判斷連線經過了哪些層級。重現步驟應包含客戶端、接管方式、目標應用程式、預期策略、實際命中項目與網路環境。若基礎概念仍不清楚，可前往 FAQ，依「基礎認知、安裝設定、使用技巧、故障排查」查找；若需要重新進行訂閱匯入與模式選擇，則返回 使用指南。

一份長期穩定的 Clash 設定通常不複雜：訂閱負責提供代理，策略組表達出口選擇，規則集負責可重複使用的匹配，DNS 保留網域資訊，TUN 只在需要時接管更多流量，嗅探用於補足缺失的網域，外部控制介面則限制在明確邊界內。每次只修改一個層級並使用固定測試集驗證，就能在增加功能的同時維持設定可讀、可回退、可遷移。