Clash 進階設定指南

CHAPTER 01

策略組類型與實戰

策略組位於規則與代理節點之間。規則的最後一個參數通常不是具體節點，而是策略組名稱；策略組再決定請求要走哪個節點、自動測速組或直接連線出口。排查「規則明明命中但出口不對」時，先查看記錄中的規則名稱，再開啟對應策略組確認目前選項。修改規則不會自動改變手動選擇組的狀態，切換節點也不會改寫規則，因此這兩個動作必須分開驗證。

select、url-test、fallback 與 load-balance 的差異

select 是手動選擇組，適合「代理選擇」、「串流媒體」、「下載」等需要固定出口的情境。它可以包含具體節點，也可以包含其他策略組。將自動測速組放入手動組後，平時選擇自動組，需要固定地區時再改選某個地區組，層級清楚且方便還原。不要把幾十個節點直接平鋪到每一條業務策略中，否則節點名稱變更後，多處引用會一起失效。

url-test 會定期存取測試網址，並從候選節點中選擇測試結果較佳者。它測量的是指定網址的連線表現，不代表所有網站與大檔案傳輸都相同。interval 控制測試間隔，設定過短會增加背景請求；tolerance 用於抑制小幅波動造成的頻繁切換。只要目前節點仍可用，且與最佳結果的差距未超過容許值，通常繼續使用目前節點會更穩定。

fallback 更重視可用性排序。候選清單前方的節點恢復後，策略組會傾向回到前方項目，適合主備出口明確的情境。load-balance 則將連線分配給多個節點，適合能接受出口變動的並行請求。需要登入狀態、地區一致性或對風控敏感的網站，不適合任意使用負載平衡，因為同一業務的不同連線可能出現不同出口。

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

  - name: 自動選擇
    type: url-test
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

  - name: 故障轉移
    type: fallback
    include-all: true
    url: https://www.gstatic.com/generate_204
    interval: 600
    lazy: true

使用過濾條件控制候選節點

訂閱節點很多時，應在自動組或地區組內使用過濾條件，而不是手動複製節點名稱。支援相關欄位的核心可以透過 include-all 納入節點，再用 filter 比對名稱，並以 exclude-filter 排除倍率、測試或不希望參與的項目。過濾表達式依節點名稱運作，訂閱提供者改名後可能導致候選清單為空，因此每次更新訂閱後都要開啟策略組，確認至少存在一個可用成員。

策略組可以引用其他組，但不要形成循環。例如「代理選擇」包含「自動選擇」是正常結構；如果「自動選擇」又把「代理選擇」列為候選，核心就無法得到確定出口。組名也必須與規則末尾完全一致，空格、大小寫與全形字元都算差異。遇到設定載入失敗時，先搜尋是否有重複的同名組，再檢查規則引用的組是否確實存在。

CHAPTER 02

規則集訂閱化管理

規則數量增加後，將所有項目堆在主設定中會造成三個問題：訂閱更新時本地修改容易被覆蓋、規則來源無法單獨更新，排錯時也難以判斷是哪一組規則命中。rule-providers 將規則內容拆成獨立集合，主設定只保留來源、儲存路徑、更新間隔與引用順序。如此即可分別維護廣告、區域網路、直連區域與代理服務規則，但最終比對順序仍由主設定中的 rules 決定。

behavior 決定規則檔案的內容形式

domain 類型用於純網域集合，規則檔案的 payload 通常填寫網域、後綴或萬用字元表達式；ipcidr 用於 IP 網段；classical 可容納包含類型的完整規則，例如 DOMAIN-SUFFIX、PROCESS-NAME 與 IP-CIDR。選擇錯誤時，檔案即使下載成功也可能無法解析。先查看規則來源內容，再決定 behavior，不要只靠檔名猜測。

