Clash 進階設定指南

策略組類型與分流實務

將規則目標與節點選擇分開

策略組是規則與實際出口之間的中介層。規則決定連線交給哪個組別，再由組別選擇使用哪條出口。若業務規則直接綁定節點名稱，節點改名、訂閱替換或服務商調整都可能連帶影響規則。建立穩定的組名後，只需維護組內成員，規則仍可引用同一個目標，長期維護也更省力。

proxies 定義實際出口，proxy-groups 定義可供選擇或自動調度的集合，rules 則依序引用這些項目。三處名稱必須完全一致，空格、大小寫與標點都不能任意更動。組別可以引用其他組別，但不可形成循環依賴；例如業務組指向自動組，而自動組又指回業務組，就會導致設定無法建立有效的選擇路徑。

依選擇方式決定組別類型

select 用於手動選擇，適合需要明確指定出口的情境。url-test 依探測結果選擇出口，適合用途相近的一組線路。fallback 依成員順序檢查可用性，優先維持使用前方可用的出口。load-balance 依策略分配連線，不代表多個節點的頻寬會合併到同一個下載工作，也不保證同一帳號的所有連線都從相同位址送出。

建立業務組與自動組的雙層結構

以下範例使用核心內建的直連出口，可呈現組別之間的實際引用關係，但不會產生代理效果。實際使用時，請將自動組中的直連成員替換為現有節點名稱，或透過 use 引用已定義的代理提供者。保留手動入口，方便自動選擇不符合需求時，快速切回固定出口。

proxy-groups:
  - name: 自動出口
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true

  - name: 日常連線
    type: select
    proxies:
      - 自動出口
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,日常連線
  - MATCH,日常連線

interval 的單位是秒，代表檢查間隔；tolerance 的單位是毫秒，用來減少微小差異造成的頻繁切換。lazy 控制組別閒置時的檢查行為。探測網址應能穩定連線，並盡可能符合線路用途。只根據輕量網頁的探測結果，無法判斷大型檔案傳輸、影片播放或特定地區服務的表現。

需要維持登入狀態的服務，適合另設手動組，並盡量保持出口穩定。若購物、付款或帳號管理連線使用不斷輪替的出口，可能觸發服務端的風險判斷。需要切換時，先停止相關工作，再選取目標節點並重新建立連線；既有連線通常不會因組別選擇變更而自動切換。

從實際命中結果反查組別路徑

疑難排解時，先在連線詳細資訊中確認規則目標，再展開策略組查看目前選取項目，最後確認實際節點。介面顯示已選取某個節點，不代表目標網站一定會經過該組：規則可能更早命中直連，或應用程式根本沒有進入核心。先確認連線路徑，再比較線路，才不會把規則問題誤認為節點問題。

如果組別顯示為空，請檢查成員名稱是否存在、代理提供者是否成功載入，以及篩選條件是否排除了所有節點。不要反覆切換全域模式來掩蓋引用錯誤。模式說明請參閱出站模式教學；想了解 YAML 各區段的對應關係，可接著閱讀逐段拆解設定檔。

以訂閱方式管理規則集

先確認規則順序，再拆分規則來源

規則由上往下比對，通常找到第一個符合條件的項目後，就會決定出站目標。較明確的網域規則應排在範圍較廣的地區規則之前，最後再放上兜底規則。將規則拆成外部檔案只會改變維護方式，不會改變比對順序。即使規則集維護得再完善，放錯位置仍可能永遠不會命中。

rule-providers 用來宣告規則資源，RULE-SET 則負責將資源接入比對流程。提供者名稱只是引用識別碼，不會自動決定走代理或直連；真正的策略目標寫在 RULE-SET 後方。同一個規則集可在不同設定中綁定不同策略組，方便分開維護分類資料與個人出口偏好。

了解 behavior 與 format 的差異

behavior 說明內容應如何解讀。domain 用於網域集合，ipcidr 用於 IP 網段，classical 則保留完整規則類型，例如 DOMAIN-SUFFIX 或 IP-CIDR。format 說明檔案的編碼格式，常見類型包括 YAML、純文字與 MRS。副檔名只是命名慣例，不能取代對實際內容格式的確認。

以下先用內嵌提供者示範完整的接入方式。這種方式不需要遠端下載，適合用來確認名稱、行為類型與規則順序。classical 內容中的各項規則不需再寫策略目標，因為引用它的 RULE-SET 已指定目標。若在規則項目中重複加入策略名稱，容易造成格式不相容。

