Clash 進階設定指南：策略群組、DNS 與 TUN

01 · 設定生效流程與修改原則

用戶端、核心與執行設定

用戶端介面負責匯入訂閱、儲存選項及啟動背景服務；核心則負責解析規則、建立連線與轉送流量。介面上有某個開關，不代表訂閱檔案一定包含同名欄位；反之，在檔案中加入欄位，也可能在用戶端產生執行設定時被覆蓋。排查時，應先從用戶端的核心資訊或記錄確認實際使用的核心，再找出最後交由核心讀取的設定，而非只查看訂閱編輯器。

本站依平台整理用戶端下載入口，挑選時可先查看 Clash Plus，再依作業系統與所需功能確認其他用戶端。Clash Verge Rev、Clash Meta for Android、FlClash 等用戶端的設定入口與合併方式各不相同。若要重新選擇安裝來源，請前往用戶端下載頁。本頁不會將特定用戶端的介面路徑視為所有平台通用的操作方式；欄位是否支援，仍須依實際執行的核心判斷。

建立可復原的最小修改流程

修改前，分別備份訂閱來源、本機覆寫內容與目前可用的執行設定，並記下系統代理與 TUN 的原始狀態。訂閱網址可能含有存取憑證，請勿貼到公開儲存庫、截圖或求助文章。建議每次只修改一個設定層：先確認檔案能載入，再確認規則命中，最後才調整流量接管方式。若同時更換 DNS、路由與規則集，即使連線失敗，也很難判斷是哪項變更改變了流量路徑。

以下片段用來說明基本欄位，並非含有代理節點的完整訂閱。範例使用規則模式與混合連接埠，未命中規則的連線會直接送出。與現有設定合併時，請編輯既有的同名頂層欄位，不要在同一個檔案末尾重複新增第二個 rules。YAML 重複鍵的處理方式會依解析流程而異，不能假設後出現的內容一定會覆蓋先前設定。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,DIRECT

縮排請統一使用空格，清單項目的連字號應與所屬欄位保持一致的層級。含有冒號、井字號或容易被識別為特殊型別的字串，建議加上引號。最常見的格式問題通常不是欄位太複雜，而是複製片段時遺失縮排，或把完整設定嵌入子欄位。編輯器顯示正常不代表核心一定能解析；儲存後仍須確認載入結果。

分開進行語法檢查與行為檢查

若有獨立的 Mihomo 執行檔，可先執行下方的測試命令。命令所用的檔案應位於目前目錄；若規則集、資料庫等依賴項使用相對路徑，也須確保測試工作目錄與實際執行環境一致。語法測試通過只表示設定可以解析，不代表節點可用、DNS 連得上，或系統路由已建立。

mihomo -t -f ./config.yaml

行為檢查應沿著一條新建連線逐步進行：應用程式是否進入核心、目標網域是否被識別、命中哪條規則，以及最後選擇哪個出口。瀏覽器既有的長連線可能仍沿用舊策略；測試時請重新發出請求，必要時關閉應用程式再重新連線。不要因為切換策略群組後舊分頁仍可瀏覽，就認定新規則已生效。

若連最小設定都無法啟動，請先檢查連接埠占用、檔案權限與路徑，再查規則語法。若出現位址已被占用的提示，可參閱排查 7890 衝突與修改 mixed-port 的步驟。修改連接埠後，也要同步更新應用程式的手動代理設定，避免核心已在新連接埠監聽，瀏覽器卻仍連到舊連接埠。

02 · 策略群組類型與分層實作

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

規則決定「這條連線交由誰處理」，策略群組則決定「目前從哪些候選出口中選一個」。規則可以指向特定節點，也可以指向策略群組。日常設定較適合讓規則引用穩定的群組名稱，節點增刪則在群組內處理；如此一來，訂閱更新造成節點改名時，就不必逐條修改業務規則。群組名稱是引用識別值，空格、大小寫與文字都必須完全一致。

select 是手動選擇群組，適合放在方便使用者操作的入口層；url-test 依探測結果選擇候選項目；fallback 在候選項目可用時，優先沿用清單中排序較前的出口；load-balance 則依指定的分配策略，讓不同連線使用不同候選出口。這些策略解決的問題各不相同，不應只看名稱就認定「自動」一定比「手動」適合所有用途。

