Clash 設定進階指南：策略組、DNS 與 TUN 設定參考

策略選擇 / proxy-groups

策略組類型與實際出口

策略組決定流量符合規則後交由哪個出口處理。規則中的 Proxy 只是一個名稱，不代表核心內建了代理出口；它必須對應節點或策略組。一個連線可能先符合業務規則，再進入手動選擇組，最後連到自動測試組中的某個節點。理解這條引用鏈，比一次建立許多分組更重要。修改前，先列出訂閱提供的節點名稱、現有組名與規則引用，避免名稱重複或引用無效導致設定載入失敗。

手動選擇、自動測速與故障切換

select 提供手動選擇入口，適合需要明確掌控出口的情況。url-test 依指定測試網址的探測結果選擇候選項目，適合日常自動選擇；測量結果只反映特定網路路徑，不代表所有網站的連線速度。fallback 依設定順序使用可用候選項目，重點是保留優先順序並在故障時切換，而非挑選延遲最低的項目。三者可以巢狀搭配，但層級應保持簡單，且不可讓兩個組互相引用。

load-balance 會將不同連線分配給候選節點，無法累加單一下載連線的頻寬。涉及帳號工作階段、出口地區或伺服器風控的服務，通常較適合使用固定出口。負載平衡的分配方式也受 strategy 影響，例如 consistent-hashing 會盡量讓相同目標維持相近的出口對應，但候選項目變動仍可能改變結果。不要將此視為身分或公網 IP 長期不變的保證。

config.yaml · 引用現有 provider 的策略組片段

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - 自動選擇
      - 故障切換
      - DIRECT

  - name: 自動選擇
    type: url-test
    use:
      - 訂閱來源
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 故障切換
    type: fallback
    use:
      - 訂閱來源
    url: https://www.gstatic.com/generate_204
    interval: 300

節點來源、探測與選擇狀態

上例需要已有名為「訂閱來源」的 proxy-providers。use 會引入提供器中的節點；proxies 則引用指定的節點名稱、策略組名稱或內建策略。訂閱新增或移除節點時，使用提供器可減少逐項維護的工作，但仍須確認提供器檔案已成功載入。若用戶端匯入的是包含完整分組的訂閱，不要直接再貼上同名的 proxy-groups 頂層欄位；應透過覆寫或編輯有效設定來合併清單。

interval 是探測間隔，單位為秒；tolerance 是自動選擇時容許的延遲差距，單位為毫秒，可減少因小幅波動而頻繁切換。測試網址應穩定且可連線，並盡量符合實際使用的網路路徑。某節點測試成功，只表示該次探測請求完成，無法證明特定網站、UDP 或所有地區的服務都可用。排查時，應分開觀察測試連線與實際連線。

提供器的健康檢查與策略組測試位於不同設定位置。前者維護節點可用性資訊，後者負責組內選擇邏輯；為了方便定位問題，初次調整時不要同時變更測試網址、間隔、篩選條件與組別類型。先保留一個明確可用的候選出口，再確認自動組能否引用它。若候選清單為空，應先檢查提供器與篩選條件，而不是反覆切換全域模式。

類型	主要用途	注意事項
`select`	手動固定策略	選取 DIRECT 即會直連
`url-test`	依探測結果自動選擇	測試網址會影響判斷
`fallback`	依序故障切換	優先順序由候選項目排列決定
`load-balance`	分散不同連線	不會累加單一連線的頻寬

確認規則與策略組之間的關聯

修改後先查看連線詳細資料中的比對規則與策略鏈。如果規則命中業務組，但最後走 DIRECT，通常應檢查組內選項，而不是修改網域規則。若節點確實已切換，但頁面表現沒有變化，先關閉現有長連線再試一次；既有 TCP 工作階段不會因手動選擇策略組就自動改走另一個出口。瀏覽器連線池、應用程式背景連線與快取都可能造成觀察延遲，驗證時請使用新連線。

實際設定建議保留一個總入口組，再依確實不同的業務拆分少量子組。只有當某類業務需要固定地區、不同傳輸能力或獨立故障策略時，分組才有明確價值。想了解節點選擇、測試結果與地區判斷的差異，可繼續閱讀如何挑選代理節點；若介面操作結果與核心不一致，可先在常見問題確認代理模式與系統代理的差異。

規則管理 / rule-providers

以規則集訂閱管理規則與比對順序

