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

模式與設定基準

進階設定應從一條已驗證可用的連線路徑開始。保留目前可用的訂閱、手動選取的節點與系統代理設定，並記下用戶端名稱、核心類型、混合連接埠及目前的 Profile。不要同時更換訂閱、啟用 TUN 和調整 DNS；多項變更疊加後，即使網頁能開啟，也只能確認最終結果，無法判斷是哪一層改變了行為。

區分設定來源與執行結果

用戶端通常會將訂閱檔、本機設定和覆寫內容組合後交給核心。訂閱編輯器中顯示的連接埠，不代表核心最後監聽的也是同一個連接埠。請查看用戶端提供的執行設定、核心設定預覽或啟動記錄，確認實際值。如果檔案已成功儲存，但行為沒有改變，先確認編輯的是目前啟用的 Profile，再確認是否需要重新載入，不要一再加入相同欄位。

設定中的名稱引用也屬於執行相依項目。規則末尾的策略名稱必須存在於節點或策略組中，策略組引用的 provider 也必須已定義。YAML 可以解析，只代表語法正確，不代表引用的物件確實存在。請使用空格縮排，避免使用定位字元；名稱含逗號、冒號或特殊符號時請加上引號，重新命名後也要檢查所有引用位置。

規則、全域與直連的用途

mode: rule 會依規則清單的順序，由上而下決定出站；全域模式通常會將需要代理決策的連線交由全域策略處理；直連模式則用來略過代理，直接連線。選擇模式不會自動修復節點、解析或路由問題，也不代表所有應用程式都已接管。系統代理以外的程式是否進入核心，仍取決於應用程式設定、TUN 或閘道轉送。

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

這份基準設定將混合代理連接埠設為 7890、關閉區域網路存取，並保留資訊層級的記錄。混合連接埠可接收 HTTP 與 SOCKS 代理請求，但應用程式仍須使用正確的代理協定。若連接埠已被占用，請先停止另一個監聽程序，或統一調整用戶端與應用程式設定；只修改應用程式中的數字，會讓連線指向不存在的監聽器。

模式	適合檢查	無法據此判斷
規則	網域、位址與規則順序	所有應用程式都已接管
全域	目前的代理路徑是否可用	規則內容正確
直連	區域網路與直接連線路徑	DNS 一定會繞過核心

建立可重複的驗證流程

每次只變更一項設定，再用同一個應用程式建立新連線。既有長連線可能繼續沿用舊策略，因此請關閉相關連線或重新啟動測試應用程式。先在連線面板確認請求是否進入核心，再查看命中的規則與實際出站路徑。若沒有連線記錄，請回頭檢查流量接管層；若有記錄但策略選錯，則檢查規則與策略組。

全域模式可用、規則模式卻失敗，通常表示兩種模式選用了不同的出站路徑，或規則模式將目標導向不適用的直連路徑。請先比較實際出站名稱再判斷。直連能連上某個網站，也不代表整份訂閱都失效；目標位址、解析結果與伺服器行為都可能不同。保留同一目標的對照結果，才能避免把局部狀況當成整體故障。

若要區分用戶端介面與核心行為，可先閱讀名詞解釋中的設定結構與網路接管概念。更換用戶端時，建議先到下載中心選擇 Clash Plus，再依平台與所需核心功能比較其他用戶端。各介面的開關位置可能不同，但本頁採用的驗證順序一致：載入設定、確認請求進入、比對規則、檢查出站連線。

策略組類型與實務應用

策略組可將規則與個別節點分開管理。規則可以長期引用「業務出口」，組內節點則可隨訂閱更新而替換。設計前先釐清選擇需求：要手動指定、優先維持特定線路、自動選擇回應較快的候選項，還是將不同連線分散到多個出口。不要在同一份設定中堆疊所有組類型；層級越多，排查時需要追蹤的引用鏈就越長。

手動選擇與自動選擇

select 適合手動固定出口，選擇結果容易理解。url-test 會依探測結果自動選擇候選項；fallback 按清單順序使用可用項目，適合設定主備線路；load-balance 會依策略將不同連線分配到不同出口，不會將單一下載連線的頻寬合併。需要穩定出口的登入、付款或工作階段服務，通常不適合頻繁自動切換。

