Clash 進階設定指南

策略組類型與出口配置

策略組介於規則與節點之間：規則判斷連線屬於哪類流量，策略組則決定這類流量最後使用哪個出口。若在大量規則中直接填入節點名稱，節點改名或訂閱更新就可能牽動整份設定。先建立穩定的用途策略組，再於組內調整節點，便能將日常切換與規則維護分開，也更容易從連線記錄追查決策過程。

手動選擇與自動選擇的分工

select 適合需要人工確認出口的情境，例如工作服務、特定地區內容或臨時排錯。組內成員可以是節點，也可以是其他策略組。外層保留手動選擇組，內層放置自動測速組，是較容易理解的配置方式。使用者只需決定採用自動選擇或直連，不必為每條網域規則重新指定節點。

url-test 會透過指定的測試網址評估組內成員，適合從用途相近的一組節點中自動選擇。測試結果只反映節點連線至該測試目標的狀況，不代表所有服務的實際體驗。測試網址應長期穩定、允許探測，且盡量符合實際使用情境；若只依據偶發失敗的目標，容易造成不必要的切換。

fallback 會依候選順序尋找可用出口，適合主線路優先、備援線路接手的情境。load-balance 則依策略分配連線，並非將單一連線拆成多條線路。對登入狀態、來源位址或地區一致性敏感的服務，應先使用固定出口；確認服務允許出口變動後，再考慮分配連線。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - MATCH,DIRECT

上方範例僅用於確認組名與規則引用關係。由於目前 PROXY 內只有 DIRECT，因此仍會直連。實際使用時，請在用戶端加入現有節點或其他策略組；名稱必須與目前設定完全一致。不要因組名是代理，就認定其內部一定會透過遠端出口；請展開成員確認最後的選擇。

自動測速參數與節點提供器

使用節點提供器時，策略組透過 use 引用 proxy-providers 的鍵名，而不是檔名。提供器的健康檢查與策略組的自動選擇用途不同：前者維護節點可用狀態，後者用於組內決策。兩處都設定密集探測會重複消耗請求，通常先採用較長的間隔，再依實際故障復原需求調整。

interval 表示探測間隔，單位為秒；tolerance 用於避免因細微差異而頻繁切換。它不是最低速度保證，也不是連線逾時設定。自動選擇主要影響新建立的連線，已建立的下載、通話或長連線不一定會立即改走目前選定的出口。需要驗證切換結果時，請先結束測試連線，再重新發出請求。

引用檢查與切換驗證

策略組可以彼此巢狀引用，但不能形成循環。例如業務組引用自動組，而自動組又引用業務組，就無法得出確定的出口鏈。修改時先列出所有組名，再逐一檢查成員。多個組共用同一個節點並無問題；真正要避免的是組名重複、引用不存在的名稱，以及透過多層巢狀引用間接回到自身。

驗證時請在連線記錄中一併查看命中規則、策略鏈與最終節點。若規則正確但出口不符，先檢查外層組儲存的選擇，再查看內層自動組狀態；若組內沒有成員，請確認提供器是否載入成功，以及篩選條件是否排除了所有節點。不要一開始就修改 DNS，否則出口問題和解析問題會混在一起。

訂閱更新可能移除節點，但穩定的業務組名稱仍應保留。重要服務可以建立獨立策略組，避免隨一般組自動變動。記錄已驗證的配置方式，比持續增加巢狀層數更容易維護；多份訂閱的節點整合方式，請參閱本機覆寫與多訂閱合併。

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

規則集可將經常更新的網域或網段從主要設定中拆分，由 rule-providers 負責載入，再透過 RULE-SET 加入規則鏈。如此一來，主要設定只需保留分類與出口關係。規則集不是節點訂閱，也不會自動建立策略組；即使檔案載入成功，若沒有對應的引用規則，也不會參與任何連線判斷。

先確認行為類型與檔案格式

behavior 說明規則內容的語意。domain 儲存網域集合，ipcidr 儲存 IP 網段，classical 儲存含類型的規則項目。format 則說明檔案的編碼格式，兩者不能互相取代。下載到文字檔不代表應選用某一種行為類型，必須開啟檔案確認實際內容。

