Clash 進階設定指南

策略群組類型與實作

策略群組負責決定流量符合規則後要使用哪個出口，不負責判斷流量屬於哪個網站。設定中的 proxies 定義實際節點，proxy-groups 將節點或其他策略群組組成可選的出口，rules 則引用這些出口名稱。這三層的名稱必須完全相符；把節點改成相近的名稱，不會讓既有規則自動找到新對象。

調整前，先在設定頁確認目前啟用的訂閱，再到代理頁檢查現有策略群組。服務商可能已建立自動選擇、地區分類及應用程式分流等多層結構。直接新增同名策略群組會造成衝突，整份清單直接覆蓋則可能讓既有規則失去目標。先記下名稱與引用關係，比直接複製整份設定更容易找出問題。

手動選擇、速度測試與故障切換

select 用來手動指定出口，適合需要固定地區或登入環境的應用程式。用戶端記住的選擇也可能受持久化設定影響，因此不能只看 YAML 清單中的第一個項目。排錯時，請在代理頁展開策略群組並確認實際選取項目；如果群組又引用另一個群組，還要繼續展開，直到找到真正使用的節點。

url-test 依探測結果選擇出口，適合有多個用途相近的節點。探測網址是否穩定、節點能否連到該網址，以及測速間隔是否太短，都會影響結果。單次探測速度較快，只代表當次請求的表現，不代表所有網站都會更快；下載、影音與辦公服務的連線路徑可能不同，不宜把探測結果當成頻寬排名。

fallback 依清單順序優先使用可用項目，適合明確指定主要與備援出口。load-balance 則依選定策略分配連線，不會把單一下載連線拆到多個節點來累加頻寬。涉及帳號地區、付款驗證或來源 IP 限制時，頻繁更換出口可能觸發額外驗證，通常先用手動群組或主備群組確認行為較妥當。

先建立容易理解的出口層

以下片段只示範策略群組如何供規則引用，不包含代理伺服器。兩種內建出站都可直接辨識，因此不必虛構節點資料。合併至現有設定時，應整合清單，而不是再新增同名的頂層欄位。範例預設直連；若要使用代理出口，請將已匯入訂閱中的實際節點或既有策略群組加入項目清單，再於用戶端選取。

proxy-groups:
  - name: 手動出口
    type: select
    proxies:
      - DIRECT
      - REJECT

rules:
  - DOMAIN-SUFFIX,example.org,手動出口
  - MATCH,DIRECT

實際使用自動群組時，可設定 url、interval 與 tolerance。間隔以秒計，容差可減少細微差異造成的頻繁切換。間隔越短不一定越好，尤其在行動網路或按流量計費的環境中，多個群組同時探測會產生額外請求。先採用適中的探測頻率，再根據記錄確認是否確實需要調整。

群組之間可以互相引用，但必須避免形成循環。例如「辦公出口」引用「自動出口」是清楚的單向結構；如果後者又把前者列為項目，核心就無法建立有效的依賴關係。合併多個訂閱後更容易遇到這個問題，因為不同訂閱常使用相同的群組名稱。建議在本機維護的群組名稱前加上用途識別字，避免依賴可能隨訂閱更新而改變的顯示名稱。

驗證策略群組時，先維持規則模式，造訪一個確定能符合規則的網域，再到連線頁查看命中規則、策略鏈與實際出口。如果連線頁沒有記錄，先確認流量是否進入核心；如果有記錄但走錯群組，再檢查規則順序。不要同時修改模式、節點與 DNS，否則成功或失敗都難以判斷原因。

以規則集訂閱管理

規則集可將經常變動的比對條件從主要設定中拆出，主要設定只保留引用方式與順序。如此一來，網站網域清單更新時，就不必反覆修改策略群組與連接埠設定。規則集與節點訂閱是不同項目：節點訂閱提供出口，規則集提供比對條件，最後使用哪個出口仍由 RULE-SET 規則中指定的策略決定。

管理規則集前，先依用途整理現有規則。裝置與區域網路例外通常要放在較前面；明確的網站分流接著處理；地理範圍與預設規則則放在後面。Mihomo 通常由上而下比對，找到第一條符合的規則就停止；排在後面的精確規則不會自動覆蓋前面的寬泛規則。維護規則順序和維護網域內容同樣重要。

先選行為類型，再選檔案格式

