mihomo 進階設定指南

01 / 設定基準

設定來源、執行檔案與驗證順序

開啟用戶端的設定頁，先找到目前啟用的設定，再查看執行設定或核心設定入口。下載的訂閱檔、本機編輯的檔案，以及最後交由 mihomo 使用的檔案，可能是三個不同的物件。介面中的系統代理、連接埠、DNS 或 TUN 開關也可能參與設定產生。排查前，先記錄目前的設定名稱、設定目錄與實際監聽連接埠。只查看訂閱編輯器中的某個欄位，無法確認核心是否已採用；執行日誌與最終產生的檔案才是確認生效狀態的起點。

建立可還原的設定基準

先匯出目前可正常連線的設定，並另外儲存本機覆寫內容。備份可能包含訂閱網址、伺服器密碼或控制介面密碼，請存放在本機受限目錄；分享截圖時也要遮住這些資訊。建議每次只修改一個模組，例如先調整策略組，再調整 DNS，最後啟用 TUN。發生問題時，才能確切找出與最近一次變更的關聯。直接執行核心的使用者也應記錄啟動指令與工作目錄；相對路徑會受設定目錄影響，從其他目錄啟動可能導致找不到規則檔案或面板資源。

閱讀 YAML 時，先檢查縮排層級與重複鍵。縮排請使用空格，同一層保持一致，清單項目前加連字號；欄位名稱中的連字號與清單標記用途不同。含特殊字元的字串可以加上引號，尤其是密碼、含查詢參數的網址與含冒號的文字。不要在檔案末尾再新增第二個 dns 或 rules 頂層鍵來模擬覆寫：不同解析方式可能會報錯，也可能只保留其中一份，最後結果往往與編輯時的預期不同。

# 合併至現有可用設定；保留原有出口與規則
mixed-port: 7890
allow-lan: false
mode: rule
log-level: info
external-controller: 127.0.0.1:9090

先檢查語法，再觀察實際連線

若使用獨立核心，可以執行下方指令測試檔案，路徑請依本機實際位置調整。測試可找出無法解析的 YAML、部分欄位錯誤與引用問題，但無法證明遠端服務可連線，也不能證明系統流量經過該程序。圖形用戶端通常提供設定檢查、重新載入或日誌入口，請優先使用。檢查失敗時，先查看日誌中第一個有意義的錯誤；後續錯誤可能只是同一個層級錯誤引起的結果，逐項盲目修改反而容易破壞原本正確的設定。

mihomo -t -f ./config.yaml

語法檢查通過後，重新載入設定，再關閉測試應用程式原有的連線並發出新請求。在連線頁確認目標網域、命中規則、策略鏈與出口名稱；若只重新整理頁面，瀏覽器可能沿用舊連線，讓新規則看起來沒有生效。需要區分本機接入與遠端出口時，可以明確指定本機代理連接埠進行測試。下方指令僅驗證 HTTP 代理入口可用，不能取代 TUN 路由驗證；連接埠應與執行設定一致，目標網站也可換成目前需要排查的公開網站。

curl -I --proxy http://127.0.0.1:7890 https://example.com

用戶端的選擇也會影響設定入口的位置。初次安裝可先前往用戶端下載頁選擇推薦的 Clash Plus，並依系統晶片選擇安裝檔；已使用 Clash Verge Rev 或 FlClash 的使用者可以沿用目前的用戶端，重點是確認實際執行的核心與支援欄位。設定結構逐段說明請參閱config.yaml 結構解析。遇到連接埠被占用、權限遭拒或啟動失敗，請先前往說明中心處理基本問題，再繼續本指南的進階設定，避免將環境問題誤判為規則問題。

02 / 出口選擇

策略組類型與自動選優實作

開啟代理頁，先查看規則最後指向哪個策略組，再展開該組查看成員。策略組是選擇出口的層級，不負責識別流量：規則決定連線進入哪個組，策略組再決定使用哪個出口。修改組內選項通常不必重寫整套規則，因此適合將業務需求與訂閱內容分開。例如，讓業務規則統一指向「業務出口」，再讓這個組包含手動選擇與自動選擇兩種方式。組名可自行設定，但所有引用都必須完全一致，包括空格、大小寫與標點。

