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

策略與出口

策略組類型與實作

策略組是規則與代理節點之間的中介層。規則決定連線要使用哪個出口，策略組則決定該出口目前採用哪個節點。若規則直接指定單一節點，節點改名後就得修改多條規則；改為指定固定的組名，即使訂閱內容更新，規則仍然有效。規劃時先列出所需的出口，例如手動代理、自動選擇與預設備援，再決定組內的候選節點，不要一開始就建立大量地區分組。

依選擇機制區分組類型

select 用於手動選擇，適合需要明確控制出口的情境。url-test 會定期測試候選節點，並依測試結果選擇節點；測得的只是指定網址的連線能力與回應狀況，不代表所有網站都會更快。fallback 依設定順序尋找可用候選節點，適合主備架構。load-balance 會依策略分配不同連線，無法將單一下載連線的速度合併成多個節點的總頻寬。

巢狀組可以減少重複設定，但每多一層就會增加排查難度。若業務組指向手動組，而手動組又指向自動組，面板上看到的第一層名稱不一定是最後使用的節點。排查時應繼續展開選擇鏈，確認最終出口。對登入敏感或連線時間較長的服務，建議維持穩定出口；自動切換可能讓新連線改用其他 IP，舊連線仍留在原節點，短時間內便會同時使用不同出口。

使用節點提供器隔離訂閱變更

以下片段假設本機已有節點提供器檔案，且檔案包含頂層 proxies 清單。檔案路徑是相對於核心工作目錄，而非瀏覽器的下載資料夾。自動組透過 use 引用提供器，外層代理組則只引用自動組與內建的直連出口。實際使用時，請將既有訂閱的節點匯出至該檔案，或使用用戶端支援的訂閱管理功能產生對應提供器；不可將一般網頁另存為 YAML 後直接引用。

proxy-providers:
  本機節點:
    type: file
    path: ./providers/nodes.yaml

proxy-groups:
  - name: 自動選擇
    type: url-test
    use:
      - 本機節點
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
    lazy: true
  - name: 代理
    type: select
    proxies:
      - 自動選擇
      - DIRECT

interval 的單位為秒；tolerance 是切換容許差距，可避免候選節點回應時間相近時頻繁切換。lazy 可減少閒置時的測試。請勿將間隔設得過短，營造「即時最佳」的假象；頻繁測試會增加請求量，也會消耗行動裝置電力。若所有候選節點測試都失敗，請先確認測試網址能否透過這些節點連線，再檢查節點本身，不要只憑面板結果就判定整份訂閱失效。

篩選、命名與驗證順序

使用 filter 篩選提供器節點時，通常是以正規表示式比對名稱，不會自動辨識地理位置。訂閱改名、符號變更或大小寫差異，都可能導致篩選結果為空。請先在面板確認提供器已有節點，再驗證篩選式，最後檢查策略組是否出現候選節點。組名必須與規則中的目標完全一致，尤其要留意全形空格、相似標點，以及手動複製時產生的不可見字元。

驗證時，先選擇明確可用的節點，再以規則模式連線至目標網站。在連線詳細資料中核對命中規則、策略組與最終節點，不要只看用戶端的總開關。若手動選擇正常、自動組異常，問題多半出在測試網址、篩選條件或自動選擇機制；若所有組都失敗，再回頭檢查訂閱與網路連線。訂閱下載或解析問題可參閱訂閱更新失敗自我檢查，避免將匯入問題誤判為分流問題。

規則與維護

規則集訂閱管理

規則集可將網域、網段或完整規則從主要設定檔拆出，主檔只保留引用關係與比對順序。它能解決的是維護規模，並不會改變「第一條符合的規則決定出口」這項基本原則。即使規則集包含大量項目，只要前面已有較寬泛的規則命中，後續規則就不會執行。規劃時先列出區域網路與明確例外，再安排業務規則集、地理規則及最後的兜底規則，避免以大量重複規則彌補順序錯誤。

先確認內容語意，再選擇格式

behavior 用來說明規則集內容的語意。domain 適用於網域清單，ipcidr 適用於 IP 網段清單，classical 則可容納包含規則類型的項目。這與副檔名是兩回事：副檔名為 YAML 的檔案，也可能是節點訂閱或完整設定檔。匯入前請開啟來源內容，檢查頂層結構與每筆資料，不要只憑下載網址的副檔名判斷是否相容。