以下片段假設目前設定已定義「線路甲」和「線路乙」兩個節點。實際使用時，請替換為訂閱中的正確名稱。頂層手動組可以選擇自動組，也可以直接選取節點；規則只需引用頂層組，之後調整候選清單時便不必逐條修改規則。

proxy-groups:
  - name: 自動出口
    type: url-test
    proxies:
      - 線路甲
      - 線路乙
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 50

  - name: 業務出口
    type: select
    proxies:
      - 自動出口
      - 線路甲
      - 線路乙

rules:
  - DOMAIN-SUFFIX,example.com,業務出口
  - MATCH,業務出口

了解探測參數的意義

interval 是探測間隔，單位為秒；tolerance 是切換容許值，可避免候選項之間的小幅差異造成頻繁切換。探測 URL 應能透過候選線路穩定連線。探測結果反映的是該線路連至指定測試服務的狀況，不等於所有網站的速度，也不能據此推算影片傳輸量、封包遺失率或目標平台的可用性。

多個組共用相同候選項且探測間隔很短時，健康檢查會增加背景請求。建議先設定適中的間隔，再依線路變化頻率調整。啟用延遲探測相關的延遲執行行為後，未使用的組可能不會立即取得新結果；查看面板數值時，也要參考最近探測時間，不能將舊值視為持續更新的即時監控。

巢狀組、訂閱引用與業務分層

節點由 proxy-providers 提供時，策略組可使用 use 引用 provider，無須複製所有節點名稱。訂閱新增或移除節點後，候選集合便能隨載入結果更新。名稱篩選可用來縮小候選範圍，但地區標籤通常只是提供者的命名習慣，不代表實際出口屬性。篩選條件有誤時可能產生空組，請檢查展開後的候選清單。

常見且穩定的結構是設定一個手動總出口，再建立少量依用途分類的組。業務規則引用用途組，用途組再引用自動組或固定節點。避免甲組引用乙組、乙組又引用甲組；循環相依會導致設定載入失敗。也不要讓自動組包含會回到自身的選擇鏈，即使介面能顯示名稱，最終出站仍可能無法解析。

自動組頻繁切換時，先檢查候選項是否穩定、測試服務是否受到限制，再提高容許值或改用主備組。若只有特定服務異常，請固定同一個節點重新測試，避免測試期間出口不斷變動。組的選擇改變後，舊連線可能仍沿用原本的出站路徑；請觀察新連線，不要只看策略組按鈕是否已顯示新名稱。

節點品質還受到流量倍率、地區與協定影響，不宜只按單一探測數值排序。可參考節點選擇與延遲評估方法建立候選集合。進階設定的目標不是讓所有業務共用同一條自動路徑，而是讓每條規則的選擇理由清楚，並在故障時保留可手動切換的出口。

以訂閱方式管理規則集

規則清單決定比對順序，規則集則用來管理一批比對條件。將經常變動的網域或位址整理到 rule-providers 後，可讓主要設定保持精簡，但規則集並不是另一套獨立的優先順序系統。核心仍會依照 rules 由上而下檢查，第一條符合的規則會決定出站；若將涵蓋範圍過大的集合放在前面，就可能遮蔽後續更精確的規則。

先確認規則行為，再選擇檔案格式

behavior: domain 用於網域集合，ipcidr 用於 IP 網段，classical 則可包含多種完整規則條件。行為類型與檔案格式是兩個不同維度：format 說明檔案如何編碼，行為類型則說明內容如何解讀。不能因為副檔名都是 YAML，就將完整的 DOMAIN-SUFFIX 項目放進只接受網域項目的集合。

以下使用本機 classical 規則集，方便先驗證設定結構。請將第二段存入核心工作目錄的 rules/work.yaml，並將第一段合併到目前的設定中。此範例假設「業務出口」策略組已存在。檔案型 provider 通常需要重新載入才會套用變更；若用戶端將檔案複製到其他工作目錄，請確認實際讀取路徑。

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

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

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,example.org

安排例外、一般比對與後援規則

