Clash 進階設定指南

策略組類型與實務

策略組決定符合規則的連線最後使用哪個出口，但不負責接管系統流量，也不負責將網域解析為 IP 位址。排錯時，先確認連線是否進入核心，再查看命中的規則指向哪個策略組，最後檢查組內選取的成員。只在代理頁面切換出口，卻未確認規則目標，可能一直操作與目前連線無關的組。

先分清手動選擇與自動選擇

select 是手動選擇組，適合需要明確控制出口的情境；url-test 依探測結果自動選擇，適合對連線狀況變化較敏感的常用出口；fallback 依清單順序使用可用成員，重點在優先順序，而非每次都挑選最快的成員。三者差異在於選擇邏輯，並不代表能改善節點本身的線路品質。

load-balance 用於在多個出口間分配連線，不會將單次下載拆成多條線路來疊加頻寬。不同的分配策略可能影響同一服務所看到的來源 IP。若帳號服務需要維持工作階段，請先使用固定出口，或確認一致性分配符合需求；不宜將自動輪替視為適用所有網站的預設做法。

健康檢查會連線至組內設定的探測網址，但實際業務可能使用不同的網域、通訊協定與連接埠。探測成功只代表測試路徑可連線，不代表所有網站都能正常存取。探測頻率過高也會增加額外連線與行動裝置喚醒次數，請依使用環境設定，不要為了讓介面持續更新而把間隔縮得太短。

從容易理解的小型設定開始

以下範例中的組只引用內建的直連與拒絕策略，用來示範命名與引用關係，不會產生代理出口。載入設定後，可在代理頁面切換選項，再發起新的測試連線，觀察放行與拒絕的差異。確認理解這個流程後，再將現有訂閱中的實際節點名稱或下層組名稱加入清單；名稱必須完全一致。

proxy-groups:
  - name: 手動出口
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.com,手動出口
  - MATCH,DIRECT

實際使用時，可讓業務組指向自動選擇組，也可保留直連作為手動排錯入口。但組與組之間應形成單向引用，不能讓甲組包含乙組、乙組又包含甲組。節點重新命名後，規則與組成員中的舊名稱不會自動對應到新名稱；若載入設定失敗，請先檢查日誌是否指出目標不存在或引用循環。

如果成員來自 proxy-providers，策略組通常透過 use 引用提供者，而不是把提供者名稱當成節點寫進 proxies。提供者是節點集合的來源，策略組則負責從集合中選擇。將兩者分工清楚，更新訂閱時只需調整來源，業務規則仍可引用穩定的組名。

確認選取結果與連線生命週期

變更組內選項通常只會影響之後建立的連線。瀏覽器重複使用的連線、執行中的下載或長連線應用程式，可能仍會沿用舊出口。測試前請關閉相關連線，再重新發出請求；若需要中斷業務，請先儲存工作。不要只重新整理頁面就認定新出口已生效；連線頁面顯示的路徑，比網頁是否重新載入更具參考價值。

自動選擇組反覆切換時，先檢查成員是否過多、探測目標是否受到特殊處理，以及測試路徑是否受 DNS 影響，再考慮調整容差與間隔。每次只改一個因素，並記錄原始值與結果。如果所有成員都失敗，應優先檢查共同依賴項，例如本機網路、訂閱是否有效，以及節點網域能否解析，而不是繼續疊加自動選擇層級。

以規則集管理訂閱

規則集可將網域、IP 位址或傳統規則從主要設定中分離，適合管理經常變動的業務清單。主要設定只需保留來源定義、引用位置與出口選擇，內容更新則交由規則提供者處理。如此一來，新增網域時不必每次修改整份訂閱，也能清楚區分「比對條件變更」與「出口策略變更」。

分清規則內容、格式與引用方式

rule-providers 用來定義可讀取的規則來源，RULE-SET 才會將規則來源納入比對流程。只宣告提供者卻沒有引用，規則不會自動生效。規則中的目標仍須是已存在的策略組或內建策略。規則集本身通常不應綁定業務出口，否則同一份清單就難以在不同設定間重複使用。

