Clash 策略組、規則集與網路堆疊設定

策略組類型與易於維護的分流架構

策略組不是節點的簡單資料夾，而是規則與實際出口之間的穩定介面。規則只需指向「代理」「串流媒體」「下載」這類長期不變的策略名稱，節點增刪、訂閱更換與地區調整則在策略組內完成。這樣做能減少設定連動：替換訂閱時不必重寫規則，切換某項服務的出口時也不必逐一尋找網域。規劃策略組時，應先畫出流量層級，再決定群組類型，而不是把訂閱中的所有節點一次塞進同一個選擇組。

四種常用群組類型如何選擇

select 是手動選擇組，適合總入口、指定地區與需要穩定出口的服務。它不會自行變更目前選項，因此行為最容易預測。url-test 會依測試網址與間隔檢查可用性，並從候選項目中選擇回應較快的節點，適合日常網頁瀏覽。fallback 依清單順序使用第一個可用節點，更重視優先順序與連續性，適合希望主要線路失效後才切換備用線路的情境。load-balance 會將不同連線分配到多個節點，適合平行請求較多的工作，但同一網站的不同連線可能出現出口變化，對登入狀態與風控嚴格的網站並不友善。

延遲測試值只代表測試目標在當時網路條件下的回應，不等於下載速度，也不能取代實際可用性判斷。測試網址應選擇穩定、檔案很小且能快速回應的 HTTPS 資源。interval 太短會持續產生探測請求，太長則可能在節點失效後很久才更新。家用網路通常從數分鐘的間隔開始較合適；行動網路還要考慮背景限制與網路切換，不能只靠測試組完成恢復。

先建立地區組，再建立服務組

較穩妥的架構通常分成三層。底層是節點或代理提供者；中間層是「香港自動」「日本備用」「美國手選」等地區組；頂層則是「代理」「串流媒體」「開發服務」等服務組。服務組引用地區組，規則只引用服務組。不要讓每個服務組直接包含數十個原始節點，否則訂閱改名、節點下線與重複節點都會讓所有群組一起變得難以維護。

proxy-groups:
  - name: 香港自動
    type: url-test
    use:
      - provider-main
    filter: "(?i)港|HK|Hong Kong"
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80

  - name: 日本備用
    type: fallback
    use:
      - provider-main
    filter: "(?i)日|JP|Japan"
    url: https://www.gstatic.com/generate_204
    interval: 600

  - name: 代理
    type: select
    proxies:
      - 香港自動
      - 日本備用
      - DIRECT

  - name: 開發服務
    type: select
    proxies:
      - 代理
      - 香港自動
      - 日本備用
      - DIRECT

use 引用的是 proxy-providers 名稱，proxies 引用的是具體節點、內建策略或其他策略組。兩者不能任意互換。過濾運算式應盡量相容於供應方的命名差異，例如同時涵蓋中文地區名、英文縮寫與完整英文名稱；但運算式也不能過於寬鬆，「US」可能誤中其他單字，最好搭配名稱分隔符並依實際訂閱格式測試。

策略組之間也要避免循環引用。例如「代理」包含「自動選擇」，而「自動選擇」又把「代理」列為候選項目，核心就無法取得最終出口。修改後若出現群組為空、策略無法選擇或設定載入失敗，應先檢查名稱是否完全一致，再檢查引用方向。中文標點、前後空格與大小寫差異，都可能造成看似相同、實際不同的名稱。

最後保留一個明確的總入口組，讓臨時排障更簡單。發現某個網站異常時，先將總入口手動切換到另一個地區或 DIRECT，再判斷問題屬於節點、規則還是目標網站。如果切換總入口後立即恢復，優先檢查目前節點與地區組；如果始終直連，則檢查規則順序與模式；如果所有策略都無法存取，再進一步排查 DNS、TUN 與系統網路堆疊。策略組設計清楚，後續每一章都會更容易驗證。

規則集訂閱管理與比對順序

