進階設定 · MIHOMO

Clash 進階設定指南

從策略選擇到流量接管，依設定層級確認生效狀況。

先確認基本連線正常，再調整規則、DNS 與網路接管方式。入門指南帶你快速匯入訂閱、選擇節點並確認連線；本頁則整理參數之間的關係，協助管理長期設定並排查修改後的異常。初次使用可先選擇 Clash Plus；其他用戶端與系統架構選項請見用戶端下載頁。

以下內容以 mihomo 的設定語意為主。不同用戶端的介面、核心功能與設定產生流程可能各異，介面名稱不一定對應 YAML 欄位。每段設定都會標明示範範圍；內容未提供實際代理節點，也不是可直接連線的完整設定。修改前請先匯出目前設定，記下核心類型、接管模式與重現問題的網址；每次只調整一個層級，避免多個問題互相干擾。

策略組類型與實作

策略組負責決定「符合規則後要使用哪個出口」，而不是「哪些請求應該走代理」。規則會將連線交給某個組別，再由該組依手動選擇、健康檢查或分配演算法決定下一個出口。排查時，先在連線詳細資料中確認命中的規則，再查看最後選用的節點；如果請求根本沒有進入目標組，調整測速間隔也無濟於事。組名也是設定中的引用名稱；修改後，必須一併檢查規則、巢狀組別，以及用戶端儲存的選擇狀態。

依用途選擇策略組類型

select適合需要明確控制出口的情境，組內可加入節點或其他策略組。url-test會根據探測結果選出表現較佳的候選項目；但探測只反映指定測試網址的狀況，不代表所有服務都會變快。fallback會優先使用清單中排序較前且通過檢查的候選項目，適合出口優先順序固定的環境。load-balance會將不同連線分配給候選項目，不會拆分單一下載連線來累加頻寬。

類型決策依據主要限制
select由使用者明確選擇所選出口失效時通常需要手動處理
url-test候選項目的探測結果測試網址與實際服務可能不一致
fallback清單順序與可用狀態優先順序比最低探測耗時更重要
load-balance連線分配策略服務端可能看到多個出口 IP

先建立可追蹤的手動選擇層

建議先保留一個頂層手動選擇組，將自動選擇組放在其中，而不是讓每條服務規則直接引用自動組。遇到異常時，可暫時固定出口，判斷問題是來自自動切換還是規則設定錯誤。以下僅示範引用關係，兩個候選項目都是內建策略，不代表可用的代理節點；實際使用時，請換成已匯入且能正常連線的節點或組別，並確認名稱完全一致。

mode: rule

proxy-groups:
  - name: 出口選擇
    type: select
    proxies:
      - DIRECT
      - 故障阻斷
  - name: 故障阻斷
    type: select
    proxies:
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.org,出口選擇
  - MATCH,DIRECT

自動組的關鍵參數包括測試網址url、檢查間隔interval與切換容差tolerance。測試網址應能穩定回應，且符合目前網路的存取條件；間隔過短會增加探測請求，過長則可能讓失效狀態維持較久。容差可減少候選項目表現相近時頻繁切換的情況；單位與欄位的實際定義，請以所用核心的文件為準。健康檢查失敗不代表節點一定完全離線；測試網域解析、目標網站限制及代理連線路徑都可能造成失敗。

確認切換是否影響實際連線

切換組別後，請重新建立連線再觀察。瀏覽器連線池、HTTP/2 長連線與持續下載可能仍在使用舊連線，因此出口沒有立即改變，不一定代表切換失效。請先關閉測試頁面，再建立新連線，並確認連線詳細資料中的完整策略鏈。若需要中斷舊連線，請使用用戶端提供的連線管理功能；不要為了更新狀態就直接重開整個系統，以免重要記錄遺失。

登入、付款及長時間維持的工作階段通常較適合固定出口。負載平衡可能讓同一服務的不同連線使用不同 IP，造成工作階段驗證或地區判定改變；這類服務可獨立指定手動組。巢狀組別也必須避免循環引用，例如甲組引用乙組，而乙組又引用甲組。設定能成功載入只是第一步，還要確認最終出口、失敗時的回退行為，以及恢復後的優先順序。更多參數比較請參閱自動策略組類型與設定方式。