behavior 描述內容類型：domain 用於網域清單，ipcidr 用於 IP 網段，classical 用於傳統規則表達式。format 則指定儲存格式。若將傳統規則檔案當成網域清單載入，即使檔案下載成功，也可能無法解析。選擇來源時，必須同時確認內容格式與行為類型。

以下範例使用本機傳統規則集，適合先確認檔案路徑與引用關係。範例中的相對路徑是以核心工作目錄為基準，不是網頁所在目錄，也不一定是安裝目錄。請在客戶端可管理且核心具有讀取權限的設定目錄中建立檔案，再從日誌確認載入位置。不同客戶端的工作目錄設定可能不同。

# 主要設定中的片段
rule-providers:
  work-sites:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/work-sites.yaml

rules:
  - RULE-SET,work-sites,DIRECT
  - MATCH,DIRECT

# ./rules/work-sites.yaml
payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,example.org

遠端更新需另外確認下載路徑

從本機檔案改用遠端規則來源時，請依來源文件設定 type: http、實際網址、快取路徑與更新間隔。不要把網頁介紹頁當成原始規則檔案網址；即使成功收到回應，若內容是 HTML，對核心而言仍是錯誤資料。請先用瀏覽器確認回應內容，再查看核心日誌中的下載與解析結果。

規則更新失敗與規則沒有命中是兩種不同問題。前者應檢查遠端網址、連線、解析結果與目錄寫入權限；後者則應確認檔案是否包含目標、引用是否存在，以及規則是否已被前面的項目攔截。網路連線失敗時，舊快取仍可能可用，因此「目前能正常分流」不代表最近一次更新成功。

更新間隔通常以秒為單位，請依來源更新頻率安排。靜態業務清單不必頻繁下載，過度頻繁的請求也可能觸發伺服器限流。不同提供者最好使用不同快取路徑，以免互相覆寫。變更來源網址前，請保留一份可用檔案；確認新內容可正常解析後，再移除舊設定，降低更新錯誤導致設定中斷的風險。

依首次命中原則安排規則順序

規則會依順序比對，較具體的業務例外通常應放在較廣泛的規則之前，兜底規則 MATCH 則放在最後。同一網域若出現在兩個規則集中，系統不會自動比較哪個集合更精確，而是由先命中的引用決定後續處理方式。因此，管理多份清單時，除了檢查重複內容，也要記錄各清單在主要規則列表中的優先順序。

IP 位址規則可能需要先解析網域才能取得可供比對的位址；no-resolve 可避免特定 IP 位址規則主動觸發這個步驟，但不會全域停用 DNS。若不加判斷地為所有 IP 位址規則加上這個參數，原本依賴解析結果的流量可能會落入兜底規則。請根據應用程式送入的是網域還是目標 IP，以及前置規則是否已命中來判斷。

驗證規則時，請選擇一個確定存在於集合中的測試網域，關閉舊連線後重新存取，並查看連線頁面的比對類型與目標。如果日誌沒有載入錯誤，連線卻總是落入兜底規則，請進一步確認應用程式是否使用獨立 DNS、直接連線 IP 位址，或網域是否已被其他規則攔截。不要以「整個網站看起來正常」取代具體的連線紀錄。

DNS 設定最佳化

DNS 負責將網域解析為 IP 位址，但代理連線中的網域解析可能發生在不同位置。系統解析、瀏覽器加密 DNS、Mihomo 內建解析，以及代理伺服器端解析不能混為一談。排查 Clash DNS 洩漏或解析異常時，請先確認是哪個程式發出查詢、查詢送往何處，再判斷是否需要修改核心的 DNS 欄位。

分清業務解析與引導解析

nameserver 用來指定一般解析上游；若上游是以網域名稱表示，還需要有能解析該上游的引導路徑。default-nameserver 主要用於這類引導需求，並非所有業務網域都必經的統一入口。若引導上游與代理出口互相依賴，啟動時可能形成循環：連線尚未建立，卻得先透過代理解析。