以下使用本機經典規則集，方便在不受遠端更新影響的情況下驗證結構。請將第二段儲存至主要設定目錄下的 rules/work.yaml，先確認目錄可讀取，再載入第一段。此處的 PROXY 必須事先定義於策略組中；規則集只儲存比對條件，不會在每個項目後重複附加出口。

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

rules:
  - RULE-SET,work,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

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

經典規則集會保留 DOMAIN-SUFFIX 等類型前綴；網域集合有自己的項目語意，不能只修改上方檔案的 behavior 後繼續使用。若採用二進位規則格式，也要確認目前的核心支援該格式。發生錯誤時，應優先核對檔案內容與設定宣告是否一致，而不是不斷更換快取路徑。

遠端更新與快取的用途

改用遠端規則提供器時，請設定 type: http、填入有效的規則網址，並設定更新間隔與專用快取路徑。更新間隔的單位同樣是秒。遠端網址必須回傳符合宣告格式的規則內容；回傳網頁、登入頁或錯誤訊息都不算更新成功。連線成功也不代表內容已成功解析。

快取可讓用戶端在暫時無法取得遠端檔案時，嘗試沿用既有內容；但能否啟動仍取決於快取是否存在，以及核心的載入結果。首次使用時，請在記錄中確認下載與解析都已完成。多個提供器不要共用同一個快取檔案，否則更新時可能覆蓋其他規則，造成分類名稱正確、內容卻錯誤的隱蔽問題。

遠端規則來源也屬於設定的信任範圍。規則維護者可以變更網域分類，進而改變連線出口。導入前應先了解規則用途、更新方式與涵蓋範圍，並在本機測試後再加入主要設定。對少數必須維持穩定的服務，可以使用主要設定中的精確規則固定行為，不必完全依賴涵蓋範圍廣泛的遠端清單。

依優先順序排列規則鏈

一般規則會依序比對，由第一條命中的規則決定出口。因此，本機例外通常應放在通用規則集之前，涵蓋範圍較大的網段判斷則排在後面，並以 MATCH 作為最後的兜底規則。若將兜底項目放在前面，後續規則就不會再有比對機會；若將範圍寬泛的拒絕規則放在業務例外之前，也會直接擋住後者。調整策略組無法修正這類順序錯誤。

涉及 IP 的判斷可能需要先解析網域。部分 IP 規則支援 no-resolve，可避免為該規則額外觸發解析，但不代表連線完全略過 DNS。是否加入此設定取決於規則用途：若要依據已知目標位址判斷，可以考慮使用；若預期先解析網域，再判斷其所屬網段，就要謹慎處理，以免改變原本預期的命中範圍。

排查流量分流錯誤時，先記錄目標網域與實際命中的規則，再找出對應的提供器。暫時將一條精確網域規則放在最前面，有助於判斷問題出在規則順序還是出口本身。測試完成後請刪除臨時項目，只保留用途明確的正式例外，避免設定逐漸累積出彼此遮蔽的規則。

規則較多時，可依工作服務、媒體服務與本機網路分類整理，而不是依來源任意堆疊。每次只更新一類並觀察連線記錄，才能釐清變化來源。欄位間的引用基礎請參閱config.yaml 頂層欄位解析；連線失敗的一般檢查方式請見常見問題。

DNS 設定最佳化與解析路徑

DNS 的目的不只是取得 IP 位址，還要讓網域、位址與後續出口保持一致。同一個網域透過不同解析服務，可能得到不同結果；代理出口所在的網路也可能影響目標是否可連線。最佳化前，先確認應用程式的請求是否進入用戶端 DNS，再確認解析請求透過哪個出口送出，最後才比較解析服務，而不是只更換伺服器清單。

區分監聽、上游與引導解析

listen 定義用戶端 DNS 服務的監聽位置，nameserver 則定義一般網域查詢所使用的上游，兩者屬於不同層級。監聽回環位址只供本機存取；寫入設定也不代表作業系統已改用該位址。還需要透過系統 DNS 設定、TUN 的 DNS 接管或用戶端的相關功能，才能將請求實際送至該監聽埠。