格式必須與內容語意相符。YAML 規則集通常使用頂層 payload 陣列；文字格式則逐行讀取項目；MRS 是編譯後的規則格式，支援範圍視核心實作而定。若檔案內容是 DOMAIN-SUFFIX,example.org 這類完整規則，應採用合適的 classical 語意，不要將它放進純網域清單。更換來源時，請一併確認 behavior 與 format，不要只修改 URL。

先在本機驗證，再接入遠端更新

建議先從本機檔案開始驗證。以下主設定引用兩個本機規則集：業務網域 對應網域清單，本機網段 對應 IP 網段清單。兩個檔案都必須確實存在於磁碟上。代理組 代理 必須事先定義；no-resolve 可避免地址類規則為了比對網域而額外進行解析，但不代表任何情況下都會略過 DNS，也不會阻止後續規則在需要時解析。

rule-providers:
  業務網域:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/business.yaml
  本機網段:
    type: file
    behavior: ipcidr
    format: yaml
    path: ./rules/private.yaml

rules:
  - RULE-SET,本機網段,DIRECT,no-resolve
  - RULE-SET,業務網域,代理
  - MATCH,代理

例如，business.yaml 可採用以下結構。這裡使用保留的示範網域，只用於說明語法，不會實際影響業務分流。替換為確實需要的網域後，請先確認核心能否載入，再觀察目標連線。網域規則不包含 URL 路徑，不可寫成包含通訊協定、連接埠與網頁路徑的完整網址；若要區分同一網域下的不同路徑，單靠網域分流無法表達。

payload:
  - "+.example.org"
  - "example.net"

改用 HTTP 提供器時，請補上可信來源的 url、本機快取 path 與更新間隔 interval。各快取路徑應互不相同，避免不同來源覆寫同一檔案。更新間隔應依規則變動頻率設定，不必與節點速度測試間隔一致。下載失敗後能否繼續使用既有快取，取決於快取是否有效及核心狀態；部署至新裝置前，應另外確認首次下載路徑可連線。

分別檢查更新結果與比對結果

提供器顯示更新成功，只代表檔案已下載並完成解析，不代表目標連線一定會命中。排查時先檢查規則集項目，再檢查它在主規則鏈中的位置，最後確認連線實際帶有的是網域還是目標 IP。瀏覽器快取、既有長連線及應用程式內建解析，都可能讓測試結果與預期不同。修改規則後，關閉目標應用程式的連線並重新發出請求，比反覆重啟整個用戶端更容易保留可供比較的記錄。

維護多個來源時，應明確寫出每個規則集的用途，並保留少量易於理解的本機例外。不要同時訂閱多套涵蓋相同業務的大型規則集，再靠順序猜測哪套生效。移除來源前，請檢查所有 RULE-SET 引用；合併來源時則要留意授權、更新穩定性與內容差異。規則命中不如預期時，可先在目標網域前新增一條暫時性的精確規則來驗證出口，驗證後再刪除，以免臨時修正長期遮蔽原有邏輯。

解析路徑

DNS 設定最佳化

DNS 設定至少涉及三件事：由誰接收應用程式的查詢、由誰解析目標網域，以及代理伺服器本身的網域如何解析成 IP。把所有路徑都交給同一個上游，看似簡單，卻可能形成依賴循環。例如，解析代理伺服器時必須先連上代理，而建立代理連線又需要先解析伺服器名稱。最佳化前先畫出這三條路徑，確認引導解析能獨立完成，再考慮加密上游、依網域指定解析器及快取行為。

區分引導解析與一般解析

default-nameserver 主要用於解析 DNS 上游本身的網域等引導用途，通常設定明確的 IP 位址。nameserver 是一般業務使用的解析上游；nameserver-policy 可為特定網域或規則指定解析路徑；proxy-server-nameserver 則用於解析代理節點的伺服器網域。用戶端是否保留這些欄位，應以產生後的執行設定為準，不要只看訂閱編輯器中的內容。