behavior 表示規則內容的語意。domain 用於處理網域集合，ipcidr 用於處理 IP 網段，classical 則可包含帶有類型前綴的規則條件。format 描述檔案的編碼格式，例如 YAML、純文字或受支援的二進位規則格式。格式正確不代表行為類型也正確，兩者都必須符合來源內容。

以下範例使用本機檔案，不需要遠端網址。先在用戶端允許存取的設定目錄中建立對應檔案，再將提供者與規則引用合併至主要設定。相對路徑以用戶端實際傳給核心的工作目錄為準，不是瀏覽器的下載目錄；如果記錄顯示找不到檔案，應檢查設定目錄與執行環境，而不是反覆修改網域內容。

rule-providers:
  local-direct:
    type: file
    behavior: classical
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,手動出口

對應的 local-direct.yaml 內容如下。這裡保留規則條件，沒有在每一行指定出站策略，因為出口由主要設定統一引用。末尾的 no-resolve 表示這條位址規則不會主動觸發網域解析，並非關閉整個用戶端的 DNS。上例的「手動出口」請沿用上一章建立的策略群組，或替換成現有群組名稱。

payload:
  - DOMAIN-SUFFIX,example.org
  - IP-CIDR,192.168.0.0/16,no-resolve
  - IP-CIDR,10.0.0.0/8,no-resolve

改用遠端管理時，將提供者改為 type: http，填入實際可連線的 url、本機快取 path，以及以秒為單位的 interval。不要只憑副檔名猜測檔案內容：伺服器若回傳登入頁、存取限制提示或一般網頁，即使網址以 YAML 結尾，也無法當成規則集解析。先確認回應本文，再檢查設定欄位。

分別處理更新失敗與規則未命中

更新失敗時，先確認下載路徑是否可用。更新規則集本身也需要網路，不能讓唯一可用的出口完全依賴尚未成功下載的資源。若已有快取，用戶端可能繼續使用舊內容，因此「網路仍可連線」不代表新規則已載入。請在提供者狀態與記錄中確認更新完成，再檢查快取內容是否符合預期。

更新成功但沒有命中時，先檢查前面是否已有更寬泛的規則，例如相同網域後綴已設為直連，或較早的 IP 規則先符合。接著確認連線對象是網域還是 IP：以 IP 建立且沒有網域對應資訊的連線，不一定能符合網域規則。最後確認測試的是新連線，因為瀏覽器的連線池可能讓舊連線繼續使用。

規則集變大時，不宜把所有來源都一併堆疊。不同來源可能互相覆蓋、更新週期不一，甚至將同一網站分類為不同類別。較容易維護的做法是選定一套基礎分類，再加入少量本機例外；為每個提供者記錄用途、來源、行為類型與引用位置。刪除時先移除引用，再移除提供者定義。

本機例外應盡量使用範圍明確的規則。只需修正單一網域的出口，就不要把整個頂層網域或大段 IP 範圍都納入同一策略。IP 規則尤其要確認是否會觸發解析，避免為了符合寬泛網段而產生不必要的 DNS 查詢。規則命中理由越具體，之後排查錯誤分流時需要檢查的範圍就越小。

遠端規則是設定供應鏈的一環，應選擇用途明確且內容可供檢視的來源。更新前保留上一份可用檔案，更新後挑選幾個代表性網域檢查策略鏈。若要進一步了解頂層欄位與縮排，請參閱Clash 設定檔 YAML 逐段解析；不要用新增重複欄位的方式嘗試解決合併問題。

DNS 設定最佳化

DNS 設定的目標，是讓網域解析流程與連線出口一致，而不是單純增加伺服器數量。一次請求可能涉及應用程式自行解析、系統解析、核心 DNS，以及代理伺服器的網域解析。只有先判斷查詢發生在哪一層，才能釐清為何瀏覽器正常、命令列卻失敗，或是切換出口後仍連到原本的位址。

用戶端中的 dns.enable 會啟用核心 DNS 功能，但不代表所有應用程式都一定使用它。系統代理通常只處理支援代理設定的應用程式連線，不一定會接管系統 DNS；TUN 的 DNS 劫持則是另一條路徑。應用程式內建的加密 DNS 也可能繞過一般的 53 埠查詢，因此不能只看開關狀態，就認定所有解析都已統一。

分清引導解析、一般解析與策略解析