規則清單決定「這個連線應交由哪個策略處理」。在 Rule 模式下，核心通常會依 rules 由上而下檢查，第一條符合的規則就會決定後續策略，不會繼續尋找更精確的其他規則。因此，順序本身就是設定語義：個人例外應排在涵蓋範圍較大的規則之前，最後的兜底規則則放在末尾。把項目排列整齊，不代表邏輯就正確；真正需要維護的是例外、業務分類與兜底規則之間的優先順序。

將維護來源與本機策略分開

rule-providers 用來定義可重複使用的規則集，RULE-SET 則在主要清單中引用它。規則集描述比對對象，實際採用哪個策略仍由引用項目決定。如此一來，同一組網域清單可在不同裝置使用不同出口，不必修改上游規則檔。對於檔案較大且需定期更新的清單，這種做法也比將所有內容複製到訂閱中更容易檢視與還原。

先用本機檔案完成整個流程，再改用遠端來源，會比較容易排查問題。以下是可實際使用的本機規則集：主設定檔與規則檔都以 mihomo 工作目錄為基準放置。實際工作目錄取決於啟動方式與用戶端管理方式，不一定是下載資料夾。若路徑錯誤，即使檔案內容完全正確，核心也無法載入對應規則集。

config.yaml · 本機 classical 規則集

mode: rule
rule-providers:
  development:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/development.yaml

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - RULE-SET,development,Proxy
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

rules/development.yaml

payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com

behavior 與 format 必須符合內容

behavior: classical 可接受附有規則類型的項目，例如範例中的 DOMAIN-SUFFIX；項目中不必再填入 Proxy，因為策略已寫在 RULE-SET 引用項目中。domain 用於網域清單，ipcidr 用於 IP 位址區段清單，內容語法不可與 classical 混用。format 用來描述載荷格式，例如 YAML 或純文字；副檔名本身不能取代正確的格式宣告。

改用 HTTP 來源時，將 type 改為 http，加入可實際連線的 url 與以秒為單位的 interval，並設定獨立的快取 path。每個提供器都應使用不同的檔案路徑，避免內容互相覆蓋。下載到的網頁錯誤訊息、存取驗證頁或登入頁都不是規則檔；瀏覽器能開啟網址，不代表核心收到的回應就是預期的載荷。

首次部署遠端規則時，應確認冷啟動也能取得檔案。若取得規則所需的網域恰好要靠這份規則才能連線，就會形成啟動依賴。較穩妥的做法是先確保下載路徑可用，並保留已驗證的本機快取。規則提供器下載失敗與代理節點無法使用是兩種不同問題，應分別查看更新記錄與連線記錄，不宜只憑網站無法開啟就判斷是哪一層出錯。

以少量請求驗證分流

驗證新規則時，先選一個確定屬於目標集合的網域，建立新連線，並在連線詳細資料中查看命中規則、規則載荷與策略鏈。若命中較前面的 DIRECT 項目，應調整優先順序；若看不到預期的規則集，請檢查提供器名稱、載入狀態與檔案內容。IP 類規則也仰賴解析結果或目標位址資訊，不能假設它們總能取代網域比對。

對於區域網路裝置、印表機與本機服務，應優先維護明確的直連範圍，並確認不會被涵蓋範圍較大的代理規則提前攔截。新增 REJECT 規則前，應評估目標網域是否由多項服務共用；誤擋內容傳遞網域可能造成登入、圖片或更新異常。排查期間可暫時將可疑規則改成便於觀察的策略並記錄結果，避免直接刪除整組規則而失去問題線索。

規則集更新屬於外部輸入變更，應與訂閱節點更新分開管理。更新後若只有某一類網站異常，可先還原該規則檔或暫停對應的 RULE-SET，而不是同時重設 DNS 與 TUN。個人例外盡量保存在本機覆寫層，並在註解中說明原因與適用對象；上游清單更新時，才能保留這些設定。核心與舊版規則功能的差異，請參閱mihomo 與原版 Clash 核心比較。

解析路徑 / dns

DNS 設定最佳化與解析路徑

設定 DNS 前，先釐清三件事：由誰發起查詢、查詢經由哪個出口送到解析器，以及查詢結果用於哪個連線。系統 DNS、瀏覽器安全 DNS、應用程式內建解析與 mihomo DNS 可能同時存在。只修改 nameserver，無法保證所有應用程式的查詢都會進入核心；也不能只憑網頁能開啟，就認定解析結果符合預期。先整理實際查詢路徑，再調整欄位，會比同時填入多個解析器更有效。