rule-providers:
  本機例外：
    type: inline
    behavior: classical
    payload:
      - DOMAIN-SUFFIX,example.com
      - IP-CIDR,192.168.50.0/24,no-resolve

rules:
  - RULE-SET,本機例外,DIRECT
  - MATCH,DIRECT

確認本機結構可以載入後，再將需要集中更新的部分改用遠端提供者。以下網址僅供示範；套用前必須替換成實際可連線且內容格式相符的規則檔案，不能直接當成可用的規則服務。相對路徑 path 會依核心工作目錄解析，不一定等於用戶端顯示的訂閱目錄。

rule-providers:
  業務網域：
    type: http
    behavior: domain
    format: yaml
    url: https://example.com/rules/business.yaml
    path: ./rules/business.yaml
    interval: 86400

rules:
  - RULE-SET,業務網域,DIRECT
  - MATCH,DIRECT

規劃更新與離線復原方式

規劃遠端更新時，首次啟動與後續重新整理都要納入考量。若首次啟動時沒有本機快取，而資源網址又需要仰賴尚未建立的代理連線，就可能遇到啟動依賴問題。優先選擇目前網路可連線的規則來源；若要指定資源下載出口，請先確認目前核心支援的提供者欄位，並確保該出口不會反過來依賴這個規則集。

更新間隔不宜設得太短。規則分類通常不會以秒為單位變動，頻繁下載不但增加網路請求，也會讓錯誤更新更快擴散。請保留可還原的上一版設定，並查看日誌確認提供者是否載入完成。既有快取能否繼續使用，取決於快取狀態、用戶端目錄與錯誤類型，不能視為永久保障。

每個規則集都應使用獨立路徑，避免多個提供者寫入同一檔案。更換電腦或重新安裝用戶端時，也別只備份主要 YAML 而漏掉本機規則檔案。行動裝置的應用程式沙箱與桌面檔案目錄不同，直接複製絕對路徑通常無法移植。長期設定建議使用清楚的相對目錄，並記錄哪些檔案由用戶端管理。

處理誤判與 DNS 的連帶影響

網站分流錯誤時，先查看實際命中的規則名稱，再判斷是分類資料還是規則順序有誤。個人例外通常放在公共規則集之前，只加入必要的網域或網段。不要為了修正單一網域就將整個大分類改為直連，否則同一規則集中的其他服務也會一併改變路徑。

no-resolve 用於避免某些位址規則為了判斷而觸發額外的網域解析，並不是關閉整個連線的 DNS。若應用程式已提供目標 IP，位址規則仍可正常檢查。網域與位址規則混用時，請釐清哪個步驟可能發出查詢，以免將規則觸發的查詢誤認為重複 DNS 請求。

DNS 設定與解析路徑最佳化

沿著查詢路徑找出解析發生的位置

調整 DNS 前，先釐清查詢路徑：應用程式把網域交給誰、系統是否介入、核心是否收到查詢，以及最後由哪個上游回覆。只修改主 YAML 中的 DNS 位址，不代表瀏覽器、系統服務和獨立應用程式都會改走相同路徑。瀏覽器內建的加密 DNS、應用程式自行解析與快取，都可能讓測試結果不如預期。

系統代理主要接管遵循代理設定的應用程式流量，並不會自動接管系統的所有 DNS。TUN 可以擴大接管範圍，但仍受路由、劫持規則與應用程式行為影響。測試時應指定一個應用程式、清除必要快取，並比對核心日誌中的網域資訊；不要同時切換上游、增強模式和路由設定，否則很難判斷是哪項調整生效。

區分引導解析、一般解析與節點解析

default-nameserver 主要用於解決 DNS 上游網域本身的引導解析問題。nameserver 是一般查詢使用的上游集合。proxy-server-nameserver 專門用來解析代理節點網域，有助於避免節點解析依賴代理，而建立代理又依賴節點解析的循環。這幾組欄位並非單純的主要與備用關係，不能只看名稱就認定會依序切換。

nameserver-policy 可指定特定網域使用特定上游，例如區域網路服務或企業內部網域。比對語法應以目前核心的文件為準；一般網域後綴可使用 +.example.com 這類寫法。內部網域應交由能識別它的內部 DNS 解析，而不是送到公共解析器後，再期待它回傳私有服務位址。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "+.example.com":
      - 192.168.50.1
  fake-ip-filter:
    - "*.lan"
    - "*.local"