類型	適用情境	注意事項
`select`	明確指定出口	需要手動維持目前選擇
`url-test`	自動挑選探測結果合適的候選項目	測試網址不等於實際目標服務
`fallback`	主備順序明確	候選項目順序會影響選擇
`load-balance`	分配多條連線	無法將單一連線疊加成多倍頻寬

分開設定入口群組與自動群組

容易維護的結構是：規則指向「網路出口」，入口群組再提供自動群組、手動候選項目或直連選項。以下片段只引用內建的 DIRECT，因此能示範群組之間的引用關係，但不會產生代理出口。實際使用時，須先透過合法取得的訂閱或本機節點定義加入真實候選項目，再將候選項目名稱填入自動群組；請勿將範例誤認為節點來源。

proxy-groups:
  - name: 網路出口
    type: select
    proxies:
      - 自動選擇
      - DIRECT

  - name: 自動選擇
    type: url-test
    proxies:
      - DIRECT
    url: https://example.com/
    interval: 300
    tolerance: 50

rules:
  - DOMAIN-SUFFIX,example.com,網路出口
  - MATCH,DIRECT

此處的 interval 表示定期探測的間隔，tolerance 用來降低探測結果略有差異時頻繁切換的情況。測試網址應能透過候選出口連線，且回應表現明確；範例保留的網域僅供理解欄位，實際設定應選擇適合自身網路環境的探測目標。測試結果反映的是通往該目標的路徑，不能取代下載速度、影片播放或帳號服務穩定性的評估。

登入工作階段、付款頁面或對出口 IP 敏感的服務，通常應固定使用手動選擇的群組，避免不同的新連線切換出口。即使採用一致性分配策略，也無法保證所有相關網域一定會連到同一個位址：頁面可能依賴多個服務，候選清單也可能變動。若需要固定出口，應核對實際連線記錄，而不是只看群組名稱。

避免循環引用與候選項目缺漏

策略群組可以引用其他群組，但不能形成循環。例如入口群組引用自動群組，而自動群組又引用入口群組，就會使選擇流程失去明確的終點。較穩妥的做法是維持單向層級：業務規則指向入口群組，入口群組指向功能群組，功能群組再指向實際節點或內建出口。引用訂閱提供者時，則要確認 use 中的名稱確實存在，且提供者已成功載入。

若群組有顯示但沒有可選節點，先檢查篩選條件是否排除了所有候選項目，再查看訂閱載入記錄；不要直接把篩選條件改成更複雜的運算式。節點名稱重複也可能造成顯示與引用上的混淆，合併訂閱時應預先訂定唯一的命名規則。若自動群組中的候選項目全都失敗，先單獨測試一個已知可用的候選項目，以分辨是節點連線問題，還是探測目標本身無法連線。

更改群組選擇後，只觀察新連線。部分用戶端會儲存上次的選擇，並在重新啟動後還原；這與 YAML 清單的排列順序是兩回事。若介面上的選擇與預期不同，應一併檢查用戶端的持久化設定與目前執行狀態；需要比較用戶端操作入口時，可參閱用戶端比較頁，不要反覆更改群組名稱來繞過狀態儲存機制。

03 · 以規則集管理規則與比對順序

分開管理規則內容與分流目標

網域與網段項目逐漸增加時，把所有內容堆在主設定中會讓更新與檢查變得困難。rule-providers 用來定義規則內容的來源，RULE-SET 則在主規則清單中引用規則集，並指定命中後採用的策略。規則集負責定義「有哪些目標」，主設定負責決定「這些目標要走哪裡」；分開管理後，同一份業務網域清單就能在不同裝置上指向不同策略群組。

提供者的 behavior 必須與內容相符：domain 適用於網域集合，ipcidr 適用於 IP 網段，classical 則允許包含傳統規則類型的項目。下載網址可以開啟，不代表檔案格式就正確；將含有 payload 的 YAML 當成純文字清單讀取，或把完整規則列交給網域解析器，都可能導致載入失敗或結果不符預期。

先用本機檔案確認引用關係

以下使用本機檔案，方便在不依賴遠端下載的情況下驗證規則集。先在核心工作目錄下建立 rules 資料夾，再儲存 local-domains.yaml。此檔案只包含規則內容，不需填入代理策略。範例網域僅供測試比對；實際使用時請換成確實需要管理的網域，並保留修改記錄。

# rules/local-domains.yaml
payload:
  - '+.example.com'