規則集訂閱管理

規則集可將經常變動的比對內容，與相對穩定的出口策略分開管理。主設定只保留規則集宣告、引用順序與最終兜底規則，網域或網段清單則獨立維護。更新服務網域時不必改動整套策略，也更容易檢視變更內容。不過，外部規則集仍屬於設定輸入，請確認來源、格式與更新範圍；不能只因為檔案下載成功，就直接讓它改變本機規則的優先順序。

先釐清宣告、內容與引用方式

rule-providers用來宣告來源與解析方式，RULE-SET則是在規則清單中引用規則集；實際檔案提供比對項目。behavior決定內容要按網域、IP 網段或經典規則語法解讀；format則指定檔案格式。兩者不可混為一談，例如 YAML 檔案可以儲存網域清單，也可以儲存經典規則。副檔名不足以判斷核心能否正確解析檔案內容。

以下使用本機檔案建立最小驗證流程，避免同時引入網路下載問題。請將規則檔放在核心工作目錄的對應位置，再把宣告合併到現有設定中。路徑通常是相對於核心工作目錄，不一定相對於正在編輯的檔案；圖形化用戶端也可能使用獨立的設定目錄，請從記錄或設定管理頁面確認。沙箱與服務的執行方式也可能限制可存取的路徑。

rule-providers:
  本機網域：
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,本機網域,DIRECT
  - MATCH,出口選擇

對應的rules/local-domains.yaml內容如下。此處使用保留的範例網域，只用來確認檔案是否載入、規則是否命中；不會取代實際服務規則，也不會新增代理節點。

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

規則順序決定套用範圍

規則通常會由上而下比對，第一條符合的規則會決定後續處理方式。精確的例外規則應放在廣泛分類之前，兜底規則MATCH則放在最後。如果將範圍很廣的直連規則集排在服務代理規則之前，後者可能永遠不會命中。規則集彼此重疊很常見；維護重點不是讓所有集合完全不重疊，而是能說明某個目標為何被前面的規則攔截。

網域規則仰賴連線可取得的網域資訊；IP 規則則可能觸發解析。對於支援此參數的 IP 比對規則，no-resolve表示不要只為了比對這條規則而主動解析網域，並不表示整個連線從此不會查詢 DNS。是否使用此參數應視規則用途而定：內網網段例外通常不值得額外解析；若策略明確依賴目標 IP 的地理資訊，則要考量解析結果的來源。

改用type: http時，必須補上規則集網址，並明確設定更新間隔與快取路徑。先確認目前可用的網路能連上來源，再決定更新請求的出口；否則可能陷入「必須先有規則才能連上規則來源」的循環依賴。更新失敗時，核心可能繼續使用快取；但首次啟動時可能沒有快取可用，因此請分別測試已有快取與空快取的啟動情境，不要只看一次更新成功的提示。

依序檢查更新失敗原因

先從記錄確認是下載失敗、讀取檔案失敗，還是格式解析失敗。下載失敗時，檢查來源解析、TLS 連線與出口；讀取失敗時，檢查目錄權限與路徑；解析失敗時，則檢查payload結構、縮排與行為類型。經典規則集中的項目通常不會附帶最終策略，因為策略是由外層的RULE-SET指定；直接把完整主規則搬進去，可能造成欄位數量錯誤或語意混亂。

更新後，選一個確定包含在清單中的網域，以及一個確定不在清單中的網域，重新建立連線並確認命中結果；接著檢查是否有更前面的規則先行匹配。用戶端連線面板顯示的規則名稱，比「網頁可以開啟」更有參考價值：網頁能開啟，也可能只是命中兜底規則。保留上一份可用的規則檔與來源說明；發生分類錯誤時，先新增範圍明確的本機例外，再調查上游變更，不要立刻將整套規則改成全域代理。

DNS 設定最佳化