default-nameserver 用來解析 DNS 上游伺服器本身的網域，通常應設定可直接連線的 IP 位址。nameserver 是一般上游伺服器清單。nameserver-policy 則可依網域為特定範圍指定上游伺服器。它控制解析的去向，不等同於 rules 控制業務連線的去向，兩者需要分別檢查。

以下片段示範一般解析模式與局部網域策略。監聽位址設為回環介面，高位連接埠則有助於避免與系統服務衝突。此片段不會自動變更作業系統的 DNS 設定，也不包含 TUN；可先使用查詢命令直接連線至監聽連接埠，確認核心有回應，再考慮讓應用程式使用。合併時應取代或整合原有的 DNS 物件，不要在檔案末尾再新增一份。

dns:
  enable: true
  listen: 127.0.0.1:1053
  ipv6: false
  enhanced-mode: redir-host
  default-nameserver:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  nameserver-policy:
    "+.example.org":
      - 223.5.5.5

範例中的網域策略只用來說明比對方式，不代表該網域一定要使用指定的上游伺服器。企業內網網域應指向實際能解析它的內部 DNS，不要直接照抄公共伺服器。使用內部伺服器時，也要確認請求經過的網路介面與路由；離開公司網路後，內部 DNS 可能完全無法連線，長期寫死設定就會造成間歇性故障。

啟用依規則控制 DNS 出站時，還要檢查 respect-rules 與 proxy-server-nameserver 如何搭配。若代理伺服器位址本身是網域，核心必須先解析該網域才能連線，不能又要求解析只能經過尚未建立的代理。為代理伺服器網域保留獨立且可連線的解析路徑，可避免這種啟動依賴循環。

備援機制不等於多放一組伺服器就有保障

fallback 與 fallback-filter 必須一起理解。後者決定哪些解析結果會採用備援解析，並非主伺服器逾時後就依序嘗試所有備用位址。只增加備援伺服器而不檢查篩選條件，可能讓同一網域得到不同於預期的位址。建議先以精簡設定確認基本解析，再依實際的 DNS 污染或地區需求增加分流條件。

啟用加密 DNS 可保護查詢傳輸至上游伺服器的過程，但無法自動確保解析結果適合目前的出口。遠端上游可能回傳其他地區的內容傳遞網路位址，導致連線繞路。遇到網站載入變慢時，應比較解析結果、實際連線位址與出口路徑，不宜把所有效能差異都歸咎於節點，也不必為每個網域個別設定策略。

IPv6 應從整條連線路徑判斷。系統取得 IPv6 位址，不代表代理節點、TUN 路由與目標網站的 IPv6 路徑都正常。停用 DNS 的 IPv6 回應可以縮小排錯範圍，但不能取代系統路由檢查；若應用程式使用快取位址，修改後仍可能繼續連線。先結束相關應用程式的連線，再重新查詢與測試，結果才有比較意義。

在有提供 dig 的系統上，可使用以下命令檢查範例監聽連接埠。留意是否收到回應、耗時是否異常，以及位址類型是否符合目前模式。查詢成功只能證明這次直接連線至核心 DNS 成功，仍需從實際應用程式發起連線，確認沒有使用其他解析方式。若未安裝相關查詢工具，不必為了測試而修改整個系統的 DNS。

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

排查快取時應分層進行：瀏覽器、作業系統與核心都可能保存解析結果。修改策略後先建立新連線，必要時再清除對應層級的快取，不必每次都重新啟動電腦。若記錄持續出現解析失敗，記下失敗網域與使用的上游伺服器；若只有單一網站異常，優先檢查網域策略與應用程式本身的設定。錯誤訊息的閱讀方式請參閱記錄訊息解讀與排查方向。

TUN 與 Fake-IP

TUN 透過虛擬網路介面接收流量，適合不讀取系統代理設定的應用程式。Fake-IP 則是 DNS 的一種運作模式：核心會回傳供內部映射使用的位址，並在後續連線中還原網域資訊。兩者常一起使用，但並非同一項功能，也不代表所有環境都必須同時啟用。先確認缺少的是流量接管還是網域關聯，再決定要調整哪一層。

若系統代理已能滿足需求，可以先維持 TUN 關閉。需要接管命令列工具、遊戲或其他直連應用程式時，再啟用 TUN 並檢查系統權限。Clash Verge Rev 的服務模式、作業系統授權及其他網路軟體都可能影響虛擬介面的建立；介面上的開關顯示已啟用，不能取代對介面、路由與連線記錄的檢查。