先區分手動選擇、優先選擇與故障切換

select 適合明確指定出口，或作為上層選單在多個子組之間切換；url-test 會根據測試結果選擇延遲較低且可用的成員；fallback 著重成員順序，通常優先使用排在前面的可用成員。這些方式都無法保證實際業務體驗與測試結果一致。測試網址只反映連線至該網址的狀況，影音、下載與企業系統可能使用不同的網路路徑。排查時先固定一個已確認可用的成員，再觀察業務連線，避免自動切換不斷改變測試條件。

load-balance 用於依策略分配新連線，不代表能將多個出口的頻寬合併至同一條連線。對於登入工作階段、付款頁面或要求出口一致的服務，頻繁更換出口可能觸發重新驗證，因此較適合流量特徵明確的情境。需要穩定連線的業務，可以另外建立 select 組並固定出口。分組愈複雜，檢視連線鏈的成本愈高；先用一個手動組搭配一個優選組涵蓋常見需求，再依實際使用情況逐步拆分。

利用本機代理集合建立兩層選擇

以下範例的前提是設定目錄中已有 providers/nodes.yaml，檔案內包含有效的 proxies 清單，內容由現有訂閱或本機設定提供。範例不會產生遠端帳號，也不能取代訂閱。先確認代理集合可載入，再將兩個組加入現有設定。use 用來引用代理集合，proxies 用來引用單一出口或其他組；兩者都不是填入訂閱網址的欄位。測試網址應能穩定連線，且確實適用於目前的網路環境。

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

proxy-groups:
  - name: 自動選擇
    type: url-test
    use:
      - local-nodes
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50
  - name: 業務出口
    type: select
    proxies:
      - 自動選擇
      - DIRECT
    use:
      - local-nodes

interval 是測試間隔，單位為秒；tolerance 是切換容差，單位為毫秒，可減少結果接近時頻繁切換的情況。間隔設得太短會增加測試請求與喚醒頻率，在行動網路上也會耗用額外流量。同一代理集合若啟用健康檢查，而多個策略組又各自進行測試，就應確認是否有重複測試。不同測試層各有用途，建議只保留容易說明且能觀察的一套安排，而不是同時啟用所有檢查。

驗證時，先在規則中讓一個明確的測試網域指向「業務出口」，再分別選擇「自動選擇」與某個指定成員，建立新連線後查看策略鏈。上層組不可間接引用自身，否則會形成循環；訂閱更新後，若組內只列出已刪除的成員，也可能導致空組或引用失敗。若要篩選集合，可使用篩選欄位，但應先在代理頁確認篩選結果確實包含成員。自動優選只能解決候選出口之間的選擇問題；DNS 失敗、驗證失敗或目標服務限制仍須另外排查。

03 / 規則維護

以規則集訂閱管理規則與匹配優先順序

開啟執行設定中的 rules 區段，先確認自訂規則位於訂閱規則之前或之後。mihomo 通常會由上而下比對，遇到能決定流向的規則便採用該結果；因此，最明確的業務例外應排在前面，範圍較大的地區規則與最後的兜底規則則排在後面。將規則清單拆成規則集，可以分開管理規則內容與路由意圖：規則集負責列出網域或網段，主設定則決定這些項目走直連、代理或拒絕。

先確認規則內容與 behavior 相符

rule-providers 定義規則來源，RULE-SET 則在主規則清單中呼叫該來源。behavior: domain 適用於網域集合，ipcidr 適用於 IP 網段集合，classical 則使用帶有類型的傳統規則項目。格式與行為是兩個不同面向：YAML、文字或二進位格式描述檔案的儲存方式，behavior 則描述如何解讀每一筆內容。取得規則訂閱後，請先閱讀格式說明；不能只看副檔名判斷內容，更不能將完整用戶端設定直接載入為規則集。

先用本機檔案建立最小測試，比直接接入遠端來源更容易定位問題。將下方第一段內容寫入 rules/local-direct.yaml，檔案應放在設定目錄之下；第二段內容則合併至主設定。範例使用 classical 行為，每條規則都列出類型與匹配內容，不在規則檔案中指定最終策略。主設定中的 RULE-SET 才會將整個集合導向 DIRECT。兜底使用前一章建立的「業務出口」；若採用其他組名，請同步修改引用。