以下是用來理解各欄位分工的基本範例，使用明確的上游位址，避免額外引入網域引導依賴。監聽連接埠設為本機非標準連接埠，不代表系統已將 DNS 查詢送到此處。啟用前請確認本機連接埠未被占用；使用 TUN 攔截查詢時，再依照下一章將流量導入核心 DNS。上游是否可連線會受目前網路影響，範例位址不保證適用於所有地區與線路。

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
    - 1.1.1.1
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  nameserver-policy:
    "+.lan":
      - 192.168.1.1

範例中的區域網路解析器應改為目前網路實際可用的路由器或內部 DNS；若不需要解析內部網域，請移除對應策略。使用公共解析器查詢企業內部網域，通常只會得到不存在的結果。反過來，若將所有公共網域交給只能解析內部紀錄的伺服器，也會普遍失敗。判斷解析器是否適用於某個網域，應觀察回傳位址與連線路徑，而不只是確認查詢是否有回傳紀錄。

fallback 並非任何失敗情況的萬用解法

fallback 搭配 fallback-filter，用來決定某些情況下採用哪一組解析結果；它不是網路出口的主備策略組。篩選條件可能涉及地理資訊、位址範圍或網域；條件過於寬鬆會讓大量查詢改走備用上游，條件太嚴格則可能繼續採用不合適的結果。若尚未理解選擇條件，請先使用清楚的 nameserver-policy 區分必要網域，再評估是否確實需要 fallback。

使用 respect-rules 讓 DNS 上游連線遵循路由規則時，必須先處理代理伺服器網域的獨立解析，否則容易形成解析與代理互相等待的循環。加密 DNS 只會改變查詢的傳輸方式，不會自動確保查詢經由代理，也不保證回傳的位址適合目前出口。若目標網域解析成功但連線逾時，應先確認解析結果是否符合正確的網路，再檢查策略與路由，不要繼續不加判斷地堆疊上游位址。

依查詢、回應與連線分層排查

排查時先確認應用程式的查詢是否進入核心，再檢查核心是否向預期的上游送出請求，最後比對目標連線使用的位址。可以使用系統提供的 DNS 查詢工具，指定本機監聽位址與連接埠；若工具不支援自訂連接埠，請勿把查詢系統解析器的結果誤認為核心的結果。分別測試內部網域、公共網域與代理節點網域各一個案例，通常比反覆重新整理同一個網頁更容易找出問題環節。

修改 DNS 後，系統、瀏覽器與核心可能各自保留快取。請先關閉目標應用程式的既有連線，必要時依用戶端支援方式清除 DNS 快取，再送出新請求。若出現 IPv6 位址，但網路沒有可用的 IPv6 路徑，應區分 DNS 回傳紀錄與實際路由能力；只切換一個 DNS 開關未必能涵蓋所有應用程式。是否啟用 IPv6，應一併檢查系統路由、核心設定與節點支援情形，不要只憑某個網站能開啟就判定一切正常。

DNS 處理與規則分流有先後依賴，但兩者不是同一項設定。網域規則可在保留網域資訊時直接比對，位址規則可能觸發解析；no-resolve 則會限制這個步驟。記錄一次請求的網域、回傳位址、命中規則與出口，才能釐清設定的實際效果。更詳細的欄位組合與 DNS 攔截範圍，請參閱DNS 參數與攔截設定說明。

流量接管

TUN 與 Fake-IP

系統代理仰賴應用程式遵循作業系統的代理設定；TUN 則透過虛擬網路介面接收路由至核心的流量。兩者處理的是流量如何進入用戶端，不會決定流量一定要走代理。啟用 TUN 後，規則模式仍可讓區域網路與指定業務直連；全域代理也不代表所有系統流量都已接管。要確認接管是否完整，應從目標應用程式的連線記錄與路由表著手，而不是只看一個開關。

先確認權限與路由條件

桌面用戶端通常需要服務元件、管理員權限或相應的系統授權，才能建立介面與路由。行動平台則透過系統 VPN 介面接管流量，設定入口與桌面版不盡相同。首次啟用前，請記下原有的系統代理與 DNS 設定，暫停其他可能接管路由的 VPN，再操作用戶端提供的 TUN 開關。不要同時手動啟動另一個核心執行個體，否則連接埠、虛擬網卡與預設路由可能互相衝突。