先建立流量接管路徑，再調整 DNS 模式

以下片段示範常見的 TUN 自動路由與 Fake-IP 組合。用戶端必須具備建立虛擬介面及設定路由的權限，請透過用戶端提供的設定入口確認權限狀態。各平台對協定堆疊與介面的支援有所不同，不能直接把其他平台的某個值視為效能最佳選擇；遇到相容性問題時，先還原原本的協定堆疊。

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:
    - https://dns.alidns.com/dns-query

auto-route 負責新增相關路由，auto-detect-interface 用來辨識出站介面。但在同時使用多張網卡、虛擬機橋接或企業 VPN 時，這些設定無法保證自動選對路徑。切換無線網路、接上有線網路或啟動另一套隧道後，如果流量突然中斷，先檢查出口介面與路由變化，不要立刻重建訂閱。

dns-hijack 中的一般 DNS 劫持，不等於攔截所有形式的網域解析。應用程式自帶的 HTTPS DNS 請求屬於加密業務流量，通常不能當成一般 DNS 封包處理。部分系統的本機 DNS 服務也有獨立的轉送路徑。驗證時應同時查看查詢結果與連線頁顯示的網域，而不是因為設定了 53 埠規則，就認定所有應用程式都已受控。

Fake-IP 位址是映射，不是遠端伺服器

在 Fake-IP 模式下，看到保留範圍內的位址是正常現象，不能直接判定目標網站故障。實際連線時，流量必須回到維護這份映射的核心。如果應用程式取得映射位址後繞過核心直接連線，通常就會失敗。因此，DNS 接管與流量路由必須搭配使用；單獨把系統 DNS 指向核心不一定完整。

fake-ip-filter 用來讓特定網域取得真實解析結果，常見情況包括區域網路裝置名稱，以及確實有相容性問題的應用程式網域。清單並非越長越穩定：排除太多網域會減少可用的網域映射資訊，也可能改變後續規則的比對路徑。先確認具體故障對象，再新增範圍最小的例外，避免一開始就排除整個公用網域空間。

本地域名後綴例外不能取代對裝置探索協定的支援。印表機、投放與檔案共用可能還依賴多點傳送、廣播或作業系統服務；解析成功不代表一定能探索到裝置。排查時分別確認裝置 IP 是否可連線、名稱是否能解析、服務連接埠是否開啟，再判斷是否需要排除路由。不要為了修復單一裝置，就強制代理所有私有網路流量。

與企業 VPN 共用時，應先保留企業網路所需的路由。如果兩套軟體都試圖接管預設路由，流量可能反覆進入隧道，或導致內部服務無法連線。記錄啟用前後的路由表，分別測試公網、內網位址與代理伺服器位址，再決定是否排除介面或網段；具體欄位應依目前核心能力與系統路由設計選擇。

停用 Fake-IP 或切換設定後，應用程式可能仍快取舊的映射位址，而新核心已沒有對應記錄。此時先結束應用程式連線並重新解析，必要時清除快取，不要把所有連線失敗都歸咎於節點中斷。啟用映射持久化有助於部分重新啟動情境維持一致，但無法解決 DNS 被其他服務接管或流量繞過核心的問題。

建議固定驗證順序：先確認一般代理連線可用，再啟用 TUN，檢查原本不走代理的應用程式，最後切換 Fake-IP 觀察網域比對。每一步都保留可用設定。若剛啟用 TUN 就全面斷網，優先停用並恢復網路，再檢查權限與路由；反覆更換節點通常無法解決虛擬介面未建立的問題。

網域嗅探

網域嗅探會從連線初期可取得的協定資訊補上網域，例如 HTTP 要求中的 Host、TLS 交握中的伺服器名稱。這有助於在只有目標 IP 時比對網域規則，但無法保證還原所有連線的網域，也不會解密 HTTPS 內容。結果會受到應用程式使用的協定、交握名稱是否隱藏，以及流量是否進入核心等因素影響。

啟用前先確認是否真的缺少網域資訊。如果 Fake-IP 映射已提供正確網域，嗅探未必有額外幫助；如果連線根本沒有進入核心，開啟嗅探也無法補救。常見的排查情境是：連線頁看得到目標 IP 與連接埠，但網域欄位空白，導致原本針對網站後綴的規則沒有命中。