# rules/local-direct.yaml
payload:
  - DOMAIN-SUFFIX,apple.com
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve

# 合併至主設定
rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,業務出口

分開管理遠端更新與本機例外

確認本機規則能命中後，再將需要持續維護的集合改為 type: http，填入可信來源提供的有效規則網址、快取路徑與更新間隔。interval 的單位是秒，不必為了追求即時更新而設成極小值。不同規則集應使用不同的本機快取路徑，避免互相覆蓋。首次啟動時若尚無快取，必須能成功取得遠端規則；已有快取時能否正常使用，則與檔案狀態及核心處理方式有關，因此應同時查看下載日誌與規則集載入結果。

規則集下載本身也會使用網路路徑。若下載網址必須透過代理才能連線，而代理路徑又依賴尚未載入的同一個規則集，就可能形成啟動依賴循環。可在用戶端提供的資源下載策略中指定已可使用的出口，或為規則來源網域設定明確且可用的連線路徑。不要只看規則頁面是否顯示集合名稱，也要查看載入日誌、更新時間與實際命中情況。即使下載成功，項目數量異常、行為類型不符或內容為空，都會使路由結果偏離預期。

no-resolve 常用於 IP 類規則，表示不會為了匹配該規則而主動將網域解析成 IP。這不代表整條連線停用 DNS，也不表示連線從此沒有位址資訊；原本就是 IP 的請求仍可依位址匹配。網域規則通常較直觀，IP 規則則適合網段及缺少網域資訊的連線。若將範圍寬泛的 IP 規則放在業務網域規則之前，可能讓業務過早走直連或代理，因此應根據連線頁顯示的規則類型確認實際匹配順序。

需要進一步細分時，可閱讀自訂規則語法與優先順序，以及中國大陸與海外分流設定實作。訂閱更新後若例外消失，應調整覆寫合併位置，而不是反覆編輯遠端產生的檔案。分享設定前，也要確認規則來源可信，且規則不會將敏感業務導向非預期出口；規則文字能正確解析，只代表結構可讀取，不代表策略符合使用需求。

04 / 網域解析

最佳化 DNS 設定並拆分解析路徑

開啟 DNS 設定前，先從日誌確認問題發生在網域解析、連線至代理伺服器，還是目標網站回應階段。DNS 負責將網域轉換成後續可使用的資訊，但瀏覽器、作業系統、用戶端與遠端代理都可能參與解析。同一個網域可在命令列開啟、卻無法在瀏覽器開啟，可能是瀏覽器使用自己的加密 DNS；代理伺服器的網域解析失敗，也不代表目標網站的解析服務有問題。先分清楚「要解析哪個網域」和「請求要走哪條路徑」，再決定要修改哪個欄位。

分別檢查引導解析與一般查詢

nameserver 定義主要上游 DNS，default-nameserver 用於解析 DNS 上游本身的網域等引導需求，proxy-server-nameserver 則用於解析代理伺服器網域。使用含網域名稱的加密 DNS 位址時，核心必須先取得該伺服器的 IP，才能建立連線；若引導流程又依賴尚未建立的代理，就容易卡在啟動階段。以下是便於理解的基本分工範例，使用的是實際公用解析服務，不代表它們在所有網路環境中都能連線。

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:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "localhost"

將監聽位址設在迴路介面，可供本機程序或 TUN 劫持路徑存取，同時降低區域網路暴露的風險。1053 是可選的示範連接埠，執行設定與相關重新導向設定必須一致。設定 listen 不會自動將 macOS 的所有 DNS 查詢交給核心處理；系統 DNS、TUN 的 DNS 劫持與應用程式自行解析仍須分別確認。若要讓其他裝置使用本機解析服務，還要檢查監聽位址、防火牆、存取範圍與回程路由，而非只改成監聽所有介面。

依網域選擇上游，別盲目堆疊服務

nameserver-policy 可為特定網域或匹配集合指定上游，適用於企業內部網域、家庭網路網域，以及需要指定解析來源的業務。先為一個明確網域建立策略並驗證，再逐步擴大範圍；直接加入大量上游，可能增加並行請求、路徑不確定性與排錯成本。若使用規則集作為 DNS 匹配條件，也應確認目前核心支援相應語法，且規則集已載入。路由規則中的策略名稱與 DNS 上游設定各有語法，不能直接將其中一套字串搬到另一處。