在主設定中定義檔案來源，再於一般規則中引用。相對路徑是依核心工作目錄解析，不一定相對於用戶端目前開啟的編輯器檔案。使用桌面用戶端時，應先確認用戶端為核心指定的設定目錄，避免檔案放在下載資料夾，執行時卻到另一個目錄尋找。

rule-providers:
  local-domains:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-domains.yaml

rules:
  - RULE-SET,local-domains,DIRECT
  - MATCH,DIRECT

改用 HTTP 來源時，須設定確實可連線的 url、快取用的 path 與更新 interval，並確認伺服器回傳的是規則本文，而非網頁預覽或登入頁面。快取路徑應保持唯一，不要讓不同提供者寫入同一個檔案。檔案格式可使用核心支援的 YAML、文字或編譯格式，但內容必須與宣告的格式相符，不能只更改副檔名。

規則順序決定實際結果

規則通常依照由上而下的順序比對，第一條命中的規則會結束本次選擇。特定網域的例外應放在範圍較廣的分類之前，最後再用 MATCH 處理剩餘流量。將規則集加在 MATCH 後面不會得到預期效果；同樣地，若範圍過廣的網域後綴規則排在前面，後續較精細的分類規則可能永遠沒有機會命中。

IP 類規則可能會觸發網域解析。部分規則末尾可使用 no-resolve，表示目標仍是網域時，不為這條 IP 規則額外發起解析；它不是「禁止整條連線使用 DNS」。若希望優先套用網域規則，就應將網域規則放在需要解析的網段規則之前。若為減少不必要的查詢而到處加上此參數，可能會讓原本依賴解析結果的規則失效。

遠端規則集更新失敗時，先確認核心是否仍有可用快取，再檢查下載路徑與存取條件。首次啟動與日常更新的條件不同：日常更新可能依賴舊快取啟動，首次啟動時卻可能沒有任何可用內容。若下載規則所需的連線本身也依賴代理，而代理選擇又仰賴尚未下載的規則，就會形成啟動依賴循環；應讓基本啟動路徑保持簡單。

對於頻繁更新的規則來源，應保留變更前的內容快照，並在更新後檢查重要業務網域是否被新增分類涵蓋。GeoIP、GeoSite 與一般規則提供者並非完全相同的儲存機制，相關資料庫的格式、路徑與更新條件可參閱GeoIP 與 GeoSite 資料庫更新說明。不要為了統一命名而互換不同機制的檔案。

04 · DNS 解析路徑與設定最佳化

分清應用程式查詢、核心解析與節點解析

DNS 問題往往不在於「有沒有填解析伺服器」，而在於查詢究竟由誰發出。瀏覽器可能啟用了自己的加密 DNS，作業系統可能快取舊結果，核心也需要解析代理伺服器的網域。系統代理只會影響遵循代理設定的應用程式，並不會自動確保所有 DNS 查詢都交給核心處理。開始調整前，應先確認應用程式使用的是系統解析、核心 DNS，還是獨立的解析路徑。

nameserver 是一般解析的上游伺服器；default-nameserver 用於解析 DNS 上游伺服器本身的網域等基本啟動需求；proxy-server-nameserver 則可單獨指定代理伺服器網域的解析來源。分開設定是為了避免代理連線尚未建立前，必須先經過該代理才能解析節點位址。即使把所有上游都改成 HTTPS，也無法自動消除這種依賴關係。

先設定容易理解的基本解析

以下片段讓核心在回送位址的非標準連接埠提供 DNS 服務，並使用 Fake-IP。這不會自行變更作業系統的 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:
    - 1.1.1.1
    - 8.8.8.8
  nameserver:
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://1.1.1.1/dns-query

此處的上游位址只是設定範例，不保證適用於所有網路環境。選擇上游時，應考量本地連線條件、查詢隱私需求與解析結果是否符合服務需求。ipv6: false 控制此處 DNS 對 AAAA 查詢的回應行為，不等於關閉整個系統的 IPv6 網路。若網路本身支援 IPv6，停用此項也可能改變原有連線路徑；請依明確問題調整。

依網域指定解析策略

企業內部網域、家用裝置名稱或特定服務網域，可能只有指定的解析器才能正確回覆。此時可考慮使用 nameserver-policy，讓這些網域交由專用上游解析。內部網域不要不加判斷就送往公共解析器，不但可能查不到結果，也會暴露原本只在內部網路使用的名稱資訊。設定前應先確認網域範圍，避免過寬的網域後綴把大量公共查詢也送進內網伺服器。

