mihomo 進階設定

策略組類型與實際應用

先分清規則目標與實際出口

規則決定連線要交給哪個目標，策略組再決定該目標最後使用哪個出口。規則中的名稱必須與代理、策略組或內建策略完全一致，大小寫與空格也都屬於名稱的一部分。建議先定好穩定的業務組名稱，再讓訂閱更新只影響組內成員。如此一來，即使代理項目有所變動，規則仍可指向同一個業務組，不必一併重寫所有規則。

select 適合手動指定出口。即使某個成員暫時無法使用，它也不會自動切換到其他成員。用戶端面板中的選擇通常可以保存，但是否能保留仍取決於設定名稱與用戶端實作。排查時不要只看組名，應展開至實際代理，確認目前選取的成員，並查看新連線使用的完整策略鏈；已建立的長連線通常不會立即切換。

依目標選擇自動策略

url-test 會依據探測結果選擇成員，適合可接受出口變動的流量。探測結果反映的是連線至指定網址的狀況，不代表所有網站或各種通訊協定的使用體驗。某個成員連到測試網址的表現良好，仍可能無法順利使用特定服務。tolerance 可減少因些微差異而頻繁切換，但無法保證出口固定；需要維持工作階段身分的服務，應另外使用手動策略組。

fallback 更重視成員順序：在健康檢查判定可用的成員中，優先使用排序較前面的出口。適合主要出口與備援出口已有明確先後順序的情境，而非追求每次都選擇探測時間最短的成員。load-balance 則會將連線分配給多個成員，但不會把單一下載連線合併成多個出口的總頻寬。登入、付款或限制來源 IP 的服務，不適合直接套用輪替策略。

以雙層結構區分日常選擇與自動探測

實用的架構是外層手動組、內層自動組。外層提供自動選擇、固定代理與直連等選項，內層只放入需要測試的代理成員。不要再把外層組放進內層，否則會形成循環參照。層數也不宜過多：從規則目標往下展開，兩三步就能找到實際出口，通常比難以追蹤的多層巢狀結構更容易維護。

以下範例只引用內建的 DIRECT，可用來了解策略組之間的參照方式，但不代表已設定遠端代理出口。實際使用時，請在自動組的成員清單中加入現有設定裡確實存在的代理名稱，再視需求保留或移除直連選項。測試網址使用 HTTPS，探測間隔以秒為單位；測試網址本身是否連得上，也會影響健康檢查結果。

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - AUTO
      - DIRECT
  - name: AUTO
    type: url-test
    proxies:
      - DIRECT
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

rules:
  - DOMAIN-SUFFIX,github.com,PROXY
  - MATCH,DIRECT

如果代理來自 proxy-providers，策略組可以透過 use 引用提供者，省去複製一長串成員名稱。先確認提供者已成功載入，再檢查策略組是否包含預期成員。篩選條件應由寬到窄逐步新增；條件設得太嚴，即使訂閱更新成功，策略組也可能沒有可用成員。遇到成員清單為空時，繼續調整探測參數也無法解決問題。

驗證策略組時，先在面板確認組別類型、候選成員與目前選擇，再建立一條新的服務連線。記錄中出現探測成功，只能證明健康檢查流程正常，不能取代實際服務測試。切換策略組後若頁面沒有變化，可以關閉該應用程式的舊連線，或重新開啟應用程式再測試，不必立刻重新啟動所有網路服務。模式的基本差異請參閱代理模式說明。

以訂閱方式管理規則集

規則決定順序，規則集管理內容

rules 決定執行順序，rule-providers 則提供可重複使用的比對內容。將大量網域移至規則集後，主設定仍須透過 RULE-SET 引用，並指定命中後採用的策略。宣告規則集不代表它會自動參與分流。核心通常由上而下檢查規則，第一個符合的項目就會生效；因此，本機例外、業務規則與最後的兜底規則之間如何排序，比檔案拆成幾份更重要。

建議先建立少量、名稱明確的集合，例如開發服務、區域網路位址，以及需要使用特殊出口的服務。不要為了分類完整，就在多個集合重複維護同一批網域。若無法避免規則重疊，應在主規則中明確指定優先順序並記錄原因。每新增一條例外，都應能回答三個問題：比對什麼、交給哪個策略，以及為何放在這個位置；若說不清楚，日後更新時就很難判斷是否能刪除。