建議先列出少量必須優先處理的例外，再加入業務網域集合，接著處理所需的位址規則，最後保留 MATCH。此處的 GEOIP,CN,DIRECT 只是常見結構範例，不代表所有目標都適合依地區直連。位址歸屬資料、跨區域服務與共用基礎架構都會影響結果，請依實際業務需求調整。

網域規則通常不需要先解析位址才能比對；位址規則則可能觸發解析。對支援此參數的位址規則加入 no-resolve，可避免只為比對而主動解析，但也可能導致只有網域、沒有目標位址的請求無法符合該規則。這不是通用的效能開關，而是對比對準確度與解析行為所做的明確取捨。

行為類型	內容重點	常見檢查項目
`domain`	網域及其比對形式	是否符合網域集合語法
`ipcidr`	IPv4、IPv6 網段	遮罩與位址類型是否正確
`classical`	完整規則條件	是否誤含出站策略名稱

將遠端更新視為設定相依項目

切換為 HTTP 類型時，必須提供可連線的實際規則網址、快取路徑與更新間隔。更新間隔的單位為秒，不可直接套用用戶端訂閱介面的分鐘或小時數值。快取路徑應保持唯一，避免兩個 provider 共用同一個檔案。首次啟動時若沒有快取，下載規則所需的連線路徑必須先能運作，否則可能形成設定相依項目尚未建立，卻又等待它完成的循環。

遠端更新失敗與規則比對失敗應分開排查。先確認 provider 是否載入、項目是否存在，再檢查請求是否符合集合。已有快取可能讓服務繼續運作，但不代表更新成功；反過來說，下載成功也不代表內容符合指定的行為類型。記錄中的解析錯誤、空集合與下載異常應分別處理，不要一概歸因於節點無法使用。

維護規則集時，請記錄來源、用途與復原檔案，並保留上一份可正常載入的內容。新增集合後，以一個應符合及一個不應符合的網域進行正反測試，再觀察是否影響其他業務。若比對結果不如預期，可暫時將相關規則移到前面測試涵蓋關係；確認原因後，再恢復預定的順序，不要長期依賴不斷追加的例外。

DNS 解析路徑最佳化

DNS 設定首先要規劃解析路徑，其次才是選擇伺服器。需要分清楚應用程式向誰查詢、核心向誰查詢，以及核心如何解析代理伺服器本身的網域。瀏覽器可能使用獨立的加密 DNS，作業系統可能快取舊結果，路由器也可能轉送查詢。只修改 nameserver，不代表所有應用程式的查詢都會經過核心，也不保證代理節點網域使用相同的解析路徑。

區分引導解析與一般解析

default-nameserver 主要用來引導解析 DNS 上游伺服器本身的網域，應選擇目前網路可直接連線的位址；nameserver 負責一般業務查詢；proxy-server-nameserver 則用於解析代理節點網域。混淆這幾種用途，可能造成「必須先連上代理才能解析代理位址」的相依循環，導致啟動後長時間無法建立任何出站連線。

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:
    - 223.5.5.5
  nameserver:
    - https://dns.alidns.com/dns-query
  proxy-server-nameserver:
    - 223.5.5.5
  fake-ip-filter:
    - "*.lan"
    - "*.local"

此範例假設目前網路可連線至列出的解析服務。它不會自動將系統 DNS 改為 1053 連接埠，也未啟用 TUN 劫持。多數系統的一般 DNS 設定不支援自訂連接埠，因此應分別驗證監聽與流量接管。可使用支援指定連接埠的查詢工具測試核心，再檢查系統請求是否確實重新導向至核心。

依網域選擇 DNS 上游

nameserver-policy 可讓特定網域使用指定的上游，適用於內部網域、專用解析環境或確實有不同需求的業務。它決定使用哪個解析器，不會直接決定最終連線的出站路徑。不要將「某網域使用某 DNS」與「某網域一定走代理」畫上等號；連線仍須經過規則比對，必要時也會受到 DNS 請求本身路由設定的影響。

使用 respect-rules 讓 DNS 請求遵循規則時，必須特別檢查代理伺服器網域的解析與引導路徑。DNS 請求也進入規則比對後，錯誤的後援策略可能讓查詢依賴尚未建立的代理連線。請先確認哪些查詢必須能直接完成，再逐步增加策略限制。僅看到加密 DNS 位址，不足以證明傳輸路徑符合預期。

