Clash 策略組、DNS
與 TUN 進階設定

策略組類型與實戰

先分清節點、策略組與規則。節點描述實際的代理連線方式；策略組決定從哪些出口中選擇；規則則將連線交由特定策略組處理。直接在大量規則中填入節點名稱，短期容易理解，長期卻難以維護：節點改名後就得逐條修改。較穩妥的做法是讓規則指向用途固定的策略組，再於組內更換節點。設定中的名稱比對會區分字元，空格、大小寫及中文標點不同，都可能導致引用失效。

手動選擇、延遲測試與故障切換

select 是手動選擇策略組，適合作為主要出口或特定用途的出口；組內可放入節點，也可放入其他策略組。url-test 會定期測試指定網址的可用性與回應時間，再依測試結果選擇出口，適合節點條件相近的情況。fallback 著重候選順序：優先使用排在前面且可用的出口，失效時才切換至後面的出口。它不會依延遲重新排列節點，因此適合明確的主備線路，不能取代延遲測試組。

load-balance 會依設定的分配策略，將不同連線交由不同出口處理，不會把單一下載連線的速度相加。需要登入狀態、固定出口或地區一致性的服務，若出口頻繁變動，可能觸發額外驗證。先用手動組確認服務狀況，再考慮是否採用負載平衡。節點測速結果只代表探測網址的狀況，不能據此認定影片、程式碼儲存庫或遊戲連線一定更快；還應以實際服務進行第二次驗證。

建立可觀察的雙層結構

以下架構將人工選擇與自動探測分開。「訂閱節點」必須是現有 proxy-providers 中已定義的提供器，且至少包含一個可用節點。先將「手動選擇」交給自動組；若連線異常，再從控制面板切換至特定出口。請勿將同一段範例重複貼到檔案末尾；若已有 proxy-groups，應在其清單中新增項目，並保留同一個頂層鍵。

proxy-groups:
  - name: 自動選擇
    type: url-test
    use:
      - 訂閱節點
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

  - name: 手動選擇
    type: select
    proxies:
      - 自動選擇
      - DIRECT
    use:
      - 訂閱節點

interval 的單位是秒，代表探測間隔；tolerance 的單位是毫秒，用於減少小幅波動造成的切換。lazy 可在策略組未使用時減少不必要的探測，但實際探測也會受到提供器健康檢查設定影響。避免同時將策略組探測與訂閱健康檢查設得過於頻繁，尤其在行動網路上，持續探測會增加喚醒與流量消耗。先觀察故障是否真的需要縮短間隔。

檢查引用、迴圈與連線穩定性

策略組應維持單向巢狀關係，例如業務組指向主要出口，主要出口再指向自動組，自動組最後指向節點。不要讓兩個組互相引用，也不要讓組經由多層關係回到自身。排錯時，可從報錯的組沿引用逐層檢查：名稱是否存在、提供器是否已載入、篩選條件是否排除了所有節點。空組通常是上游節點遭到篩除，不一定是規則寫錯；反覆修改規則無法解決這類問題。

切換策略通常只會影響之後建立的連線，既有長連線不一定會立即切換。驗證時先關閉測試應用程式中的舊連線，再重新發出請求；必要時只清除相關連線，不必直接重新啟動整台裝置。登入型服務建議固定使用同一個業務組，避免測速結果波動造成出口反覆切換。若要了解規則與全域切換的差異，可參考三種代理模式說明；切換全域模式不能作為策略組設定正確的證明。

規則集訂閱管理

規則集可將經常更新的網域或網段清單從主要設定中分離。主要設定保留比對順序與出口名稱，規則檔則負責維護比對項目。如此一來，更新業務網域時不必反覆修改所有策略組，也更容易追蹤每次更新的差異。請留意，規則提供器與節點提供器是不同物件：前者只提供比對條件，不會產生可連線的代理節點；成功下載也不代表規則已加入主要規則清單。

選擇 behavior 與檔案格式