從少數協定與連接埠開始

以下片段只會在常見 Web 連接埠嘗試 HTTP、TLS 與 QUIC 嗅探，並允許處理尚無網域資訊的連線。它不會啟動 TUN、不會取代 DNS 設定，也不會自動改變所有應用程式的代理行為。合併後需要重新建立連線；已完成交握的長連線通常不會因為開啟嗅探而重新提供初始協定資訊。

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

parse-pure-ip 表示嘗試處理原本只有 IP 資訊的連線，不代表能辨識任意二進位協定。連接埠範圍也只是嘗試辨識的入口，不代表該連接埠上一定執行對應協定。把所有連接埠都加入所有協定，通常只會擴大處理範圍，無法解決交握內容本來就沒有可讀網域的問題。

override-destination 涉及是否以嗅探取得的目標資訊覆寫原始連線目標，與「能否取得網域」不是同一件事。有些應用程式對實際連線位址有明確要求，覆寫目標可能改變服務選擇，或與應用程式快取不一致。範例明確關閉 HTTP 的目標覆寫，是為了先觀察網域辨識結果，再依相容性判斷是否需要調整。

將辨識結果與原始目標交叉比對

CDN、多個網域共用位址及應用程式內建的位址清單，都可能讓 IP 與網域的對應關係不唯一。一個 IP 可以服務多個網站，不能只憑反向解析或位址歸屬判定目前的業務網域。嗅探取得的協定名稱比依位址猜測更具體，但仍應配合應用程式實際的存取行為判斷，尤其是遇到重新導向與多個後端請求時。

測試時先選擇一個能穩定重現的請求，結束相關連線後重新操作，並在連線頁查看目標網域、命中規則與出站鏈。如果網域已顯示但規則仍未命中，檢查規則順序與比對類型；若規則正確但服務仍失敗，就繼續確認出口、DNS 位址與目標覆寫行為。嗅探成功不代表整條連線都正常。

可暫時提高記錄層級，以便觀察連線過程；完成一次完整重現後，請恢復常用層級。詳細記錄可能包含瀏覽過的網域與連線中繼資料，不宜長期保存後直接公開。提供排錯資料給他人時，請移除訂閱網址、帳號資訊與控制介面憑證，只保留故障相關的幾行記錄與必要設定結構。

QUIC 使用 UDP，HTTP/3 能否正常運作還取決於代理節點與網路路徑是否支援 UDP。連線失敗時，先判斷是傳輸協定失敗還是網域辨識失敗。單純關閉 QUIC 嗅探不會強制應用程式改用 TCP；是否切換取決於應用程式本身，不能把這個開關當成通用的協定轉換功能。

部分 TLS 連線可能使用加密交握名稱機制，或透過另一層隧道傳輸。此時可觀察到的資訊會減少，嗅探無法憑空還原原始網域。較穩妥的做法是讓應用程式使用可控的 DNS 路徑、保留 Fake-IP 映射，或在清楚了解適用範圍後，以位址與處理程序條件補充規則，而非無限制擴大嗅探連接埠清單。

遇到單一應用程式的相容性問題，可考慮依目前核心支援的欄位設定 skip-domain 等例外，先排除特定網域再測試。例外條件必須符合實際辨識到的對象：如果記錄中只有 IP，填入一個從未出現的網域未必有效。若關閉嗅探後恢復正常，請逐項比較協定範圍與目標覆寫設定，不要直接刪除整套規則。

企業內部應用程式、固定 IP 服務與裝置管理頁面尤其需要謹慎。它們可能傳送與實際位址用途不同的主機名稱，或依賴閘道器特定映射。先保留區域網路直連規則，避免嗅探結果將內部請求送往公網出口。若要了解連線、規則與記錄頁面的用途，可參閱用戶端介面功能速覽逐項確認。

本機覆寫與多訂閱合併

訂閱內容通常由遠端維護，本機偏好設定則需要在更新後保留下來。直接編輯從遠端訂閱下載的 YAML，短期內可能生效，但下次更新時修改內容可能被覆蓋。本機覆寫可將穩定的個人設定與定期更新的遠端內容分開；重點不在編輯入口的名稱，而是確認它在哪個階段執行、會修改哪些欄位，以及最後產生的內容。