若使用 respect-rules 讓 DNS 上游連線遵循分流規則，也須考量代理伺服器網域如何解析。此選項改變的是核心連線至 DNS 上游的路徑，不會讓每個 DNS 回應自動取得正確分類。先建立獨立且可用的節點解析通道，再觀察上游連線命中哪條規則，可避免出現一邊需要解析節點、一邊又等待節點連線的循環。

fallback 與 fallback-filter 也不是單純的「主要伺服器故障時切換備用伺服器」開關。啟用後，結果篩選會受到網域、位址範圍等條件影響。若沒有明確的篩選目標，建議先維持單一且可靠的解析路徑；只有確認特定網域的解析確實有問題時，再加入回退機制。上游越多不一定越穩定，反而會增加排查範圍。

dig @127.0.0.1 -p 1053 example.com A

測試時應同時記錄查詢耗時、回傳的位址類型與核心記錄。Fake-IP 模式下取得保留位址範圍內的位址可能是正常結果，不能只因它不是公用 IP 就判定解析失敗。修改解析模式後，應用程式與系統快取可能仍保留舊結果；請重新發出請求，並依作業系統提供的方法清除快取，不要一味新增 DNS 上游。

若網域能解析但網頁無法開啟，請繼續檢查連線使用的規則與出口；若只有瀏覽器行為不同，請確認瀏覽器是否使用獨立 DNS 或代理擴充功能。相關症狀可依照已連線但無法瀏覽網頁的排查清單逐步確認。DNS 最佳化的目標是讓解析路徑清楚、結果可驗證，而不是盡可能增加設定欄位。

05 · TUN 流量接管與 Fake-IP 對應

了解兩種機制各自的用途

TUN 會建立虛擬網路介面，讓作業系統將符合路由條件的 IP 流量交由核心處理；Fake-IP 則在 DNS 階段回傳受控的虛擬位址，並由核心保存該位址與原始網域之間的對應關係。前者回答「流量如何進入核心」，後者則協助判斷「這條流量原本要連線到哪個網域」。兩者常一起使用，但功能並不相同，啟用其中一項也不代表必然能取代另一項。

系統代理依賴應用程式遵循代理設定，對未遵循設定的程式可能不起作用；TUN 透過路由接管更多流量，但也會涉及權限、虛擬網卡、系統 DNS 與其他 VPN。接管範圍擴大，不代表所有通訊協定都會自動獲得遠端支援；最終可用性仍受代理節點支援的通訊協定限制。尤其是 UDP，從應用程式、核心到遠端的整條路徑都必須具備相應支援。

依照用戶端權限流程啟用

桌面版應先使用用戶端提供的服務安裝或授權流程，再啟用 TUN。Windows 通常需要背景服務或系統管理員權限；macOS 須依用戶端實作完成系統授權；Linux 則取決於服務權限、網路管理與路由設定。Android 通常透過系統 VPN 服務授權，是否直接提供相關欄位由用戶端決定。iOS 的網路接管由應用程式與系統延伸功能機制管理，不宜照搬桌面版的原始網卡設定。

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

此片段依賴前一章已啟用的核心 DNS，並假設用戶端允許相應的 TUN 設定。auto-route 會嘗試加入所需路由，auto-detect-interface 會嘗試識別出口介面；在多網卡、容器、遠端桌面或企業網路環境中，自動識別未必符合實際網路拓樸。stack 的選擇須考量平台支援與應用程式表現，不應將某種堆疊視為所有裝置的固定答案。

dns-hijack 的範例適用於傳統 DNS 連接埠，不能因此推斷瀏覽器的 DoH 或其他加密 DNS 已被解密或取代。部分應用程式會直接連線至固定 IP，或使用自己的解析服務，仍須從連線記錄確認。若應用程式完全沒有出現在核心連線清單中，應先調查路由與流量接管入口，而不是反覆修改網域規則。

Fake-IP 過濾只加入必要例外

部分依賴真實位址回應的應用程式可能不適合收到 Fake-IP，例如某些區域網路探索、裝置連線或特定驗證流程。可在 fake-ip-filter 中為明確的網域加入例外，讓這些查詢取得真實解析結果。新增前請先確認現有 fake-ip-filter-mode 的語意；不同過濾模式下，同一份清單的含義可能相反，不能直接複製他人分享的長清單。