把數千條網域或 IP 規則直接寫進主要設定，會讓檔案難以閱讀，也會讓更新變成整份設定的替換。rule-providers 的作用是將規則內容拆成可獨立下載、快取與更新的集合，主要設定只保留提供者定義與少量 RULE-SET 引用。規則集更新時不需要修改策略組，設定結構也更容易進行版本管理。適合訂閱化的內容包括廣告網域、區域網路位址、特定服務網域與地區 IP 網段；只針對一兩個網域的個別規則則繼續放在主要設定頂部會更直觀。

behavior 決定如何解析規則集

domain 用於網域集合，項目可以是完整網域、網域後綴或關鍵字形式，具體寫法取決於載荷格式。ipcidr 用於 IPv4、IPv6 網段，比對時需要目標 IP。classical 可容納帶有類型前綴與參數的傳統規則，例如 DOMAIN-SUFFIX、IP-CIDR 與 PROCESS-NAME。如果來源檔案本身使用傳統規則，卻將 behavior 設為 domain，下載可能成功，但項目不會如預期運作。建立規則集前應先查看檔案內容，不要只憑檔名判斷。

format 常用 yaml、text 或核心支援的二進位格式。YAML 載荷通常包含頂層鍵 payload，文字格式則多半是每行一條。path 是本機快取位置，每個提供者必須使用不同路徑，避免後下載的檔案覆蓋前一個。interval 控制更新間隔；規則本身變動不頻繁時，沒有必要每幾分鐘抓取一次。遠端請求失敗時，既有快取通常仍可繼續使用，因此不要把短暫的更新失敗誤判為所有規則都已失效。

rule-providers:
  private-domain:
    type: http
    behavior: domain
    format: yaml
    path: ./ruleset/private-domain.yaml
    url: https://example.com/rules/private-domain.yaml
    interval: 86400

  service-rules:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/service-rules.yaml
    url: https://example.com/rules/service-rules.yaml
    interval: 86400

  private-ip:
    type: http
    behavior: ipcidr
    format: yaml
    path: ./ruleset/private-ip.yaml
    url: https://example.com/rules/private-ip.yaml
    interval: 86400

rules:
  - DOMAIN,router.local,DIRECT
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-rules,代理
  - RULE-SET,private-ip,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,代理

範例中的網址用於展示結構，實際設定應替換成自己確認可存取且內容格式相符的規則來源。若規則檔案需要驗證，不要把長期憑證放在會公開同步的主要設定中。較合適的做法是使用本機產生流程、受控反向代理或客戶端支援的安全儲存方式，並確保匯出的診斷資訊不會包含存取參數。

規則由上到下，首次命中即停止

Clash 的規則順序比規則數量更重要。精確網域與個人覆寫應放在前面，服務規則集居中，廣泛的地區規則靠後，最後用 MATCH 承接其餘流量。若先寫 GEOIP,CN,DIRECT，後面某個服務規則集想將對應 IP 交給代理，已經命中的連線不會繼續向下檢查。同樣地，將 MATCH 放在中間會讓後續規則全部失去作用。

no-resolve 適合不希望規則比對階段主動解析網域的 IP 規則。目標本來就是 IP 時，它仍然能夠比對；目標是網域時，則不會為了判斷網段而額外查詢位址。這個參數能減少不必要的 DNS 行為，但若設定依賴某個 IP 規則決定出口，就要確認目標位址在進入規則系統前是否已經可用。不要機械式地為所有 IP 規則加上這個參數。

規則集未命中時，先確認三件事：提供者狀態是否成功、檔案格式與 behavior 是否一致、目標請求是否帶有可比對的網域。瀏覽器使用加密 DNS、應用程式直接連線 IP，或 TUN 沒有接管該程序時，看到的比對對象可能與預期不同。此時應搭配連線清單查看實際目標、命中規則與策略，而不是反覆調整規則順序碰運氣。