快取、IPv6 與結果比對

修改 DNS 後，應分別考慮應用程式快取、系統快取與核心快取。重新開啟網頁可能沿用既有連線，不能作為重新解析的證據。請關閉相關連線、清除適當層級的快取，再查看查詢與連線記錄。不要一開始就清除所有狀態；保留修改前的結果，並比較回傳位址、回應類型與實際出站，才能判斷問題發生在哪一層。

頂層的 ipv6 與 DNS 區段中的 ipv6 作用範圍不同：前者涉及核心使用 IPv6，後者影響解析回應是否包含 IPv6 結果。若網路沒有可用的 IPv6 路由，卻提供應用程式優先使用的 IPv6 位址，連線可能會等待一段時間後才改用其他方式。反過來說，直接停用 IPv6 也不是所有網路都適用的做法，請先確認裝置路由與服務需求。

解析正常但連線失敗時，不要繼續盲目更換 DNS。請檢查目標位址能否透過選定的出站路徑連線、規則是否判斷錯誤，以及憑證與系統時間是否正常。若解析失敗但節點仍可連線，則應著重檢查查詢路徑與上游可達性。將「解析出位址」和「應用程式完成請求」視為兩個驗收項目，可大幅縮小 DNS 層的排錯範圍。

TUN 與 Fake-IP 搭配使用

TUN 是讓流量進入核心的方式，Fake-IP 則是保留網域關聯的一種 DNS 運作方式。兩者常一起使用，但並非同一項功能。TUN 會建立虛擬網路介面並搭配路由接管封包；Fake-IP 則會向應用程式回傳保留位址，再由核心將該位址對應回原始網域。只啟用 Fake-IP 不會自動接管應用程式；只啟用 TUN，也不保證核心知道每條連線對應的網域。

從最小接管範圍開始

桌面用戶端啟用 TUN 通常需要服務模式、系統管理員權限或系統網路擴充授權，實際方式依平台而異。請先保留原有的 DNS 與規則基準，確認用戶端成功建立介面後，再啟用自動路由。其他 VPN、虛擬機器網路與安全軟體也可能安裝路由或篩選器；同時啟用時請記錄預設路由變化，避免將資源衝突誤認為設定語法問題。

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

此範例會劫持一般 UDP 與 TCP DNS 連接埠，但不會透明接管所有加密 DNS。瀏覽器自行發出的 HTTPS DNS 請求看起來仍是一般 HTTPS 連線，僅靠連接埠劫持無法還原查詢內容。驗證時，請先讓測試應用程式使用系統解析路徑，確認網域對應正常，再決定是否保留應用程式內建的加密 DNS 設定。

選擇 stack 與介面策略

system、gvisor、mixed 分別採用不同的網路堆疊處理方式，支援情況會依平台與核心建置版本而異。不要認定某種 stack 永遠是最佳選擇。遇到特定協定不相容時，請在其他設定不變的情況下逐一比較，並查看記錄是否明確指出不支援該選項。設定成功儲存，不代表核心確實採用了該值。

自動偵測出口介面適用於常見的單一出口裝置，但多網卡、熱點分享、容器或路由器環境可能需要明確規劃介面與路由。系統更新、重新連線或裝置變更後，介面名稱可能不同。若流量不斷回到虛擬介面、連線數異常增加或整個網路中斷，請先關閉 TUN 以恢復網路，再檢查是否形成路由迴圈，不要持續重試目標網站。

管理 Fake-IP 對應與例外

應用程式取得 Fake-IP 後，後續連線必須再次經過保存對應資料的同一個核心。若 DNS 由裝置甲回覆，連線卻交由裝置乙處理，乙可能不知道該保留位址對應哪個網域。在區域網路共用代理時，尤其要釐清 DNS 與連線分別由哪台裝置處理；不要將 Fake-IP 解析結果直接提供給未經該代理處理的裝置或其他網路路徑。