type: http 表示遠端更新，url 是來源網址，path 是本地快取位置，interval 是更新週期。不同 provider 必須使用不同路徑，否則後下載的檔案會覆蓋前一個。遠端更新失敗時，核心通常會繼續使用既有快取；首次啟動時若沒有快取且遠端網址無法連線，對應規則集就無法載入，因此關鍵的區域網路規則可以保留少量內嵌項目作為啟動保障。

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

  service-proxy:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/service-proxy.yaml
    url: https://example.com/rules/service-proxy.yaml
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-proxy,代理選擇
  - GEOIP,CN,DIRECT
  - MATCH,代理選擇

範例網址用於說明欄位結構，部署時應替換為實際維護的規則來源。規則檔案使用 YAML 時，domain provider 可以寫成：

payload:
  - localhost
  - "*.lan"
  - "+.example.internal"

排序比規則數量更重要

Clash 規則會由上到下檢查，首次命中後即停止。精確的業務規則應放在廣泛的區域規則之前，區域網路與保留位址應放在預設代理之前，MATCH 必須放在最後。若先寫 GEOIP,CN,DIRECT，再寫某個依賴 IP 判斷的代理規則，前一條可能提前攔截請求。若先寫寬泛的網域後綴，再寫同一主網域下的特殊子網域，後者也不會執行。

處理規則衝突的方法不是繼續增加例外，而是先記錄請求實際命中的項目。客戶端記錄或外部控制面板通常會顯示規則類型、規則內容與目標策略。確認命中錯誤後，將更具體的規則移到更前面的位置。只有在無法取得網域、連線只剩 IP，或應用程式繞過系統解析時，才考慮增加 IP 類規則；任意堆疊網域與 IP 規則會讓結果難以預測。

no-resolve 適用於不希望為了比對 IP 規則而額外觸發 DNS 解析的情境。例如 GEOIP,CN,DIRECT,no-resolve 只會在目標 IP 已可用時進行判斷。它能減少額外查詢，但若目前連線只有網域，這條規則不會主動解析後再比對。使用前應先確認請求在規則階段是網域還是 IP，不能把 no-resolve 當成通用的效能選項。

更新失敗與規則未生效要分開處理

provider 下載失敗屬於來源層問題：先用直連網路確認網址可存取，再檢查 URL、回應格式與快取目錄權限。下載成功但未命中屬於引用層問題：檢查 rules 中是否存在對應的 RULE-SET、策略組名稱是否正確，以及更前面的規則是否提前命中。檔案解析失敗則屬於格式層問題：重點檢查 behavior、format、YAML 縮排與 payload 層級。

規則更新後應重新載入一次設定，再用固定網域測試。不要同時用多個網站驗證，因為瀏覽器背景請求、QUIC 與快取會混入記錄。選定一個目標，清除連線記錄，發起一次存取，確認網域、命中規則與最終策略三者一致。規則基礎概念可搭配術語手冊核對；若遇到節點全部逾時，應改查節點逾時排查順序，不要繼續反覆修改規則集。

CHAPTER 03

DNS 設定最佳化

DNS 問題常被誤判為節點問題。瀏覽器顯示連線失敗時，可能是網域未解析、解析結果被錯誤快取、查詢沒有進入 Clash，或規則階段取得不到原始網域。診斷時先區分「由誰處理 DNS 查詢」與「解析結果如何用於連線」。系統 DNS、客戶端內建 DNS、瀏覽器加密 DNS 與應用程式自帶解析可以同時存在；只有確認查詢路徑後，設定項目才有意義。

先了解 nameserver、default-nameserver 與 fallback

nameserver 是主要解析上游。它可以使用一般 UDP/TCP DNS，也可以使用 DoH 或 DoT。default-nameserver 主要用於解析加密 DNS 上游本身的網域，通常應填寫可直接連線的 IP 位址，避免出現「為了連線到 DoH，先解析 DoH 網域，而解析又依賴 DoH」的循環。它不是所有業務查詢的預設出口，也不應填入大量位址。