behavior: domain 用於網域清單，適合集中管理同類網站；ipcidr 用於 IP 網段；classical 則可包含網域後綴、關鍵字、IP 網段等傳統規則條件。選擇時應先確認來源檔案的實際內容，而非只看副檔名。檔案中的項目結構，以及提供器的 format 與 behavior 必須相符。若將帶有規則類型前綴的內容當成純網域清單讀取，可能會發生解析錯誤，也可能得到不符合預期的比對結果。

先用本機規則檔確認結構，再接入遠端更新，排錯會更容易。以下的 ./rules/work.yaml 是相對於核心工作目錄的路徑，不一定是圖形用戶端的安裝目錄。若用戶端以沙箱或服務模式執行，請透過用戶端提供的設定目錄入口確認路徑，並檢查核心是否有讀取權限。主要規則中的「手動選擇」沿用上一章的組名；若實際設定使用其他名稱，這裡也要一併調整。

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

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - RULE-SET,工作站點,手動選擇
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,手動選擇

# rules/work.yaml 檔案內容
payload:
  - DOMAIN-SUFFIX,github.com
  - DOMAIN-SUFFIX,githubusercontent.com
  - DOMAIN-SUFFIX,gitlab.com

先確認順序，再安排更新

規則通常由上往下比對，符合條件後便結束本次選擇。精確的例外規則應放在廣泛規則之前，兜底用的 MATCH 則放在最後；否則後續業務規則根本沒有執行機會。若同一網域同時出現在兩個規則集中，不會自動選擇較精確的一個，而是依引用順序決定。調整規則前，先在連線詳細資訊中記下目前命中的規則、策略組與出口，再移動一條規則比較結果；不要一次更動整份清單，最後只確認網頁能否開啟。

改用遠端提供器時，請將類型設為 http，再設定來源 url、本機快取 path 與更新間隔 interval。來源必須是已確認內容與維護方式的規則網址；本頁不會預設任意網路清單都是可信規則。不同提供器不要共用同一個快取路徑，否則更新結果可能互相覆蓋。更新間隔應依來源檔案的變動頻率設定，通常每隔數小時或數天即可，不必反覆下載；手動排錯時再主動更新。

遠端下載也有啟動時的依賴問題：若取得規則檔需要代理，而代理選擇又依賴該規則集，首次啟動時就可能形成循環。可以為下載明確指定已可使用的出口，或預先儲存規則快取，再確認冷啟動是否仍能完成。不要以「設定已載入」取代提供器狀態檢查；主要設定載入成功時，遠端規則可能還在下載，也可能仍沿用舊快取，因此還要查看提供器的更新時間與錯誤訊息。

處理 IP 規則與規則回退

no-resolve 適用於不希望為了比對 IP 條件而主動觸發網域解析的情況，並非讓所有流量略過 DNS。若連線已帶有目標 IP，IP 規則仍可能符合；若只有網域而沒有 IP，帶有此選項的規則便可能略過。將它加到大範圍規則前，必須先確認後續由哪條規則接手。內網、私有 IP 與自建服務應明確設定直連規則，不能只依賴最後一條代理兜底規則。

規則更新後若出現局部故障，先暫停更新並還原上一版規則檔，再比對新增與刪除的項目。重點檢查網域是否被加入較前面的類別、網段是否擴大，以及兜底出口是否改變。若檔案能載入但始終沒有命中，再確認連線是否保留網域、嗅探是否可用，以及應用程式是否繞過核心入口。規則模式常見狀況可參閱常見問題；請保留能重現問題的最小規則，不要直接重寫整份設定。

DNS 設定最佳化

排查 DNS 時，先畫出解析路徑：應用程式將查詢交給誰、查詢是否進入核心、核心向哪個上游發出請求，以及上游請求經由哪個出口傳送。瀏覽器能開啟網頁，只代表某條存取路徑可用，不能證明系統 DNS、應用程式的加密 DNS 與核心 DNS 完全一致。尤其啟用 TUN 後，原本由路由器處理的查詢可能改由用戶端處理；若同時保留多套強制解析工具，觀察到的結果會更難判讀。

分清監聽位址、上游與引導解析