default-nameserver 主要用於解析 DNS 上游本身的網域，因此應選擇可直接連線的明確位址。若加密上游以網域表示，就必須先完成這個引導解析步驟。若引導解析又依賴尚未建立的代理，設定便可能陷入啟動循環，導致節點網域與解析服務網域都無法解析。

dns:
  enable: true
  listen: 127.0.0.1:1053
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  fake-ip-filter:
    - "*.lan"
    - "*.local"

此範例展示欄位位置，所列的公用解析位址應依目前網路的連線狀況選用。它不會自動將系統埠轉送至 1053，也不保證所有應用程式都會使用這項服務。部署後，請先直接查詢此埠，確認監聽正常，再驗證系統與應用程式的解析路徑，避免將系統尚未接入誤判為上游故障。

分別處理節點網域與服務網域

服務網域最後可以透過代理存取，但代理節點本身的網域通常必須在代理可用之前完成解析。支援對應欄位的核心可使用 proxy-server-nameserver，為節點網域單獨設定解析服務。修改前請確認上游可直接存取；若節點位址本身無法解析，策略組探測失敗並不能證明遠端服務無法使用。

nameserver-policy 可針對特定網域選擇解析服務，適合內部網域、分流解析或有明確地區需求的服務。企業內部網域應交由可存取內部區域的解析服務處理，公用解析服務通常查不到這些記錄。策略範圍應明確，先驗證單一後綴，再逐步擴大，避免一般網域被意外送往只有內部網路才能存取的伺服器。

respect-rules 會讓 DNS 上游連線依規則選擇出口。使用時必須同時釐清節點網域的解析方式，避免 DNS 依賴代理、代理又依賴同一條 DNS 路徑。這不是普遍適用的加速開關。若沒有明確的解析出口需求，先維持簡單設定，等基本連線穩定後再加入策略，通常更容易排查問題。

分層驗證，不以瀏覽網頁的體驗取代查詢

應用程式可能保留自己的 DNS 快取，也可能啟用加密 DNS。瀏覽器內建解析會略過系統設定，而已建立的連線甚至不會再次查詢。修改設定後，請分別檢查用戶端查詢、系統查詢與應用程式的新連線，必要時清除對應快取。只重新整理頁面而不關閉舊連線，很難確認新設定是否生效。

具備 dig 的系統可用下列指令直接查詢範例監聽埠。若回傳 Fake-IP 位址，表示查詢進入了對應的映射機制，不代表目標伺服器真的使用該位址。若指令逾時，先檢查監聽位址與埠號是否被占用；若有回應但應用程式仍失敗，再檢查系統接入、路由與規則命中情況，不要立刻更換所有上游。

dig @127.0.0.1 -p 1053 example.com A

若一般網域正常、只有內部網域失敗，請檢查搜尋網域、內部解析伺服器與 VPN 路由；若所有網域都解析失敗，但直接輸入 IP 可以連線，請優先檢查 DNS 接管與上游路徑。若網域已取得位址但連線逾時，就要回頭檢查策略鏈與目標可達性。DNS 解析成功本身不代表連線會透過預期出口建立。

不要將增加上游數量當成通用的最佳化方式。伺服器過多會擴大隱私與故障範圍，也可能因回傳結果不一致而增加排查難度。先選擇少量可靠的上游，並記錄特殊網域策略與選擇原因。DNS 設定與 Fake-IP 的關係，請搭配下一章理解，尤其是位址映射、快取失效與應用程式保留位址等情況。

TUN 與 Fake-IP 的接管範圍

TUN 是虛擬網路介面，用來接收由系統路由送入的 IP 封包；Fake-IP 則是 DNS 層的位址映射機制。兩者經常搭配使用，但並非同一項功能。系統代理主要服務遵循代理設定的應用程式，TUN 則能接管更多網路請求。是否啟用應取決於應用程式的接管需求，而不是把它當成所有連線問題的預設解法。

建立可復原的接管順序