排查 DNS 時，先釐清兩件事：應用程式向誰查詢網域，以及核心向誰查詢最終 IP。應用程式可能使用系統 DNS、瀏覽器加密 DNS 或自己的解析器；代理節點的伺服器網域也需要先解析。只修改nameserver，不代表所有應用程式的查詢都會經過核心。建議先確認問題是否只出現在特定應用程式，再檢查查詢入口、解析上游與連線出口；不要一看到解析錯誤就同時更換所有位址。

拆解解析流程，逐步檢查

default-nameserver主要用來解析 DNS 上游本身的網域，負責提供引導解析；nameserver是一般解析上游；nameserver-policy則可為特定網域指定解析路徑。若節點伺服器網域需要獨立處理，可確認所用核心是否支援proxy-server-nameserver。不要讓節點解析依賴尚未建立的代理出口，也不要讓加密 DNS 伺服器的網域只能靠該伺服器自己解析。

以下範例會在本機回環位址開啟測試連接埠，並使用真實 IP 格式的上游，方便先確認解析流程。它不會自動修改作業系統的 DNS 設定，也不會自動啟用 DNS 劫持。範例啟用redir-host，以便觀察回傳的真實位址；若用戶端已管理 DNS，請先檢查最終設定，避免重複監聽連接埠。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver-policy:
    'example.org':
      - 223.5.5.5

若系統已安裝dig，可直接查詢這個監聽連接埠，再與系統預設解析結果比較。此處只驗證核心 DNS 服務入口是否正常，不代表瀏覽器已使用該服務。查詢逾時時，先檢查服務監聽狀態、連接埠占用與上游連線；若有回傳位址但網頁仍無法使用，請繼續檢查連線規則、TLS 交握與應用程式代理設定。

dig @127.0.0.1 -p 1053 example.org A
dig @127.0.0.1 -p 1053 example.org AAAA

選擇上游與網域分流策略

多個上游的執行方式與結果取用方式，取決於核心實作與欄位設定，不應直接把清單理解成主備順序。選擇上游時，應考量目前網路是否能穩定連線、是否適用於內部網域，以及回傳位址是否符合實際出口。公司內部網域通常應交由公司 DNS 解析器處理，公共解析器不了解內部區域；將內部網域送往外部，不但可能查詢失敗，也會增加網域資訊外洩的風險。

DoH 或 DoT 可保護 DNS 查詢傳輸，但不會自動修正錯誤的出口或路由，也不會讓目標服務略過分流規則。啟用依規則進行 DNS 路由前，應先了解respect-rules與節點網域解析之間的依賴關係，並為節點解析設定明確路徑。舊設定中的fallback與篩選條件也要一併檢查；不要只貼上一段上游清單，就假定解析選擇已經改變。

IPv6 應依實際網路能力決定，不要一律停用或啟用。只有在位址可解析、系統有可用路由，且用戶端接管方式支援相關流量時，IPv6 才能形成完整連線。若網頁偶爾卡住，可分別測試 A 與 AAAA 查詢，以及 IPv4 與 IPv6 連線，確認是否某一類位址持續失敗。即使只在 DNS 區段停用 AAAA 回應，也不保證應用程式不會透過快取或獨立解析取得 IPv6 位址。

快取、瀏覽器解析與故障複測

修改解析策略後，舊結果可能仍留在核心、作業系統與瀏覽器的快取中。先用明確的查詢確認新結果，再依用戶端提供的方法清除 DNS 快取、重新啟動測試應用程式並建立新連線。不要只是不斷重新整理同一個頁面；連線池可能根本沒有觸發新的 DNS 查詢。若問題只出現在瀏覽器，請檢查安全 DNS 設定與擴充功能的影響，並記錄停用相關功能前後的差異。

測試時請記錄查詢網域、記錄類型、回傳位址、耗時或逾時狀況，以及對應的連線記錄。NXDOMAIN、空結果與請求逾時並非同一種問題：前者表示網域不存在，空結果可能只是該記錄類型沒有資料，逾時則通常代表連線或上游回應有問題。更多應用程式端的檢查方式請見常見問題；確認問題位於解析環節後，再考慮調整 Fake-IP 或 DNS 接管方式。

TUN 與 Fake-IP