listen 是核心接收 DNS 查詢的位置，不是上游伺服器位址。繫結回環位址適合本機使用；若繫結區域網路位址，則須額外考量防火牆與存取範圍。nameserver 用來設定一般查詢的上游；default-nameserver 則用於解析 DNS 上游本身的網域，解決必須先知道解析服務位址才能向其查詢的問題。使用數字位址作為引導解析，可減少這層循環，但仍須確認目前網路能連到該伺服器。

以下設定可作為檢查起點：監聽本機的非特權連接埠，使用加密上游，並為特定網域後綴指定解析器。它不會自動變更系統 DNS，也不會單靠這段設定就接管所有應用程式。合併後，必須透過用戶端的 DNS 接管設定或下一章的 TUN 設定，將查詢送進核心。若用戶端已管理監聽連接埠，不要再直接設定相同連接埠，以免位址衝突或產生兩組互相衝突的設定。

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
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "+.example.org":
      - 223.5.5.5

依網域指定解析器，而非堆疊上游

nameserver-policy 適合處理企業內網、自建網域，或明確依賴特定解析路徑的服務。企業網域應指向能查詢內部紀錄的解析器；將內部查詢送往公共解析服務，通常只會得到不存在或錯誤的位址。範例中的 example.org 僅用來示範後綴比對語法，不代表需要特別分流的實際服務。實際使用前，請確認目標網域與解析器的對應關係，再替換成自己擁有或獲准存取的網域。

增加上游數量不代表解析一定更可靠。不同上游可能回傳不同地區的 CDN 位址，也可能使用不同快取；混用多個結果會讓連線表現不穩。若使用 fallback，應先了解篩選條件與回退觸發方式，不要只把它當成主要解析器逾時後的備用清單。建議先從一條可觀察的路徑開始，記錄解析耗時、回傳位址與實際服務連線結果，確認問題確實出在解析層後，再加入其他策略。

若設定要求 DNS 請求遵循路由規則，respect-rules 可參與控制這條路徑，但也必須為代理伺服器網域安排明確的解析來源，例如使用 proxy-server-nameserver。否則可能形成循環：解析代理位址需要先連上代理，而連上代理又需要先解析位址。功能支援範圍應以核心實際文件與執行日誌為準；圖形用戶端的 DNS 開關可能會產生額外設定，不能只看編輯器中的文字片段。

檢查快取、IPv6 與應用程式內建 DNS

測試分三層進行：先直接查詢核心監聽連接埠，再測試系統預設解析，最後以實際應用程式連線。可以使用支援指定伺服器與連接埠的工具，例如執行 dig @127.0.0.1 -p 1053 example.org。若第一層正常、第二層異常，優先檢查系統設定與接管路徑；若前兩層正常但瀏覽器結果不同，則檢查瀏覽器的安全 DNS、應用程式代理設定與既有快取。修改設定後，最好重新建立測試連線，避免舊連線掩蓋變更。

停用核心 DNS 的 IPv6 回應，不代表作業系統完全停止 IPv6 通訊。應用程式仍可能使用快取、其他解析來源，或直接連線至 IPv6 位址。反之，啟用 IPv6 也不能只看是否回傳 AAAA 紀錄，還要確認本機路由、代理出口與目標服務都支援這條路徑。若問題只出現在部分網路，分別測試 IPv4 與 IPv6 通常比反覆切換所有 DNS 設定更有效；修改系統網路參數前，請先記下原值以便還原。

調整 DNS 後若發生間歇性故障，先檢查上游是否可連線、監聽是否衝突，以及查詢是否實際進入核心，再考慮清除快取。快取有其用途，頻繁清除會增加重複查詢，也可能掩蓋啟動階段的依賴問題。公共網路、企業網路與家用路由器可能限制不同的解析協定，應分別在各網路環境驗證。不要以單次查詢成功推論所有情境都已解決，也不要將某個上游位址視為長期固定答案。

TUN 與 Fake-IP