在 Clash Verge Rev 中，應透過設定頁提供的擴充、合併或腳本入口管理本機調整，具體名稱以實際介面為準。有些設定也會由用戶端的全域設定寫入核心執行設定，因此訂閱檔中的值未必是最後生效的值。先檢查用戶端設定，再查看執行設定與記錄，比在原始檔中反覆新增相同欄位更有效。

分別驗證物件合併與清單取代

不同的合併機制可能以不同方式處理物件與陣列。物件可能依鍵值合併，而 rules、proxy-groups 這類清單則可能整份取代、加在前面或加在後面。不能因為 DNS 的某個欄位保留成功，就推定規則清單也會以相同方式保留。先用一條容易辨識的本機規則測試實際行為，再擴大修改範圍。

以下片段表達「保存策略群組選擇」的設定意圖，本身不是通用的合併指令。將它放入用戶端認可的合併入口後，還需確認執行設定保留了原訂閱的其他必要欄位。如果某個腳本會重建整個 profile 物件，後執行的結果仍可能覆蓋先前設定，因此應檢查最終輸出，而不只是確認編輯器已成功儲存。

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

新增本機規則時，最需要留意的是插入位置。用來修正特定網站的規則應放在較前面；如果加在現有的 MATCH 後面，通常永遠不會執行。保留一條明確的預設規則就足夠，不必為每個訂閱各新增一條。合併後的清單應能逐行說明用途；重複規則太多會增加排錯難度。

兩個訂閱不代表能直接拼接兩份完整設定

完整設定通常同時包含連接埠、DNS、策略群組與規則，不能把兩份檔案直接首尾相接。YAML 頂層鍵重複時，解析器可能拒絕載入，也可能以前面的值或後面的值為準，結果取決於工具的處理方式。若只需要組合節點，優先將訂閱作為代理提供者，再由本機統一管理策略群組與規則，避免多個遠端來源爭用相同的基礎設定。

以下範例使用兩個本機代理提供者，方便先驗證設定結構。兩個檔案都必須由使用者準備，且各自包含有效的 proxies 清單；它們不是任意的 Base64 節點字串。此片段也不含虛構伺服器，只有提供者引用與一個備用直連項目。第一次測試時，先確認兩個檔案都能正常使用，再啟用統一的選擇群組。

proxy-providers:
  source-a:
    type: file
    path: ./providers/source-a.yaml
  source-b:
    type: file
    path: ./providers/source-b.yaml

proxy-groups:
  - name: 訂閱彙整
    type: select
    use:
      - source-a
      - source-b
    proxies:
      - DIRECT

代理提供者檔案可保留原本可用的節點定義，但應移除與提供者格式無關的整套規則與全域設定。改用遠端提供者後，再補上實際訂閱網址、快取路徑與更新間隔。格式不相容時，請使用可信任的本機處理方式或服務提供者的相容入口；具體差異請參閱訂閱匯入方式與格式說明。

多個來源的另一個問題是節點名稱重複。即使提供者名稱不同，同時顯示在同一策略群組中的節點仍可能難以區分，腳本依名稱篩選時也容易選錯。優先使用來源前綴或目前核心支援的名稱處理功能，並維持命名穩定；不要只憑地區旗幟、短期活動名稱或流量提示來建立長期引用。

篩選條件也應設有備援方案。依地區關鍵字篩選時，服務商更改名稱可能導致群組突然沒有節點。請確認用戶端是否明確回報空群組，並保留可操作的選擇方式。使用正規表示式前，先用少量節點確認比對結果；不要未經驗證就把複雜條件套用至所有策略群組，再靠猜測尋找消失的項目。

腳本適合處理明確且可重複的轉換，例如統一命名或插入少量規則，不適合隱藏大量沒有記錄的設定變更。執行前保留輸入資料，執行後檢查輸出；發生錯誤時，應能明確還原原始訂閱。若腳本來自他人，請檢查它是否會連線至外部網址、讀取本機資訊或修改控制介面；不能只憑「可以連網」就認定適合長期使用。

外部控制面板

外部控制介面可查詢核心狀態、查看連線與調整策略選擇；控制面板則是呼叫此介面的前端。它與瀏覽器使用的 HTTP 代理連接埠不是同一個入口。混合連接埠處理代理流量，控制連接埠處理管理要求；若將控制面板的連線位址填成混合連接埠，通常只會發生連線錯誤，不會開啟用戶端的代理頁面。