若啟用 respect-rules，上游 DNS 連線會依相應路由規則處理，此時代理伺服器網域的獨立解析尤其重要。若尚無可用出口，解析卻依賴代理，就可能形成循環。請先確保代理伺服器網域能透過明確可連線的解析服務取得位址，再處理一般網站查詢。若設定中同時出現 fallback 與篩選條件，請閱讀實際判斷方式：它並非單純「第一台伺服器失敗才使用第二台」，不能以傳統備援 DNS 的直覺推測其行為。

驗證解析時，請區分真實 IP 模式與 Fake-IP 模式。Fake-IP 模式下看到映射網段位址通常是預期結果，不能因為位址不像網站的公網 IP 就判定解析錯誤。修改 DNS 後先重新建立連線，必要時再清除相關快取；一次清除所有快取會失去診斷線索，也可能造成短暫波動。選擇解析服務時，應考量目前網路、隱私需求與存取目標，不必機械式照抄公用設定。涉及本機內網服務時，請保留可還原的原有 DNS 設定，避免調整期間影響工作網路。

05 / 系統接入

TUN、系統代理與 Fake-IP 協同運作

啟用系統代理後，先確認需要使用的應用程式是否遵循系統代理；只有部分應用程式或命令列工具接入時，再考慮使用 TUN。系統代理主要向應用程式提供 HTTP、HTTPS 或 SOCKS 接入資訊，是否採用取決於應用程式的實作；TUN 則透過虛擬網路介面與路由接管更廣泛的 IP 流量。兩者不是必須同時開啟的加速開關。先保留一種已驗證的接入方式，確認目標應用程式的流量進入核心，再依需求擴大接管範圍。

啟用 TUN 前先確認系統權限

在 macOS 用戶端中找到 TUN 或服務模式入口，依照提示完成輔助服務安裝與系統授權，再查看執行日誌。不同用戶端的按鈕名稱可能不同，授權流程也會隨系統版本而異；請以目前介面為準，不要為了解決授權問題而停用系統安全機制。獨立執行核心通常需要足夠的網路權限。啟用失敗時，先檢查權限、虛擬介面建立與路由設定；遠端代理是否可用屬於後續步驟，兩類問題應分開驗證。

# 合併至現有可用設定；DNS 仍須使用上一章的有效設定
tun:
  enable: true
  stack: mixed
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53

auto-route 用於自動建立接管路由，auto-detect-interface 用於偵測出口介面，stack 則決定 TUN 使用的網路堆疊。範例中的 mixed 是其中一種選擇；若遇到相容性問題，應依核心支援情況比較其他堆疊，不要同時修改 MTU、DNS、規則與系統路由。dns-hijack 會接管進入相關路徑的一般 DNS 查詢，但應用程式直接連線至加密 DNS 服務的 HTTPS 請求，不會因目的連接埠屬於網路請求就自動變成一般 DNS 查詢。

了解 Fake-IP 位址為何仍能連上網站

Fake-IP 會為網域指派映射位址；連線進入時，再根據映射還原網域並套用規則。如此一來，核心不必先取得目標的真實位址，也能保留網域資訊作為判斷依據，有助於網域分流，並減少部分本機解析路徑對結果的影響。映射網段並沒有因此成為網站實際所在的網路，也不代表網站最終不需要建立實際連線。代理出口與直連出口如何解析及建立遠端連線，仍取決於通訊協定、DNS 設定與出口行為。

fake-ip-filter 可讓指定網域避開虛擬映射，適用於確實依賴真實解析結果的業務，例如部分區域網路服務探索或對位址結果敏感的程式。先針對發生問題的特定網域建立例外，再測試功能是否恢復，不要為了消除表面症狀就將所有網域加入篩選清單。若更換 Fake-IP 網段，請確認不會與現有網路、企業 VPN 或其他虛擬介面衝突。仍保留舊映射的應用程式可能繼續連線至舊位址，因此修改後也要考量連線與 DNS 快取的存續時間。