以下是常見的 Mihomo 局部設定。auto-route 用於自動設定相關路由，auto-detect-interface 用於識別對外網路介面，dns-hijack 則會將符合條件的傳統 DNS 請求交由核心處理。此片段必須搭配已啟用的 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

stack 用來選擇協定堆疊的實作方式，沒有適用於所有系統的固定最佳選項。遇到相容性問題時，每次只更換這一項，並以同一項業務重新測試，記錄連線能否建立、能否持續傳輸，以及 UDP 是否正常。不要同時修改協定堆疊、MTU、DNS 與節點，否則即使問題消失，也無法判斷是哪個參數生效。若自動偵測介面異常，請先查看系統目前實際使用的對外介面，尤其是在有線與無線網路切換後。

Fake-IP 保留網域對應關係，並非真實服務位址

Fake-IP 模式會向應用程式回傳保留位址池中的虛擬位址，核心則記錄該位址與網域的對應關係；後續連線進入核心後，便會依此比對規則並建立對外連線。應用程式看到的虛擬位址，不應直接拿到另一台未參與映射的裝置上使用，也不能據此判定遠端服務真的位於該網段。排查時應同時查看映射網域與最終出口資訊，不要只依系統工具顯示的目標位址判斷分流是否正確。

部分區域網路探索、裝置管理或需要真實解析位址的服務，可能需要排除 Fake-IP，可依明確網域設定 fake-ip-filter。排除後，這些網域會改用真實位址解析；後續規則能否保留網域資訊，則仍受應用程式行為與嗅探影響。不要為了解決單一裝置問題就排除所有網域；請先確認實際請求的網域，再測試最小範圍。若位址池與現有 VPN 或測試網路衝突，請依核心支援範圍調整，並重新建立映射。

以可復原的流程驗證流量接管

驗證時先保留已知可用的規則與節點，只啟用 TUN。選擇原本不會遵循系統代理設定的目標應用程式，建立新連線並檢查連線清單中是否出現記錄。若看得到連線但無法存取，通常表示接管步驟已完成，接下來應檢查規則、DNS 與出口；若完全沒有記錄，則檢查應用程式是否繞過目前網路路徑、介面路由是否建立，以及是否有其他網路工具搶先接管。

傳統 DNS 攔截無法自動攔截所有加密解析。應用程式內建的 DoH 或其他加密協定看起來就像一般的加密連線，不會只因目標連接埠是非標準 DNS 連接埠，就被交給本機解析模組。若缺少網域資訊，請先確認應用程式的安全 DNS 設定，再搭配下一章的嗅探功能判斷；不要把啟用 dns-hijack 當成所有解析路徑都已統一處理的證明。

若發生斷網，先關閉 TUN，觀察路由與 DNS 是否恢復，再處理衝突來源。退出用戶端後仍有異常，請檢查殘留的系統代理、其他 VPN 狀態與系統網路設定，不要不斷新增路由。遠端維護伺服器時尤其要保留回復管道，避免接管管理連線後失去存取能力。完整原理與系統代理比較請參閱TUN 流量接管說明；首次安裝仍請以快速上手教學為準。

補足網域資訊

網域嗅探

網域規則需要知道目標網域，但進入核心的連線有時只帶有目標 IP。應用程式可能直接連線至快取位址，也可能自行完成解析，繞過核心 DNS。嗅探會嘗試從受支援協定的交握或請求資訊中還原網域，供規則比對或目標處理使用。它補足的是連線中繼資料，不會解密所有加密內容，也不能取代合理的 DNS 路徑與完整的規則設計。

辨識範圍與資訊來源

HTTP 嗅探通常依據請求中的主機資訊，TLS 嗅探通常依據交握中的伺服器名稱；QUIC 則需要核心支援相應流量。若協定不在支援範圍、交握資訊不可見，或使用隱藏名稱的機制，就可能無法取得網域。面板未顯示網域不一定代表用戶端故障，也可能是流量本身沒有提供可用資訊。遇到這種情況，應保留位址規則與明確的兜底規則，而不是無限制擴大嗅探連接埠範圍。