fallback 與過濾設定用於在不同解析結果之間進行選擇。此機制設定較複雜，若沒有明確的污染或分區解析需求，可以先只使用穩定的 nameserver，確認基本解析正常後再加入 fallback。增加上游不等於更快；並行查詢可能讓記錄更混亂，也可能在不同結果間產生快取差異。優先維持兩到三個職責明確的上游。

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.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - localhost.ptlogin2.qq.com
    - time.*.com
    - time.*.gov

proxy-server-nameserver 用於解析代理伺服器本身的網域。節點位址若寫成網域，必須先取得節點 IP，之後才能建立代理連線。若這類查詢錯誤地依賴尚未建立的代理，就會形成啟動死結：代理必須先連線，而連線又必須先透過代理解析。將節點網域解析交給可直接連線的上游，就能把業務 DNS 與節點 DNS 分開。

Fake-IP 與 redir-host 的選擇

fake-ip 不會立即將網域解析為真實目標 IP，而是回傳保留位址池中的對映位址。應用程式連線到該位址後，核心會從對映表還原網域，再依網域規則處理。它通常能保留更完整的網域資訊，並減少真實 DNS 結果過早暴露給應用程式。代價是部分區域網路探索、裝置投放、時間同步、遊戲與依賴真實 IP 驗證的程式不相容，需要透過 fake-ip-filter 排除。

redir-host 回傳真實解析結果，相容路徑更接近傳統代理，但規則階段可能更依賴 DNS 結果與嗅探。選擇模式時不要只看「能否開啟網頁」，也應同時驗證區域網路裝置、系統時間、常用通訊軟體與需要地區判定的服務。若只有某一類網域異常，優先將該網域加入過濾清單，而不是立即把全域模式切回 redir-host。

IPv6 開關需要搭配本地網路判斷

ipv6: false 會抑制 AAAA 結果，適合本地 IPv6 不完整、節點不支援 IPv6，或經常出現 IPv6 優先但連線失敗的環境。若本地與出口都具備穩定 IPv6，啟用後應分別檢查 A、AAAA 查詢與實際出口。只在系統中關閉 IPv6，卻讓 Clash 回傳 AAAA，應用程式仍可能先嘗試無法連線的位址；反過來，網路具備 IPv6 但 DNS 禁止 AAAA，則不會使用 IPv6。

判斷 DNS 洩漏不能只看一個檢測網站。先確認系統 DNS 是否指向客戶端監聽位址，再檢查瀏覽器是否啟用獨立的安全 DNS，最後觀察查詢記錄是否進入核心。瀏覽器 DoH 可能繞過系統 DNS，但連線流量仍經過代理；這表示查詢路徑不同，不等於所有流量都直連。需要統一控制時，應在瀏覽器中關閉獨立解析，或讓其上游也由規則正確處理。

依現象定位 DNS 故障

「網域無法開啟但直接存取 IP 可以」時，優先檢查解析上游與監聽埠；「首次開啟很慢，重新整理後正常」時，檢查上游連線、快取與 IPv6 逾時；「部分區域網路裝置找不到」時，檢查 Fake-IP 過濾；「記錄只顯示 IP，網域規則未命中」時，檢查應用程式是否繞過 DNS、是否啟用嗅探，以及透明代理是否擷取到對應連線。修改後清除系統與瀏覽器 DNS 快取，再重新啟動目標應用程式，避免舊連線干擾結果。

CHAPTER 04

TUN 與 Fake-IP

系統代理只會影響主動讀取代理設定的應用程式。命令列程式、部分遊戲、虛擬機器與自帶網路堆疊的軟體可能完全忽略它。TUN 模式會在系統中建立虛擬網路介面，透過路由將更多 TCP、UDP 流量交給核心處理，因此適合需要透明接管的情境。TUN 解決的是流量入口問題，Fake-IP 解決的是網域對映問題，兩者經常搭配使用，但不是同一個開關。

設定前先排除路由衝突