Clash Verge Rev 已提供常用的代理、連線與記錄介面，一般在本機操作時直接使用用戶端即可。只有需要獨立面板、遠端裝置管理或自動化查詢時，才需要設定外部控制。控制功能可能影響目前所有連線與出口選擇，因此應優先考慮監聽範圍與連線來源，不要先把連接埠開放給區域網路。

本機使用先從回環監聽開始

以下範例只監聽回環位址，並引用已放在本機的面板靜態檔案目錄。目錄需由使用者自行準備，路徑以實際核心工作目錄為準。範例中的密碼是明確標示的教學用假值，實際使用前請換成自行產生的長隨機字串；不要把實際密碼寫入公開設定、螢幕截圖、分享連結或版本控制儲存庫。

external-controller: 127.0.0.1:9090
secret: "example-only-change-before-use"
external-ui: ./ui

控制連接埠與混合連接埠需要分別檢查是否被占用。設定儲存後，如果記錄顯示監聽失敗，先確認是否有其他用戶端或核心程序占用該連接埠；不要為了避開占用就直接改成監聽所有介面。修改連接埠後，也要同步更新面板連線設定。處理方式可參考混合連接埠占用排查文章，但查詢的連接埠應改為目前的控制連接埠。

面板需要知道介面位址與驗證資訊，但面板本身不一定和核心在同一台裝置上。面板頁面中的 127.0.0.1 指向瀏覽器所在的裝置：在手機瀏覽器開啟面板時，它不是桌上型電腦的回環位址。這是遠端連線失敗的常見原因，不能只靠在桌面設定中啟用「允許區域網路連線」解決。

跨裝置連線要檢查安全邊界，不只是更改位址

確實需要跨裝置管理時，應使用可信任的網路、明確的防火牆規則與經過驗證的存取路徑。將監聽位址改為 0.0.0.0 只代表接受來自多個介面的連線，不會自動建立安全邊界。裝置若同時連接公網介面、虛擬網路或訪客 Wi-Fi，開放範圍可能比預期更大，設定前應逐一確認。

透過瀏覽器存取介面時，還可能受到同源政策、跨來源設定與混合內容限制。HTTPS 面板要求一般 HTTP 介面時，瀏覽器可能會封鎖請求，這不代表核心沒有啟動。請先在本機確認介面能正常回應，再檢查開發者工具中的具體錯誤；不要用允許任意來源的寬鬆跨來源設定，掩蓋位址或通訊協定設定問題。

本機面板資源應取自可供檢視且相容於該介面的專案，並依專案說明部署。目錄存在不代表資源完整，資源能開啟也不代表管理介面已通過驗證。排錯時請將「靜態頁面載入」、「介面可連線」、「驗證通過」、「操作成功」分成四個步驟；每一步都確認結果後再進行下一步，避免將空白頁面與驗證失敗混為一談。

自動化查詢同樣應遵循最小暴露原則。若腳本只需在本機使用，就不必為了方便將控制介面公開至網際網路。驗證資訊應由執行環境安全提供，不要硬編碼在網頁腳本中；訪客可以讀取任何由瀏覽器下載的 JavaScript，不能靠壓縮程式碼或更改檔名保護密碼。排錯資料也應清除要求標頭與連線設定中的敏感資訊。

修改後依固定順序驗收

第一步，檢查執行設定是否包含預期的監聽位址，以及記錄是否回報連接埠占用或設定解析錯誤。第二步，在同一台裝置上確認介面可連線且驗證結果正確。第三步，再載入面板，確認連接的是目前使用的核心，而不是背景中殘留的另一個程序。最後修改一項容易還原的策略選擇，觀察用戶端介面是否同步更新。

若介面可連線但面板中的代理群組是空的，先確認目前設定確實載入了策略群組，再檢查面板與介面的相容性。若能查看狀態卻無法切換，請檢查該群組是否允許手動選擇，以及驗證與要求是否出錯。不要以重新安裝用戶端取代分層檢查；重裝無法自動修正錯誤的目標位址或背景重複程序。

結束前恢復常用記錄層級、關閉暫時開放的監聽、刪除不再需要的本機面板目錄或自動化工作，並保留一份可用設定備份。備份應區分公開結構與私人訂閱資訊，分享時只提供必要片段。日後更新用戶端或核心後，依相同順序重新測試重要功能，才能判斷變化來自設定、面板還是執行環境。