proxy-server-nameserver 可單獨處理代理節點的網域解析，避免節點連線又依賴自身才能完成解析。nameserver-policy 則依比對條件指定業務網域的上游，適合內網、企業服務等需要特定解析結果的情境。不同欄位解決的問題不同，不要為了多加「備援」而將所有伺服器重複填入每個清單。

以下片段會啟用 Fake-IP，並使用加密上游處理一般查詢。這裡示範的是欄位組織方式，不保證所有網路環境都能連線。使用前請確認這些上游符合所在地的網路條件；若客戶端已產生 DNS 設定，請將片段合併到現有對應設定中，避免重複的頂層 dns 鍵造成覆寫歧義。

dns:
  enable: true
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://cloudflare-dns.com/dns-query

確保解析路徑與連線路徑都能釐清

加密 DNS 能保護查詢傳輸過程，但不會自動讓查詢經過代理，也不保證解析結果適合目前的連線出口。直連業務可能需要本機可連線的位址，代理業務則可能由出口端解析網域。若部分網站已解析出 IP 卻無法連線，應一併檢查解析結果、規則去向與實際出口，不要只看上游名稱就認定設定正確。

若要讓 DNS 連線遵循路由規則，可研究 respect-rules；但啟用前應先準備獨立的節點網域解析路徑，並確認 DNS 上游本身會套用哪些規則。否則 DNS 查詢需要代理，而代理節點網域又需要同一個查詢才能解析，設定在啟動階段就會失去可用出口。

企業網域與區域網路網域尤其需要謹慎處理。公共解析器不一定能解析內部位址，任意更換系統 DNS 可能導致辦公室應用程式失效。請先確認內部網域後綴、指定解析伺服器，以及連線至該伺服器所需的路由，再透過策略限制適用範圍。不要將所有網域都送往只服務內網的伺服器，也不要不慎將內部查詢交給外部上游。

從快取、來源與位址族別逐層排查

修改 DNS 後，請分別考量應用程式快取、系統快取與核心快取。瀏覽器若仍沿用既有連線，即使清除系統快取也未必會重新查詢。請先關閉目標連線，必要時重新啟動測試應用程式，再觀察日誌。命令列查詢只能證明該工具使用的解析路徑，不能直接推論瀏覽器、遊戲或其他應用程式也走同一條路徑。

ipv6: false 在此控制核心 DNS 的相關回應行為，不等同於停用作業系統的所有 IPv6，也不代表所有應用程式都不再嘗試使用 IPv6。若網路支援 IPv6，請明確確認是否要接管相關流量；若只有部分位址族連線失敗，應比較同一網域的解析結果與路由，不要將停用通訊協定當成通用的長期解法。

檢查是否有 DNS 洩漏前，應先明確定義預期行為：哪些應用程式必須交由核心解析、哪些內網查詢應保留本機路徑，以及瀏覽器是否允許使用獨立加密 DNS。偵測頁面顯示的解析服務名稱只能作為線索。更可靠的判斷方式是綜合系統 DNS 設定、應用程式設定、連線紀錄與必要的網路封包擷取，區分預期的直連查詢與意外繞送。

TUN 與 Fake-IP

TUN 透過虛擬網路介面接收流量，Fake-IP 則使用合成位址保留網域對應資訊，兩者用途不同。啟用 TUN 不代表所有 DNS 查詢都已進入核心，啟用 Fake-IP 也不代表所有應用程式都已被接管。設定時需一併檢查虛擬介面、系統路由、DNS 查詢路徑與規則比對；缺少任何一環，都可能造成部分正常的假象。

先規劃可還原的流量接管方式

系統代理適用於會遵循代理設定的應用程式；不讀取這項設定的程式可能需要 TUN。兩者不是必須同時啟用才能使用的固定組合。初次測試時請保留目前可用的方案，記錄系統原有的代理與 DNS 設定，再啟用服務模式與 TUN。若基本網路因此失效，請先關閉新增的接管設定，恢復連線後再分析日誌。