啟動 TUN 需要建立虛擬介面、寫入路由並接管 DNS，通常需要系統授權。若客戶端介面顯示 TUN 已啟用，但目標應用程式仍直連，先檢查虛擬介面是否存在，再確認預設路由與排除路由是否生效。VPN、虛擬機器、容器、遊戲加速器與其他代理軟體都可能同時修改路由。排查時先退出同類工具，只保留一個流量接管程式。

auto-route 讓核心自動設定路由，適合桌面端一般使用；auto-detect-interface 用於識別實際出站網卡，避免代理流量再次進入 TUN 形成迴圈。網路從有線切換到無線、從家用網路切換到熱點後，舊介面資訊可能失效。若切換網路後突然全部逾時，先重新啟動 TUN 或客戶端，讓介面重新偵測，不要立即更換節點。

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

stack 決定 TUN 資料如何進入使用者態網路堆疊。mixed 通常用於兼顧 TCP 與 UDP 的一般桌面環境；若特定系統出現相容性問題，可以在客戶端支援範圍內比較其他堆疊，但每次只修改這一項。strict-route 會更嚴格限制流量路徑，有助於減少繞行，但也可能影響區域網路、虛擬網卡與多網卡環境。啟用後應立即測試閘道、區域網路裝置與常用服務。

DNS 劫持要與監聽設定相互對應

dns-hijack 會將經過 TUN 的一般 53 埠查詢交給內建 DNS。它無法直接解密應用程式自行發起的 DoH，也無法保證未經過 TUN 的查詢會被接管。設定了劫持但未啟用 dns.enable，或監聽位址衝突，可能表現為所有網域都失效。此時不要先修改規則，先確認 DNS 模組是否啟動、埠是否被其他服務佔用。

Fake-IP 位址池通常使用專用保留範圍。應用程式看到該位址後，連線必須繼續經過同一個核心，核心才能從對映表還原網域。如果 DNS 查詢由 Clash 回傳 Fake-IP，但後續連線繞過 TUN 或系統代理，應用程式會直接嘗試存取無法路由的保留位址，結果就是「能解析但連線失敗」。這類故障應檢查流量入口是否一致，而不是更換 DNS 上游。

MTU 與 UDP 是常見邊界

網頁可以開啟，但大檔案、圖片或部分 TLS 連線卡住時，需要考慮 MTU。虛擬介面封裝會增加額外負擔，而底層網路可能使用較小的有效 MTU。先觀察是否只在特定網路出現，再逐步降低 TUN 的 MTU 進行測試，不要一次降得過低。數值過低會增加分片與處理負擔，數值過高則可能遇到路徑中的黑洞。

遊戲、語音與 QUIC 依賴 UDP。TUN 擷取到 UDP 不代表節點協定與出口一定支援。檢查順序為：記錄中是否出現 UDP 連線、規則是否命中正確策略、所選節點是否支援 UDP、系統防火牆是否允許虛擬介面。瀏覽器頁面異常時，也可以暫時關閉 QUIC，比較 TCP 路徑是否正常；這一步用於定位，不應直接當成長期解決方案。

各平台的處理重點

Windows 重點查看驅動程式授權、系統服務與其他 VPN 虛擬網卡；macOS 重點查看網路延伸功能授權與系統網路服務順序；Linux 重點查看 TUN 裝置權限、策略路由、轉送與防火牆規則。Android 與 iOS 上的 Clash 類客戶端通常透過系統 VPN 介面接管流量，系統同時只允許一個主要 VPN 工作階段，啟用其他 VPN 後目前連線可能被取代。需要選擇適用的客戶端時，前往下載中心查看各平台清單，Clash Plus 為全平台首選。

CHAPTER 05

網域嗅探

當應用程式直接連線到 IP、使用快取結果，或 DNS 查詢沒有經過 Clash 時，規則階段可能只能看到目標 IP。網域嗅探會從連線初始資料中擷取主機名稱，例如 TLS 握手中的 SNI 或 HTTP 請求中的 Host，再將網域交給規則系統。它的作用是補足路由依據，不是解析所有加密內容，也不能保證每種協定都能還原網域。

什麼時候需要啟用嗅探