TUN 與 Fake-IP 分別處理流量入口與網域映射，雖然常一起使用，卻不是同一個開關。TUN 透過虛擬網路介面接收流量，適合接管不會主動遵循系統代理的應用程式；Fake-IP 則先回傳虛擬位址，再由核心依據映射還原網域並建立連線。系統代理通常需要應用程式主動遵循；TUN 則會涉及系統路由、權限與網路堆疊。是否需要啟用，應視哪些特定應用程式尚未被接管而定。

先確認目前由誰接管流量

同一台裝置同時執行多個 VPN、網路加速器或虛擬網卡工具時，路由與 DNS 可能互相覆蓋。先記錄系統代理狀態、現有虛擬介面與預設路由，再只保留一個接管入口進行比較。桌面用戶端可能透過服務程序取得權限，也可能要求授權；行動作業系統通常使用系統提供的 VPN 通道。不同平台的介面設定，不一定對應完全相同的底層路由行為。

以下片段只示範 mihomo 中 TUN、DNS 接管與 Fake-IP 的組合，不包含代理節點。用戶端可能已自動產生其中部分欄位，請以最終設定為準。啟用前，請確認能從本機介面關閉 TUN，並保留不依賴網路即可存取的原始設定副本。

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'
  nameserver:
    - 223.5.5.5

auto-route用來建立接管路由，auto-detect-interface協助選擇實際出口介面，stack則會影響流量處理方式。system、gVisor 與混合堆疊的可用性及相容性，取決於平台與核心建置；不要為了追求特定名稱就直接更換。先採用用戶端建議的預設值確認基本連線，再針對有問題的協定逐項比較，並記錄調整前後的日誌。

了解虛擬位址的使用限制

Fake-IP 位址不是目標伺服器的真實位址，不能直接用來判斷公網是否可連線。應用程式取得虛擬位址後，後續連線仍須經過持有映射資料的核心；若應用程式繞過 TUN 直接連線、映射資料遺失，或流量進入另一個代理執行個體，就可能無法還原目標網域。快取中若殘留虛擬位址，關閉接管後仍可能短暫連線失敗；請清除相關快取，讓應用程式重新解析。

fake-ip-filter列出的網域通常會改為回傳真實解析結果，但這不代表連線會自動直連，最終出口仍由規則決定。區域網路探索、依賴真實位址驗證的應用程式，或特定裝置通訊，可考慮精確排除，並確認是否確實解決問題。不要把所有網域都加入篩選清單來掩蓋接管異常；這會改變整套解析模式，也讓排查失去比較基準。

範例中的 DNS 接管只處理傳統目標連接埠為 53 的請求，不會直接解密應用程式自行使用的 DoH 或 DoT。瀏覽器內建解析、企業 VPN 內部解析及特殊網路介面都需要分別檢查。區域網路廣播、群播與某些本機服務也不是一般公網連線，不能只靠一個 TUN 開關就假設所有流量都會正確轉送。無法連線至路由器或印表機時，先檢查內網路由與解析，不要盲目更換代理節點。

依影響最小的順序還原

整台裝置斷網時，先關閉 TUN，確認預設路由與系統 DNS 是否恢復，再還原原始設定。若用戶端異常結束後路由未恢復，請使用用戶端的修復功能，或重新啟停網路介面；不熟悉系統路由指令時，不要直接照抄批次刪除路由的操作。基礎網路恢復後，再分別測試系統代理與 TUN，避免網路已失常時又繼續疊加規則。

穩定後，分別用瀏覽器、命令列，以及一個原本不遵循系統代理的應用程式進行測試，確認連線是否進入核心、是否帶有網域資訊，以及是否命中規則。UDP 服務還需確認節點協定與伺服器是否支援所需傳輸方式；TUN 收到流量不代表出口也支援。完整機制比較請參閱TUN 與系統代理的運作原理；先區分流量入口與出口能力，再決定下一步調整方向。

網域嗅探