Clash Verge Rev 的 TUN 功能取決於服務權限與平台支援。Windows 上請確認服務正常、虛擬介面可建立，且安全軟體未加以阻擋；macOS 需完成相應權限授權；Linux 則要檢查執行權限、路由與防火牆環境。相同的 YAML 在不同系統上的路由實作不盡相同，不能只看開關已開啟就認定流量接管成功。

以下是常見的流量接管片段，DNS 部分需與上一章的既有設定合併。auto-route 請求核心設定路由，auto-detect-interface 用來自動偵測出口介面，dns-hijack 則將符合條件的傳統 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 回傳的合成位址是讓核心對應原始網域之用，並非網站的真實伺服器位址。應用程式接著連線至該位址時，核心可還原網域並套用網域規則。診斷工具顯示合成位址，不代表解析錯誤。真正需要確認的是後續連線是否由同一個核心接收，以及對應資料是否仍然存在。

若應用程式取得合成位址後繞過 TUN 直接連線，或裝置從休眠恢復後仍快取舊對應資料，就可能無法連線。此時應檢查路由與快取生命週期，不要立即將所有網域加入排除清單。只有確定需要真實位址、執行特殊連線測試或使用區域網路探索的應用程式，才依最小範圍設定 fake-ip-filter。

排除清單的作用會依篩選模式而異，新增項目前請先確認目前採用的語義。在一般排除模式下，符合條件的網域會回傳真實解析結果；切換至其他篩選模式後，清單的意義可能改變。不要混用不同教學中語義相反的設定片段。修改後請清除相關快取，並測試應用程式的實際工作流程。

處理多網卡、其他隧道與休眠恢復

在多網卡環境中，自動偵測可能選到與預期不同的預設出口。若辦公室網路、手機熱點與其他 VPN 同時啟用，請先確認哪條連線承載實體網路，哪條連線用來存取企業資源。路由設定不是開關越多就越完善；多套工具同時改寫預設路由與 DNS，反而容易造成連線循環或流量送往錯誤介面。

strict-route 可在特定平台收緊路由行為，但不應被當作初次設定時的萬用修復方式。它可能影響區域網路存取，以及與其他軟體的相容性。只有在確認一般自動路由會造成流量繞行，並了解相關系統實作後，才逐項測試。測試範圍應包含網頁、區域網路服務、企業應用程式與休眠喚醒。

DNS 劫持主要針對符合條件的傳統查詢，不會自動將應用程式內所有加密 DNS 轉成一般查詢。瀏覽器和應用程式使用自己的解析連線時，仍可能需要個別設定與規則處理。如果某個程式一直未出現在預期的紀錄中，請先檢查其網路權限、代理設定與獨立解析方式，不要持續增加 DNS 劫持項目。

若遇到「啟用 TUN 後無法上網」，請依序檢查核心是否啟動、服務是否可用、介面是否建立、預設路由是否合理、DNS 是否能回應，最後再檢查代理出口。與停用 TUN 時的狀態比較，有助於縮小問題範圍。不要同時更換節點、DNS、網路堆疊與規則來源，否則即使恢復連線，也無法判斷是哪項變更發揮作用。

網域嗅探

網域嗅探會嘗試從連線初期的通訊協定內容擷取主機名稱，為只有目標位址的連線補上網域資訊。這通常有助於網域規則比對，但它不是解密工具，也無法從所有連線還原網域。啟用前請先判斷缺少的是網域資訊、規則內容還是流量接管路徑，避免將無關的連線故障都歸咎於嗅探開關。

了解可識別資訊的限制

一般 HTTP 請求可能包含主機欄位，TLS 交握在某些情況下會提供伺服器名稱，QUIC 也有相應的辨識方式。可取得的資訊會受通訊協定、實作方式與加密機制影響；使用加密用戶端問候等機制時，原本可辨識的名稱可能不再直接可見。因此不能保證所有 HTTPS 連線都能還原出正確網域。