當記錄長期只顯示 IP，導致 DOMAIN、DOMAIN-SUFFIX 與網域規則集無法命中時，嗅探會有幫助。使用 Fake-IP 時，核心通常已掌握網域，嗅探的必要性會降低，但對繞過內建 DNS 的連線仍可能有幫助。不要為了「功能更完整」而無條件啟用所有連接埠，應先找出問題連線使用的協定與埠，再決定擷取範圍。

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

parse-pure-ip 允許對目標為純 IP 的連線嘗試擷取網域；force-dns-mapping 會結合既有 DNS 對映；override-destination 決定是否使用嗅探取得的網域取代原始目標。覆寫目標可以讓網域規則生效，但對某些使用固定 IP、憑證驗證或私有協定的應用程式可能產生副作用。建議先在協定分項中啟用覆寫，不要一開始就全域覆寫。

HTTP 嗅探依賴明文請求標頭，TLS 嗅探讀取握手階段可見的 SNI，QUIC 則受協定實作與加密握手影響。ECH 等機制可能隱藏傳統 SNI，使嗅探無法取得目標網域。這不是設定錯誤，而是連線中沒有可供擷取的明文識別資訊。此時應讓 DNS 查詢進入核心，或使用明確的 IP、程序與規則集策略補足。

skip-domain 用於處理相容性問題

區域網路裝置探索、推播服務、系統連線檢測與某些遊戲可能不適合改寫目標。出現「關閉嗅探就正常，啟用後只有某個應用程式失敗」時，先從記錄確認嗅探取得的網域，再將具體網域加入 skip-domain。排除範圍應盡量小，避免使用過寬的頂級後綴，否則大量正常連線會失去網域規則能力。

部分客戶端會將嗅探選項放在圖形介面的覆寫設定中，訂閱更新時不會改變；另一些客戶端則直接讀取設定檔。排查前請確認最終生效設定，而不是只看訂閱原文。若客戶端介面提供「執行設定」或「目前設定」的檢視入口，應以該內容為準。本地覆寫可能已修改 sniffer，手動編輯訂閱檔案卻不會有任何效果。

驗證嗅探是否真正參與路由

選擇一個記錄中只顯示 IP 的目標，清除現有連線後重新發起請求。依序記錄原始目標、嗅探網域、命中規則與最終策略。看到網域不代表規則一定使用了它；還要確認命中項目已從 IP 規則變成預期的網域規則。若網域正確但仍命中預設規則，檢查規則順序與後綴寫法。若嗅探網域錯誤，先關閉目標覆寫，再將該網域或應用程式加入排除清單。

程序規則可作為桌面端的補充，但不同作業系統對程序識別的支援與權限不同。程序名稱也可能因啟動器、子程序或沙盒而變化，因此不宜把所有業務都綁定到程序。穩定的分流通常以網域規則為主，IP 與程序規則則用來涵蓋無法取得網域的少數連線。

CHAPTER 06

本地覆寫與多訂閱合併

遠端訂閱適合提供節點與基礎策略，但不適合作為長期手動編輯區。客戶端更新訂閱時通常會重新產生設定，直接寫入訂閱檔案的 DNS、規則與策略組可能被覆蓋。本地覆寫的目的，是將「由上游負責更新的內容」與「本機長期保留的內容」分開。修改前先確認客戶端支援的是欄位覆寫、腳本處理、設定片段合併，還是完整設定託管；這些機制名稱相近，但合併順序各不相同。

先確認最終設定的產生順序

常見流程是：讀取遠端訂閱，解析節點與策略組，套用本地前置腳本或片段，再寫入執行設定。有些客戶端會將本地規則加到訂閱規則前面，有些則加到後面；有些會覆蓋同名鍵，有些則連接陣列。若不了解順序，新增規則可能落在 MATCH 之後，永遠不會命中；同名策略組也可能被整組取代，而不是只增加一個節點。