分清啟動解析與一般解析

default-nameserver 用於解析 DNS 伺服器本身的網域，解決加密解析器啟動時「必須先知道位址才能發出請求」的問題。nameserver 是一般網域查詢使用的上游伺服器。proxy-server-nameserver 用於解析代理節點網域，有助於將建立代理連線所需的基礎解析，與業務網域解析分開。這三個欄位負責不同階段，並非簡單的第一、第二、第三順位備援。

以下先展示不需代理出站的基本片段，可用來確認監聽位址、上游解析器與網域策略是否生效，但不代表所有網路環境都能確保隱私或連線可用。解析器位址應依實際網路與維護需求選擇；某個公共解析器在一種網路環境中可用，不代表在所有網路中都能使用。

config.yaml · 基礎 DNS 片段

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    '+.example.com':
      - https://dns.alidns.com/dns-query

依網域選擇上游，依規則選擇出口

nameserver-policy 會依網域比對來選擇上游解析器，範例中的 +.example.com 涵蓋該網域及其子網域。它解決的是「向誰查詢」，不直接決定「網站連線經由哪個出口」。連線策略仍由代理模式、規則與策略組決定。企業內部網域通常需要組織內部 DNS，公共解析器可能完全沒有對應記錄；對這類網域，應先確認目前網路能否連上內部解析器。

若要讓 DNS 上游連線遵循路由規則，可評估使用 respect-rules。啟用前必須先安排好代理節點網域的解析，避免形成「解析節點要先走代理，建立代理又得先解析節點」的循環。不要只複製一組「防止 DNS 洩漏」開關就認為設定已完成；應分別驗證節點解析、上游連線與一般網域查詢，尤其要留意首次啟動且快取為空時的狀況。

fallback 與 fallback-filter 各有自己的回應篩選邏輯，不應視為簡單的「第一台失敗才查第二台」。上游解析器也不是越多越可靠：它們可能回傳不同位址，造成內容傳遞節點定位差異與不一致的故障狀況。若沒有明確的篩選需求，先使用少量且容易理解的上游，記錄查詢路徑後再增加複雜度。

監聽、快取與 IPv6 範圍

範例在回送位址的 1053 連接埠監聽，系統不會只因該連接埠存在就自動使用它。系統 DNS 設定通常無法直接指定自訂連接埠，因此需要 TUN 的 DNS 接管、系統解析服務轉送，或支援指定連接埠的測試工具。使用 dig 可直接驗證監聽端點，但命令結果只代表這次明確送給核心的查詢，不代表所有應用程式都已接入。

dig @127.0.0.1 -p 1053 example.com A
dig @127.0.0.1 -p 1053 example.com AAAA

dns.ipv6 控制核心 DNS 如何處理 AAAA 查詢；頂層 ipv6 則關係到核心的 IPv6 支援，兩者位於不同層級。關閉其中一個欄位，不代表作業系統或瀏覽器完全停止使用 IPv6。若只有部分應用程式繞過預期路徑，應檢查系統 IPv6 路由、應用程式安全 DNS、代理接入方式與既有連線，而不是只在 DNS 設定中反覆切換同一個值。

調整解析策略後，舊快取可能讓測試結果仍停留在修改前的狀態。應分別考慮核心、系統與瀏覽器快取，必要時關閉原有連線並重新查詢。看到 Fake-IP 位址時，不能據此判斷真實伺服器所在的地區；它只是核心配置的對應位址。排查解析污染、接管範圍與加密 DNS 路徑時，可參閱DNS 洩漏檢測與修復，依序進行檢測、修改與複測，逐層確認。

網路接管 / tun

TUN 模式與 Fake-IP 的搭配

TUN 透過虛擬網路介面接收由系統路由轉送的 IP 流量，適合不遵循系統 HTTP 代理設定的應用程式。Fake-IP 則是 DNS 的一種運作模式，會為網域回傳用於對應的位址。兩者經常一起設定，但解決的問題不同：TUN 決定流量如何進入核心，Fake-IP 則協助核心保留網域與連線之間的關聯。啟用 TUN 不代表所有 DNS 路徑都會自動修復；使用 Fake-IP 也不代表所有情境都必須啟用 TUN。