範例中的內網 DNS 位址須替換成實際路由器或組織提供的解析器。如果沒有內部網域的需求，請刪除對應策略，不要保留無法連線的位址。加密 DNS 會改變查詢的傳輸方式，但不會自動確保查詢經由代理；連線出口仍須一併考量核心 DNS 選項、路由與規則。

謹慎設定規則遵循與備用解析

respect-rules 可讓 DNS 上游連線遵循路由規則，但也會增加依賴關係。啟用前，請先為節點網域準備可用的專用解析路徑，並確認規則不會讓解析器連線再次依賴尚未建立的出口。網路已經穩定時，不要只因欄位看起來更完整就啟用它。

使用 fallback 與 fallback-filter 時，請先了解核心如何判定哪些解析結果可接受。備用上游不一定只會在一般上游逾時後才接手；篩選條件也可能決定要回傳哪一組結果。若不了解實際網路環境，就將大量地區條件與位址篩選複製到設定中，容易造成額外查詢和位址選擇不一致。

評估 IPv6 時，應一併考量 DNS 回應、系統路由、節點能力與目標網站的連線狀況。dns.ipv6: false 主要影響核心的解析回應，不代表系統層完全停用 IPv6，也無法阻止應用程式使用已快取的位址。若只有部分網站載入緩慢，請查看連線詳細資訊，確認是否先嘗試連線到無法使用的 IPv6 路徑。

依問題現象縮小疑難排解範圍

網域完全無法解析時，先檢查上游位址是否可連線，以及上游本身的網域能否完成引導解析。只有節點連線失敗時，優先檢查節點網域解析。只有內網服務異常時，確認是否誤送到公共上游。若多個不相關網站都同時載入緩慢，則應比對系統原生解析與核心解析，確認問題是否真的出在 DNS。

解析成功不代表目標位址一定能連線。若日誌已取得位址，但後續連線逾時，請繼續檢查規則出口、防火牆與線路，不要不斷更換 DNS。瀏覽器、系統與核心各自有獨立快取，修改後請依測試範圍清除快取並關閉舊連線。快取殘留與傳輸瓶頸的區別，可參閱網速慢的分層排查。

TUN 虛擬網卡與 Fake-IP

先分清流量入口與 DNS 增強模式

TUN 會在系統中建立虛擬網路介面，將符合路由條件的流量送進核心。Fake-IP 則是 DNS 增強模式：核心會為網域回傳虛擬位址，再透過對應關係還原網域並進行後續處理。兩者經常搭配使用，但不是同一個開關。啟用 TUN 不代表 DNS 已被接管，啟用 Fake-IP 也不代表所有應用程式都會經過虛擬網卡。

系統代理適合瀏覽器與遵循代理設定的程式；TUN 則適合需要接管系統代理未涵蓋流量的情境。切換前先確認原有系統代理連線正常，再單獨測試 TUN。若同時安裝其他 VPN、虛擬網卡軟體或端點安全產品，請檢查預設路由與介面優先順序，不要假設多個流量接管工具會自動協調。

從最精簡的路由設定開始

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"

auto-route 用於自動設定相關路由，auto-detect-interface 用於自動偵測出口介面。stack 決定流量處理堆疊，不是效能等級開關；不同系統、協定與應用程式的相容性各有差異。先使用用戶端目前支援的預設值，只有在能重現問題並記錄比較結果後，再測試其他可用的堆疊。

dns-hijack 的一般連接埠劫持主要針對一般 DNS 流量，不能據此認定加密 DNS 也會轉成核心查詢。實際效果還取決於作業系統和路由行為。應用程式若直接連線到加密解析服務，可能繞過預期的網域映射；請檢查應用程式自己的解析設定，不要一再新增連接埠規則。

處理權限與平台差異

桌面版建議優先透過用戶端提供的服務安裝與授權流程啟用，不建議長期以過高權限執行整個桌面工作階段。Android 的 VPN 授權由系統管理，一般情況下無法同時讓兩個應用程式使用同一個 VPN 通道。iOS 使用者應選擇對應的用戶端入口，不要將桌面版 TUN 欄位視為所有平台都適用的操作說明。

裝置連線到企業網路時，內網網段、專用 DNS 與安全軟體可能有額外要求。請先確認組織允許的連線方式，再設定必要的路由排除。不要直接複製排除所有私有位址的清單，因為有些服務確實需要經過核心；排除範圍應符合實際網段，並避免讓遠端服務誤走區域網路出口。

管理 Fake-IP 映射與相容性例外