嗅探取得的名稱，也不一定能代表應用程式存取的所有業務服務。一個應用程式可能連線至多個服務網域，內容傳遞平台可能共用 IP 位址，連線重複使用也可能讓後續請求不再重新交握。請依個別連線檢查，不能以一次嗅探成功就推論該應用程式往後所有流量都會使用相同的業務策略組。

以下範例僅在明確指定的 HTTP 與 TLS 連接埠範圍內嘗試辨識，並保留原始目標，不強制改寫目的位址。建議先觀察辨識結果是否改善規則判斷，再決定是否擴大範圍。不同客戶端的介面選項與產生的設定可能有所差異；儲存後請檢查執行時設定，不要假設介面勾選就等於一段完整的 YAML。

sniffer:
  enable: true
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: false
    TLS:
      ports:
        - 443
        - 8443
      override-destination: false

分別測試網域辨識與目標改寫

override-destination 會決定是否以辨識出的網域取代連線目標，影響的不只是顯示名稱，也可能改變後續解析方式與實際連線路徑。有些服務要求使用原始位址、特定地區或專用入口，直接替換目標可能破壞原本正常的行為。請先使用保守設定驗證，再針對確有需要的範圍調整。

若應用程式本來就會透過代理通訊協定傳遞網域，或 Fake-IP 對應資訊已能提供網域，啟用嗅探未必有明顯好處。為各種通訊協定開放更大的連接埠範圍，可能增加處理負擔，也會讓排錯流程更複雜。網域資訊已完整時，採用有限範圍比追求所有通訊協定一律啟用更容易維護。

特定網站啟用嗅探後發生問題時，請先建立可重複的測試條件：使用相同出口、相同規則與新連線，比較啟用和停用時的目標、命中規則及錯誤類型。確認差異確實來自嗅探後，再考慮以 skip-domain 縮小例外範圍。不要為了掩蓋局部相容性問題，就將整個公用網域後綴加入略過清單。

搭配 DNS、規則與日誌交叉排查

如果連線紀錄中只有 IP 位址，請先確認連線是否使用預期的通訊協定與連接埠，再檢查應用程式是否沿用舊連線。嗅探通常仰賴連線建立初期的資訊；連線已建立後才啟用，不一定能還原既有連線的名稱。關閉目標連線並重新發出請求，比反覆切換開關更能建立明確的測試條件。

若畫面已顯示網域但出口仍不正確，請回頭檢查規則順序，而不是繼續擴大嗅探範圍。還原網域只能補足缺少的資訊，不能自動建立不存在的規則。若網域規則已命中但業務仍失敗，接著檢查所選節點、DNS 與目標連線狀況；請分別記錄「辨識成功」與「連線成功」這兩項結果。

QUIC 使用 UDP，排錯時還需確認出口與流量接管路徑支援相關流量。應用程式可能在失敗後改用其他通訊協定，造成有時能開啟、有時無法開啟的情況。不要為了證明嗅探有效就全域封鎖某種通訊協定；請先蒐集連線證據，再判斷需要通訊協定層級的策略、調整應用程式設定，或只為特定服務保留例外。

請依診斷需求暫時提高日誌層級，重現問題後恢復原設定。日誌與連線資訊可能包含存取網域、程序路徑及業務位址；分享截圖前，請先移除不必要的資訊。記錄設定差異時，只需保留欄位與錯誤類型，不必附上完整訂閱、節點驗證資訊或無關的存取紀錄。

本機覆寫與多重訂閱合併

訂閱提供遠端內容，本機覆寫則用來保留裝置與個人使用需求。直接編輯遠端訂閱檔案，下一次更新時可能會還原；直接修改執行時設定，也可能在客戶端重新產生設定時遺失。長期維護前，請先區分來源訂閱、覆寫輸入與執行時結果，並確認每項變更由哪個層級負責保存。

先確認覆寫入口與套用範圍