先確認權限與系統路由

桌面用戶端可能透過服務模式或提高權限的操作建立虛擬介面與路由。行動裝置通常透過系統 VPN 介面接入，介面也可能稱為 VPN 模式，不能直接照搬桌面平台的網路介面設定。Linux 的執行權限、路由管理與解析服務同樣取決於部署方式。初次啟用時，先確認用戶端顯示接管成功，再檢查路由與 DNS；不要只因開關顯示為已啟用，就認定網路堆疊已正常運作。

以下片段用於說明自動路由與 DNS 劫持之間的關係，使用前需合併上一章的 DNS 設定。stack 可依系統與核心的支援狀況選擇，mixed 不保證在所有裝置上都比較快。若已有其他 VPN、容器網路或企業隧道，自動路由可能互相衝突；建議先在可復原的本機環境逐項測試。

config.yaml · TUN 與 DNS 搭配片段

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  fake-ip-filter:
    - '*.lan'
    - '*.local'

DNS 劫持不是所有解析協定的總開關

dns-hijack 中的 any:53 針對進入接管路徑的一般 DNS 流量。應用程式透過 HTTPS 或其他加密協定連線至解析服務時，不會只因內容是 DNS 就自動變成 53 連接埠的查詢。瀏覽器安全 DNS 與應用程式內建解析仍須個別辨識。若要統一解析路徑，應優先讓應用程式使用系統解析，再確認系統查詢確實進入核心。

auto-detect-interface 可協助選擇實際出站網卡，但多張網卡、熱點分享、網路切換與既有隧道都可能使自動判斷不符合需求。常見症狀是啟用 TUN 後所有連線都逾時，關閉後立刻恢復。此時先確認實際預設出口與路由是否形成迴圈，再檢查核心連線記錄；持續更換節點通常無法修正出口選錯的問題。遠端維護伺服器時，尤其要保留獨立的復原途徑。

部分系統支援透過 strict-route 加強路由限制，但也可能影響區域網路存取，或與其他網路元件衝突。尚未找出問題原因前，不適合盲目啟用此欄位。應先建立最小可用設定，記錄直連、代理與本機網路的行為，再依明確需求增加限制。不同平台的防火牆與路由實作各有差異，相同片段不代表效果一致。

Fake-IP 例外與本機服務

部分裝置探索、區域網路服務或需要真實位址的應用程式不適合使用 Fake-IP 對應，可透過 fake-ip-filter 設定例外。範例使用通常需要本機解析的網域後綴，但實際例外應依應用程式需求決定。加入例外代表該網域會依相應模式回傳真實解析結果，不代表其業務流量必定直連；後續規則仍可能將連至真實位址的流量送往代理。

切換 Fake-IP 模式或對應範圍後，應用程式可能仍保留舊位址。舊對應與核心的新執行狀態不一致時，可能出現 DNS 查詢看似成功、連線卻失敗的情況。先關閉相關應用程式的連線，清除對應層級的 DNS 快取後再重新請求。不要將整個保留位址範圍當成遠端服務位址加入一般代理規則；這些位址用於本機對應，實際目標由核心依關聯資訊還原。

建議固定排錯順序：先檢查虛擬介面與權限，再確認一般 DNS 是否已接管，接著查看連線是否進入核心，最後驗證規則與策略組。若只有 UDP 應用程式異常，還應確認節點協定、伺服器與網路路徑是否支援所需的 UDP，而不是只切換 TUN 堆疊。若目標是讓區域網路裝置共用代理，通常還須另外了解監聽位址、防火牆與接入範圍，請參閱mixed-port 與 allow-lan 設定；啟用 TUN 本身不會自動替其他裝置設定代理。

網域關聯 / sniffer

網域嗅探的用途與限制

網域嗅探用於連線只呈現目標 IP、缺少可靠網域關聯時，嘗試從部分協定的交握或請求資訊取得網域，協助規則判斷。它與 DNS 不同：DNS 負責名稱解析，嗅探則觀察已進入核心的連線。它也不是解密代理，不會因為啟用就能讀取所有 HTTPS 內容。先確認流量已進入核心，才能判斷嗅探是否有效；未接管的連線不在處理範圍內。

先指定明確的協定與連接埠範圍