啟用前，先確認一般代理模式下節點、訂閱與策略組都能正常運作，再檢查用戶端是否需要安裝服務或取得管理員權限。桌面系統通常涉及虛擬介面與路由權限；行動裝置通常透過系統 VPN 介面授權。開啟介面開關不代表接管已完成，請在記錄中確認介面建立、路由安裝與 DNS 接管都沒有錯誤。

以下列出常見的基本欄位。auto-route 用於自動設定路由，auto-detect-interface 用於識別出口介面，dns-hijack 用於設定 DNS 接管目標。實際支援與行為會因系統及核心而異，建議先使用用戶端提供的預設 TUN 設定，再核對最終設定，避免在介面與覆寫中設定相反的值。

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

stack 用於選擇網路堆疊實作，不能只憑名稱判斷效能。不同系統對相關實作的支援、協定處理與資源耗用各有差異。若特定應用程式發生異常，先維持其他參數不變，只切換用戶端實際支援的網路堆疊進行比較，並記錄系統環境；不要同時調整路由、DNS 與 MTU。

了解 Fake-IP 的網域映射

Fake-IP 模式會向應用程式回傳一個映射位址，用戶端在後續連線中依此位址還原網域並執行分流。範例中的位址範圍供此機制使用，並非目標網站的真實位址。它能降低只依賴目標 IP 判斷網域的難度，但前提是 DNS 查詢與後續連線都進入同一套映射環境；映射鏈一旦中斷，就可能導致連線失敗。

應用程式長期快取位址、休眠後恢復連線，或切換用戶端執行個體，都可能讓舊映射失效。遇到這種情況，請先重新解析並建立新連線，必要時清除應用程式與系統快取。不要將舊的 Fake-IP 位址寫入 hosts 或服務設定，也不要把它分享給其他裝置當作伺服器位址；離開對應映射表後，該位址就不再具有預期的網域意義。

fake-ip-filter 用於指定哪些網域不回傳假位址，適合需要真實位址語意的部分區域網路探索、內部服務或相容性情境。過濾不等於直連規則；網域取得真實位址後，連線仍會依規則決定出口。請針對已確認的問題逐項加入，不要使用範圍過大的比對條件，讓整套機制失去作用。

路由衝突與區域網路存取

公司 VPN、容器網路、虛擬機器與其他代理工具都可能改寫路由。啟動 TUN 後若只有內部資源無法連線，請先比對相關網段的路由歸屬，確認是否需要排除或保留原有路徑。不要直接刪除所有路由來恢復網路，這可能中斷管理連線；遠端操作裝置時尤其要預先準備其他復原方式。

開啟「允許區域網路連線」與啟用 TUN 是兩回事。前者通常影響代理監聽是否接受其他裝置的連線，後者影響本機路由接管。若要為其他裝置提供代理服務，還要檢查監聽位址、防火牆與驗證設定；只在本機啟用 TUN，不會自動讓整個區域網路的流量經過用戶端。

若接管後整體無法連線，請依序檢查 TUN、系統 DNS 與系統代理的復原狀態，並確認用戶端結束後是否清除了介面與路由。先恢復基本網路，再重新測試單一接管方式。安裝檔與平台選擇請參閱下載頁，建議優先選擇 Clash Plus；實際功能支援仍請以所用用戶端的設定為準。

網域嗅探與規則補充

網域嗅探會嘗試從連線初期的協定資料識別主機名稱，補足只有目標 IP 時缺少的資訊。它可補充 DNS 提供的網域映射，但不能取代完整的解析與路由設計。啟用前，先確認問題是否真的來自網域遺失：若連線記錄已顯示正確網域與命中規則，繼續增加嗅探通常無法解決出口故障。

可識別的資訊與限制

HTTP 請求可能包含主機標頭，TLS 握手可能提供伺服器名稱，部分 QUIC 握手也可能帶有可用線索。能否取得這些資訊取決於協定、握手形式及核心支援。嗅探並非解密 HTTPS 內容，無法藉此讀取完整的加密請求；若名稱資訊受到保護或協定不支援，用戶端也無法憑空還原網域。