fake-ip-filter 可讓指定網域不使用 Fake-IP 配發位址，但篩選後仍須有可用的真實位址解析上游。若應用程式依賴真實位址，請從實際發生異常的網域開始加入例外，不要一次排除大範圍的公開後綴。篩選範圍過大會減少核心透過對應資料取得網域的機會，並將部分判斷工作交回位址規則或嗅探。

若應用程式快取了舊的 Fake-IP，而核心重新啟動後對應資料已遺失，新連線可能無法還原網域。了解儲存行為後，可使用 profile.store-fake-ip 保留對應資料，並確認用戶端是否保留相關資料目錄。排錯時，清除應用程式快取並重新解析，通常比擴大篩選清單更有針對性；切換到不使用該核心的網路後，也應避免沿用這些保留位址。

驗收時應測試一般網頁、一個不遵循系統代理設定的應用程式，以及區域網路服務。分別確認流量是否進入核心、是否顯示網域，以及是否符合預期規則。若系統代理正常而 TUN 異常，請將範圍縮小到路由、權限、DNS 劫持與網路堆疊。兩種方式的詳細差異可參閱TUN 模式與系統代理原理比較，無須為了擴大涵蓋範圍而同時啟用所有接管功能。

網域嗅探與比對範圍

連線只有目標 IP、沒有可靠網域資訊時，網域規則可能無法依預期參與決策。網域嗅探會嘗試從部分協定交握或請求資訊中擷取主機名稱，補足規則比對所需的線索。它不會解密 HTTPS 內容，也不保證能辨識每一條連線。通常應先修復正常的 DNS 接管與 Fake-IP 對應，再用嗅探處理邊界情況，比完全依賴嗅探更容易維護。

依協定與連接埠限制範圍

HTTP 可從請求中的主機資訊擷取網域；TLS 通常可從可見的交握資訊擷取伺服器名稱；QUIC 則取決於核心支援與實際流量。應用程式使用自訂協定、直接連線至 IP、重用既有連線或隱藏相關交握資訊時，嗅探可能無法取得網域。結果為空不代表核心失效，請先確認這條流量是否包含可辨識的資訊。

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 對應情境下的嗅探行為。兩者名稱相近，但不能取代正常的 DNS 流程。若核心回報不支援某個欄位，請確認實際使用的核心版本，而非只看用戶端名稱。

區分補充網域與覆寫目標

override-destination 決定是否允許嗅探結果影響連線目標。變更目標可能有助於某些需要依網域重新建立連線的情境，也可能破壞應用程式原先選用的位址。若業務依賴專用 IP、內部服務、內容傳遞網路調度或憑證綁定，請先保持關閉，只觀察網域補充與規則結果，再評估是否需要啟用覆寫。

同一個 IP 可能承載多個網域，同一個網域也可能回傳多組位址。嗅探取得網域後再次解析，結果可能與應用程式原先使用的位址不同。因此，「辨識出正確網域」與「最終連上正確服務」仍是兩個不同的驗收項目。若啟用覆寫後只有某個應用程式失敗，可先關閉覆寫進行比較，再針對該網域設定略過策略。

處理例外與隱私界線

對不適合嗅探的網域，可依核心支援情況使用 skip-domain 等排除設定。請只針對明確的相容性問題新增例外，並記錄原因；不建議複製來源不明的大型排除清單。排除範圍過大時，嗅探幾乎不再運作，排查者卻可能以為功能仍全面生效，最後只能不斷在規則層追加補丁。

嗅探無法保證突破加密用戶端問候等機制，也不能取代應用程式記錄。取得的網域可能是連線層的主機名稱，不一定等於使用者造訪的頁面標題或完整業務歸屬；共用基礎架構上的服務尤其如此。規則設計應以穩定且可驗證的主機名稱為依據，不要只因一次擷取到某個網域，就將整個基礎架構都導向相同出站。

除錯時先固定一個目標，關閉舊連線後重新發出請求，比較開啟與關閉嗅探時的目標網域、規則名稱和出站路徑。若請求在嗅探前已符合明確的位址規則，也應一併檢查規則順序與核心處理方式。不要在同一次測試中同時調整連接埠範圍、目標覆寫與分流集合，否則無法判斷是哪項設定造成差異。