最可靠的檢查方式是比較三份內容：遠端訂閱原文、本地覆寫內容與客戶端最終執行設定。只查看編輯器中的片段無法證明已生效。每次修改後搜尋目標欄位，確認它在最終設定中只出現一次、層級正確且引用存在。特別注意 YAML 中陣列與物件的差異：rules、proxies 是有順序的清單，dns、tun 通常是鍵值物件，錯誤的合併策略會直接改變語意。

prepend-rules:
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - PROCESS-NAME,backup-client,DIRECT

append-proxies:
  - name: 本地出口
    type: socks5
    server: 127.0.0.1
    port: 1081

override:
  ipv6: false
  log-level: info

上例表達的是常見覆寫意圖，不同客戶端對片段檔案的欄位名稱並不統一，應以客戶端實際說明為準。通用 Clash 設定中沒有 prepend-rules 這個頂層欄位，不能把覆寫工具的語法直接複製到 config.yaml。排查設定錯誤時，第一步就是區分「核心原生欄位」與「客戶端合併器欄位」。

多訂閱合併要先處理命名衝突

兩個訂閱可能同時包含「自動選擇」、「代理選擇」等策略組，也可能出現同名節點。直接拼接會導致名稱重複、引用錯位或後一份覆蓋前一份。合併前應為來源加上穩定前綴，例如依用途標記「辦公」、「備用」，再建立自己的上層策略組。上層規則只引用自建組，不直接依賴上游隨時可能改名的組，如此更新某個訂閱時就不會牽動所有規則。

節點名稱是引用鍵，也是過濾依據。同名節點來自不同訂閱時，即使伺服器不同，策略組中也很難區分。重新命名應在節點進入策略組前完成，並讓地區、用途與來源資訊保持簡短明確。不要把訂閱到期時間、剩餘流量等動態文字混入長期過濾條件，因為上游更新這些文字後，正則表達式可能產生意外比對。

proxy-groups:
  - name: 總出口
    type: select
    proxies:
      - 主要訂閱自動
      - 備用訂閱自動
      - DIRECT

  - name: 主要訂閱自動
    type: url-test
    use:
      - provider-main
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: 備用訂閱自動
    type: fallback
    use:
      - provider-backup
    url: https://www.gstatic.com/generate_204
    interval: 600

覆寫範圍越小，更新成本越低

長期覆寫建議只保留本機確實需要的內容：區域網路直連規則、DNS 選擇、TUN 參數、自建策略組與少量業務例外。不要複製整份上游設定再修改，因為這會失去訂閱更新帶來的節點變化。若必須維護完整設定，應明確將訂閱降級為節點 provider，只從中讀取代理節點，所有策略與規則則由本地設定負責。

合併失敗時分三個層次檢查。語法層檢查 YAML 縮排、清單符號與重複鍵；引用層檢查策略組、provider 與規則名稱是否存在；執行層檢查客戶端是否真的選用了產生後的設定。設定可以載入但節點為空，通常是 provider 或過濾問題；設定無法載入，優先檢查重複名稱與未知欄位；更新後本地設定消失，則是覆寫執行順序或儲存位置錯誤。

建立還原點比增加更多自動處理更重要。保留一份已驗證可用的基礎設定，記錄每個本地片段的用途，並在修改後執行重新載入測試。若客戶端更新或遷移裝置，先載入基礎設定確認核心與網路正常，再逐一恢復覆寫。不同平台客戶端可在下載中心選擇，首次遷移流程則參考使用指南。

CHAPTER 07

外部控制面板

外部控制介面用於讀取連線、記錄、規則與策略組狀態，也可以切換策略、關閉連線或重新載入設定。它是排錯工具，不是流量轉發入口。控制面板只是呼叫核心提供的 API，頁面本身不會取代核心，也不會自動修復設定。遇到介面顯示離線時，先確認控制位址與認證，再確認核心程序是否正在執行。

監聽位址決定暴露範圍