TUN 透過虛擬網路介面接收符合路由條件的流量，可處理部分不遵循系統代理設定的應用程式；Fake-IP 則將網域對應至虛擬位址，協助核心在後續連線中還原網域資訊。兩者常一起使用，但並非同一項功能。系統代理正常運作，不代表 TUN 權限與路由也設定正確；看到虛擬位址，也不代表連線已送往遠端代理。請分別檢查入口接管、網域映射、規則比對與最終出口。

依序啟用入口、路由與解析

先在現有系統代理模式下確認訂閱與節點可用，再關閉其他會修改路由的工具，最後啟用 TUN。桌面用戶端可能需要安裝服務、系統管理員權限或系統網路延伸功能；行動裝置通常透過系統 VPN 介面接管流量。各平台的啟用方式不同，不要直接照搬桌面權限設定。首次設定可下載下載頁首推的 Clash Plus，依系統指示完成授權，再確認目前用戶端採用的核心確實支援這些欄位。

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 協助識別外部介面，避免代理自身的連線再次送回 TUN。stack 決定網路堆疊的實作方式；可選項目與適用情況須依系統支援狀況判斷，沒有一種設定適用於所有裝置。範例使用 mixed 作為檢查起點；若啟動日誌指出不支援，請依用戶端文件選擇，不要同時繼續調整 DNS 與規則。

了解虛擬位址與 DNS 劫持範圍

Fake-IP 回傳的位址用於本機映射，並非目標網站的真實公網位址。因此，不能只因「解析結果看起來不正常」就判定設定失敗；應確認連線是否成功，以及連線詳細資訊能否還原網域。若區域網路探索、某些連網裝置或特殊應用程式需要真實位址，可將相關網域加入 fake-ip-filter，改用真實位址解析。篩選只會改變解析結果的形式，不代表自動直連；若需要直連，還須設定相應的路由規則。

dns-hijack 中的 any:53 是針對進入 TUN 且符合條件的傳統 DNS 查詢，不能因此宣稱所有 DNS 都已接管。應用程式內建的 HTTPS 加密解析通常使用其他連接埠，無法單靠這項設定識別。若應用程式繞過核心進行解析，核心可能只看得到目標位址；網域規則能否命中，還取決於嗅探等條件。請先確認查詢協定與實際入口，再決定是否調整應用程式設定，避免用更廣泛的路由規則掩蓋解析路徑差異。

處理內網連線與殘留路由

啟用後，先測試公網連線，再測試路由器管理頁、印表機與公司內網。若只有內網受影響，請檢查直連規則與路由排除範圍，不要立刻更換節點。企業 VPN 可能會下發專用網段與 DNS；若同時使用 TUN 自動路由，必須明確分工各自負責的位址範圍。排除網段應精確符合實際需求；一次排除過大的位址範圍，可能讓原本應走代理的連線也繞過核心，表面上修復局部服務，卻造成新的分流錯誤。

若所有連線都失敗，先停用 TUN，改用系統代理測試。若系統代理恢復後可正常連線，代表節點未必有問題，應優先檢查 TUN 初始化日誌、預設出口識別與路由安裝。正常關閉用戶端通常會清除自行建立的狀態；若異常結束後網路仍未恢復，請使用用戶端提供的修復入口檢查服務與路由，再視情況重新啟動網路。不了解系統路由表時，不要批次刪除項目，尤其不可刪除企業網路下發的路由。

Fake-IP 映射與應用程式 DNS 快取都有使用期限。核心重新啟動後，若應用程式仍沿用舊的虛擬位址，可能暫時無法連線；先讓應用程式重新解析，再判斷是否需要清除相關快取。持續執行狀態與行動裝置的背景執行策略也會影響結果，詳見手機背景耗電與常駐連線取捨。確認正常運作後，記下當時的介面、路由與 DNS 設定，下次切換網路時便能比較差異，不必重新猜測。

網域嗅探

網域規則需要核心知道連線所對應的網域。透過一般代理入口發出的請求通常會直接帶有網域，但從 TUN 進入的連線可能只有目標位址；應用程式自行解析、使用快取或直接連線至位址時，這種情況更常見。網域嗅探會嘗試從連線初始的協定資訊補上網域，例如 HTTP 的主機欄位、TLS 交握中的伺服器名稱。它是用來補足資訊缺口，不是取代 DNS，也不會解密所有應用程式內容。