長期維護時，可以為每個規則集記錄來源、用途、行為類型與對應策略組。新增規則先以單條形式放在主要設定頂部觀察幾天，確認沒有誤傷後再併入自建規則集。刪除規則也應先檢查連線記錄，避免把「目前沒有存取」誤當成「永遠不需要」。想進一步了解主要設定各段的排列關係，可閱讀Clash 設定檔 YAML 各段欄位逐段解析。

DNS 設定最佳化與洩漏排查

DNS 設定要解決三個不同問題：由誰解析網域、查詢本身從哪個網路出口發出，以及解析結果如何交給規則系統。只修改一個公共 DNS 位址通常無法同時解決這三件事。系統 DNS、Clash 內建 DNS、瀏覽器安全 DNS 與應用程式自帶解析可能同時存在，因此排查時應先確認實際請求路徑，再討論伺服器選擇。一個可控的方案通常會讓受接管的應用程式統一進入 Clash DNS，由規則與代理策略決定後續連線。

nameserver、proxy-server-nameserver 與 direct-nameserver

nameserver 是一般網域查詢的主要上游。使用 HTTPS 或 TLS 形式可以降低本地網路對明文查詢的干擾，但連線加密不代表查詢一定經過代理，具體出口仍取決於核心能力、規則與引導解析。proxy-server-nameserver 主要用於解析代理伺服器本身的網域，避免出現「要連線代理前必須先解析網域，而解析又必須經過尚未建立的代理」的循環。direct-nameserver 用於明確走直連的查詢，適合區域網路裝置名稱或本地網路服務，但需要客戶端與核心支援相應欄位。

default-nameserver 常用於解析加密 DNS 伺服器位址本身，通常填入可直接存取的 IP 形式解析器。它不是所有查詢的最終上游，也不應堆放大量位址。若加密 DNS URL 使用網域，而預設解析器無法存取，常見表現是客戶端啟動後所有網域都卡住，但直接存取 IP 可能仍然正常。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: false
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  default-nameserver:
    - 223.5.5.5
    - 1.1.1.1
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query
  proxy-server-nameserver:
    - https://dns.alidns.com/dns-query
  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "time.*.gov"
    - "+.stun.*.*"
    - "+.stun.*.*.*"

listen 監聽所有介面時，區域網路中的其他裝置可能存取該連接埠。若只供本機使用，優先繫結回送位址；若確實需要作為區域網路 DNS，則同時檢查系統防火牆、存取控制與路由器設定。連接埠被占用時，核心可能啟動失敗或 DNS 模組無法監聽。Windows 上可以使用系統網路工具尋找占用程序，macOS 與 Linux 可使用 lsof 或 ss 檢查。

# Windows PowerShell
Get-NetUDPEndpoint -LocalPort 1053

# macOS
lsof -nP -iUDP:1053

# Linux
ss -lunp | grep 1053

Fake-IP 與 redir-host 的取捨

fake-ip 會先回傳保留位址範圍中的映射位址，連線抵達核心後再還原原始網域。如此一來規則系統更容易保留網域資訊，網域規則比對更穩定，也能減少「解析得到某個 IP 後只能依 IP 判斷」的情況。代價是部分區域網路探索、時間同步、遊戲連線、印表機或依賴真實解析結果的程式可能不相容，需要加入 fake-ip-filter。過濾項目應依實際失敗的網域逐步增加，不要直接複製一份極長清單，否則大量網域繞過 Fake-IP 後會削弱統一分流效果。

redir-host 會回傳真實解析結果，通常相容性更直觀，但網域與連線之間的關聯更依賴 DNS 映射快取。面對 CDN、多位址輪替與應用程式自帶解析時，規則判斷可能不如 Fake-IP 穩定。選擇時不要只看某個測試網站的結果：常用應用程式、區域網路服務、休眠恢復與網路切換都應納入驗證。

DNS 洩漏要依請求路徑確認