Fake-IP 回傳的虛擬位址不是節點位址，也不是真正的伺服器位址。應用程式將連線送往該位址後，核心會依據映射還原網域。切換設定或重新啟動核心後，如果系統仍快取舊的虛擬位址，而核心映射已經變更，可能會短暫連線失敗。建議先清除相關快取並重新建立連線，再考慮是否需要將映射持久化。

fake-ip-filter 會讓符合條件的網域改用真實位址解析，適用於確實需要真實位址的區域網路探索或特定應用程式。不要為了疑難排解一次加入涵蓋整個網際網路的大範圍篩選條件，否則會失去 Fake-IP 的網域關聯能力。套用篩選後仍須確認真實位址是否正確、存取規則是否合理；篩選本身無法修復無法連線的伺服器。

要確認接管是否成功，應在連線頁面看到測試應用程式的新連線，並確認命中的規則與出口；只看到 TUN 開關已啟用並不足夠。關閉 TUN 後，也要確認網路是否恢復，以及系統是否還留有手動代理設定。安裝與權限問題可先回到教學；需要更換用戶端時，請在下載中心選擇對應平台，不要同時執行多個代理入口來比較。

網域嗅探與規則命中

了解嗅探能補足哪些資訊

有些連線進入核心時只帶有目標 IP，缺少可直接用於網域規則的資訊。網域嗅探會嘗試從協定交握或請求內容擷取主機名稱，例如 HTTP 的 Host、TLS 交握中可見的伺服器名稱，或受支援的 QUIC 交握資訊。嗅探補足的是路由線索，不會解密加密網頁內容，也不能保證每條連線都能識別出網域。

Fake-IP 映射完整時，核心通常已知道對應網域，嗅探的作用可能不大。應用程式自行解析、直接使用真實 IP，或 DNS 查詢未經過核心時，嗅探才較可能改善網域規則的命中率。請先確認資訊在哪個步驟遺失，再決定是否啟用；連線路徑已穩定時，不必為了讓設定看起來完整而增加額外判斷。

限制協定與連接埠範圍

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

範例將範圍限制在常見的網頁連接埠。parse-pure-ip 允許對純 IP 目標嘗試嗅探，force-dns-mapping 用於擴大部分 DNS 映射情境下的嗅探處理範圍；兩者都不會憑空產生應用程式未傳送的主機名稱。連接埠範圍越廣，需要判斷的流量就越多，非網頁協定被誤判為候選對象的機率也越高。

override-destination 決定是否使用嗅探結果改寫連線目標，而不只是補充比對資訊。改寫可能觸發新的網域解析，導致連線到與應用程式原先選擇不同的位址。依賴特定入口、位址親和性或區域網路解析的服務，應謹慎評估這項變更；初次測試可先保持關閉，觀察路由資訊是否已足夠。

為相容性問題設定精確例外

skip-domain 用於略過已知不適合嗅探的網域。範例中的後綴僅用來說明格式，實際設定應填入發生問題的服務。新增例外前，先比較啟用與停用嗅探時的連線日誌、目標位址和規則。只有能穩定重現的差異才適合設為長期例外，否則可能把暫時的線路問題固定成不必要的設定。

若應用程式使用固定 IP，且交握中不含網域，網域規則便缺乏可靠依據。此時可考慮明確設定 IP 規則，或在用戶端與平台支援的範圍內使用程序規則。不要為了讓某條網域規則命中而虛構映射；同一個位址可能承載多項服務，反向解析得到的名稱也不等於應用程式實際存取的主機名稱。

加密客戶端問候等技術可能減少可見的交握資訊，非標準協定也可能無法識別。QUIC 能否正確解析，還取決於核心能力與實際交握結構。嗅探未能取得網域不一定是設定錯誤；應回頭檢查流量入口與 DNS 路徑，判斷是否該讓應用程式的查詢先經過核心，而不是不斷擴大嗅探連接埠範圍。

使用同一條連線驗證規則變更

進行對照測試前，先關閉測試應用程式的既有連線，再開啟單一目標頁面。在連線詳細資訊中記錄原始目標、識別出的網域、命中規則與最終出口。接著只變更嗅探開關或單一參數，再重複相同步驟。舊的長連線不會自動重新交握，直接重新整理頁面有時仍會沿用原連線，因此測試結果看起來可能沒有變化。

網域嗅探與規則優先順序是兩個不同問題。即使已識別出正確網域，前面較早命中的位址規則或程序規則仍可能先決定出口。結果不如預期時，請先查看實際命中的規則，再調整順序。在全域模式下看到代理連線，也不能證明特定網域規則已生效。