先確認缺少網域資訊，再啟用嗅探

排查時先查看連線詳細資訊：若目標欄已顯示網域，且規則能正常命中，就不必為了「設定完整」而啟用更多強制選項。若只顯示位址，先檢查 DNS 是否進入核心、Fake-IP 映射是否仍存在，再考慮使用嗅探。啟用嗅探可能改變規則命中的依據，原本依位址分流的連線會新增網域條件；因此正式啟用前，應選擇幾個明確的服務進行比對，記錄開啟前後的規則與出口變化。

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: false
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443

sniff 用來指定嘗試辨識的協定與連接埠，不是開放防火牆連接埠。只列出實際需要的範圍，才能更清楚掌握哪些連線會受到處理。force-dns-mapping 用於擴大特定 DNS 映射情境中的嗅探機會，不會主動將所有 DNS 查詢送進核心；parse-pure-ip 則涉及直接以 IP 位址為目標的流量。範例先維持後者停用，避免將原本明確的位址連線也納入範圍較廣的網域推斷。

分清網域比對與目標改寫

override-destination 會影響是否以嗅探取得的網域取代連線目標。保持關閉時，可先觀察嗅探是否補上路由判斷所需的資訊，而不必同時改變目標連線方式。部分服務的交握名稱不適合直接取代實際目標，尤其是自建入口、共用位址或特殊轉送情境。若啟用後出現憑證錯誤、連線重設或特定應用程式故障，應將目標改寫視為獨立變因檢查，不要直接歸咎於節點無法使用。

若某個網域不適合嗅探，可在 skip-domain 中列出明確例外；但例外應有實際故障證據，不要直接複製網路上冗長的通用清單。新增例外前，先重複測試並記錄連線顯示的網域、實際位址與命中規則。若停用嗅探才能恢復，也應繼續確認問題出在協定辨識、目標改寫還是規則順序。釐清這些關係後，日後更新才不必再靠擴大排除範圍維持運作。

了解加密協定的限制

TLS 嗅探依賴交握過程中可見的資訊；遇到加密用戶端問候等機制時，無法保證取得實際服務網域。QUIC 的辨識也會受到協定、實作方式與封包可見度影響；設定協定名稱不代表每條連線都能辨識。對於無法還原網域的流量，應準備合理的 IP 規則或兜底策略，而不是無限制擴大連接埠範圍。若服務本身提供應用程式代理設定，改用能攜帶網域的代理入口連線，有時比不斷增加嗅探設定更清楚。

嗅探結果不能視為應用程式身分驗證。連線所帶的主機資訊，只是目前協定情境中的線索，無法證明請求屬於哪位使用者，也不能作為不同租戶之間的安全隔離界線。共用出口、內網授權與存取控制應採用獨立的網路與身分驗證機制。對目的位址有嚴格限制的工作環境，應由管理員制定可驗證的規則，不能只靠網域嗅探判斷是否允許連線，更不可將觀察到的網域視為存取授權。

建議驗證時保留三組測試樣本：正常使用核心 DNS 的網頁、使用獨立解析的應用程式，以及直接以 IP 位址連線的服務。每組都要檢查目標資訊、命中規則與最終出口，不能只確認能否開啟。若啟用嗅探後才出現額外延遲，可先只保留一種協定範圍測試，再逐項恢復。日誌等級提高到足以定位問題即可；排錯完成後請恢復日常等級，避免持續寫入大量連線資訊，也不要直接公開分享含有瀏覽紀錄的日誌。

本機覆寫與多訂閱合併

遠端訂閱會定期更新，直接修改下載後的設定，下一次重新整理時很容易被覆蓋。本機覆寫可將個人偏好的連接埠、DNS、規則與策略組放在獨立的維護層，讓上游繼續負責更新節點。不同用戶端可能稱之為覆寫、合併、擴充設定或腳本處理，實際運作方式不盡相同。開始前務必確認修改的是哪一層：原始訂閱、用戶端儲存的設定，或交給核心執行的最終設定；這三份內容可能不同。