所謂洩漏通常是指應由受控上游或代理路徑處理的查詢，仍被系統、路由器、電信網路或瀏覽器獨立送出。線上檢測只能看到檢測頁面觸發的一部分查詢，不能證明所有應用程式都採用同一路徑。較可靠的做法是先關閉瀏覽器內建的安全 DNS，或將其設定為與系統方案一致，再觀察 Clash 記錄、系統 DNS 設定與本機連接埠流量。本網站的Clash DNS 洩漏檢測方法與防洩漏設定步驟提供了線上檢測與本機觀察的組合流程。

出現「能開啟 IP，卻打不開網域」時，從 DNS 模組啟動狀態、監聽連接埠與上游可達性開始；出現「部分網域解析很慢」時，檢查多個上游是否有一個長期逾時，以及 IPv6 查詢是否被網路丟棄；出現「規則應該代理卻直連」時，確認應用程式是否繞過系統解析、連線清單中是否保留網域，以及目標規則是否位於寬泛直連規則之前。

如果系統在啟停 TUN 後留下錯誤 DNS，可以先完全退出客戶端，將網路介面的 DNS 恢復為自動取得，再重新啟動。不要同時執行多個會修改系統代理、虛擬網路介面或 DNS 的網路工具。它們各自單獨運作正常，也可能因為後啟動者覆蓋前者而造成間歇性故障。

TUN 模式、Fake-IP 與系統網路堆疊

系統代理只會影響主動讀取代理設定的應用程式。命令列程式、遊戲、商店元件、部分桌面客戶端與直接建立通訊端的程式，可能完全忽略它。TUN 模式透過虛擬網路介面接管更廣泛的 IP 流量，再交由 Clash 規則判斷，適合需要統一處理不支援代理的應用程式。它不是「更強的系統代理開關」，而是一套涉及路由、DNS、虛擬介面與權限的網路路徑，因此啟用前應先確保一般系統代理模式已正常運作。

核心欄位與堆疊選擇

enable 控制 TUN；auto-route 讓核心安裝必要路由；auto-detect-interface 用於識別目前預設的出站介面，減少有線、無線與熱點切換後的手動修改；dns-hijack 將指定連接埠的 DNS 請求交給內建 DNS。stack 決定網路堆疊實作，常見值包括 system、gvisor 與支援混合處理的堆疊。不同核心及平台的支援範圍有所差異，應以目前客戶端實際提供的選項為準。

system 通常利用系統網路能力，效能與相容性較自然，但行為會受到作業系統差異影響。gvisor 使用使用者態網路堆疊，隔離更明確，在部分環境能繞過系統堆疊限制，但也可能對特殊協定或高併發連線呈現不同結果。切換堆疊屬於排障手段，不應在沒有故障證據時頻繁更改。每次只修改一個變數，並在相同網路條件下驗證。

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

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16

strict-route 能減少流量繞過預期路由的機會，但在虛擬機器、容器、公司 VPN 與複雜區域網路環境中，也可能影響原有路由。啟用後如果區域網路裝置、遠端桌面或開發容器突然無法存取，應對照啟用前後的路由表，確認私有網段是否仍經由正確介面。需要存取區域網路時，可以用規則將私有位址設為直連，但規則只能決定進入核心後的出口，無法修復已被錯誤系統路由截走的連線。

Fake-IP 位址不是實際目的位址

啟用 Fake-IP 後，在封包擷取或系統連線清單中看到 198.18.0.0/16 類型的位址是正常現象。應用程式先連線到這個映射位址，核心依映射表還原網域，再執行規則與真實解析。不要把該位址範圍加入一般直連路由，也不要將它解讀為遠端伺服器位址。如果連線到 Fake-IP 後沒有被 TUN 接管，系統會嘗試把保留位址當作真實目標，表現為立即失敗或長時間等待。