部分應用程式會直接連線至固定位址，或使用自己的解析流程，使連線未經用戶端 DNS。在這些情況下，嗅探可能讓網域規則重新有機會比對。不過，同一個位址可能承載多項服務，應用程式握手中的名稱也未必等同於使用者在介面輸入的位址，因此必須依據實際連線記錄確認結果，不能只看網站是否開啟。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: false
    TLS:
      ports:
        - 443
      override-destination: false
  skip-domain:
    - "*.lan"
    - "*.local"

範例先限定 HTTP 與 TLS 的常見埠號，並關閉目標覆寫，適合用來觀察識別效果。它不會自動涵蓋所有自訂埠號，也未啟用 QUIC 識別。若服務實際使用其他埠號，請先確認服務協定再擴大範圍。埠號只是篩選條件，並不能證明協定真實性；在任意埠號上強行嘗試所有解析方式，反而會造成不必要的干預。

分開驗證網域識別與目標覆寫

override-destination 用來控制是否依據識別出的網域覆寫連線目標。關閉時較適合先觀察網域識別與規則變化；開啟後則可能改變後續解析與建立連線的方式。兩種行為應分開測試：先確認識別結果可信，再評估是否確實需要改變目標，避免一次全開後無法判斷是哪個步驟造成異常。

固定位址存取、內部反向代理，以及某些對目的位址有特殊要求的應用程式，可能不適合使用目標覆寫。原本指定連線至特定伺服器的請求，若依握手網域重新解析，可能會轉向另一台伺服器。發生登入異常或服務回應改變時，請比對原始位址、識別出的網域與最終連線目標，而不只是查看是否命中預期的策略組。

skip-domain 可排除不希望納入嗅探處理的網域。先從明確的內部服務與已知相容性例外開始，不要複製用途不明的大量排除清單。排除範圍過大，可能讓原本要解決的網域資訊缺失問題繼續存在；範圍過小，則可能讓不需要干預的內部連線產生額外變化。關鍵在於逐項驗證。

配合 DNS 與應用程式加密解析排錯

瀏覽器的加密 DNS 可能讓用戶端看不到一般查詢，但不代表嗅探一定能還原名稱。若握手中的名稱也受到隱藏，用戶端便只剩下 IP 與其他有限資訊。此時應明確選擇：讓應用程式使用可由用戶端接管的解析路徑，或接受以位址為基礎的規則範圍，而不是反覆堆疊無效的嗅探埠號設定。

排錯時可選擇一個網域固定、容易重新建立連線的服務。先關閉嗅探並記錄命中結果，再開啟識別但不覆寫目標，最後視需要測試目標覆寫。每次測試都要關閉舊連線，並維持策略組選擇不變，同時查看網域與最終出口。如此便能分開檢視名稱識別、規則比對與目標重建三種變化，減少彼此掩蓋的情況。

若只有 UDP 服務異常，請另外確認節點是否支援所需傳輸方式、TUN 是否已接管，以及對應協定是否在嗅探範圍內。瀏覽器也可能在 QUIC 失敗後改用 TCP；網頁最後能開啟，不代表兩條路徑都正常。不要透過全域拒絕所有 UDP 來證明規則正確，這會改變應用程式行為並掩蓋原始問題。

嗅探設定應維持範圍精簡、目的明確。確認 DNS 映射穩定後，只為確有需要的協定啟用嗅探，並在記錄中註明用途。若啟用後看不出可重現的改善，恢復較簡單的設定會更容易維護。規則模式、連線記錄與常見故障可搭配常見問題一併檢查，不必讓嗅探承擔所有分流工作。

本機覆寫與多訂閱合併

訂閱負責提供遠端內容，本機覆寫則處理裝置與個人需求，兩者應分開保存。直接修改下載的訂閱檔案，可能在下次更新時被覆蓋；將所有設定都交給訂閱，又容易讓埠號、DNS 或接管方式隨遠端內容變動。較穩定的做法是明確區分哪些欄位由遠端維護，哪些欄位始終由本機設定接管。

先確認用戶端的合併規則

不同用戶端可能提供設定合併、覆寫檔案、規則修補或指令碼處理等功能，名稱相近，實際行為卻未必一致。尤其是陣列欄位，有些實作會整個取代，有些則支援附加或插入前方。使用前必須了解執行順序與適用範圍，不要將特定用戶端的修補語法直接當成通用 mihomo YAML，也不要同時啟用兩套順序不明的覆寫方式。