過度寬泛的過濾會減少核心透過對應關係還原網域的機會，進而改變規則比對條件。實際排查時，建議從單一故障網域開始：確認查詢是否到達核心、回傳的位址類型，再觀察連線是否依賴真實位址。裝置探索也可能依賴廣播或多點傳播；只新增網域過濾無法解決所有區域網路存取問題。

與其他 VPN 並用時，應先釐清由哪一方負責預設路由、由哪一方負責 DNS，以及是否發生重複接管。兩張虛擬網卡若宣告相似路由，可能造成請求繞行、迴圈或只有部分目標可達。停用其中一方的流量接管後重新測試，是判斷衝突來源的有效方法；不要在網路拓樸不明時，直接加入更嚴格的路由選項。

復原時，先關閉 TUN，再確認系統代理與 DNS 是否回到預期狀態；切換 Fake-IP 與真實解析模式後，也應清除相關快取並重新建立連線。若用戶端介面已關閉但網路仍異常，請檢查背景服務是否仍在執行，以及系統是否殘留手動代理設定。一般問題可繼續參閱說明中心，並記下故障發生前最後變更的網路層。

06 · 網域嗅探與識別範圍

透過嗅探補足連線資訊

連線進入核心時若只有目標 IP，網域規則可能缺少可供比對的資訊。網域嗅探會嘗試從通訊協定交握中擷取主機名稱，例如 HTTP 請求中的主機資訊或 TLS 交握中的伺服器名稱，再提供後續處理使用。它無法解密任意 HTTPS 內容，也不是能將所有 IP 自動還原成唯一網域的工具。同一個位址可能承載多個網站，單靠位址本來就無法判斷服務名稱。

嗅探與 Fake-IP 都有助於保留網域資訊，但來源不同：Fake-IP 仰賴由核心處理的 DNS 對應，嗅探則仰賴連線初期可觀察到的通訊協定內容。若應用程式繞過核心 DNS，嗅探可能補足部分資訊；若交握沒有暴露可用網域，或通訊協定不在支援範圍內，就不能期待它憑空產生網域。

先限定通訊協定與連接埠範圍

以下片段示範 HTTP 與 TLS 的基本嗅探設定，同時保留原始連線目標。建議先使用較窄的連接埠範圍觀察效果，再依實際應用逐步擴大；比起一開始涵蓋所有連接埠，這樣更容易定位問題。範例中的連接埠範圍只是設定條件，不代表這些連接埠上的所有流量都必定使用對應通訊協定。

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

parse-pure-ip 允許嘗試處理以 IP 為目標的連線，force-dns-mapping 與 DNS 對應情境有關；是否確實需要這些行為，應依原始連線資訊判斷。override-destination 決定是否允許使用識別結果改寫連線目標，而不只是補充網域資訊。使用前應分清「希望規則能識別網域」與「希望改變最後的連線目標」這兩種需求。

保留原始位址較容易比較啟用前後的行為。對於依賴特定位址、私人解析或專線入口的服務，改寫目的地可能引入額外解析，並使請求偏離原本的伺服器。若需啟用目標改寫，應先針對單一應用程式與單一網域驗證，再考慮擴大範圍；不宜把它當成所有連線故障的通用修復方式。

設定排除範圍與無法識別的情況

對不適合嗅探的服務，可使用核心支援的網域或位址排除欄位設定例外。例外應根據可重現的相容性問題建立，而不是複製來源不明的排除清單。記錄排除前後的目標位址、識別網域與命中規則，才能判斷問題出在識別流程，還是後續策略選擇。

QUIC 的傳輸方式與一般 TLS 不同，只有啟用且取得核心支援的相應解析能力，才可能擷取相關資訊。即使支援，也不代表加密交握中的所有資訊都可見。啟用 ECH 等機制的連線可能不再暴露可用的目標名稱；私人通訊協定、直接使用 IP 的應用程式，或沒有主機資訊的連線，也可能無法透過嗅探取得可供網域規則使用的結果。

不要只為了讓記錄顯示網域就任意封鎖某種通訊協定。封鎖 UDP 可能迫使部分應用程式改用其他傳輸方式，也可能直接造成服務中斷。若確實需要進行相容性測試，應明確記錄測試條件，並在完成後還原設定。正常設定應以應用程式需求為依據，而非追求連線清單看起來整齊。

利用連線記錄比較前後差異