以下片段以常見的網頁連接埠為起點，並保留 TLS 與 QUIC 的範圍。這是能力設定，不代表每條連線都一定能取得網域。parse-pure-ip 允許嘗試處理目標僅有 IP 的連線；force-dns-mapping 則涉及 DNS 映射情境下的嗅探行為。首次啟用時只新增嗅探設定，不要同時改寫 DNS 與規則，方便比較啟用前後的網域與比對結果。

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

連接埠範圍應符合實際業務需求。若讓所有連接埠都交由所有協定解析，不但會增加不必要的處理，也可能讓非目標協定進入更複雜的判斷流程。自建服務使用非標準連接埠時，先確認實際採用的協定，再只為相應項目新增連接埠。QUIC 通常使用 UDP，能否正常代理還取決於節點協定、伺服器與連線路徑的支援；啟用 QUIC 嗅探，不代表 UDP 對外連線已可用。

區分比對用途與連線目標改寫

override-destination 用來決定是否以嗅探到的網域覆寫連線目標。將網域用於規則判斷，與用它重新連線，是兩種不同效果。某些業務仰賴特定 IP、內部解析結果或位址綁定，改寫目標可能改變原有連線語意。範例先關閉覆寫，以降低影響並觀察網域還原狀況；確有需要時，再依協定或業務調整，並確認目前核心對全域值與協定層級值的繼承規則。

同一個目標 IP 可能承載多個網域，而同一網域也可能對應多個位址。只看到 IP 改變，無法判斷嗅探是否正確；應核對原始目標、嗅探網域、命中規則與最終出口。若應用程式將請求交給另一個中介代理，嗅探到的資訊也可能只反映該中介連線。應在接近目標應用程式的流量入口進行分析，不要把連線清單上的名稱都視為使用者正在瀏覽的完整網站。

限定範圍，保留相容性例外

若啟用後只有少數服務異常，先關閉目標覆寫並重新測試，再考慮透過 skip-domain 排除明確不相容的網域。只有確實需要強制處理特定網域時，才評估使用 force-domain，不要將它當成一般白名單。例外項目應註明業務原因，避免過了半年只剩下一串無法解釋的網域。對內部系統尤其要留意私有憑證、非標準交握與固定 IP 的存取方式，不宜直接套用公共網站的處理方式。

驗證時必須使用新連線。瀏覽器連線池、HTTP/2 連線重用及應用程式長連線，可能讓修改後的設定暫時沒有新的交握可供觀察。先關閉目標應用程式的相關連線，再開啟可重複測試的頁面，檢查記錄是否出現預期網域。不要同時清除所有系統網路設定，否則會失去原本可供比較的環境。若需保存除錯記錄，只保留與問題相關的時間範圍，並隱藏存取網域、節點位址等個人資訊。

嗅探後命中不同規則，不代表結果一定更正確。請檢查新規則是否符合實際業務目的，尤其是範圍廣泛的網域後綴規則，可能會覆蓋原本精確的位址例外。可以暫時新增一條明確指定目標網域的規則來驗證，再將結果納入長期規則設計。若不啟用嗅探，只調整 DNS 也能穩定取得網域資訊，建議保留結構較簡單、依賴較少的路徑，避免每個問題都靠新增功能開關來補救。

仍無法辨識的流量，應依位址、連接埠或可靠的程序資訊處理。程序規則是否可用，取決於平台、權限與核心能力；行動平台與桌面平台也不盡相同。將無法確定的流量交由明確的兜底組處理，至少能說明最終出口。若不熟悉相關術語，可參閱術語指南中的 DNS、規則與網路堆疊概念，再回到連線詳細資料逐項比對，避免將「沒有網域」直接歸因於「代理沒有運作」。

設定產生與更新

本機覆寫與多訂閱合併

訂閱設定會在更新時重新產生；直接修改訂閱檔案中的連接埠、DNS 或規則，下一次更新時可能就會遺失。本機覆寫的用途，是將長期由使用者維護的設定與遠端內容分開。節點交由訂閱更新，個人規則、監聽範圍與必要的 DNS 策略則保存在本機層。操作前先確認用戶端提供的是欄位合併、規則前置、規則後置，還是指令碼處理；不能一概視為單純附加文字。

先釐清設定由誰管理及處理順序