先記錄合併順序與清單處理方式

純量欄位通常容易理解，例如最後寫入的 mode 會覆蓋先前的值；但清單欄位可能採用附加、置前或整段取代，物件欄位也可能採用淺層合併或遞迴合併。不能因為兩個用戶端都稱為「合併」，就假設結果相同。建議先在本機副本中只修改一個不影響連線的欄位，預覽最終設定並確認結果，再加入 DNS 或規則。若用戶端沒有預覽功能，可查看執行設定匯出檔或啟動日誌；分享前務必移除訂閱網址與節點憑證。

尤其要確認 rules 的處理方式。若覆寫將自訂規則附加在既有 MATCH 之後，這些規則可能永遠不會執行；若整段取代，則可能刪除原有的內網與業務例外。策略組清單也有相同問題：整份覆蓋會導致上游規則引用的組名失效。維護時應列出需要保留的固定組名，並明確指定自訂規則的插入位置。不要以重複的 YAML 頂層鍵模擬合併，不同解析器處理重複鍵的方式並不可靠。

透過提供器分層管理多個訂閱

多個訂閱不必直接拼接成數份完整設定。較容易維護的架構是：每個來源各自作為節點提供器，由總設定統一管理策略組、規則與 DNS。以下以兩個本機節點檔示範整理方式；每個檔案都必須包含合法的 proxies 清單，不是任意的完整用戶端設定。檔案路徑相對於工作目錄。若已設定提供器健康檢查，可依實際需求統一調整，避免與策略組探測重疊，造成過於頻繁的週期請求。

proxy-providers:
  線路甲:
    type: file
    path: ./providers/a.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900
  線路乙:
    type: file
    path: ./providers/b.yaml
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 900

proxy-groups:
  - name: 多訂閱出口
    type: select
    use:
      - 線路甲
      - 線路乙

改用遠端提供器時，應使用自己有效且獲准使用的訂閱來源，並分別設定快取路徑與更新間隔。訂閱網址通常包含存取憑證，不可放進公開儲存庫、截圖或求助文章。也要檢查上游回傳內容的格式：可供匯入完整設定的網址，不一定能直接作為提供器檔案讀取。若錯誤訊息指出缺少節點清單，先核對回應內容與格式，不要急著修改每個節點的通訊協定欄位；問題可能出在最外層的資料結構。

不同來源若有相同的節點名稱，控制面板中的選擇與日誌追蹤會變得模糊，也可能造成名稱衝突。優先採用用戶端或核心支援的名稱前後綴機制，為各來源建立固定識別；若使用轉換腳本，先在副本上執行並檢查輸出。篩選條件也要反映來源用途，不能只依賴地區關鍵字，否則上游改名後可能導致組內突然沒有節點。完成合併後，分別停用其中一個來源進行測試，確認另一個來源可以獨立完成預期的回退。

以執行設定驗證，不要只看編輯器

每次調整後都要檢查設定，再重新載入並查看日誌。若裝置上有可直接執行的 Mihomo 程式，可在正確的工作目錄中執行下方指令；此指令只檢查檔案結構與引用等內容，無法證明遠端節點或規則來源一定可連線。圖形用戶端使用者可透過內建檢查功能，不必另外啟動第二個核心程序。兩個程序同時執行會爭用連接埠與路由，反而造成原本不存在的問題。

mihomo -t -f ./config.yaml

建立回復紀錄時，至少保存原始設定、本機覆寫，以及一份已移除敏感資訊的變更說明。節點憑證應只保存在受控位置，不要隨排錯資料散布。訂閱更新後，也要重新檢查最終規則順序、提供器狀態與組內節點數量，尤其是上游修改組名或預設模式時。首次安裝階段的設定順序可參閱初始設定檢查清單；設定穩定後，應盡量減少自動改寫層數，讓每項需求只由一層負責，排錯會更直接。

外部控制面板