驗證時，先關閉嗅探並對目標發出新請求，記錄目標類型、規則與出口；再開啟嗅探，對相同服務建立新連線。若出現網域但分流沒有改變，可能是前面的 IP 規則已命中，或網域規則的比對範圍原本就不包含該目標。若啟用後反而連線失敗，應優先比較目標是否遭到改寫，以及額外解析是否成功。

測試記錄應限制保存範圍。網域、請求路徑、節點名稱與控制介面資訊都可能涉及個人或組織的網路活動；求助時只保留必要欄位，並先去識別化。遇到「所有節點都逾時」這類較基礎的故障時，嗅探通常不是第一個檢查項目；應先依照訂閱、系統時間與通訊協定相容性的排查順序確認出口本身可以建立連線，再調整網域識別。

07 · 本機覆寫與多訂閱合併

分開管理可更新內容與裝置設定

訂閱適合管理節點、群組與由提供者維護的規則；本機設定則較適合保存裝置連接埠、TUN、區域網路存取限制與個人分流例外。直接修改訂閱本文，往往會在下次更新時遺失。使用用戶端提供的覆寫、合併或增強設定機制，可在維持訂閱更新的同時，將需要長期保留的裝置差異獨立管理。

不同用戶端對「覆寫」的定義不盡相同：有些會合併物件，有些會取代整個欄位，有些提供指令碼處理，還有些會在最後強制套用介面設定。尤其是 rules、proxy-groups 這類陣列，不能假設一定會逐項追加。設定前應先確認處理順序，修改後再查看最後的執行設定；只看覆寫編輯器無法確認實際結果。

透過代理提供者管理多個來源

多份訂閱不一定要將完整檔案直接串接。對於格式合適的節點來源，可分別使用 proxy-providers 管理，再由策略群組透過 use 引用。以下示範檔案型來源，適合先驗證結構。須先在核心工作目錄中準備實際節點檔案；檔案尚未建立前，不應將此片段視為可直接啟動的完整設定。

proxy-providers:
  personal-nodes:
    type: file
    path: ./providers/personal.yaml

  work-nodes:
    type: file
    path: ./providers/work.yaml

proxy-groups:
  - name: 個人線路
    type: select
    use:
      - personal-nodes

  - name: 工作線路
    type: select
    use:
      - work-nodes

提供者檔案應包含符合核心要求的 proxies 清單，而非任意儲存一份包含完整規則的用戶端設定。編碼後的分享連結集合、完整 Clash 設定與代理提供者檔案是不同格式；匯入前須確認用戶端或來源支援相應轉換。不要將私人訂閱交給來源不明的線上轉換服務；訂閱網址與節點憑證一旦離開受控環境，存取權限也可能跟著外洩。

若來源本身支援 HTTP 提供者，可為每份來源設定獨立的快取路徑與更新間隔。將個人與工作來源分開，能讓策略群組界線更明確，也方便單獨停用某個來源進行測試。不過，應先確認來源授權的使用範圍；技術上可以合併，不代表能將存取權限轉交給其他裝置或人員。

管理命名、追加位置與優先順序

合併前先訂定命名規則：提供者名稱不可重複，策略群組名稱應保持穩定，節點名稱則應避免不同來源互相衝突。引用關係是依名稱判斷，不能假設介面上顯示相同名稱時仍會自動區分來源。若需要加上前綴或重新命名，應優先使用用戶端或核心明確支援的機制，並測試篩選條件是否仍能找到更名後的節點。

本機規則通常可分為前置例外與最後的兜底選擇。必須優先處理的內部網域應放在寬泛規則之前；最後的 MATCH 只能用於兜底。有些合併機制會將本機清單加在訂閱規則之後；若訂閱已有 MATCH，後加的規則就不會執行。正確做法是調整合併方式或明確重建規則順序，而不是繼續在末尾新增更多相似規則。

訂閱更新後也要重新驗證

更新成功後，請檢查三項內容：來源是否正常載入、群組引用是否仍然有效，以及前置規則是否仍位於預期位置。訂閱新增的欄位可能被舊版覆寫設定整個取代；本機儲存的群組選擇也可能仍引用已不存在的節點。排查時，先停用個人覆寫並確認原訂閱能否正常執行，再逐段恢復設定，會更容易找出衝突。

若用戶端不方便顯示最終設定，至少保留載入記錄、節點清單與重要連線的規則記錄。還原舊快照時，也要留意節點憑證可能已失效；設定能載入不代表舊節點仍可使用。日常操作請以快速入門指南中的匯入與連線流程為主；本章用來說明更新後為何需要重新確認合併結果，並非要求每次連線都手動編輯檔案。