可以先用低風險欄位驗證，例如變更記錄層級，載入後查看最終設定是否有變化；接著再測試規則前置與清單取代。介面顯示儲存成功，只能代表輸入內容已被接受，不代表最終合併結果符合預期。真正需要核對的是交給核心的有效設定，以及核心是否接受並載入這些欄位。

建議將本機維護內容分為裝置層與服務層。裝置層保存監聽埠、DNS、TUN 與控制介面；服務層保存穩定組名、規則順序與本機例外。如此遷移裝置時，可單獨調整網路參數，不必重寫所有服務規則。若覆寫涉及指令碼，也應先了解其行為，因為指令碼可能直接重建整份設定。

多份訂閱優先拆分為節點提供器

合併兩份完整訂閱時，常見衝突不在節點本身，而在同名策略組、重複規則與彼此不相容的 DNS 設定。若需求只是同時使用兩組節點，較清楚的做法是讓每個來源各自提供節點檔案，再由本機設定統一整理策略組。以下以本機檔案示意結構；檔案必須包含節點提供器可讀取的 proxies 清單。

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

proxy-groups:
  - name: PROXY
    type: select
    use:
      - access-a
      - access-b
    proxies:
      - DIRECT

完整訂閱通常也包含策略組與規則，不能只將檔案重新命名，就認定它是格式正確的節點提供器。必須確認檔案結構與讀取方式相容，或使用用戶端明確支援的轉換功能。若使用遠端提供器，請填入有效訂閱網址並使用獨立快取路徑；訂閱網址可能包含存取憑證，請勿貼到公開文件或排錯截圖中。

名稱衝突與規則順序

不同來源可能有相同的節點名稱，導致選項難以區分或引用結果不明確。建議在匯入或預處理階段加入穩定的來源前綴，並先確認用戶端支援的重新命名方式，再套用變更。不要只根據節點顯示名稱推斷地區或用途；來源標記用於區分維護範圍，實際可連線性仍應透過一般連線驗證。

合併規則時必須保留順序語意。個人精確例外通常放在前面，訂閱的通用分類放在中間，兜底規則只保留一條並置於末尾。單純將兩份規則陣列首尾串接，第一份中的 MATCH 就會遮蔽第二份的所有內容。若用戶端預設採用附加規則的方式，請特別確認是否支援將規則插入前方；不能只因項目存在，就認定它已生效。

策略組也必須檢查引用是否形成閉環。合併後保留兩個同名業務組，或重新命名組別卻未同步更新規則出口，都可能造成載入錯誤或意外選擇。最精簡的驗證順序是先載入提供器，再建立統一策略組，最後加入規則。每個步驟都要查看記錄，避免節點讀取失敗與規則引用失敗同時進入最終設定。

備份、更新與復原

備份至少應包含本機覆寫、主要設定、規則檔案與提供器的配置說明；敏感訂閱網址則應另外保管。只備份用戶端截圖，無法完整還原引用關係；只備份更新後的有效設定，也可能遺失原有的覆寫邏輯。每次進行較大幅度的修改前，請保留可正常連線的設定與相關說明，以便判斷復原時需要還原哪些層級。

測試訂閱更新時，請檢查本機例外是否仍存在、規則順序是否變動，以及目前的選擇是否指向已移除的節點。發生異常時，先停用最新的修補並載入備份，不要在失敗的設定上連續修補。Profile 切換與訂閱更新的差異，請參閱多設定檔管理筆記；基本匯入流程仍請以使用指南為主。

外部控制面板與設定驗證流程

外部控制介面可讀取執行狀態、切換策略組並執行部分管理操作；控制面板則是它的圖形化入口。面板本身不會提供代理出口，也不能取代核心。面板連線失敗與代理連線失敗屬於不同層次：用戶端仍可能正常轉送流量，但管理介面可能沒有監聽、驗證資訊不符，或受到瀏覽器安全政策阻擋。

本機監聽與本機面板檔案