因此，Fake-IP 與 TUN 的關鍵在於形成閉環：DNS 查詢由 Clash 回傳映射位址，應用程式連線映射位址，路由再把這條連線送回 Clash。任何一個環節被其他工具接管，都可能破壞映射。典型衝突包括瀏覽器繞過系統的獨立 DNS、另一張虛擬網路介面搶占預設路由、公司安全軟體過濾保留網段，以及休眠恢復後舊虛擬介面仍保有較高的路由優先順序。

依平台理解權限與衝突

Windows 上若出現啟用後完全斷網，先關閉 TUN，確認基本代理恢復，再檢查虛擬網路介面是否成功建立，以及預設介面是否正確識別。macOS 上應確認客戶端已取得網路擴充功能權限，並關閉其他同時執行的 VPN。Linux 伺服器上還要檢查核心是否提供 TUN 裝置，以及執行使用者是否具備建立介面與修改路由的能力。Android 依賴系統 VpnService，一次通常只能保留一個啟用中的 VPN；相關授權與背景限制可參考Android 版 VpnService 授權與省電白名單設定要點。

排查 TUN 最有效的方法是分層測試：先關閉 TUN，只使用系統代理驗證節點；再啟用 TUN，但維持簡單規則；接著測試網域、直接 IP、區域網路位址與不讀取系統代理的應用程式；最後才加入複雜 DNS、嗅探與規則集。若一開始同時啟用所有進階選項，任何一處失敗都會呈現為「網路無法使用」，很難判斷實際故障點。

網域嗅探的用途、設定與界線

規則分流最理想的輸入是網域，因為網域通常比不斷變化的 CDN 位址更容易表達服務歸屬。但部分應用程式會先自行解析，再直接連線 IP；有些透明接管情境也只能在連線建立初期看到目標位址。網域嗅探會從 TLS 握手中的 SNI、HTTP 請求標頭或其他可識別資訊中還原目標網域，讓網域規則重新取得比對機會。它補充的是連線中繼資料，不是取代 DNS 的萬能功能。

TLS 與 HTTP 嗅探分別查看什麼

TLS 嗅探通常讀取握手階段公開可見的伺服器名稱，不會解密後續內容。HTTP 嗅探可以讀取明文請求中的 Host 欄位。目標協定不攜帶網域、應用程式使用直接 IP、連線重用既有通道或採用隱藏伺服器名稱的機制時，嗅探可能無法取得結果。UDP 協定的可識別範圍也取決於核心實作與具體流量，不能假設所有 UDP 連線都能還原網域。

嗅探取得的網域應與連線的真實目的保持一致。若共用 IP 上承載多個網站，錯誤覆寫目標可能導致規則誤判；某些應用程式也會連線到與憑證、SNI 不一致的專用位址。設定時可以先開啟常用連接埠，觀察連線記錄，再決定是否擴大範圍。不要為了追求更高的「網域顯示率」而掃描所有連接埠。

sniffer:
  enable: true
  parse-pure-ip: true
  force-dns-mapping: true
  override-destination: false
  sniff:
    TLS:
      ports:
        - 443
        - 8443
    HTTP:
      ports:
        - 80
        - 8080-8880
  skip-domain:
    - "Mijia Cloud"
    - "+.push.apple.com"

parse-pure-ip 允許對純 IP 目標嘗試還原網域，正是透明代理情境常用的能力。force-dns-mapping 會結合 DNS 映射協助識別目標，與 Fake-IP 搭配時尤其常見。override-destination 決定是否以嗅探結果覆寫原始目的地；開啟後規則與連線目標可能更符合網域預期，但誤嗅探的影響也更直接。建議先保持關閉，確認記錄中的還原結果穩定後，再依實際需求決定。

何時應加入跳過清單

跳過清單用於明確排除不適合嗅探或覆寫的目標。區域網路裝置、智慧家庭、推播服務、特殊驗證程式與部分遊戲，可能依賴固定位址或非標準握手。若某個應用程式在關閉嗅探時正常，開啟後卻持續失敗，且連線記錄顯示還原出無關網域，可以將對應網域或程序相關目標加入跳過範圍。不過應先確認問題確實來自嗅探，而不是 TUN、MTU、UDP 或節點本身。