08 · 外部控制介面與維護流程

控制介面不是代理連接埠

external-controller 提供核心管理介面，可讓面板讀取狀態、切換策略或執行管理操作。它與接收 HTTP、SOCKS 請求的混合代理連接埠不同，也不是 DNS 監聽連接埠。將代理連接埠填入面板連線位址，不會因此取得管理功能；把控制連接埠當成網路代理使用，也無法建立正確的流量轉送路徑。

控制介面可以影響網路行為，因此預設應繫結至回送位址，只允許本機存取。若確實需要跨裝置管理，應先規劃存取界線，再考慮監聽位址、驗證機制、傳輸保護與防火牆。不要只為了讓手機開啟面板，就將介面公開到所有網卡，並依賴容易猜到的範例密碼。控制介面外洩的風險不只在於他人看見狀態，也可能包括變更執行中的選擇。

本機面板與驗證設定

下方片段示範回送位址監聽與本機面板目錄。your-password 是教學範例，實際啟用時必須換成自行產生的高強度密鑰；不要將真實密鑰貼到公開問題記錄中。external-ui 指向已準備好的靜態面板檔案目錄；若目錄中沒有面板檔案，僅設定此欄位不會自動產生可用頁面。

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

若用戶端已內建面板與控制設定，應優先使用內建管理入口，避免本機覆寫與介面設定互相衝突。手動測試管理介面時，可在可信任的本機終端發送請求。以下命令會以互動方式讀取密鑰，避免將真實值直接寫入命令歷史；使用後會清除目前終端中的變數。

read -r -s -p "控制介面密鑰: " MIHOMO_SECRET
printf '\n'
curl --fail --silent --show-error \
  -H "Authorization: Bearer $MIHOMO_SECRET" \
  http://127.0.0.1:9090/configs
unset MIHOMO_SECRET

此命令適用於 Bash 環境，其他終端請使用相應的安全輸入方式。成功讀取只表示目前終端到控制介面的連線可用，不代表瀏覽器面板也具備相同條件。瀏覽器還會受頁面來源、混合內容、跨來源政策與網路位址限制；應分別檢查介面連線與頁面存取問題。

遠端存取前先確認位址的指向

面板頁面中的 127.0.0.1 指向開啟瀏覽器的裝置，而非部署核心的遠端主機。從另一台電腦存取面板時，若仍填入回送位址，瀏覽器會嘗試連線到自己的裝置。較穩妥的遠端管理方式是使用受控的加密通道，或經過驗證與存取限制的反向代理，同時讓核心控制介面維持本機監聽。

使用反向代理時，應同時確認一般 HTTP 請求與 WebSocket 連線是否正常；連線清單或記錄可能仰賴持續通訊。頁面能開啟但狀態未更新，常見原因包括代理未轉送連線升級標頭、驗證設定不一致，或瀏覽器封鎖連線。跨來源允許範圍應限於實際需要的頁面來源，不要為了消除錯誤訊息而無條件放寬。

面板的靜態檔案也需要維護。請確認更新來源，升級前備份目前可用的檔案與設定，升級後測試登入、策略切換與記錄連線。若控制介面可連線但新版面板異常，應先還原面板檔案，不要立刻修改整份核心設定。若由用戶端統一管理內建面板，則應遵循其更新機制，避免手動替換造成路徑衝突。

將每次變更整理成可驗證的記錄

完成設定後，請保留簡短記錄：修改了哪個欄位、預期產生什麼變化、用哪條新連線驗證，以及失敗時要還原哪個檔案。策略群組須驗證最終出口，規則集須驗證命中順序，DNS 須驗證查詢路徑，TUN 須驗證流量入口與路由，面板則須驗證驗證機制與存取範圍。這類記錄比保存大量來源不明的設定截圖更利於長期維護。

發生異常時，請沿著同一方向排查：先確認設定已載入，再確認流量已進入核心，接著檢查解析、規則與出口。面板失去連線時，不要立刻認定是節點故障；網頁無法開啟時，也不要馬上修改控制介面。若要依症狀尋找解決方式，請前往說明中心；若要更換用戶端，可在下載頁依平台確認下載入口。維護的目標是讓每個層級都有明確職責，且每項修改都能說明、驗證與復原。