mihomo 可設定 HTTP、TLS 與 QUIC 等嗅探對象。HTTP 可能提供 Host 資訊，TLS 通常可從交握中的伺服器名稱取得線索，QUIC 也有相應的處理方式。不過，協定演進、加密交握方式、用戶端實作與流量型態都會影響結果，無法保證每個連線都能取得可見網域。對於直接使用 IP 或採用不支援協定的應用程式，最終仍可能只能使用 IP 類規則與兜底策略。

初次使用時建議只限定在確有需要的連接埠，先觀察規則命中是否改善，再決定是否擴大範圍。連接埠只是篩選條件，不能證明流量一定使用相應協定；將所有連接埠都納入，不會自動讓結果更容易理解。以下範例先啟用網域擷取，不覆寫實際連線目標，適合將「辨識到什麼」與「是否改寫目標」分開測試。

config.yaml · 保守的嗅探設定起點

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
    QUIC:
      ports:
        - 443
  skip-domain:
    - '+.example.com'

區分網域辨識與連線目標覆寫

parse-pure-ip 可對沒有網域資訊的純 IP 連線嘗試嗅探；force-dns-mapping 與 DNS 對應情境有關，用於擴大相關連線的處理範圍。這兩者都不保證一定成功，也不表示可以忽略 DNS 設定。override-destination 決定是否以嗅探結果覆寫連線目標，影響比單純辨識更大；應先了解目標服務特性，再評估是否啟用。

例如，應用程式可能先透過自身的調度機制選定某個服務 IP，再於 TLS 交握中帶上網域。如果覆寫目標後改為依網域重新建立連線，實際選擇的位址可能改變，影響原有調度或連線能力。因此，遇到「啟用嗅探後部分網站異常」時，應先分辨是網域規則變動，還是連線目標遭到覆寫。保留連線記錄，針對同一請求分別關閉目標覆寫與嗅探，比同時重設所有設定更有助於診斷。

skip-domain 可讓指定網域略過嗅探處理。上例中的 example.com 只是語法示範，不是通用的必要例外；實際部署時只保留確有需求的目標。例外範圍太大，可能使原本仰賴嗅探的網域分流失去依據；範圍太小，則可能漏掉相關子網域。新增例外後，請重新建立連線，並確認實際辨識到的名稱符合預期。

將嗅探納入可驗證的分流流程

驗證時選擇一個可重複測試的目標，先記錄未啟用嗅探時的目標位址、規則與策略，再啟用嗅探並建立新連線。若規則由 IP 類變為 DOMAIN-SUFFIX，代表網域資訊參與了比對；若完全沒有變化，不應立即認定功能失效，連線可能原本就有 DNS 對應，或嗅探未取得可用名稱。若頁面載入涉及多個網域，請查看實際失敗的連線，而不只是首頁主網域。

嗅探取得的名稱不一定與使用者網址列中的名稱完全相同；重新導向、內容傳遞、資源網域與後端服務都可能使用不同名稱。若業務需要穩定的地區或固定出口，應維護實際連線網域清單，而非依賴單一主網域推斷所有資源。規則命中後仍由策略組選擇節點；嗅探無法修復節點無法連線、帳號失效或伺服器端限制。

正式環境應保留最小必要範圍，避免把嗅探當成設定錯誤的補丁。先確保系統解析、Fake-IP 對應與 TUN 接管各自正常，再用嗅探補足缺少網域資訊的連線。若問題只出現在某類應用程式，可為其設定明確例外並加上註解；確認原因後再決定長期做法。相關基本概念可參閱術語表；若只是初次匯入後無法上網，請先依快速入門教學確認代理接入與節點，而不是直接擴大嗅探範圍。

設定生命週期 / merge

本機覆寫與多訂閱合併

訂閱檔案是外部輸入，本機覆寫是使用者自行管理的設定層，而實際執行設定則是用戶端處理兩者後的結果。三者不可混為一談。直接編輯下載的訂閱檔案，下次更新時可能會被覆蓋；只修改覆寫範本，卻未套用到目前設定，也不會改變核心行為。開始修改前，應在用戶端確認目前啟用的設定、覆寫適用範圍與最終產生的檔案，避免一直修改錯誤的對象。

先釐清各設定層的管理權責

不同用戶端的覆寫介面與合併機制各不相同，並不存在適用所有圖形用戶端的通用 override YAML 頂層欄位。請使用目前用戶端明確提供的覆寫、合併或腳本入口，並確認它如何處理映射、清單與空值。下載頁提供 Clash Plus、Clash Verge Rev、FlClash 等平台選項，但不能因此假設它們的設定編輯介面完全相同。