清單項目需要遵守目前核心支援的網域比對語法。完整網域適合單一服務，網域後綴適合一組子網域。範圍越大的後綴越要謹慎，例如跳過整個頂級網域會讓大量連線失去嗅探能力。名稱看起來像應用程式名稱的項目是否有效，取決於核心對特殊標記的解釋；遷移到另一個客戶端時要重新核對。

嗅探與規則、DNS 的協作順序

連線進入核心後，可能先從 Fake-IP 映射取得網域，也可能透過嗅探補回網域，然後才依規則選擇策略。若 DNS 映射已經可靠，嗅探更多是補充；若應用程式完全繞過 Clash DNS，嗅探可能成為網域規則生效的關鍵。看到同一個應用程式有時依網域規則、有時落到 IP 或最終規則，往往表示不同連線採用了不同的解析與傳輸路徑。

驗證時準備三個層次的規則：一條精確網域規則、一條對應 IP 或地區規則，最後一條 MATCH。存取目標後查看命中的層次。如果精確網域規則始終不觸發，但連線記錄能看到正確網域，檢查規則順序與拼寫；如果記錄中只有 IP，檢查 DNS 映射與嗅探；如果連線根本沒有出現，檢查應用程式是否被系統代理或 TUN 接管。這種對照比只看網頁能否開啟更具診斷價值。

不同圖形客戶端可能將這些欄位拆分為「網域嗅探」「覆寫目標」「純 IP 解析」等開關，也可能只開放部分功能。Clash Plus、Clash Verge Rev、FlClash 等客戶端的介面位置並不完全一致，但最終仍應以匯出的實際設定與核心記錄為準。遷移客戶端時先保留最小嗅探設定，確認欄位已被目前核心識別，再逐項恢復進階選項。

本機覆寫與多訂閱合併

遠端訂閱解決節點分發問題，本機覆寫解決個人策略的長期保留問題。將 DNS、規則、策略組與實驗參數直接寫回訂閱檔案，下一次更新很可能全部被覆蓋；完全禁止更新又會錯過節點變更。更合理的架構是將遠端訂閱視為輸入，將本機覆寫視為可重複套用的轉換，最後由客戶端或轉換流程產生執行設定。如此既能更新節點，也能保留自己的規則與網路堆疊設定。

區分替換、追加與前置

不同客戶端對覆寫的名稱不完全相同，但操作通常分成三類：替換某個頂層欄位、在陣列末尾追加項目、在陣列開頭插入項目。DNS、TUN 這類完整物件適合明確替換或深度合併；規則陣列通常需要將個人精確規則前置，並把兜底規則保留在最後；策略組則要依名稱去重，不能簡單地將兩份陣列串接。

最危險的操作是直接覆蓋整個 rules 或 proxy-groups，卻沒有重新納入訂閱原有內容。結果可能是節點存在但沒有策略組引用，或規則只剩幾條個人項目。修改前應匯出目前有效設定，確認覆寫發生在訂閱更新之前還是之後，並檢查客戶端的合併順序。相同腳本在不同客戶端中的執行時機不同，結果也可能不同。

# 本機前置規則範例
rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,example.internal,DIRECT
  - DOMAIN-SUFFIX,developer.example,開發服務

# 本機 DNS 覆寫範例
dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - https://dns.alidns.com/dns-query
    - https://1.1.1.1/dns-query

YAML 合併還會遇到錨點、空值與類型變更。一個欄位在來源中是陣列，在覆寫中卻寫成物件，通常無法如預期合併；寫成 null 可能表示刪除，也可能只是得到空欄位，取決於工具實作。為了方便移植，覆寫盡量使用一般映射與陣列，不要依賴某個圖形客戶端獨有的腳本介面。必須使用腳本時，應同時記錄輸入結構、處理順序與預期輸出。