讓 behavior 與檔案內容一致

behavior: domain 用於網域項目，ipcidr 用於 IP 網段，classical 則用來存放包含規則類型的傳統規則內容。這三者不能任意互換。網域集合中放入完整的 DOMAIN-SUFFIX 語法，或在傳統規則集合中只寫純網域，都可能導致載入失敗或比對結果不符預期。請先查看檔案格式，再選擇對應的行為類型，不要只憑檔名猜測。

format 也必須符合實際資料格式。YAML 規則集通常使用 payload 陣列；文字格式則逐行讀取；二進位規則集有自己的產生方式，不能只改副檔名就當成二進位檔。同一個網域來源若提供多種格式，請選擇核心明確支援的格式，並讓路徑副檔名反映檔案實際內容。載入記錄中的解析錯誤，比瀏覽器能否開啟下載網址更能說明問題。

# 合併至主設定；rules 的位置需配合現有規則調整
rule-providers:
  development:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/development.yaml

rules:
  - RULE-SET,development,PROXY
  - MATCH,DIRECT

# 儲存至核心設定工作目錄下的 rules/development.yaml
payload:
  - '+.github.com'
  - '+.githubusercontent.com'

從本機驗證到遠端更新

上述範例假設已有名為 PROXY 的策略。相對路徑通常以核心工作目錄為基準，不一定是目前在編輯器中開啟的檔案所在目錄。先用本機檔案確認行為類型與比對結果，再改用遠端訂閱，就能將格式問題與網路問題分開排查。測試時，請選擇規則集中的一個網域建立新連線，並在連線詳細資訊中確認命中的是對應規則集，而不是剛好使用相同出口的兜底規則。

遠端來源使用 type: http，並設定來源網址、快取路徑與更新間隔。網址應由維護者實際提供，不要把網頁展示頁當作原始規則檔。更新頻率應配合來源的變動速度；幾天才更新一次的清單若頻繁下載，通常只會增加請求量與排查雜訊。涉及帳戶資訊的網址只應保存在本機設定中，不要放進公開截圖、共用儲存庫或故障回報內容。

規則更新失敗時，先釐清是下載失敗、內容解析失敗，還是引用錯誤。下載失敗時，檢查來源是否可連線，以及下載時使用的出口路徑；解析失敗時，確認回應內容是否變成網頁、錯誤訊息或其他格式；引用錯誤則檢查提供者名稱與 RULE-SET 名稱是否一致。現有快取可能讓流量暫時維持正常，但不能因此認定更新成功，還要一併查看更新時間與載入記錄。

網域規則應盡量放在需要解析目標位址的地理位置或網段規則之前。對於明確不希望觸發額外解析的位址規則，可依語法使用 no-resolve，但它並非所有規則都適用的通用後綴。已有真實位址的連線仍可參與位址比對；只有網域、沒有實際解析結果的連線，則可能略過相關判斷。調整這類參數前，應先確認希望省略的是哪一次解析。

維護時保留一份已驗證的本機例外集合，將訂閱內容視為外部輸入，不要把它當成個人規則的唯一來源。更新後先測試幾條具代表性的連線，再逐步擴大使用範圍。發現分流錯誤時，記錄命中的規則與目標策略，再決定要修改集合或調整順序。直接把 MATCH 改成另一個出口，可能會掩蓋問題，卻也會改變許多原本正常的連線。

最佳化 DNS 設定

依解析對象拆分流程

最佳化 DNS，首先要釐清是誰在查詢、查詢什麼，以及請求從哪裡送出。應用程式可能使用系統解析器，也可能自行發出加密 DNS 請求；核心也需要解析代理伺服器的網域。即使這三種請求都連到同一個上游，也不代表它們走相同的處理路徑。排查時先整理應用程式到核心、核心到上游，以及核心到代理伺服器之間的關係，再修改欄位，就能避免混淆引導解析與一般服務解析。

default-nameserver 主要用來解析 DNS 上游本身的網域，為加密解析建立起點。nameserver 是一般查詢所使用的上游，proxy-server-nameserver 則可指定解析代理伺服器網域的解析器。後者特別適合處理代理尚未建立時的啟動依賴。如果解析代理網域的請求也必須經過該代理，就可能形成循環，導致設定已載入，卻始終無法建立對外連線。