在 Clash Verge Rev 中，應透過訂閱關聯的擴充功能或全域擴充功能入口管理本機調整；介面名稱請以實際客戶端為準。全域覆寫適合裝置共用設定，訂閱層級覆寫則適合只套用於特定來源的業務例外。同一欄位若由兩個層級同時修改，請確認實際執行順序，不要只憑編輯器中最後儲存的位置判斷最終結果。

Merge 覆寫採用客戶端約定，不能將所有擴充欄位都視為 Mihomo 原生設定。以下的 prepend-rules 表示在相應的 Merge 機制中將規則加到前面；處理後應能在最終的 rules 中看到結果。若直接將它放進一般核心設定，不會自動套用相同的合併語義。

# 放入支援這些欄位的 Merge 覆寫入口
prepend-rules:
  - DOMAIN-SUFFIX,example.com,DIRECT

dns:
  ipv6: false

此範例只新增一條業務規則，並調整既有 DNS 對應中的欄位，並未定義完整的解析方案。儲存後請查看執行時設定，確認其他 DNS 上游沒有意外遺失，且前置規則位於預期位置。若客戶端的合併結果與預期不同，請先縮小範圍，單獨測試一個欄位，不要繼續在同一覆寫中加入更多設定。

清單與對應欄位的合併方式不同

YAML 對應可按鍵值理解，清單則涉及順序、重複項目與整份取代。規則清單的前置或後置位置會直接影響首次命中結果；若策略組清單遭到整份取代，遠端規則引用的組名可能就會消失。不同擴充機制處理清單的方式不盡相同，因此必須同時檢查最終設定與核心載入結果，才能確認「合併成功」。

若需要重新命名、去重、篩選或轉換結構，擴充腳本會很實用，但複雜度也較高。請先確認輸入物件與回傳物件的規範，並保留未修改的欄位。若只需要固定規則或單一布林設定，優先使用容易審閱的 Merge 片段，不必額外加入腳本。腳本能執行，不代表輸出結構符合核心要求。

訂閱更新後，請確認自訂組仍能引用相關成員。提供者可能重新命名或刪除節點，也可能調整組織結構；依賴特定節點名稱的本機覆寫因此可能失效。較穩妥的做法是讓業務規則引用穩定的本機組，再由組內管理來源變更；但仍需避免空組與名稱衝突，沒有一種設定能永久適用所有來源。

多重訂閱不等於直接合併多份檔案

客戶端清單中有多個訂閱，不代表它們預設會同時載入同一份執行設定。常見用法是選取其中一個作為目前設定；若需同時使用多個來源，可研究節點提供者或明確支援的彙整機制。請先確認客戶端是否支援這類輸入，再考慮合併；不要以為直接貼在一起的兩份完整 YAML 會自動協調。

合併多個來源時，至少要處理節點名稱重複、策略組名稱重複、規則優先順序與全域欄位衝突。若兩個來源都定義 DNS、監聽連接埠與兜底規則，就必須明確決定最終設定。實務上建議保留一份主要架構，讓其他來源只提供節點集合，再透過不同的提供者名稱引用；這比混合兩套完整業務規則更容易檢視。

遷移舊客戶端時，請先匯入訂閱並確認基本連線正常，再搬移連接埠、規則與 DNS，最後處理腳本邏輯。舊版 Parsers 的欄位與執行環境不能直接視為 Merge。可參考Clash for Windows 遷移指南逐項確認，不要將已失效的舊設定整份覆蓋到新客戶端。

每次修改後都保留一份本機差異紀錄，至少記下目的、適用範圍與還原方式。發生問題時，先停用新增的覆寫，再載入原訂閱驗證；確認恢復後，逐項重新啟用。備份檔案應存放在受控位置，訂閱網址與驗證資訊不應放進公開程式碼儲存庫；分享範例時只保留與結構相關的欄位。

外部控制面板

外部控制面板透過 Mihomo 控制介面讀取狀態、切換策略並執行部分管理操作。它與混合代理連接埠不同，也不是讓應用程式連上網路的入口。設定時應分開考量資料代理與管理存取：應用程式連線至代理連接埠，面板則連線至控制介面。將這兩種位址填錯，通常只會出現連線錯誤或無法解析的回應。