記錄可能包含造訪網域、目標位址與應用程式資訊。暫時提高記錄層級後，只保留定位問題所需的時間；分享前請移除訂閱網址、驗證資訊與個人瀏覽記錄。確認故障排除後，恢復一般記錄層級並保留最精簡的有效設定。嗅探應是可解釋的輔助機制，不該用來掩蓋解析、流量接管與規則引用之間尚未解決的結構問題。

本機覆寫與多訂閱合併

訂閱更新通常會取代遠端 Profile 的內容，直接修改下載檔案可能在下次更新時遺失。本機覆寫用來保存裝置或使用者需要長期保留的設定，例如監聽連接埠、DNS 策略、少量業務規則與控制介面。用戶端中的功能可能稱為覆寫、合併、擴充或腳本，但這些名稱不保證合併方式相同；請先確認用戶端是取代欄位、深度合併物件，還是串接陣列。

將設定分為三類管理

遠端訂閱負責節點及其配套結構，本機裝置設定負責權限、監聽與流量接管方式，使用者策略則負責業務分流與長期例外。盡量不要讓不同層級同時管理同一個欄位。例如介面固定一個連接埠、覆寫又設成另一個，訂閱中還帶有第三個值，最後結果就只能依賴隱含的載入順序；更換用戶端後也很容易改變。

先挑選容易觀察、影響較小的欄位測試合併行為，例如 log-level。載入後檢查最終設定，再測試規則陣列的處理方式。若新規則覆蓋整份 rules，表示這個入口並非預期的追加機制；請改用用戶端明確提供的前置、後置或規則編輯功能，不要假設所有 YAML 合併方式都會保留原有陣列。

# 合併片段：使用前先確認用戶端如何處理物件與陣列
log-level: info

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

合併節點，不直接串接完整檔案

兩份完整訂閱都可能包含連接埠、DNS、策略組與後援規則，直接串接文字會造成重複鍵或互相覆蓋。較穩定的做法是由一份主設定管理規則與組的結構，再由多個 proxy-providers 分別提供節點。前提是這些來源提供核心可接受的節點 provider 格式；不能只改檔名，就把完整用戶端設定當成節點集合使用。

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 節點清單，並使用有效的協定欄位。此範例只展示引用關係，不包含節點驗證資料。節點名稱最好能清楚辨識，避免不同來源使用相同名稱而難以區分。若需重新命名或加上來源前綴，請先確認用戶端或轉換流程明確支援；不要在更新產生的檔案上進行無法重複執行的手動替換。

更新間隔、轉換與失敗復原

用戶端的 Profile 更新間隔與核心 provider 更新間隔是不同工作，單位也可能不同。前者會重新取得主要設定，後者則更新特定節點或規則來源。請記錄每一層由誰觸發、快取存放位置，以及更新失敗後是否繼續使用舊檔案。裝置休眠、行動網路限制與背景工作策略都可能延遲更新，不能只依間隔數值推斷實際執行時間。

訂閱網址通常包含存取憑證，不要將完整連結放進公開截圖、記錄或範例儲存庫。需要轉換格式時，請先確認轉換過程是否會將原始網址傳送至第三方服務。優先使用可信任用戶端內建功能或本機處理方式，並檢查轉換後是否遺失節點選項。設定能成功載入只是第一步；協定欄位經過簡化後，實際連線仍可能改變。

進行合併前，請準備三份內容：目前可用的主設定、新的覆寫片段，以及復原方式。套用後先檢查節點數量是否符合預期，再確認策略組非空、規則引用存在，以及 DNS 和連接埠符合原定設定。更新後若發生異常，先停用新增覆寫並回到基準；若恢復正常，再逐段重新啟用，不要直接重裝用戶端而失去排查線索。

各用戶端支援多個 Profile 切換與合併的方式不同，切換設定檔不代表能同時使用多份節點。請先釐清管理方式，並參閱Profile 結構與多訂閱管理。長期維護時，簡要記錄規則目的與來源關係，比依賴複雜且沒有說明的合併腳本更容易移轉，也更容易在更新後驗證。

外部控制與維護流程