先建立容易理解的最精簡 DNS 設定

以下片段示範使用 Fake-IP 的基本架構，並在本機監聽。一般 UDP 上游與 HTTPS 上游的網路路徑不同，前者也不提供傳輸加密。這裡是為了說明引導層與服務層的分工，並非適用於所有網路的固定解答。請先確認目前網路能連上所選的解析器，再考慮加密方式、策略路由與備援機制。上游位址增加，不代表解析結果就會更穩定。

dns:
  enable: true
  listen: 127.0.0.1:1053
  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:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - '*.lan'
    - '*.local'

將 DNS 監聽位址設為 127.0.0.1:1053，只代表核心提供本機解析服務，不表示系統會自動使用它。一般系統 DNS 設定通常無法指定任意連接埠，還需要透過用戶端的 DNS 接管、TUN 劫持或其他明確的轉送路徑。若系統仍在使用原本的解析器，修改 nameserver 後看不到變化並不意外。應先確認查詢確實進入核心，再比較上游回傳的結果。

依網域選擇解析器，謹慎加入備援機制

nameserver-policy 可依網域等條件指定解析器，適用於企業內部網域、家庭裝置網域或有特定解析需求的服務。內部網域應交由能回傳內部位址的解析器處理，而不是送往公共服務。網域策略決定使用哪個解析器，不等於最終連線會使用哪個出口。取得正確位址後，連線仍須經過規則與策略組；這兩個階段都應分別驗證。

fallback 不能簡單理解成主要解析器逾時後才使用的第二個位址。它會與 fallback-filter 一起參與結果判斷，可能額外發出查詢。若設定不適合目前網路的篩選條件，反而可能以另一個不適用的結果取代原本可用的結果。只有在能明確說明哪些回應需要替換時，才加入這一層；否則先用少量可靠的上游建立基準，會更容易判斷問題來源。

啟用 respect-rules 後，DNS 上游連線可以遵循路由規則，但也必須妥善處理代理伺服器網域解析等啟動依賴。不要強迫所有 DNS 請求都導向尚未可用的代理組。測試時，請分別記錄上游連線與服務連線使用的出口：兩者可以不同，而且通常就應該不同。關於此欄位與備援解析的詳細說明，請參閱DNS 欄位解析。

加密 DNS 失敗時，應分情況排查。若出現網域解析失敗，先檢查引導解析；若已取得位址但交握失敗，檢查系統時間、憑證信任與連線路徑；若上游連線成功但回應異常，則檢查網域策略與服務回應。不要關閉憑證驗證來掩蓋網路或時間問題，也不要在沒有證據時連續更換多個上游。每次只調整一個變數，並保留可重現的查詢對象。

快取可能讓修改後的結果暫時看不出變化。系統、瀏覽器與核心都可能保存解析結果，應用程式也可能沿用舊連線。驗證前先關閉目標應用程式的舊連線，依照用戶端提供的方式清除相關快取，再重新查詢。命令列直接查詢本機監聽器，與使用瀏覽器開啟網頁，驗證的是不同路徑；兩者結果不同時，應先確認瀏覽器是否使用獨立解析器，不要立刻認定核心設定沒有生效。

最後檢查 IP 位址類型。停用 DNS 回傳 IPv6，不代表整個系統的 IPv6 通訊都已停用；應用程式仍可能使用快取位址或自行解析。反過來，允許回傳 IPv6 也要求實際網路具備可用的連線路徑。若部分網站需等待一段時間才開啟，請分別觀察 IPv4 與 IPv6 的連線結果，再決定要調整哪一層。DNS 設定的目標是取得適合目前網路路徑的結果，而不是盡可能填滿所有欄位。

TUN 流量接管與 Fake-IP 對應

Fake-IP 用來對應網域，不是遠端出口

在 Fake-IP 模式下，核心可以回傳對應位址給應用程式，並記錄該位址與網域之間的關聯。應用程式連線至對應位址時，核心會還原網域，再執行路由與出站處理。對應位址不是目標伺服器的公開 IP，也不是代理伺服器位址。看到 198.18.0.0/16 範圍的結果時，不應直接判定為解析錯誤；應一併確認連線是否由核心接收，以及能否還原出預期網域。