優先使用本機介面並設定明確驗證

external-controller 用來指定監聽位址；綁定 127.0.0.1 表示只接受本機 IPv4 迴環位址的連線。secret 用於介面驗證，請設定強度足夠且獨立的實際值。以下密碼僅供教學示範，不可直接用於部署；客戶端可能已代為管理這些欄位，覆寫前請確認內建介面是否依賴目前設定。

external-controller: 127.0.0.1:9090
secret: "your-password"

不要為了解決面板連線失敗，就直接將監聽位址改為所有網路介面並移除驗證。這會讓策略切換與執行狀態暴露在更大的網路範圍內。若確實需要跨裝置管理，請先建立受控的存取通道，並以防火牆限制來源；一般桌面使用者應保留本機管理，日常代理使用不需要開放遠端控制。

控制介面位址通常由通訊協定、主機與連接埠組成，面板中的驗證欄位必須與核心目前的設定一致。連接埠遭其他程式占用、核心尚未執行，或客戶端重新啟動後更新了驗證值，都可能讓面板中斷連線。排查時先檢查核心啟動日誌與監聽狀態，再確認面板是否保存了舊設定，避免將管理連線失敗誤判為代理線路故障。

分清面板檔案、介面與瀏覽器限制

external-ui 指向本機面板的靜態檔案目錄，不是任意網頁網址。目錄中必須有實際入口檔案與相關資源，且核心必須具備讀取權限。只填入目錄名稱不會自動產生面板。若客戶端內建介面已足以完成管理，可不必額外設定靜態面板，以減少檔案更新與介面暴露所需的維護工作。

使用獨立瀏覽器面板時，也可能遇到跨來源存取、混合內容或瀏覽器本機網路存取限制。HTTPS 網頁不一定能呼叫本機 HTTP 介面；這與密碼是否正確是兩種不同問題。請先確認瀏覽器錯誤屬於網路連線遭拒、跨來源攔截還是驗證失敗，不要為了碰運氣而全面放寬來源限制。

面板來源也是信任邊界。能讀取管理憑據的網頁可能會對介面發出操作，因此不要在不明網頁輸入控制密碼。若需要跨來源授權，請依所用核心支援的設定指定確切來源，並確認瀏覽器實際使用的通訊協定與連接埠。來源比對錯誤時，應修正具體設定，不要一次授權所有網站。

將暫時性控制與持久設定分開

面板變更的是目前執行狀態；部分設定可能由客戶端保存，也可能在重新載入設定後還原。需要長期保留的 DNS、規則與流量接管設定，應回到客戶端設定或覆寫入口管理。不要以為面板上的暫時變更已修改來源檔案；尤其在重新啟動、切換訂閱或自動更新後，應再次檢查結果。

分享截圖或匯出連線紀錄時，請留意網域、程序路徑、裝置位址與介面驗證資訊。故障回報通常只需要錯誤類型、相關欄位與重現步驟。可保留設定結構並移除實際業務內容；不要為了證明某條規則未命中就傳送完整訂閱檔案，也不要將控制介面開放給他人作為一般協助方式。

客戶端選型與核心設定需要分開評估。若要挑選跨平台客戶端，可先查看 Clash Plus，再依桌面覆寫需求比較 Clash Verge Rev 等客戶端；各客戶端的介面與擴充機制不盡相同，不能假設相同操作適用所有產品。安裝與平台資訊請統一參閱下載中心，既有設定則依目前核心的支援情況逐項遷移。

完整的排錯流程應能回答四個問題：流量是否進入核心、網域如何解析、規則為何命中，以及最後使用哪個出口。控制面板只提供觀察介面，不能取代這套推理順序。恢復穩定設定後，請將日誌層級調回日常設定、關閉暫時開放的管理入口，並保留已驗證的覆寫差異，方便下次更新後重新檢查。