較穩妥的分工方式是：訂閱負責節點資訊，本機層負責策略組、規則、DNS 與控制介面。若訂閱本身已包含完整分流設定，應先決定要沿用上游結構，還是只擷取節點後由本機管理。兩套結構同時生效，容易造成同名組、重複 MATCH 與設定互相覆蓋。長期維護的關鍵不是把檔案拼得更大，而是明確決定各類欄位由哪個來源管理。

使用 provider 區分多個節點來源

以下片段以兩個本機節點提供器示範結構，不包含遠端訂閱網址。每個提供器檔案都必須有合法的 proxies 清單與實際可用的節點；主設定檔透過 use 引入。先使用用戶端匯出的有效提供器檔案完成驗證，再改用 HTTP 來源，就能將來源下載問題與節點設定問題分開排查。

config.yaml · 雙來源組合片段

proxy-providers:
  source-a:
    type: file
    path: ./providers/source-a.yaml
  source-b:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: Proxy
    type: select
    proxies:
      - 來源甲
      - 來源乙
      - DIRECT
  - name: 來源甲
    type: select
    use:
      - source-a
  - name: 來源乙
    type: select
    use:
      - source-b

rules:
  - GEOIP,CN,DIRECT
  - MATCH,Proxy

完整訂閱與節點提供器檔案的結構不同。包含 rules、proxy-groups 及其他頂層欄位的完整設定，不會只因下載網址可用就成為合格的節點提供器載荷。若用戶端提供訂閱轉換或擷取功能，請確認轉換後的輸出格式。處理私人訂閱連結時，優先使用可控的本機流程，不要將存取憑證交給來源不明的轉換服務。

映射、清單與名稱衝突的處理

YAML 映射可依鍵值合併，但清單沒有通用且固定的合併方式。用戶端可能會取代、前置或附加整個 rules 清單，必須檢視實際產生的結果。若本機例外附加在上游 MATCH 之後，即使寫在檔案中也不會生效；若整份 proxy-groups 被取代，上游規則引用的舊組名又可能失效。設定檢查通過只代表結構與引用基本上可接受，不代表分流意圖正確。

不要在同一個 YAML 映射中重複填寫 dns 或 rules，並期待解析器自動合併。重複鍵可能遭到拒絕，也可能由後者覆蓋，結果取決於解析器的實作。請在同一個明確的鍵下整理完整內容，並保留正確的縮排層級。YAML 縮排不適合使用定位字元；冒號後的空格、清單項目前的短橫線與字串引號也必須正確。複雜的網域模式及含特殊字元的值，建議明確加上引號。

多個來源的節點可能使用相同名稱。若直接合併成平面清單，容易造成引用不明或被用戶端重新命名。分開來源組有助於辨認，但仍須檢查有效設定中的節點識別碼與顯示名稱。不要把「介面上看得到兩個來源」當成已完全隔離；健康檢查、快取檔案與持久化的選取狀態也需要分別驗證。

套用、檢查與還原

修改前先保存一份可正常運作的設定，並另外記錄本機覆寫。若環境中有 mihomo 命令列工具，可使用以下語法檢查；命令需要實際存在的設定檔與可解析的引用資源。若圖形用戶端代管核心，請優先使用用戶端提供的檢查與套用功能，不要在相同連接埠再啟動第二個核心。

mihomo -t -f ./config.yaml

依 DNS、策略組、規則、TUN 的順序，每次只調整一類內容；套用後確認有效設定與新連線。失敗時還原最近一層修改，不必刪除所有訂閱或重新安裝用戶端。更新訂閱後，再確認個人例外是否保留、來源是否已更新，以及規則兜底是否仍位於末尾。分享設定時，也應移除訂閱網址、節點憑證與控制密碼；排錯通常只需要欄位結構與去識別化記錄，不必提供完整私人設定。

執行狀態 / external-controller

外部控制面板與執行狀態驗證

外部控制面板透過 mihomo 的控制 API 查看狀態、切換策略或執行相關管理操作。它不是新的代理協定，也不是業務流量的入口。external-controller 定義管理介面，mixed-port 則定義 HTTP 與 SOCKS 混合代理的監聽連接埠，兩者用途不同。將瀏覽器代理指向控制連接埠不會建立正確的代理連線；將控制面板指向混合連接埠也無法取得執行狀態。