Fake-IP 與 TUN 是兩個不同面向。前者處理解析與網域對應，後者透過虛擬網路介面接收流量；兩者經常搭配使用，但無法互相取代。只啟用 Fake-IP，無法讓所有應用程式自動經過代理；只啟用 TUN，也不保證每條連線都帶有網域資訊。應串接檢查解析入口、虛擬介面與規則處理流程，而不是把單一開關當成完整的網路接管方案。

依權限、路由與解析順序啟用 TUN

TUN 通常需要管理員權限、服務元件或系統授權。Clash Plus、Clash Verge Rev 與 FlClash 等用戶端的設定入口與權限處理方式各不相同，請先依照目前使用的用戶端說明安裝必要元件。設定檔中的 enable: true 只代表要求核心啟用；若系統拒絕建立介面或新增路由，仍然無法接管流量。查看記錄中的介面與路由建立結果，比反覆點選開關更有效。

tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

此片段須搭配已啟用的 dns 設定使用。auto-route 會要求核心設定相關路由，auto-detect-interface 可協助辨識出站介面，dns-hijack 則會將符合條件的一般 DNS 流量交由核心處理。它不會自動接管所有 HTTPS 加密解析；應用程式內建的加密 DNS 仍須另外分析。不同平台與網路堆疊的支援範圍，應以執行記錄與目前核心文件為準。

system、gvisor 與 mixed 是網路堆疊選項，不是品質排名。它們在通訊協定處理、系統整合與相容性方面各有取捨。特定應用程式發生異常時，可在其他設定不變的情況下切換網路堆疊進行比較，但不要同時修改 DNS、路由與 MTU。只有一次改變一個變數，才能判斷改善究竟來自網路堆疊還是其他設定。

處理區域網路、VPN 與對應例外

區域網路裝置通常需要直接連線至實際位址，例如印表機、投放裝置與內部管理頁面。fake-ip-filter 可讓符合條件的網域不取得對應位址，但不代表相關連線會自動直連。還需要讓解析器回傳正確的內部位址，並透過規則指定合適的出口。只新增篩選條件，卻沒有設定正確的內部 DNS，常見結果是對應位址不再出現，裝置仍然無法連線。

企業 VPN、虛擬機器、容器及其他代理軟體都可能安裝路由。並行啟用前先記下各自使用的網段，特別留意是否與 Fake-IP 位址範圍重疊。自動辨識介面也可能在多網卡環境中選到不適合的出口。此時應依實際介面與路由調整，不要直接複製其他裝置的介面名稱。修改企業內部網路設定前，也應遵守裝置管理規範，避免破壞原有的存取界線。

某些程式會將解析出的位址用於通訊協定驗證、區域網路探索或位址顯示，無法接受對應位址。處理相容性問題時應縮小範圍：先確認發生異常的網域，再新增必要的篩選條件，並重新測試其他網域是否仍依預期建立對應。將所有網域加入篩選雖然看似簡單，卻會改變整套網域還原機制，使原本可透過網域比對的連線改為依賴實際位址與嗅探。

建議依序驗證：先確認未啟用 TUN 時系統代理可正常使用，再啟用 TUN、檢查介面與路由，接著確認 DNS 請求進入核心，最後測試不遵循系統代理的應用程式。發生故障時，依相反順序逐步還原。不要把瀏覽器能成功連線視為整個系統都已接管，因為瀏覽器可能仍在使用系統代理；也不要只憑一筆對應位址查詢結果，就認定所有流量都已進入核心。

網域嗅探與規則補充

嗅探用來補足資訊，不能取代 DNS

連線進入核心時，可能只有目的位址，沒有可用的網域資訊。例如，應用程式使用自己的解析器、連線經由透明接管，或程式直接使用快取位址。網域嗅探會嘗試從部分通訊協定的初始資料中擷取主機資訊，讓核心有機會依網域套用規則。它適合補足缺少的資訊，但不是能辨識所有流量的網域偵測工具，也不代表能讀取加密連線的所有內容。

HTTP 可能包含主機欄位；條件允許時，TLS 交握可能提供伺服器名稱；QUIC 則需要核心辨識相關交握內容。若用戶端隱藏伺服器名稱、使用核心不支援的通訊協定，或資料不足以完成辨識，嗅探就可能無法取得結果。此時應讓規則回到位址或兜底路徑，不要把嗅探失敗誤認為代理出口無法使用。通訊協定本身未揭露的資訊，不會因為擴大連接埠範圍就憑空出現。