設定通常會依序經過訂閱下載、解析、用戶端轉換、覆寫與核心執行等階段。某個欄位在編輯器中存在，卻未出現在執行設定中，可能是後續處理覆蓋了它，而非 YAML 語法錯誤。Clash Plus 與其他相容用戶端的功能名稱可能不同，請依實際介面尋找本機設定、覆寫或執行設定檢視功能。不要根據其他用戶端的選單路徑，判定目前用戶端缺少某項核心功能。

對應欄位可能依鍵值合併；陣列欄位則可能整體取代，也可能提供專用的前置或後置機制。rules、proxy-groups 與 nameserver 都涉及清單，不能假設新增一項後就會自動保留遠端的所有項目。第一次使用覆寫時，先做一項影響範圍小且容易觀察的變更，檢查執行結果並確認合併方式，再移轉其他設定。

依來源隔離多個訂閱，再統一出口

合併多個訂閱時，不宜將所有節點直接塞進同一份清單。不同來源可能包含同名節點、同名策略組或重複的提供器識別碼，覆蓋順序也可能因用戶端實作而異。較穩妥的做法是將每個來源設為獨立提供器，先建立來源組，再由共用出口組引用。以下片段假設兩個本機檔案都是有效的節點提供器檔案；完整訂閱必須先經過用戶端支援的轉換，不能只改檔名就當成節點清單。

proxy-providers:
  來源甲:
    type: file
    path: ./providers/source-a.yaml
  來源乙:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: 甲組
    type: select
    use:
      - 來源甲
  - name: 乙組
    type: select
    use:
      - 來源乙
  - name: 代理
    type: select
    proxies:
      - 甲組
      - 乙組

這種結構能讓規則與訂閱來源分開管理，但仍須處理同名節點與組名衝突。若用戶端支援替來源節點加上前綴，請使用穩定、簡短且容易辨識的前綴；若透過指令碼改名，必須同步檢查所有依名稱引用及篩選的運算式。移除來源前，先從共用出口刪除相關引用，再移除提供器。更新後若候選節點為空，請先確認來源是否已載入，再檢查篩選條件，不要立刻重建整份設定。

遠端訂閱可能不只包含節點，也可能帶有規則、DNS 與控制介面欄位。合併時應明確規定哪些內容可以進入執行設定，不要將兩份完整設定逐段拼接後，就期待核心自動判斷優先順序。尤其是 external-controller、allow-lan 與監聽位址，應由本機策略統一管理。使用訂閱轉換服務時，也要評估連結的保密性，以及轉換服務能接觸到哪些內容；建議優先採用自己可控的處理方式。

每次只修改一個層級，並保留回復檔案

建議分別保留原始訂閱、本機覆寫與最終執行設定三個檔案，不要反覆以同一個檔名覆蓋。先檢查最終設定的語法，再載入用戶端，最後驗證連線。若獨立使用 Mihomo 命令列，可執行以下設定測試；它會檢查語法與相關設定關係，但無法證明訂閱伺服器、規則下載或所有業務連線都已成功，執行後仍須持續查看記錄。

mihomo -t -f ./config.yaml

修改覆寫後若發生閃退或無法啟動，請先撤回最近一次本機變更，嘗試還原已知可用的設定，再判斷是否需要處理用戶端本身。錯誤訊息中的行號可能指向產生後的檔案，而不是遠端原始檔；排查時請開啟正確的執行檔案，重點檢查縮排、重複鍵、無效引用，以及清單遭到取代等問題。更多啟動問題的處理方式請參閱用戶端啟動崩潰排查。

備份檔案同樣包含訂閱網址、節點密碼與控制憑證，不可直接附在公開提問中。分享設定前，請刪除敏感內容，只保留能重現問題的最小結構，並以明確的教學假資料取代。移轉到其他裝置時，除了 YAML，還要檢查本機提供器、規則集、控制面板目錄與相對路徑；即使設定本文相同，工作目錄不同也可能造成檔案不存在，或誤讀舊快取。

執行狀態與控制

外部控制面板

外部控制介面可讓面板讀取代理組、連線、規則與記錄，並執行切換策略等操作。面板是核心的控制入口，不是另一個代理出口，也不負責替核心建立 TUN 路由。面板無法連線時，瀏覽器本身仍可能正常上網；反過來，面板能開啟也不代表代理連線正常。應分別確認頁面資源是否載入、控制介面是否可連線、驗證是否通過，以及業務連線是否成功。