驗證 TUN 時，不能只執行帶有 --proxy 的指令，因為明確指定代理的請求可能會繞過需要驗證的系統接管路徑。請選擇未個別設定代理的應用程式，建立新連線並在用戶端連線頁尋找該連線；再測試區域網路裝置、睡眠喚醒與網路切換。Wi-Fi 切換至有線網路後，若日誌仍指向舊介面，應先檢查介面偵測與路由還原。多個代理用戶端同時啟用 TUN 時，可能造成路由競爭、DNS 重複接管或迴圈；測試期間只保留目前需要的一套接管機制。

若啟用後整台電腦都無法連線，請依相反順序還原：先關閉 TUN，確認系統代理狀態，再恢復原有 DNS 與網路連線。不要立刻刪除所有設定，否則原本可定位的問題會變成重新安裝。介面顯示開關已啟用，只代表設定意圖，不代表虛擬介面、路由與 DNS 都已成功運作。將授權日誌、介面狀態與目標連線紀錄一起檢視，才能判斷問題發生在接入層還是出口層；基本復原步驟也可參閱說明中心。

06 / 連線識別

網域嗅探的用途、限制與排錯

開啟連線頁，先找出真正缺少網域資訊的連線，再判斷是否需要啟用嗅探。部分應用程式會直接送出 IP，或使用獨立解析路徑，導致核心收到連線時沒有原始網域。網域嗅探可從部分通訊協定交握或明文請求資訊中擷取網域，補充規則匹配依據。它不是能擷取所有加密內容的通用工具，也不是開啟後就能將所有 IP 流量還原為網域。目標是否帶有可識別資訊、通訊協定是否受支援，以及交握內容是否可讀，都會影響結果。

先謹慎啟用，再決定是否覆寫目標

HTTP 請求可能包含主機資訊，TLS 交握可能帶有伺服器名稱，QUIC 的部分交握也可能提供可識別線索。現代加密交握保護、非標準通訊協定、純 IP 服務與無法讀取的交握內容，都會限制識別能力。設定中的 sniff 用來指定嘗試識別的通訊協定與連接埠範圍，不代表這些連接埠上的所有流量都使用相應通訊協定。以下範例保留原始連線目標，只補上識別條件，適合用來觀察嗅探是否改善規則判斷。

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 允許嘗試識別缺少網域資訊的純 IP 連線；force-dns-mapping 則與 DNS 映射情境的處理有關。是否覆寫目的位址由 override-destination 控制，這與「為規則取得網域」是不同層次的決定。保留原始目的位址，有助於避免替換應用程式選定的位址所造成的差異；確實需要覆寫時，應針對目標業務個別驗證。尤其是依賴特定 CDN 位址、專用閘道或固定存取路徑的應用程式，即使網域識別正確，也不代表改寫目的地一定合適。

以同一條連線比對規則資訊

排查時先固定策略組成員，再選定一項具體業務：關閉嗅探、建立新連線並記錄目標、規則類型與出口鏈；接著啟用嗅探，再以相同方式操作。不要直接比較兩個不同網頁或兩條已重複使用的連線。若日誌沒有顯示網域，不一定代表欄位未生效，也可能是流量未經過核心、連接埠不在識別範圍內，或通訊協定沒有可擷取的資訊。先確認接入層，再檢查通訊協定識別，最後才調整規則；順序顛倒只會讓問題更複雜。

嗅探結果不能取代 DNS 查詢結果。連線帶有的伺服器名稱可能只是入口網域，後續業務存取的內容網域可能不同；同一個 IP 也可能承載多個網域。僅靠位址反查猜測網域，無法穩定還原應用程式原本的意圖。規則應盡量使用可驗證的業務網域集合，而不是將一次取得的主機名稱視為服務永久不變的範圍。處理登入、媒體與更新服務時，也要考量重新導向網域與資源網域是否使用不同出口。

若啟用後某個應用程式交握失敗、連線等待時間變長或進入錯誤入口，先關閉目的位址覆寫，再針對該業務縮小嗅探範圍。核心支援的略過網域等欄位可用來建立局部例外，但具體語法應符合目前核心文件。不要因單一業務異常就同時重設全域 DNS、TUN 與嗅探，否則會失去比較基準。較有效的做法是保留原本可用的路徑，只修改一項識別設定，並在日誌中確認該設定是否真的影響連線。