若只在本機管理，應將 external-controller 綁定至回環位址。external-ui 指向本機面板資源目錄，目錄中必須實際存在對應的靜態檔案；只填入目錄名稱不會自動產生面板。以下範例展示監聽與資源路徑。啟用前，請另外在本機設定控制介面的驗證密鑰，不要將公開範例值當成長期憑證。

external-controller: 127.0.0.1:9090
external-ui: ./ui

驗證欄位為頂層的 secret，應使用獨立的隨機長字串，並與面板連線設定一致。此密鑰用於控制介面驗證，不是節點密碼或訂閱網址，三者不可混用。將密鑰放進公開截圖、分享連結或公開設定，同樣會擴大管理權限的暴露範圍；排錯前請先移除敏感資訊。

將監聽位址改為所有介面，會讓其他網路裝置有機會存取管理介面，不應只為了方便就直接開放。若確實需要遠端管理，應透過受控網路、存取限制與適當的加密通道保護連線，並檢查系統防火牆。設定驗證資訊不代表可以忽略網路隔離；管理介面能變更執行中的行為，應視為管理權限妥善保護。

分別檢查網路、驗證與瀏覽器限制

面板無法連線時，先確認目前的核心程序確實載入控制介面設定，再核對位址與埠號。瀏覽器中的本機位址是指瀏覽器所在的裝置；在另一台裝置開啟面板時，回環位址不會指向執行核心的主機。不要因為這個認知落差就直接擴大監聽範圍，應先確認是否真的需要跨裝置管理。

在本機且未設定驗證的檢查階段，可用下列指令確認介面是否有回應；若已設定密鑰，則必須使用附帶相應驗證資訊的請求，不能因此要求移除驗證。連線遭拒通常表示沒有監聽或位址錯誤；驗證錯誤則通常表示介面可連線，但憑證不符。兩種情況應分開處理，反覆更換代理節點不會改變結果。

curl --fail --silent --show-error http://127.0.0.1:9090/version

遠端 HTTPS 頁面呼叫本機 HTTP 介面時，可能受到混合內容、跨來源或本機網路存取限制。面板空白也可能只是靜態檔案路徑錯誤。建議優先使用用戶端內建面板或可信任的本機面板，並逐項檢查瀏覽器主控台訊息；不要把允許任意來源存取當成通用修復方式，也不要為了連接面板而關閉所有瀏覽器防護。

載入前後的兩次檢查

第一次檢查在載入之前：確認 YAML 縮排、欄位類型、引用名稱與檔案路徑。在具備 mihomo 指令的環境中，可執行測試；若設定包含本機提供器，也要確保相關檔案已準備完成。測試能找出語法與部分引用問題，但無法證明遠端節點可連線、系統授權已完成，或所有服務規則都符合預期。

mihomo -t -f ./config.yaml

第二次檢查在載入之後：先查看啟動記錄，確認介面、提供器與規則集都正常；接著建立一條可重現的測試連線，查看網域、命中規則、策略鏈與最終出口。之後分別驗證需要直連與代理的服務。面板只顯示執行中，不能取代從設定到實際連線的完整檢查流程。

面板中的暫時切換不一定會寫回訂閱或本機覆寫。需要長期保存的選擇，請確認用戶端的持久化機制；需要長期保存的規則，則應放在可維護的設定層。不要把執行階段的修改當成唯一備份，否則重新啟動、更新或切換 Profile 後，先前在面板調整的狀態可能消失，讓人誤以為設定自行變動。

一次只變更一項故障因素

建議依照設定解析、檔案載入、DNS、出口、規則、系統接管的順序排查。每次只修改一個層級，記錄觀察結果後再決定下一步。若問題是在某次更新後出現，請優先還原最近可用的設定以確認關聯，不要同時開啟嗅探、更換網路堆疊並重寫 DNS。變因越少，通常越容易定位問題。

若啟動時閃退，請先保留錯誤訊息並停止反覆自動重啟，再參照從記錄定位問題與回復設定的步驟處理。若能啟動但單一功能異常，再查閱本指南的對應章節。完成調整後，請保存最終設定與用途說明，下次訂閱更新或遷移裝置時，才能沿用相同的驗證流程。