先從範圍明確的連接埠開始

以下片段會在常見服務連接埠啟用 HTTP、TLS 與 QUIC 嗅探，並關閉依據嗅探網域改寫目的位址的功能。這適合先觀察辨識結果，再決定是否需要進一步接管目標解析。合併時請確認用戶端是否已產生 sniffer 欄位，避免重複建立相同的頂層鍵。先測試一兩個明確的網頁請求，確認記錄中的網域來源有何變化，再擴大應用範圍。

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

parse-pure-ip 允許對純位址連線嘗試辨識，可協助處理部分缺少網域關聯的流量，但無法保證一定成功。force-dns-mapping 涉及在相應的 DNS 對應情境中繼續嘗試嗅探，不能取代 DNS 監聽與轉送設定。不要只憑欄位名稱，就認定它會強制所有應用程式使用核心 DNS；請求是否進入解析模組，仍取決於實際網路路徑。

override-destination 是需要另外評估的功能。啟用後，核心可以依據嗅探到的網域變更後續目標處理方式，而不只是補充比對資訊。對於使用特殊解析、固定位址或依賴特定入口的應用程式，這可能改變原有連線路徑。先保持停用可減少變數；只有確認服務確實需要，並了解重新解析與路由的影響後，才依網域或通訊協定範圍謹慎調整。

比對網域來源，確認是否真的需要嗅探

測試時先關閉目標應用程式的舊連線，再建立新連線，觀察連線詳細資訊中的網域、目的位址與命中規則。既有連線不會因為啟用嗅探就重新執行完整交握。若連線原本已透過 Fake-IP 還原網域，啟用嗅探前後套用相同規則是正常現象；此時額外嗅探的效益可能不大，不必為了欄位看起來齊全而強行啟用所有選項。

啟用後若特定服務發生異常，請先針對該服務比較啟用與停用嗅探的結果，不要立刻更換整套 DNS 設定。可以使用核心支援的略過網域等範圍設定，縮小處理對象；但例外應根據實際觀察到的網域設定，不要整段複製其他設定。強制範圍過大，會讓更多流量等待通訊協定辨識；略過範圍過大，則可能讓原本需要網域規則的連線改走位址分流。

連接埠無法唯一判斷通訊協定。有些應用程式會在常見網頁連接埠使用自訂通訊協定，也有服務會在非標準連接埠提供 TLS。限制連接埠有助於控制處理範圍，但無法保證範圍內的每條連線都能辨識。對於自訂服務，請先確認實際使用的通訊協定，再決定是否納入；加入所有連接埠通常只會擴大排查範圍，無法解決交握內容遭隱藏或核心尚不支援辨識的問題。

QUIC 通常使用 UDP，有些應用程式也會在條件不符時改用 TCP。測試時若只看網頁能否開啟，可能會忽略通訊協定已經改變。請搭配連線記錄確認使用的傳輸方式，再比對嗅探結果與命中規則。不要只為了讓記錄看起來整齊，就直接封鎖所有 UDP；語音、即時通訊與部分應用程式都可能依賴 UDP，應依實際服務需求處理，而不是只看記錄的外觀。

嗅探結果也涉及隱私與疑難排解的界線。擷取到的網域可能出現在連線記錄或除錯記錄中，分享截圖與回報問題前，請確認沒有包含內部服務名稱。一般故障通常只需要提供規則類型、策略鏈與匿名化的目標特徵，不必上傳完整瀏覽記錄。記錄內容越多，不代表問題就越容易定位；清楚記下啟用前後的差異，往往比累積大量資料更有幫助。

本機覆寫與多訂閱合併

以最終執行設定為準

圖形化用戶端通常會合併訂閱內容、全域設定與本機覆寫，再交給核心。編輯畫面顯示的是輸入內容，執行設定才是最後結果。相同的 DNS 欄位可能同時出現在訂閱與用戶端設定中，實際採用哪一份取決於合併順序。排查前先找到用戶端提供的執行設定預覽或匯出功能，確認核心實際收到的內容，避免反覆修改之後仍會被覆蓋的檔案。