網域嗅探用來補足連線上的網域資訊，不是解密網頁內容的工具。當應用程式透過獨立 DNS、快取位址或直接 IP 建立連線時，核心可能只看得到目標位址，無法套用預期的網域規則。嗅探會嘗試從 HTTP 請求或 TLS、QUIC 交握中取得可見的主機資訊，再用於後續判斷。它只能利用協定實際公開的資訊；遇到加密的用戶端問候、非標準協定或純 IP 服務時，不保證能取得網域。

先確認缺少的是網域資訊

在連線面板中找出一筆可以穩定重現的請求，確認目標只顯示 IP，且網域規則沒有命中。若面板已顯示正確網域，卻仍套用錯誤規則，應優先檢查規則順序與策略引用；啟用嗅探通常無法解決問題。若瀏覽器使用獨立的加密 DNS，先確認此解析路徑是否符合預期，再判斷要調整瀏覽器的解析方式，還是透過核心嗅探補足資訊。

以下採用較保守的連接埠範圍，只示範 HTTP 與 TLS 嗅探。將override-destination設為關閉，可降低直接使用嗅探結果改寫連線目標所帶來的影響；可取得的規則資訊與實際行為仍須依所用核心確認。請將片段合併至現有設定，不可當作獨立的連線設定使用。

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true
  override-destination: false
  sniff:
    HTTP:
      ports:
        - 80
        - 8080
    TLS:
      ports:
        - 443
  skip-domain:
    - '+.lan'
    - '+.local'

parse-pure-ip允許嘗試處理純 IP 連線，force-dns-mapping則與特定 DNS 映射情境下的嗅探行為有關；兩者都不保證「所有連線一定能取得網域」。連接埠範圍決定要嘗試檢查哪些連線，不代表該連接埠上的流量一定使用對應協定。若應用程式在非標準連接埠使用 TLS，是否擴大範圍應依實際需求判斷，避免為了解決單一問題就檢查所有連接埠。

分清補足規則資訊與覆寫目標

嗅探取得網域後，可協助判斷服務類別；目標覆寫則可能進一步改變原本要連線的目標。某些服務依賴固定 IP、自訂 Host 或特殊反向代理，貿然啟用覆寫可能導致原本正常的請求失敗。排查時應將「是否嗅探到網域」與「是否允許覆寫目標」分成兩項測試；先觀察日誌與規則命中變化，再確認服務交握是否正常。

一個 IP 可能同時承載許多網域，單靠位址反查無法準確推斷本次請求的主機。TLS 中可見的伺服器名稱也不一定涵蓋應用程式後續載入的所有資源；網頁可能還會連線至內容傳遞網路、登入服務、圖片伺服器與 API。因此，即使首頁命中正確，也不能認定整個網站都使用同一策略。請依應用程式或時間範圍檢查連線清單中的相關請求，尤其是登入重新導向與資源載入失敗的情況。

QUIC 通常使用 UDP；若要啟用對應嗅探，還需確認核心支援、實際連接埠與出口的 UDP 能力。停用瀏覽器 QUIC 後問題有所變化，只能說明協定路徑不同，不能直接證明 UDP 節點一定無法使用。若 TLS 交握中的資訊不可見，嗅探也無法憑空還原網域。此時較合適的做法可能是讓應用程式 DNS 查詢進入核心、使用已知服務規則，或在必要時依程序分流，而不是無限制擴大嗅探範圍。

設定排除項並保留複測紀錄

內網服務、裝置管理頁面與少數相容性敏感的應用程式，可設定明確的排除項。排除範圍應盡可能精確，先針對一個可重現的網域或目標測試，再評估是否擴大。不同核心支援的略過網域、來源位址與目標位址欄位可能不同；設定檢查若顯示未知欄位，不要繼續堆疊參數。先確認核心身分與支援範圍，再決定保留哪些選項。

驗證時先停用嗅探並存取一次，記錄目標網域、規則與出口；再啟用嗅探，建立新連線比較這三項。若只有啟用後才發生問題，還原設定後也要確認應用程式快取與舊連線已清除，避免把殘留狀態誤認為還原無效。記錄中若含內部主機名稱、請求網址或應用程式身分，分享前請先遮蔽敏感資訊。嗅探適合用來補足資訊；長期穩定的設定仍應優先依靠清楚的 DNS 路徑與易於理解的規則。