若啟用後只有少數應用程式的首個封包變慢，請檢查嗅探範圍是否太廣、目標協定是否受支援，以及是否啟用了不必要的目標改寫。不要立即歸因於節點品質。可先將範圍縮小至單一協定與連接埠，保留最小重現案例，再閱讀日誌頁常見錯誤，區分交握失敗、解析失敗與連線逾時。

本機覆寫與多訂閱合併

保留訂閱原始內容，釐清最終生效設定

訂閱是外部輸入，用戶端儲存的 Profile 是設定容器，而核心讀取的是最終生效設定。三者可能不完全相同：用戶端可能額外套用連接埠設定、TUN 選項與本機覆寫，也可能在重新載入時重新產生檔案。直接修改快取中的訂閱原始內容，通常無法保留到下次更新，因此不適合作為長期維護方式。

先在設定頁確認目前啟用的是哪一份 Profile，再查看用戶端是否提供覆寫、擴充或設定編輯功能。不同用戶端對功能入口名稱與合併方式的處理各不相同；FlClash 請以目前介面及實際產生的結果為準。若介面沒有對應功能，可維護獨立的本機完整設定，不要假設任意 YAML 片段都會自動合併。

本機覆寫適合儲存個人規則、DNS 偏好與控制器限制；訂閱提供者則繼續管理節點資訊。將兩者分開後，更新線路不必重寫個人規則，更換裝置時也能清楚辨認哪些內容屬於自己的環境。基礎概念請參閱Profile 與多設定管理；首次匯入訂閱仍請依照教學步驟操作。

分別處理映射、清單與引用

YAML 映射與清單不能用同一種方式理解。映射可能逐一合併欄位，也可能整個物件被取代；清單則可能附加、插入前方或完全覆蓋，實際情況取決於用戶端的覆寫機制。尤其是 rules，若新規則附加在既有的 MATCH 之後，通常不會命中。完成片段後，務必檢查最終順序，而不只是確認編輯器已成功儲存。

以下核心欄位可用來記錄選擇與映射狀態，但是否由用戶端管理，以及切換設定後是否沿用，仍須依實際行為確認。這些欄位不是合併多份訂閱內容的指令，也無法修正重名節點。在工作網路與家庭網路等環境差異較大的情境中，保留獨立 Profile 通常比不斷疊加條件更容易維護。

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

若要將不同來源的節點放進同一套策略組，可使用 proxy-providers，但來源必須提供核心支援的代理提供者格式。完整的 Clash 設定、一般節點連結清單與其他訂閱格式，不一定能直接作為提供者檔案。請先檢查內容結構，確認它是以 proxies 為主體的有效節點集合。

透過代理提供者整合多個來源

proxy-providers:
  線路甲：
    type: http
    url: https://example.com/provider-a.yaml
    path: ./providers/a.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

  線路乙：
    type: http
    url: https://example.com/provider-b.yaml
    path: ./providers/b.yaml
    interval: 3600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 整合選擇
    type: select
    use:
      - 線路甲
      - 線路乙

rules:
  - MATCH,整合選擇

範例網址須替換成實際提供者的網址，兩個快取路徑也必須不同。不要將訂閱憑證放進公開截圖、部落格或共用儲存庫。實際設定備份也應視為敏感檔案，因為其中可能同時包含節點密碼、訂閱連結與控制器密碼。提交疑難排解資料時，只保留結構與已去識別化的範例值。

多個來源容易出現同名節點。名稱不只用於介面顯示，也可能影響持續性選擇與規則引用；名稱重複會讓判斷變得模糊。若目前核心支援提供者名稱覆寫，可依文件為來源加上前綴；若不支援，請在可控的資料處理流程中重新命名，或分開使用。不要用簡單文字取代來修改整份 YAML，以免同時破壞規則目標與組名。

建立可還原的更新流程

更新前保留上一份可用設定與本機覆寫；更新後依序確認提供者載入、組別成員、規則順序與 DNS 設定。必要時可使用核心的設定測試功能檢查語法，例如在對應的執行檔目錄中執行 mihomo -t -f ./config.yaml。這只能證明設定可成功解析，不能證明節點可連線或規則符合實際需求。

重新載入後，先建立一條新連線，確認出口符合預期，再恢復其他應用程式的工作。若失敗，先撤銷最近新增的一層覆寫，不要立刻刪除所有 Profile。疑難排解紀錄應列出原始設定、修改片段、最終產生的結果與錯誤日誌。逐層還原比反覆重新匯入訂閱更容易找出問題，也能保留已驗證有效的個人設定。