建議依照用途拆分：訂閱提供代理與必要的提供者資訊，本機則維護業務組、規則優先順序、DNS 與裝置相關設定。裝置相關欄位包括監聽位址、連接埠、TUN 與控制器，不適合在不同系統間原封不動地同步。同步前應先區分可重複使用的業務需求，以及只適用於目前裝置的環境參數；檔案成功匯入，不代表路由與權限在其他裝置上也能正常運作。

不要假設所有合併工具採用相同規則

不同用戶端對映射、陣列與純量可能採用不同的合併策略。映射可能逐層合併，也可能整段取代；陣列可能附加至前方、後方，或直接覆寫。核心本身不會統一用戶端的這些行為。尤其是 rules 陣列，若本機例外被加在原設定的 MATCH 後面，就永遠不會生效。一定要檢查最終順序，不能只憑介面顯示已儲存就判定設定成功。

以下是可交由覆寫功能處理的局部設定意圖範例：固定本機監聽位址並使用規則模式，同時要求保存選擇狀態。這不是適用於所有用戶端的通用覆寫檔格式；請將這些欄位放入目前用戶端支援的 YAML 合併入口。若入口要求使用指令碼或專用結構，請遵循該入口的規則，不要把 YAML 貼進指令碼編輯器。profile 的效果也應在重新啟動後確認。

mixed-port: 7890
allow-lan: false
mode: rule

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

同一個 YAML 映射中出現重複鍵，應視為需要修正的問題。有些解析器會報錯，有些可能保留後一份值，不能依賴這種差異來覆寫設定。欄位縮排請使用空格；字串中若含有可能被視為特殊語法的內容，應加上引號。修改後先測試語法，再載入執行環境。YAML 能夠解析，只代表語法正確；策略參照、檔案路徑與規則行為仍須另外驗證。

多個訂閱先區分來源，再處理名稱與參照

不同來源可能包含同名代理、同名策略組與同名提供者。直接合併可能造成衝突，或讓規則指向非預期的項目。較穩妥的做法是為不同來源建立清楚的提供者命名空間，再由本機策略組透過 use 選擇成員。若確實需要重新命名代理，必須同步更新所有參照；只修改清單中的顯示名稱，卻未更新組內參照，會留下啟動錯誤或空白成員。

合併多個來源時，也不應複製多份完整的 DNS 與規則區段。先指定哪一份設定擁有最終決策權，再將其他來源視為代理資料來源。若某個訂閱包含必須保留的專用規則，應個別審查並放在明確的位置，不要讓它覆蓋所有本機策略。來源越多，越需要清楚規劃停用與移除方式：停用某個提供者後，所有引用它的策略組是否仍可運作，應能事先判斷。

在終端機環境中，可於部署前使用核心的設定測試功能。命令中的目錄必須替換成實際的設定工作目錄；以下命令適用於目前目錄已存放設定與依賴檔案的情況。測試無法取代實際網路連線，但可以提前找出欄位、參照或檔案載入等問題。若圖形化用戶端內建設定檢查功能，也應先完成檢查再重新載入，避免未驗證的設定直接成為啟動預設值。

mihomo -t -d . -f ./config.yaml

訂閱自動更新後，請抽查最終設定中的監聽連接埠、規則前幾項、最後的兜底規則與重要策略組成員。這些位置最容易看出覆寫關係是否改變。更新後若出現異常，先還原上一份可正常使用的輸入，再比較產生結果；不要立刻永久停用自動更新，之後便置之不理。保留容易理解的變更記錄，例如新增哪個網域例外、調整哪個策略組的成員來源，日後排查才有依據。

跨裝置同步時，只同步明確需要的檔案，並排除記錄、快取與裝置產生的暫存設定。訂閱網址與代理憑證屬於敏感資訊，不適合放進公開儲存庫。詳細作法請參閱多裝置設定同步。若遇到連接埠衝突，除了修改本機覆寫，也要一併調整系統代理與應用程式設定；詳細排查步驟請參閱連接埠占用排查。

外部控制面板與驗證流程

分清控制連接埠與代理連接埠

external-controller 提供核心管理介面，讓面板查看狀態、切換策略或執行相關管理操作。它無法取代 mixed-port 來接收一般代理流量。瀏覽器代理設定應填入代理監聽連接埠，面板連線設定才應填入控制器位址。混用這兩個連接埠，常見結果是瀏覽器無法連網，或面板顯示連線失敗，但核心本身仍在執行。