外部控制介面可讀取核心狀態、切換策略、查看連線並執行部分管理操作；它不是供應用程式上網使用的代理連接埠。常見設定使用 9090，混合代理連接埠則可能是 7890。將瀏覽器或系統代理指向控制連接埠，無法提供正常的代理服務。部署前，請分別列明兩種連接埠的用途、監聽位址與允許存取的裝置。

優先只監聽本機

單機用戶端通常不需要讓區域網路直接存取控制介面，使用迴路位址可縮小存取範圍。若用戶端已管理控制介面與驗證值，請勿在覆寫中強制改寫，否則內建面板可能無法連線。以下使用教學用驗證值，只用來說明欄位位置；實際環境請自行產生獨立且高強度的值，並妥善保存。

external-controller: 127.0.0.1:9090
secret: "your-password"

控制介面的驗證功能不能取代網路邊界防護。若確實需要遠端維護，請先規劃可信任網路、加密傳輸與防火牆限制，再考慮更改監聽位址。不要只為了方便就讓介面監聽所有位址，也不要直接設定公網連接埠轉送。可呼叫此介面的使用者可能變更出站策略或讀取連線資訊，權限範圍應比照系統管理介面審慎處理。

透過 API 區分介面問題與面板問題

先在執行核心的裝置上檢查介面，再處理瀏覽器面板。以下命令中的驗證值與前述教學設定相同；實際使用時請一併替換。驗證失敗、連線遭拒與回傳內容不符預期是三種不同故障，分別涉及驗證設定、監聽或程序狀態，以及選錯連接埠或服務；不能一概靠重新下載面板解決。

curl --fail --silent --show-error \
  -H "Authorization: Bearer your-password" \
  http://127.0.0.1:9090/version

curl --fail --silent --show-error \
  -H "Authorization: Bearer your-password" \
  http://127.0.0.1:9090/proxies

在 Windows PowerShell 中，curl 可能受命令別名或版本行為影響，建議明確使用 curl.exe，並依終端機調整換行方式。介面能回傳資料後，再檢查面板填寫的位址、協定與驗證值。面板頁面透過 HTTPS 開啟，卻連線至一般 HTTP 介面時，也可能受到瀏覽器混合內容政策限制。

靜態面板與連線歷史的範圍

external-ui 用來指定本機面板的靜態檔案目錄，目錄路徑會以核心工作位置為基準解析。靜態檔案存在不代表面板已連上正確的核心；開啟面板後，仍須確認控制位址與驗證設定。內建面板通常已處理這層連線，桌面使用者建議優先使用用戶端提供的入口，避免同時維護多個來源不明的管理頁面。

面板中的連線清單通常用來查看目前連線，不應視為永久稽核記錄。重新啟動核心、關閉連線或切換設定後，可見資料都可能改變。排錯時應保留必要記錄，但不宜長期公開連線詳細資訊。分享問題時，描述目標類別、命中規則與錯誤類型即可；請先移除訂閱連結、驗證值及完整瀏覽記錄。

建立更新後的驗收清單

每次更新用戶端、更換訂閱或調整覆寫後，請依相同順序驗收：確認核心已啟動、檢查實際監聽連接埠、確認 provider 已載入、測試規則比對，再驗證 DNS 與 TUN。最後才檢查外部面板。如此一來，即使面板暫時無法使用，也能透過記錄與基本連線判斷代理鏈路是否正常，避免將管理介面故障誤認為整體網路無法使用。

復原時應還原上一組已驗證可用的設定，而非只還原最後編輯的單一檔案。訂閱快取、覆寫、策略選擇與用戶端開關會共同決定最終行為。請保留復原記錄，註明要停用哪些覆寫、選擇哪個 Profile、是否關閉 TUN，以及何時清除快取。完成復原後，重新建立連線確認結果，避免舊工作階段影響判斷。

本頁各章可分開查閱，但調整順序仍應遵循相依關係：先穩定入口與節點，再建立策略組和規則，接著調整 DNS、TUN 與嗅探，最後設定遠端管理。基本連線問題請回到系統代理設定檢查；需要移轉用戶端時，請回到下載中心。每次留下可觀察的結果與可執行的復原步驟，比持續增加設定欄位更有助於維護。