external-controller 指定控制介面的監聽位址。只在本機使用時，優先綁定 127.0.0.1；綁定 0.0.0.0 會讓同一網路中的其他裝置有機會存取該埠，必須搭配存取控制與防火牆。不要為了讓瀏覽器頁面連線成功就直接擴大監聽範圍。先確認面板與核心是否位於同一裝置，同一裝置使用回環位址最簡單。

external-controller: 127.0.0.1:9090
secret: "replace-with-a-long-random-string"
external-ui: ./ui
external-ui-name: dashboard
external-ui-url: https://example.com/dashboard.zip

secret 是控制介面的認證資訊，面板連線時需要填寫相同內容。修改後舊面板會立即失去存取權限，這是正常現象。認證失敗通常表現為介面可連線，但無法讀取策略或連線。不要將控制密鑰寫入公開頁面、截圖或共享設定；向他人提供診斷資訊時，應刪除控制位址、認證欄位、訂閱網址與節點憑證。

external-ui 指向本地靜態面板目錄，external-ui-url 可用於取得面板檔案。核心 API 與面板檔案是兩個部分：API 正常但頁面空白，可能是 UI 檔案路徑錯誤；頁面可以開啟但沒有資料，可能是控制位址、跨網域設定或認證錯誤。分開測試才能確定故障位於哪一層。

跨裝置存取需要額外限制

確實需要從區域網路中的另一台裝置存取時，可以將監聽位址改為區域網路可達的介面，並在系統防火牆中只允許可信網段存取該埠。路由器埠轉送與公開網路監聽會大幅增加風險，不應作為一般遠端管理方式。較穩妥的做法是透過受控的私有網路或本地通道存取回環介面，並保持認證啟用。

瀏覽器面板透過 HTTP 或 WebSocket 連線到控制介面。若面板使用 HTTPS，而控制介面是一般 HTTP，瀏覽器可能會攔截混合內容。此時應讓面板與 API 透過同一受控入口存取，而不是關閉瀏覽器安全限制。出現 WebSocket 反覆斷線時，還要檢查反向代理是否正確轉送升級標頭、系統休眠是否暫停核心，以及防火牆是否回收閒置連線。

利用面板按層檢查請求

連線清單至少要查看四項：目標網域或 IP、命中規則、策略鏈與最終節點。若網域為空，回到 DNS 與嗅探章節；若規則不正確，檢查規則順序；若策略鏈正確但最終節點異常，檢查策略組目前的選擇；若所有資訊都正確但連線失敗，再查看節點握手、UDP 支援與本地網路。依照這個順序，可避免看到「逾時」就直接更換所有設定。

規則頁面通常可以確認 provider 是否載入、規則數量是否存在，但不要用數量判斷品質。連線記錄更重要：選擇一個固定目標，關閉舊連線，再發起一次請求，觀察從網域到出口的完整路徑。日常定位使用 info 等級即可；只有需要查看握手與規則細節時，才暫時切換到 debug，完成後恢復，避免大量記錄掩蓋關鍵事件。

面板切換策略後，既有的長連線不一定會立即遷移到新節點。驗證出口時應關閉對應的舊連線，必要時重新啟動目標應用程式，再發起新請求。瀏覽器分頁、下載工作與即時通訊軟體會維持連線池，只看策略組介面已切換，不能證明目前請求使用了新出口。

建立可重複的綜合排錯路徑

當設定經過多次修改後，先匯出目前的執行設定與最近記錄。接著關閉 TUN，只保留系統代理，確認基本節點可以連線；再啟用 DNS，檢查固定網域解析；然後恢復規則集，確認規則命中；最後依序啟用 Fake-IP、嗅探與 TUN。每恢復一層都使用同一個測試目標。若某一步開始失敗，故障就在剛恢復的層，或該層與前一層的交界處。

如果只有個別節點逾時，依節點逾時無法連線的排查順序檢查；如果整體速度下降，參考速度慢分層排查，區分節點、線路與本地設定。設定檔載入失敗時，則回到語法與引用關係，不要把連線問題文章中的更換節點步驟套用到解析錯誤上。