控制介面可以影響實際網路行為，應優先限制在本機回送位址。以下設定示範本機控制入口與本機面板目錄，適用於只在本機使用的基本情境。面板檔案必須事先放在核心工作目錄下的 ui 目錄；核心不會只因為設定了這個路徑就自動產生網頁。若用戶端已內建控制器與面板管理功能，應優先使用內建入口，避免手動建立重複的監聽服務。

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

回送位址監聽雖然限制了遠端存取，但不代表已完成所有安全設定。本機其他程序仍可能連到這個連接埠。請依照用戶端支援的方式，為控制器設定獨立的 secret，並在面板連線設定中填入相同值。不要將實際密鑰寫入公開檔案或範例，不要把包含驗證資訊的面板連結傳給他人，也不要使用代理帳戶密碼作為控制器密鑰。修改後重新連線面板，確認舊的驗證資訊已失效。

先確認介面，再測試瀏覽器面板

面板無法開啟時，先確認核心是否正在執行、控制連接埠是否有監聽，再檢查靜態網頁目錄。在未啟用驗證的本機基本環境中，可使用以下命令確認設定介面是否有回應；若已啟用驗證，請透過用戶端支援的入口操作，或在本機請求中提供驗證資訊，不要為了測試而暫時讓控制器監聽所有網卡。請求遭拒與完全無法連上連接埠，是兩種不同的排查情況。

curl --noproxy '*' http://127.0.0.1:9090/configs

介面可連線但面板無法使用時，請檢查面板儲存的控制器位址、驗證資訊與瀏覽器錯誤訊息。若以 HTTPS 開啟的網頁連線至本機 HTTP 介面，可能遇到混合內容或瀏覽器本機網路存取限制；跨來源存取也可能受到控制器來源政策影響。不要直接允許所有來源來當作通用解法，應優先使用用戶端內建面板或同源本機頁面，並依實際需求限制允許的來源。

遠端管理時，不能只把監聽位址改成所有網卡就算完成設定。還必須妥善規劃驗證方式、網路存取範圍、加密傳輸與防火牆規則。若透過受控的本機轉送或管理網路就能完成操作，通常不必直接將控制介面公開在公共網路上。面板頁面可以開啟，不代表管理連線已受到保護；頁面與介面可能使用不同位址與傳輸方式，必須分別確認。

透過連線記錄完成驗證流程

面板最實用的功能，是追蹤新連線的處理過程：來源應用程式、目標網域或位址、命中規則、策略鏈與最終出口。驗證時先選定明確目標，再發出一次新請求，避免在大量並行連線中憑印象判斷。看到某個組名，不代表它就是實際出口；應繼續展開查看組內選擇。若規則命中正確但連線失敗，接下來應檢查實際代理與解析，不要繼續調整規則順序。

面板顯示的策略選擇可能與設定檔中的預設成員不同。啟用選擇狀態保存後，重新載入設定可能會還原先前的選擇；調整組內順序也不一定會改變目前出口。排查時先記錄面板中的實際狀態，再手動切換。重新載入設定也不代表所有舊連線都已關閉，測試結果應以新連線為準。對需要持續運作的應用程式，請先評估主動關閉連線是否會中斷作業。

建議依固定順序完成一次完整檢查：設定語法與參照通過測試；混合代理連接埠與控制連接埠正常監聽；一般模式下能建立連線；DNS 查詢進入預期模組；規則命中正確；策略組可展開至實際出口；有需要時才啟用 TUN 與嗅探。每增加一個模組，就保留一次驗證結果。如此遇到回歸問題時，便能回到最近一次正常運作的階段，不必同時推翻所有設定。

故障回報應簡潔但資訊完整，包含作業系統、用戶端名稱、是否使用 TUN、異常目標類型、命中規則與重要錯誤訊息。不要公開完整訂閱、驗證資訊或所有瀏覽記錄。基本問題可繼續參閱常見問題；若已連線卻無法開啟網頁，可依照逐項排查清單，從系統代理一路檢查到 DNS 與防火牆。設定是否容易維護，最終取決於能否說明一條連線為何如此處理，以及發生問題時該還原到哪個階段。