分享排錯資料時，只需截取必要的目標網域、規則類型與錯誤訊息，避免上傳整段連線紀錄。網域與存取時間本身也可能包含工作或個人資訊。若要進一步判斷規則寫法，可返回規則集章節，檢查網域規則是否被更早的 IP 規則攔截；若連線根本沒有出現在清單中，則返回TUN 與系統代理章節，確認應用程式使用的網路路徑。嗅探應用於明確的識別缺口，而不是當作所有連線問題的預設開關。

07 / 設定維護

本機覆寫與多訂閱合併

開啟設定管理頁，先找到用戶端提供的覆寫、擴充或合併入口，再決定自訂內容要放在哪裡。遠端訂閱是持續更新的資料來源，直接編輯下載後的檔案，下次更新時很容易被取代。較穩妥的分工是：訂閱提供代理資料，本機覆寫保留連接埠、DNS、業務規則與策略組織。不同用戶端對這些功能的命名與執行順序不盡相同，因此不能只複製一份覆寫檔案，就假設所有用戶端都會以相同方式處理。

先了解物件合併與清單合併的差異

設定中的映射物件與清單需要不同的處理方式。映射物件可能依欄位遞迴合併，也可能整段取代；清單則可能置前、置後、串接或完全取代。規則清單的順序決定匹配優先順序，所以「成功追加」不代表「例外已生效」。若自訂直連規則排在 MATCH 之後，就無法處理流量。DNS 子欄位也可能再次被用戶端設定覆寫；排查時必須查看最終執行檔案，而不只是覆寫編輯器中儲存的內容。

先建立一條精簡的本機例外，確認它在執行設定中的位置，再加入完整規則。以下是用來說明目標結果的最終規則片段，並非適用於所有用戶端的通用覆寫檔案格式。它假設前面章節已建立「業務出口」，並將本機與私有網段排在範圍較大的規則之前。是否允許這些位址直連，應依實際網路需求判斷；企業網路的專用網段、其他 VPN 指派的位址與容器網路也應逐項檢查，避免用過於寬泛的範圍掩蓋實際路由需求。

# 目標執行設定中的規則順序
rules:
  - DOMAIN-SUFFIX,lan,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,業務出口

將多個訂閱分成獨立代理集合

合併多個訂閱時，先判斷來源提供的是完整 Clash 設定，還是可直接作為代理集合讀取的內容。完整設定包含 DNS、規則與其他頂層欄位，不能直接塞進只接受代理清單的位置。將各個可用來源整理成獨立的 proxy-providers，再由本機策略組引用，通常更容易維護。不同來源應使用不同的集合鍵與快取路徑，業務規則則只引用穩定的本機組名；如此一來，上游調整伺服器清單時，主規則不必頻繁修改。

代理名稱衝突是合併時常見的隱憂。不同來源可能使用相同名稱，卻對應不同伺服器；手動拼接 proxies 時可能造成重複或引用歧義。先保留各來源的界線，使用獨立集合檢查成員，再決定是否需要採用受支援的名稱處理方式。不要任意改寫節點名稱，卻仍沿用舊的策略組引用；也不要直接拼接多個檔案中同名的頂層鍵。若不得不使用腳本轉換，請使用目前用戶端明確支援的介面，並保留原始檔案以便還原。

修改完成後，請主動更新一次訂閱，再確認自訂內容是否仍然保留。這比等到幾天後發現規則失效更容易定位問題。匯出的執行設定也不一定包含完整的維護邏輯：它可能只有合併後的結果，缺少覆寫順序、腳本或外部集合來源。因此備份應包含設定資料與產生方式，但仍要妥善保管含敏感資訊的訂閱網址。向他人展示設定時，請使用已移除帳號資訊的最小重現檔案，不要直接分享整份個人備份。

若用戶端不支援所需的合併功能，可先採用穩定的主設定搭配本機檔案集合，避免為了自動化而導入無法檢視的訂閱轉換流程。確實需要轉換時，應了解第三方服務可能接觸訂閱中的資訊。關於網址、剪貼簿與本機檔案的匯入差異，可參閱訂閱格式與匯入方式；本節只說明匯入後如何長期維護。評估維護方案是否合適，重點在於更新能否重複執行、例外能否保留、最終結果能否說明，而不是設定檔是否夠複雜。