本機覆寫與多訂閱合併

長期使用的設定應將遠端輸入與本機需求分開：訂閱負責提供節點與可更新內容，本機覆寫則管理固定規則、DNS、策略組結構及裝置專屬設定。直接編輯用戶端產生的暫存設定，通常會在訂閱更新或切換設定時遺失。請先確認用戶端提供的是持久覆寫入口、設定合併功能，還是腳本處理方式，再檢查最終產生的檔案。只查看編輯器中的原始內容，無法證明執行中的核心已套用修改。

釐清合併順序與陣列處理方式

YAML 只是資料格式，本身沒有統一的跨檔案合併規則。用戶端可能會遞迴合併對映資料、整體取代陣列，也可能提供前置、後置或依名稱更新等功能。rules整體取代與追加的結果差異很大：前者可能刪除訂閱規則；後者則可能將本機例外放到MATCH之後。套用覆寫前，先用一條範圍明確的測試規則確認實際順序。

以下示範一份本機設定意圖；策略組只有直連候選項目，用來展示穩定的組名與規則位置。這不是適用於所有用戶端的覆寫格式；請依用戶端文件，在合併入口轉換或套用，不要將這段內容直接當成完整代理訂閱匯入。

proxy-groups:
  - name: 日常出口
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,日常出口

實際合併時，應讓「日常出口」引用現有節點、節點提供者或下層自動組。主規則只需依賴這個穩定入口；節點來源變動時，不必重寫服務規則。如果訂閱本身也定義了同名策略組，請明確指定由哪一方覆蓋哪一方；重複名稱不是可靠的合併方式。用戶端快取的舊選擇也可能指向已刪除的節點，更新後請確認組別目前選取的項目仍有效。

多個訂閱先分開管理來源，再進行組合

多個訂閱可以透過用戶端的合併功能管理，也可以使用proxy-providers等核心機制組織；但節點訂閱、完整設定訂閱與規則集並不是同一種輸入。節點提供者通常需要符合對應的節點集合格式；不能直接將含有 DNS、規則與控制器設定的完整設定網址放進去，再期待所有內容自動合併。請先確認訂閱回傳的內容類型，必要時使用可信且可供檢查的本機轉換流程。

為不同來源設定獨立名稱、快取路徑與容易辨認的節點名稱。若兩個來源都有名為「香港」的節點，在日誌與選擇紀錄中就難以區分，也可能造成名稱衝突。名稱前綴應能辨識來源或用途，不要將訂閱憑證放進節點名稱。篩選候選項目時，先確認篩選結果是否為空；正規表示式、名稱變更與地區標籤調整，都可能讓原本正常的組別突然沒有成員。

遠端訂閱網址通常含有存取憑證，應保存在用戶端的本機設定管理中。螢幕截圖、問題回報、同步儲存庫與線上轉換工具，都可能增加憑證外洩風險。分享設定前，請一併檢查 URL 查詢參數、節點密碼、控制器金鑰，以及日誌中的完整網址；只遮住節點清單，仍可能洩漏訂閱入口。備份若含有這些資訊，應存放於安全可控的位置，並限制可讀取的帳戶。

分別驗證設定產生、檢查與重新載入

修改後先查看最終設定，確認規則順序、組內成員與 DNS 欄位，再執行核心設定檢查。命令列環境可使用下方的檢查方式，其中config.yaml應指向實際要執行的最終檔案；圖形化用戶端請優先使用內建檢查功能，避免因工作目錄不同而讀取錯誤路徑。檢查通過只代表結構與引用基本有效，不代表代理節點能連上目標服務。

mihomo -t -f config.yaml

重新載入後，分別測試本機例外、一般代理與最終兜底規則，並確認再次更新訂閱後這些設定仍然存在。若更新後恢復舊行為，代表覆寫沒有進入持久設定產生流程，或被後續層級覆蓋。還原時請恢復本機覆寫與相應的訂閱快照；不要只複製一份暫存產生的檔案，當作永久解決方案。遇到複雜的合併問題，先縮減為單一訂閱與單一頂層組，再逐一恢復來源，找出造成差異的層級。