預設僅在本機監聽

僅供本機使用時，請將控制介面綁定至回送位址，並搭配獨立憑證。以下的 your-password 僅為教學假值，實際部署時必須替換成自行產生的長隨機字串，且不可與訂閱或其他服務共用。external-ui 指向本機面板資源目錄，該目錄中應有面板入口檔案；路徑是相對於核心工作目錄。尚未準備面板檔案時，可以先只測試 API，再設定介面。

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

回送監聽只允許本機存取。用手機瀏覽器連線至電腦的回送位址，實際連線的是手機本身，不會自動轉到電腦。若確實需要跨裝置管理，請優先使用受控的私人通道，並限制來源、身分與存取範圍；不要為了方便直接將控制介面暴露在公網。代理連接埠的 allow-lan 與控制介面監聽並非同一項設定；啟用區域網路代理，不代表控制面板已正確設定或受到保護。

先驗證 API，再處理面板連線

可以先在核心執行裝置上呼叫控制 API。以下命令會讀取目前設定概況，終端機中的憑證同樣只是範例。若回應未授權，先核對目前執行設定中的憑證；若連線遭拒，先檢查監聽位址、連接埠與程序狀態；若請求逾時，則還要檢查路由與防火牆。控制介面尚無法連線時，不要反覆重新安裝面板；介面檔案無法修復尚未啟動的控制服務。

curl --fail \
  -H "Authorization: Bearer your-password" \
  http://127.0.0.1:9090/configs

若 API 正常但瀏覽器面板仍無法使用，請檢查面板填寫的後端位址、通訊協定與連接埠。透過 HTTPS 開啟的頁面連線到 HTTP 後端時，瀏覽器可能依安全策略封鎖混合內容；跨來源存取也可能受到來源限制。建議讓本機面板與受控介面採用明確一致的存取路徑；確有跨來源需求時，再依核心能力設定精確來源，不要把允許所有來源當成通用解法。

面板可能會將後端位址與憑證儲存在瀏覽器中，因此更換瀏覽器後需要重新設定，使用共用裝置後也應清除已儲存的內容。截圖時請隱藏連線網域、訂閱來源、節點位址與憑證；複製除錯資訊時，只保留與故障相關的欄位。分享記錄前應檢查內容，而不只是檔名；連線詳細資料往往比主設定更容易洩漏實際存取紀錄。

透過連線詳細資料完成驗證

策略頁適合確認選擇鏈，連線頁適合確認命中規則與最終出口，記錄頁則適合排查解析失敗、提供器更新與路由錯誤。調整規則時，先記下測試請求的時間與目標，再對照該筆連線，避免在持續更新的清單中誤認其他程序。部分連線是在修改前建立的，不會因切換策略就立即重新路由；必要時只關閉對應連線，再送出新請求，以減少對其他業務的影響。

請分開看待面板中的自動測速與實際業務測試。測試成功一次，只代表當時的測試請求已完成；節點能否連線至目標服務，還取決於協定、連接埠、UDP 能力、服務端限制與出口路徑。遇到特定網站異常時，可暫時固定手動節點，排除自動切換帶來的變數，再觀察網域解析、命中規則與連線錯誤。不要用頻繁測速取代具體故障記錄，也不要只根據一次結果重新排列所有規則。

透過控制介面修改與直接修改設定檔，持續性不一定相同。有些面板操作只會改變記憶體中的狀態，有些選擇會由核心或用戶端快取；重新載入後能否保留，取決於實際實作。長期設定應回到本機設定或用戶端設定中儲存，並在重新載入後驗證；暫時性的診斷操作則應記錄變更並及時還原，避免下次排查時從已偏離檔案內容的執行狀態開始。

完成一次進階調整後，請依固定順序驗收：設定可正常解析、提供器成功載入、DNS 路徑清楚可追蹤、目標連線進入核心、命中預期規則，且最終出口符合目的。每次只變更一項主要因素，並保留可用的回復檔案。日常安裝與首次連線請參閱快速上手教學；需要更換平台或用戶端時，請前往下載頁選擇；設定概念則可在術語指南中繼續查閱。