從本機回送位址開始

本機使用時，建議優先監聽 127.0.0.1，避免管理功能暴露給區域網路或公網。以下密碼是明確標示的教學用假值，實際部署時必須透過受控的本機設定另行設定。external-ui 指向已備妥的本機靜態面板目錄；只有路徑存在且內容完整，核心才能提供相應頁面。即使沒有面板檔案，API 仍可用於檢查；不要因頁面無法顯示就誤判控制介面未啟動。

config.yaml · 本機管理介面片段

mixed-port: 7890
allow-lan: false
external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./dashboard

本機面板通常可透過 http://127.0.0.1:9090/ui/ 開啟，並在連線設定中填入控制端點與密碼。各面板的欄位名稱可能不同，請以實際提供的設定項目為準。圖形用戶端也可能自行管理控制介面並覆寫檔案中的設定；若手動編輯後連接埠仍未改變，先檢查有效設定與啟動記錄，不要同時啟動另一個核心搶占連接埠。

透過 API 區分連線、驗證與介面問題

以下請求僅示範如何查詢策略資訊，驗證值與上方的教學用假值相同。實際排錯時，不要將真實密碼寫進公開截圖、共用命令或客服案件。請在執行核心的裝置上發出請求；另一台電腦的 127.0.0.1 指向該電腦本身，不會自動連到代理伺服器。

curl --noproxy '*' \
  -H 'Authorization: Bearer your-password' \
  http://127.0.0.1:9090/proxies

若連線遭拒，通常應檢查監聽位址、連接埠占用情形與核心是否正在執行；若收到驗證失敗回應，應確認密碼與請求標頭；若 API 回應正常但頁面無法顯示，再檢查面板檔案、瀏覽器主控台與前端連線設定。依此順序排查，可區分網路層、驗證層與介面層，不必一開始就修改代理規則。若瀏覽器顯示跨來源限制，也應確認面板與 API 的來源關係，而非直接允許所有網站存取控制連接埠。

遠端管理需要另外規劃身分驗證、傳輸加密與存取範圍。最小化風險的做法通常是保留本機監聽，再透過受控的安全通道存取，而不是將監聽位址改為所有介面並開放公網連接埠。若確實需要透過反向代理，應一併評估 WebSocket、跨來源政策與伺服器端存取控制。控制 API 可以改變執行狀態，風險不應視同一般唯讀網頁。

面板狀態不等於持久化設定

在面板中切換策略組主要會影響執行狀態，重新啟動後是否保留，還取決於核心的持久化設定與用戶端管理方式。透過 API 暫時修改的欄位，也可能在重新套用訂閱或覆寫後還原。因此，長期使用的規則與網路設定應寫入受管理的本機設定層；面板適合觀察與驗證，不應成為唯一的設定紀錄。修改後應主動重新載入並檢查，確認預期行為可以重現。

檢視連線時，將目標網域、目標位址、命中規則、策略鏈與錯誤記錄一併比對。若沒有相關連線進入核心，先排查系統代理、TUN 或應用程式本身的接入方式；若連線已進入核心卻命中錯誤規則，回頭檢查規則順序；若規則正確但出口不符，檢查策略組選項；若出口正確仍然失敗，再檢查節點能力、DNS 結果與目標服務。依此排查可避免在各項欄位間反覆試錯。

觀察結果	優先檢查項目	下一步驗證
沒有目標連線	流量接入與系統路由	確認應用程式實際使用的網路路徑
命中的規則不符	順序、規則集與網域資訊	重新建立連線並查看規則詳細資料
策略鏈最後走直連	組內選擇與巢狀引用	固定使用已驗證的候選出口
控制 API 可用，但頁面異常	面板檔案與連線設定	檢查頁面請求與驗證回應

完成一輪可重複的設定驗證

最後建立一組固定測試：一個應直連的目標、一個應走代理的目標、一項區域網路服務，以及實際需要使用 UDP 的應用程式。每次修改後，只比較這組測試的新連線，並記錄有效設定與日誌。確認重新啟動、更新訂閱與切換網路後仍能得到相同結果，才能認定調整完成。一般連線問題可前往常見問題與故障排除；需要重新確認匯入流程時，請回到快速入門教學。保留能清楚說明的設定，比留下更多尚未驗證的開關更有利於維護。