08 / 本機控制介面

外部控制面板與設定變更驗證流程

需要使用外部控制面板時，先檢查執行設定中的 external-controller 監聽位址，再確認面板的執行位置。控制介面用於查詢連線、切換策略與管理核心執行狀態，不是應用程式連線至網站時使用的代理連接埠。將面板連線至 7890 這類 mixed-port，通常不會取得控制介面的回應。本機使用時，建議優先監聽迴路位址並保留現有用戶端的管理方式；圖形用戶端可能也依賴同一介面，任意更改連接埠會導致介面與核心失去連線。

分開設定本機介面與靜態面板資源

external-ui 用來指定本機靜態面板檔案目錄，該目錄中必須已有相容面板的頁面資源。核心不會只因看到目錄欄位，就自動取得完整前端檔案。以下片段只說明本機監聽與本機目錄的關係；合併前請確認連接埠未被占用，且用戶端允許修改控制介面。若需要密碼，請透過用戶端支援的安全方式在本機設定足夠強度的專用密碼，並讓面板使用相同密碼。不要將實際密碼寫入公開範例、截圖或可同步分享的設定連結。

# 僅供本機使用；先將面板靜態檔案放入對應目錄
external-controller: 127.0.0.1:9090
external-ui: ./ui

面板通常需要填入介面位址、連接埠與驗證資訊。若介面拒絕連線，先確認是否有監聽；若出現驗證錯誤，再核對密碼；只有在瀏覽器無法存取但命令列可連線時，才進一步檢查跨來源、安全內容或混合內容限制。迴路位址永遠指向存取者自己的裝置：手機瀏覽器填入 127.0.0.1 並不會連到電腦。若需要跨裝置控制，應使用受控且安全的存取方式，了解擴大監聽範圍會帶來的風險，而非直接將管理連接埠暴露於公網。

先唯讀檢查，再執行寫入操作

初次連線至面板時，先查看目前模式、策略組與連線清單，確認連到的是預期的核心執行個體。若電腦上同時執行兩個用戶端，面板可能連到舊程序，導致切換策略看似成功，卻不影響目前流量。核對監聽連接埠、目前設定與一條新建立的連線，可避免這類誤判。下方指令示範本機版本介面的唯讀請求，回應可用來確認介面是否可連線；若已啟用驗證，必須依本機實際設定附上驗證標頭，不能因請求未附驗證而將拒絕存取誤判為核心損壞。

curl --fail --silent --show-error \
  http://127.0.0.1:9090/version

透過面板切換組內成員後，請確認變更是否需要永久儲存。執行狀態、用戶端設定與遠端訂閱屬於不同層次，重新啟動後能否還原選擇，取決於核心設定與用戶端管理方式。不要將一次介面寫入視為已更新本機覆寫檔案。使用腳本自動操作時，應先驗證回應與目標組名，再進行有限範圍的修改；介面錯誤、組名變更或切換目前設定，都可能導致腳本操作錯誤的物件。自動化的價值在於可靠地重複執行，而非省略檢查。

連線清單適合驗證網域、規則與策略鏈，日誌則適合查看下載、解析與交握錯誤。除錯期間可以暫時提高日誌詳細程度，完成後請恢復日常等級，避免累積過多存取紀錄。選擇面板來源也應謹慎：能呼叫控制介面的頁面可能讀取連線資訊並執行管理操作，請只使用可信的本機資源或明確了解其部署方式。瀏覽器提示憑證、跨來源或內容安全問題時，先釐清呼叫關係，不要為了開啟面板就一概放寬所有來源限制。

最後進行一次完整回歸測試：確認訂閱可更新、代理集合與規則集可載入、系統代理或 TUN 能依預期接入、DNS 可解析常用網域、內網服務仍可存取，且面板控制的是目前執行個體。接著測試睡眠喚醒與網路切換，確認功能不只在剛啟動時正常。若某個步驟失敗，返回本指南的對應章節縮小範圍；初次安裝與基本匯入請參閱快速入門教學，選擇用戶端請返回下載頁，一般問題則查看說明中心。保留一份易於說明且可還原的設定，比一次啟用所有進階功能更方便長期維護。