多訂閱先進行命名隔離

合併兩個訂閱時最常見的問題不是節點協定，而是名稱重複。兩邊都可能包含「自動選擇」「故障轉移」「代理」這類群組名稱，節點名稱也可能重複。簡單串接會讓後出現的物件覆蓋前一個，或讓策略組引用到錯誤節點。穩妥的做法是為不同來源增加固定前綴，例如「主要訂閱 / 香港 01」與「備用訂閱 / 香港 01」，再由本機策略組統一引用。

如果客戶端支援 proxy-providers，可以讓多個來源分別成為提供者，利用 use 與 filter 組裝地區組，而不是先將所有節點展開到主要檔案中。這種方式的更新邊界清楚，某個來源失敗時不會直接破壞另一個來源的快取。提供者名稱、快取路徑與健康檢查網址都應各自獨立。

proxy-providers:
  provider-main:
    type: http
    url: https://example.com/subscriptions/main.yaml
    path: ./providers/main.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

  provider-backup:
    type: http
    url: https://example.com/subscriptions/backup.yaml
    path: ./providers/backup.yaml
    interval: 21600
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

proxy-groups:
  - name: 所有來源
    type: select
    use:
      - provider-main
      - provider-backup
    proxies:
      - DIRECT

範例網址只用於說明欄位關係。真實訂閱網址通常帶有存取憑證，不應貼到截圖、問題文章、公開儲存庫或診斷檔案中。分享設定前可以刪除 proxy-providers 的 URL、節點伺服器位址、使用者名稱與驗證欄位，只保留能重現結構問題的最小片段。

建立可回復的設定流程

每次大幅修改前保留三份內容：未處理的訂閱輸入、本機覆寫檔案、最終產生的執行設定。出現問題時先比較最終設定是否符合預期，再判斷是訂閱變更、合併邏輯還是核心行為。只保存最終檔案無法區分錯誤在哪個階段產生，也很難在下一次訂閱更新後重複建置。

調整流程建議按照固定順序進行：先更新單一訂閱並確認節點可用；再套用名稱過濾與提供者健康檢查；接著加入策略組；然後前置個人規則；最後啟用 DNS、TUN 與嗅探。每個階段都重新載入並檢查記錄。如此即使最終設定失敗，也能準確找到首次出現異常的階段。

如果合併後出現「節點可見但無法選擇」，通常是策略組引用的物件不存在；出現「個人規則更新後消失」，通常是覆寫發生在錯誤階段；出現「同名節點隨機變化」，通常是來源沒有進行命名隔離。將問題放回輸入、轉換、輸出三層檢查，比在客戶端介面中反覆刪除與重新匯入更有效。

外部控制面板與安全的遠端管理

外部控制介面允許圖形面板讀取代理組、連線、規則、記錄與提供者狀態，也能執行切換策略、更新提供者及關閉連線等操作。它適合將核心執行與管理介面分離，常見於伺服器、路由器與獨立核心部署。此介面具備實際控制能力，不應被當作普通狀態頁面直接暴露在公用網路上。

監聽位址、密鑰與面板目錄

external-controller 定義 API 監聽位址。僅供本機使用時，繫結回送位址最穩妥；需要區域網路存取時，可以繫結區域網路介面或所有介面，但必須搭配防火牆限制來源。secret 是控制介面憑證，應使用獨立且足夠長的值，不要與訂閱、系統帳戶或其他服務共用。external-ui 指向本機靜態面板目錄，核心只負責提供檔案與 API，不會自動確保目錄內容可信。

external-controller: 127.0.0.1:9090
secret: "your-password"
external-ui: ./dashboard
external-ui-name: metacubexd
external-ui-url: https://example.com/dashboard.zip