外部控制面板透過核心控制介面讀取狀態、切換策略、查看連線及管理提供器。它不是代理入口，控制面板連線成功也不代表應用程式會自動走代理。請區分三種位址：應用程式使用的代理連接埠、DNS 監聽連接埠，以及控制面板連線的控制位址。面板能開啟卻看不到連線時，先確認它連到的是目前實際承載流量的核心，而不是殘留服務、另一份設定或同一台裝置上啟動的第二個執行個體。

預設僅監聽本機

external-controller 用來設定控制介面的監聽位址。個人桌面使用時，建議優先繫結回環位址，讓控制介面只在本機存取。external-ui 指向本機控制面板的靜態檔案目錄；該目錄必須存在，且與核心工作目錄的相對關係應明確。以下片段只示範本機監聽與靜態目錄，不含存取憑證；若用戶端已自動產生控制位址與密碼，應沿用其管理方式，不要透過覆寫任意清除現有驗證設定。

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

面板驗證會受到 secret 等相關設定控制；實際部署時，應自行產生並妥善保存高強度密碼。不要將密碼放入可分享的面板連結、截圖或公開設定。即使只繫結本機，也不能忽略驗證：本機其他程式與瀏覽器的網路存取都應納入考量。若面板是從網頁載入，也要留意瀏覽器對跨來源請求、混合內容與本機網路存取的限制；頁面能載入，不代表一定能連上控制介面。

依網路、驗證與執行個體順序排錯

連線失敗時，先確認核心已在執行、監聽連接埠沒有衝突，再核對面板設定的通訊協定、位址與連接埠。連線遭拒通常表示監聽或防火牆有問題；收到未授權回應，則應優先檢查驗證設定；若能讀取狀態但策略組不符，通常是連到了其他執行個體。不要為了盡快連線就將位址改成監聽所有介面，也不要將停用驗證當成長期方案。先在本機建立最小可用的連線，再逐步擴大存取範圍。

若需要從另一台裝置管理，應優先使用受控通道或既有管理網路，再考慮調整監聽設定。直接繫結 0.0.0.0 會讓介面可從多個網路連線，實際暴露範圍取決於防火牆、路由與連接埠轉送。控制介面具備切換出口、查看連線等管理功能，不應直接暴露於公網。若確實需要反向代理，還必須同時設定傳輸加密、存取控制與驗證，並了解瀏覽器跨來源設定；只新增轉送規則並不足夠。

看懂連線詳細資訊，再進行調整

連線詳細資訊應依序檢查入口、目標、命中規則、策略鏈與實際節點。入口可用來判斷流量來自系統代理還是 TUN；目標資訊可確認網域是否保留；規則會說明為何選擇該策略組；策略鏈則顯示策略組如何繼續選出節點。看到「手動選擇」不代表已知道最終出口，還要沿著策略鏈查看。若一個網頁產生多筆連線，應依目標網域區分主要請求與資源請求，不能只看其中一筆就概括整個頁面的路由。

控制面板中的切換與重新載入操作，影響也各不相同。切換策略主要改變後續選擇；重新載入設定可能更新規則與策略組結構；關閉連線則會中斷現有工作階段。排錯時先記錄狀態，再只處理目標連線，避免同時中斷檔案傳輸、遠端終端機與工作會議。規則提供器更新失敗應檢查下載與解析日誌；節點無法使用應檢查出口；本機程式未出現在連線清單中，則應回到入口接管層檢查，不要只在控制面板中反覆測速。

日常維護可固定採用簡短流程：儲存目前設定、修改一個主題、檢查語法、重新載入並查看日誌，再以指定的應用程式重新連線驗證。跨網路測試時，額外檢查 DNS 與預設介面；多訂閱更新後，則確認引用與快取。區域網路代理分享與開放控制介面是兩回事；若要讓其他裝置使用代理，可參閱mixed-port 與 allow-lan 設定說明，不要誤將控制連接埠填入手機的代理設定。若仍無法定位問題，請帶著已移除敏感資訊的最小設定與重現步驟，參閱故障排查問答。