外部控制面板

外部控制面板會透過核心控制介面讀取狀態、切換策略與管理連線，本身不負責轉送服務流量。面板無法開啟與代理無法連線，可能是兩個獨立問題；請先確認核心仍在執行，再檢查控制介面、驗證方式與頁面來源。多數日常操作可直接使用用戶端內建介面；只有確實需要獨立監看或遠端管理時，才額外開放控制功能，避免不必要地擴大裝置管理入口。

先限制為僅本機存取

external-controller用來指定控制介面的監聽位址，secret用於介面驗證，external-ui則指定本機靜態面板目錄。以下只示範本機管理設定。範例金鑰是教學用假值；實際部署時必須換成在本機產生的高強度隨機值，並避免寫入公開檔案。靜態面板檔案必須事先放在可信任的本機目錄；設定此欄位不會自動產生頁面。

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

回環位址監聽僅供本機使用；不能因為其他裝置無法連線，就直接改成監聽所有介面並關閉驗證。若確實需要跨裝置管理，應先規劃驗證、存取控制與安全傳輸方式，再限制允許連線的來源。系統防火牆、容器連接埠轉送與用戶端設定都可能影響實際對外開放範圍；檢查時應以監聽狀態與實際測試為準，而非只看設定文字。

分清代理連接埠與管理連接埠

mixed-port等代理入口用來接收應用程式流量；控制介面則用來管理核心，兩者不可互換。將瀏覽器的代理伺服器設為控制連接埠，不會形成正常的代理連線；面板若把 API 位址設為代理連接埠，也無法讀取策略組。面板中的 API 位址應包含正確的協定、主機與連接埠，金鑰也必須與目前執行的執行個體一致；裝置上有多個核心程序時尤其要留意。

可以先透過本機 API 確認介面是否有回應。以下指令使用與範例相同的假金鑰，只供本機示範；實際操作時請留意終端機歷史記錄與螢幕分享，不要公開驗證標頭。回應未授權代表介面已有回應，但驗證資訊不符；連線遭拒通常表示位址、連接埠或程序狀態有問題；若逾時，則還需檢查存取路徑與防火牆。

curl --fail --silent --show-error \
  -H 'Authorization: Bearer your-controller-secret' \
  http://127.0.0.1:9090/proxies

API 正常但頁面空白時，再檢查靜態檔案是否完整、目錄路徑是否正確，以及瀏覽器主控台中的請求錯誤。透過安全頁面存取未加密的 API 可能觸發混合內容限制；頁面與 API 來源不同也可能受到跨來源政策影響。不要為了消除瀏覽器錯誤就允許任意來源或移除驗證；應優先讓本機面板與受控 API 採用相容的存取方式。

透過面板建立完整的排查紀錄

連線頁面應同時檢查目標、規則、策略鏈與連線狀態。只看最後的節點名稱，無法判斷節點是由服務規則選出，還是剛好命中兜底。切換策略後應建立新連線；若確有需要，先確認影響範圍再關閉指定的舊連線。不要一次清除所有連線再觀察，因為登入工作階段、下載任務與遠端終端機都可能中斷，也會失去故障現場。

日誌詳細程度以足以解釋問題為準；暫時提高詳細度後，應在複測結束時恢復。詳細日誌可能包含內部網域、目標位址、程序資訊與請求路徑；提交回報前，只保留與故障相關的時段並遮蔽敏感資訊。面板顯示的資料來自目前連線的執行個體；若用戶端運作正常，但面板上的規則清單明顯不同，請先確認控制位址與程序，不要立刻認定訂閱沒有更新。

最後，將排查紀錄整理成一條可重現的流程：哪個應用程式發起請求、是否進入核心、如何取得網域、命中哪條規則、策略組選擇哪個出口，以及問題發生在解析、連線還是服務回應階段。若瀏覽器與終端機的結果不同，可繼續閱讀系統代理與終端機排查清單。若只是初次設定尚未完成，請返回入門指南完成基本流程；比起繼續增加進階選項，這樣更容易找出可靠結論。