範例中的密碼與面板位址僅用於展示語法。實際使用時應替換密碼，並從自己確認的來源取得面板檔案。若圖形客戶端已內建控制面板，通常無需再設定遠端下載網址。多個執行個體不能監聽同一個 IP 與連接埠；發生連接埠衝突時，後啟動的核心會回報繫結失敗，面板可能繼續顯示舊執行個體的資料，讓人誤以為設定沒有生效。

從瀏覽器存取本機面板時，還要區分頁面位址與 API 位址。面板檔案可以由某個 Web 服務提供，API 則由 Clash 核心監聽。兩者的協定、主機或連接埠不同會形成跨來源存取，是否允許取決於核心與瀏覽器策略。若面板能開啟卻一直提示無法連線，先在本機確認 API 連接埠正在監聽，再檢查面板填寫的控制器位址與密鑰，不要先重新安裝核心。

區域網路存取的最小開放範圍

確實需要從手機或另一台電腦管理時，可以將控制器繫結到區域網路位址，並在系統防火牆中只允許可信任的私有網段存取。不要在路由器上為控制連接埠設定公網連接埠轉發，也不要使用弱密鑰。公用網路中的裝置可能主動掃描常見管理連接埠，一旦控制介面遭到存取，對方就能查看連線目標、變更策略或中斷流量。

更安全的遠端方式，是先透過既有的受控私有網路、裝置間安全通道或系統遠端管理功能進入本地網路，再存取回送或區域網路介面。如此控制器仍不需要直接面向網際網路。若使用反向代理控制介面，應啟用存取驗證、限制來源並正確處理 WebSocket；但多加一層代理也會增加設定複雜度，家用單機沒有必要。

# Linux：確認控制連接埠只監聽回送位址
ss -lntp | grep 9090

# macOS：查看監聽程序
lsof -nP -iTCP:9090 -sTCP:LISTEN

# Windows PowerShell：查看連接埠狀態
Get-NetTCPConnection -LocalPort 9090 -State Listen

使用控制面板定位連線問題

面板最有價值的部分不是一鍵切換，而是將連線、規則與策略串在一起觀察。排查某個網站時，先依目標網域或程序篩選連線，記錄命中規則、策略鏈與最終節點；然後關閉該連線，讓應用程式重新建立，避免舊連線繼續沿用修改前的策略。只切換群組但不重建連線，常會出現介面已經變更、實際請求仍走舊出口的錯覺。

提供者頁面可以確認訂閱與規則集最近一次更新是否成功，但不能只憑「成功」判斷內容正確。還要核對提供者項目數量是否異常、策略組過濾後是否為空，以及規則集行為類型是否相符。記錄頁面適合查看解析失敗、介面繫結失敗、規則檔案讀取錯誤與節點握手錯誤；長期維持詳細記錄會增加寫入量與隱私暴露，完成排障後應恢復一般等級。

完成設定後的整體驗證

進階設定完成後，依固定案例驗收比隨意瀏覽更可靠。先驗證直連網站、代理網站與區域網路裝置；再測試瀏覽器、命令列與一個不讀取系統代理的應用程式；接著檢查 DNS 查詢、Fake-IP 映射與網域規則；最後進行休眠恢復、Wi-Fi 切換與訂閱更新。每項都記錄預期策略與實際命中，發生異常時回到對應章節處理。

設定載入失敗時，先檢查 YAML 縮排、冒號後的空格、陣列層級與重複鍵。設定載入成功但沒有流量時，檢查系統代理或 TUN 接管；有流量但策略不正確時，檢查網域資訊、規則順序與策略組引用；策略正確但連線失敗時，再檢查節點、協定與目標網站。這個順序能避免把所有問題都歸因於節點。

仍無法確定問題所屬層級時，可查看疑難排解中的安裝設定與故障排查分類。需要更換圖形客戶端或在其他系統重現設定，可前往客戶端下載頁選擇 Windows、macOS、Android、iOS 或 Linux 版本。圖形介面適合日常切換與觀察，最終判斷仍以實際執行設定、連線記錄與核心記錄為準。