外部控制面板與維護流程

區分代理入口與管理入口

mixed-port 等代理連接埠負責接收服務連線，external-controller 則負責管理介面。控制面板透過管理介面讀取連線、切換策略組或調整執行狀態，本身不是新的代理節點。開啟允許區域網路連線的代理選項，不代表管理介面也應對外開放；兩者必須分別評估。

桌面用戶端通常已使用內部控制介面管理核心。手動修改監聽位址、連接埠或密碼，可能導致用戶端介面無法連回自己的核心。請先確認用戶端是否允許自訂這些欄位，以及啟動時是否會重新產生設定。若介面顯示已中斷，但服務仍可使用，應優先檢查控制介面，不要立刻認定代理核心已停止。

預設只監聽本機

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

此處的密碼僅供教學示範，實際使用時必須換成獨立且高強度的密碼。external-ui 指向已準備好的面板靜態檔案目錄，填入路徑不會自動產生頁面。相對目錄會依核心工作目錄解析；用戶端沙箱、服務執行帳戶與檔案權限都可能影響讀取。設定後先確認本機介面可連線，再檢查面板檔案。

若不需要網頁面板，可以省略 external-ui，繼續使用用戶端內建的管理方式。確實需要面板時，請使用與目前核心介面相容的靜態資源，並透過可信管道取得檔案。不要因面板顯示欄位缺失，就任意開放更多監聽位址；請先判斷問題出在面板相容性、介面驗證，還是核心回傳內容。

檢查瀏覽器連線與驗證

面板可以開啟，只代表靜態頁面可供存取，不代表已成功連上控制介面。請分別檢查 API 位址、密碼與事件連線。瀏覽器開發者工具顯示連線遭拒，通常指向連接埠或監聽設定問題；驗證失敗則應檢查密碼；若頁面來自不同來源，也可能受到跨來源政策限制。不同錯誤需要在不同位置修正。

HTTPS 頁面要求 HTTP 控制介面時，瀏覽器可能以混合內容為由封鎖，即使兩端網路實際可連線也一樣。跨來源許可也不應設為允許任意網站攜帶憑證存取；請先確認面板的部署來源，再依核心支援的設定採用最小權限授權。密碼不應放在公開連結的查詢參數中，以免留在瀏覽器歷史、截圖或存取日誌裡。

遠端管理時，優先透過受控的本機轉送或可信網路存取本機介面。若必須監聽區域網路，請搭配防火牆限制來源位址，並確認網路環境是否可信。不要直接將控制連接埠映射到公用網路。控制介面可以變更策略，甚至影響既有連線；其權限遠高於唯讀狀態頁面，不應當成一般展示連接埠處理。

從唯讀資訊開始疑難排解

首次連上面板後，先查看執行模式、策略組與連線紀錄，不要馬上修改全域設定。比對用戶端介面，確認兩者管理的是同一個核心執行個體。若同一台電腦上同時執行獨立的 mihomo 與桌面用戶端，不同連接埠的執行個體可能使用完全不同的設定；面板顯示切換成功卻不影響實際服務，往往是連錯執行個體。

可將疑難排解順序固定為：確認核心正在執行、確認介面正在監聽、確認驗證成功、透過面板讀取設定，再觀察新連線。每個步驟只處理目前這一層的問題。若服務連線正常但面板空白，請檢查靜態資源與瀏覽器；若面板正常但服務失敗，則回頭檢查代理入口、規則、DNS 與節點，不要以管理介面的狀態取代實際連線測試。

整理長期維護與復原清單

每次重大調整都應保留變更紀錄：修改了哪些欄位、對應什麼現象、如何驗證，以及如何還原。備份主要設定時，也要記錄本機規則目錄、提供者快取路徑與由用戶端管理的覆寫內容。遷移後先恢復最基本的可用連線，再逐項恢復 TUN、DNS 策略與控制面板，避免連同舊系統的路徑和權限問題一起搬過去。

用戶端更新與核心更新不一定會同步。遇到未知欄位、設定測試失敗或面板功能不一致時，請確認目前實際執行的核心支援哪些功能，不要只憑介面外觀推斷。需要重新選擇用戶端時，請前往下載中心查看各平台的下載入口；若要從頭恢復連線，請回到訂閱匯入與連線教學，先完成基本步驟，再逐章恢復本頁的進階設定。