Clash 設定進階手冊

設定模型、載入順序與驗證基準

先區分客戶端、核心與設定來源

Clash 生態中的桌面或行動客戶端負責訂閱管理、設定編輯、系統權限申請與介面呈現，實際處理連線的是核心。Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等客戶端都可能呼叫相容核心，但各自對訂閱覆寫、設定合併與外部介面的實作方式不同。排查時必須先確認問題屬於哪一層：下載與安裝問題屬於客戶端層，YAML 欄位無法辨識屬於核心與設定層，節點本身無法使用則屬於代理鏈路。將三層混在一起判斷，常見結果是反覆更換客戶端，卻沒有修正錯誤規則。

設定通常來自四類來源：客戶端自行產生的基礎欄位、訂閱回傳的節點與策略、使用者撰寫的本機覆寫，以及執行時狀態。執行時狀態包括目前選取的策略、快取的規則集與 DNS 對映，不一定會完整寫回 YAML。部分客戶端更新訂閱時會重新產生設定；若直接編輯產生後的暫存檔案，下次更新可能覆蓋修改。長期設定應放在客戶端明確提供的覆寫、合併或腳本入口；只供測試的變更才適合直接編輯目前設定。

理解從入站到出站的資料路徑

連線進入核心後，通常會依序經歷入站識別、網域還原或嗅探、規則比對、策略組決策與代理出站。啟用 TUN 後，系統路由會先將流量交給虛擬介面；啟用 Fake-IP 後，DNS 查詢可能先取得保留位址，再由核心依據對映表還原原始網域。規則中的 DOMAIN-SUFFIX、GEOSITE 或網域規則集依賴網域資訊，而 IP-CIDR、GEOIP 則處理目標位址。理解這條路徑後，才能解釋為何同一個應用程式在系統代理模式下正常，切換到 TUN 模式後卻命中不同規則。

規則會依順序比對，首條命中後便停止繼續檢查。因此具體網域、業務專用規則與攔截規則應放在通用地域規則之前，MATCH 必須置於末尾。策略組只是規則的目標名稱，不會主動比對流量。例如規則寫成 DOMAIN-SUFFIX,example.com,工作流量 後，設定中必須存在名稱完全相同的策略組或代理節點；全形空格、大小寫差異與重新命名遺漏，都可能造成載入失敗或無法選取。

建立最小可運作的設定

複雜設定不應直接從數百行範本開始。先保留一個監聽連接埠、一組節點來源、一個手動選擇組與一條兜底規則，確認設定能載入並完成連線後，再逐步加入規則集、DNS 與 TUN。以下骨架展示欄位之間的引用關係。範例節點位址使用保留網域，僅用於說明結構，無法直接建立代理連線。

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

proxies:
  - name: Example-Node
    type: socks5
    server: proxy.example.com
    port: 1080

proxy-groups:
  - name: 手動選擇
    type: select
    proxies:
      - Example-Node
      - DIRECT

rules:
  - DOMAIN-SUFFIX,example.com,手動選擇
  - MATCH,手動選擇

載入時先檢查縮排。YAML 使用空格表示層級，Tab 字元、同層欄位縮排不一致、冒號後缺少空格，都可能導致解析失敗。名稱中包含冒號、井號、方括號或前後空格時，建議用引號包住。陣列可以寫成多行清單，也可以寫成方括號形式，但同一段落維持同一種寫法更便於檢查。布林值使用 true 或 false，不要混用介面中常見的「開啟」「關閉」文字。

設定變更的回歸檢查

每次修改後至少驗證四類流量：明確要求直連的網站、明確要求代理的網站、使用純 IP 的連線，以及本機區域網路服務。瀏覽器存取成功不代表所有應用程式都正常，因為瀏覽器可能啟用獨立的安全 DNS 或基於 QUIC 的連線。建議同時使用系統指令檢查解析結果與連線路徑，例如執行 nslookup example.com 查看系統 DNS，再用 curl -I https://example.com 驗證命令列程式是否經過預期入口。若系統代理與 TUN 同時開啟，還應分別關閉其中一項重新測試，排除重複接管。

設定檔的穩定性取決於能否回復。保留「最近可用」「目前測試」與「計畫上線」三份狀態，比不斷覆蓋同一個檔案更安全。修改策略組名稱時，應全域搜尋規則、規則集、子策略組與快捷腳本中的舊名稱。刪除節點提供器前，應確認沒有策略組透過 use 引用它。只有設定能在客戶端重新啟動、訂閱更新與裝置重啟後維持一致，才算完成驗證。

策略組類型與實際組合方式

select：將最終選擇權交給使用者

select 是最基礎的策略組類型。組內可以放入節點、DIRECT、REJECT，也可以引用其他策略組。它不會執行自動測速，只記錄目前選擇。適合「總出口」「工作業務」「串流媒體」等需要明確控制結果的頂層策略。客戶端通常會保存選取狀態，但保存位置可能是執行時快取，而非原始設定。若希望重新啟動後延續選擇，可啟用核心支援的 profile.store-selected，同時確認客戶端沒有在每次啟動時重設設定。

頂層選擇組不宜直接塞入數百個節點。更清楚的方式是將自動測速、故障轉移與地區節點分別組織成子組，再由頂層組選擇這些子組。如此規則只依賴穩定的頂層名稱，訂閱節點增減也不會迫使規則同步改寫。對於需要臨時直連的業務，可在頂層組加入 DIRECT，但應清楚這會繞過代理鏈路，不適合要求固定出口的連線。

url-test：依探測結果選擇可用節點

url-test 會依設定的 URL 定期探測節點，並選擇回應表現符合條件的節點。測試結果只能反映探測目標的連線狀況，不代表所有網站與協定都具備相同品質。測試位址應穩定、回應內容小，並使用實際需要的協定。過短的 interval 會增加背景請求與行動裝置耗電；間隔過長則可能在節點失效後延遲切換。tolerance 用於減少多個相近節點之間頻繁跳轉，數值越大，目前節點在差異較小時越容易被保留。

proxy-groups:
  - name: 自動選擇
    type: url-test
    use:
      - main-provider
    url: https://www.gstatic.com/generate_204
    interval: 600
    tolerance: 80
    lazy: true

  - name: 總出口
    type: select
    proxies:
      - 自動選擇
      - 故障轉移
      - DIRECT

lazy: true 表示策略組在實際使用時才進行必要測試，可減少未使用分組的背景探測。若介面顯示所有節點都逾時，先不要直接判定節點全部失效。應檢查測試 URL 是否能從目前網路存取、DNS 是否正確、系統時間是否準確，以及代理協定所需的握手是否被網路入口阻擋。可參考節點逾時排查順序逐層確認。

fallback：優先順序與故障切換

fallback 著重於可用性與清單順序。它通常優先使用清單中較前且通過探測的節點，目前節點失效後再切換至後續可用項目。與 url-test 相比，它更適合固定主備出口、需要維持來源位址相對穩定的服務。將低延遲節點放在最前面不一定合理；若業務依賴固定地區或固定供應來源，應先依業務限制排序，再考慮回應時間。

故障轉移不是工作階段遷移。既有 TCP 連線在出口切換後通常需要重新建立，下載、遠端終端機或長連線可能中斷。對連續性要求較高的工作，應在應用層設定重試，並避免頻繁健康檢查造成誤切換。節點短暫抖動時，可適度增加探測間隔，或透過組內順序維持首選出口，不應單純追求最短測試時間。

load-balance：分配連線而非疊加頻寬

load-balance 會將不同連線分配至多個節點，但不會拆分單一 TCP 連線來疊加多條線路的頻寬。常見策略包括依目標位址保持一致的雜湊方式，以及更平均輪替連線的方式。需要登入狀態、來源位址驗證或穩定風控表現的業務，應使用能維持相同目標對映的策略，或直接使用 select 與 fallback。輪替方式適合彼此獨立的短連線，但可能導致同一服務在短時間內看到多個出口位址。

使用篩選器管理訂閱節點

節點提供器可以透過 filter、exclude-filter 或客戶端提供的正規表示式篩選入口產生地區組。正規表示式應符合訂閱中實際存在的命名方式，不要假設所有提供方都使用相同縮寫。先在客戶端查看節點原名，再編寫表達式；比對結果為空時，策略組可能沒有可選項目。地區名稱有多種寫法時，可使用分組表達式，例如 (香港|HK|Hong Kong)。排除「到期」「剩餘流量」等資訊節點時，應另外撰寫排除條件，避免它們進入測速組。

策略組設計的核心是穩定引用：規則引用少量固定組名，組內再組織持續變動的節點。常見結構可以是「總出口」引用「自動選擇」「故障轉移」「地區選擇」與「DIRECT」；業務規則只指向「總出口」或少數專用組。若每個規則集都建立一個功能相同的策略組，設定會迅速膨脹，訂閱更新後也更難確認實際出口。優先維持組名語意清楚、層級不超過三層，並避免兩個策略組互相引用形成循環。

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

將規則內容與策略決策分離

規則集提供器 rule-providers 用於從本機檔案或遠端位址載入一組規則。它解決的是規則內容更新問題，不負責決定使用哪個節點。主要設定透過 RULE-SET,規則集名稱,策略組名稱 將規則內容連結至策略決策。同一規則集可以在不同設定中指向不同策略組，也可以透過更換策略組實現臨時調度，而不必修改規則檔案本身。

訂閱管理適合規模較大且需要獨立更新的網域分類、IP 網段與業務清單。只有幾條且長期穩定的本機規則，直接寫入 rules 更容易檢查。不要為了形式統一，把所有單條規則都拆成遠端檔案；遠端來源會增加下載失敗、快取失效與格式變動三個變數。關鍵的本機網路、管理位址與最終兜底規則應留在主要設定中，即使外部規則集暫時無法連線，基礎路由仍然可預測。

behavior 決定規則檔案的語意

behavior: domain 用於網域集合，內容通常是完整網域、網域後綴或特定網域表達式；behavior: ipcidr 用於 IPv4 與 IPv6 網段；behavior: classical 則允許每一項攜帶完整規則類型，例如 DOMAIN-SUFFIX、PROCESS-NAME 或 IP-CIDR。主要設定宣告的行為必須與檔案內容一致。將 IP 網段按 domain 讀取，或把完整經典規則當作純網域集合載入，都可能導致解析錯誤或規則無法命中。

規則格式也可能是 YAML 文字、一般文字或核心支援的二進位規則格式。二進位格式載入效率較高，但不適合直接人工檢視；文字格式更便於排查與版本比較。客戶端與核心的支援範圍並不完全一致，遷移設定時應先確認目標核心是否能辨識對應的 format。當相容性比檔案大小更重要時，優先選擇目標客戶端已驗證支援的 YAML 或文字格式。

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

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

rules:
  - DOMAIN,router.local,DIRECT
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,service-rules,總出口
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,總出口

path 是規則集的本機快取位置。不同提供器不要共用同一個路徑，否則更新時可能互相覆蓋。路徑所在目錄需要具備寫入權限；行動裝置與受限桌面環境通常由客戶端代為管理。interval 以秒為單位控制更新週期；規則並非更新越頻繁越好，週期過短會增加啟動請求與來源壓力。業務變化不頻繁時，每日更新通常比每幾分鐘重新整理更穩妥。

規則順序比規則數量更重要

核心會由上而下進行比對。私有網路、區域網路網域與必須直連的管理位址應放在前面；精確業務規則應位於寬泛地域規則之前；需要攔截的規則必須放在可能放行它們的通用規則之前；MATCH 只負責處理先前未命中的連線。若將大範圍網域集合放在頂部，後續更具體的規則即使寫得正確也不會執行。

網域規則通常不需要先解析 IP，比對成本與結果也更直接。IP 類規則可能觸發網域解析；如果規則只用於檢查已明確的目標位址，可依核心語法加入 no-resolve，避免為了比對規則額外發出 DNS 查詢。但不能機械式地為所有 IP 規則加上此參數：當連線只有網域而規則又需要依目標 IP 判斷時，禁止解析會讓規則失去比對條件。應根據入站是否能提供位址、DNS 模式與嗅探狀態決定。

本機規則集的結構與測試

YAML 規則集通常以 payload 作為清單入口。domain 行為的檔案只保存網域模式，classical 行為的檔案則保存完整規則。更新前先對單一檔案進行語法檢查，再讓主要設定引用。若遠端規則集顯示下載成功卻沒有命中，應檢查四項：提供器名稱是否與 RULE-SET 一致、behavior 是否符合內容、規則是否被更早的條目攔截，以及目標連線是否保留網域資訊。

payload:
  - DOMAIN,api.example.com
  - DOMAIN-SUFFIX,assets.example.com
  - PROCESS-NAME,example-client
  - IP-CIDR,192.0.2.0/24,no-resolve

規則來源失效時，核心可能繼續使用既有快取，也可能在首次載入時因沒有快取而缺少該組規則。重要規則應準備本機基準，不應讓全部存取控制依賴單一遠端位址。訂閱位址解析異常與規則集格式錯誤的表現有時相似，都可能顯示更新失敗；可依照訂閱失效與設定解析復原步驟區分 HTTP 回應、檔案內容、快取與 YAML 結構。

建立可維護的命名與變更紀錄

提供器名稱應表達內容而非來源，例如 work-domain、private-cidr，避免使用「規則1」「最新規則」等無法長期理解的名稱。策略組名稱面向介面使用者，可以使用中文；提供器與路徑名稱則更適合使用穩定的 ASCII 字元，減少跨平台路徑與腳本處理差異。修改遠端位址、behavior 或格式時，應視為結構變更，先清除對應快取再測試，避免舊快取掩蓋新檔案的錯誤。

規則集規模擴大後，建議記錄每個集合的用途、資料類型、更新來源、目標策略與上次人工驗證結果。重點不是追求規則數量，而是確保每一層都有明確職責。發生命中異常時，透過日誌找到首條匹配規則，再回到對應集合定位內容，比盲目調整全域模式有效。關於中國大陸與海外直連、代理、攔截及兜底的完整排序，可繼續閱讀規則分流設定實戰。

DNS 設定最佳化與解析分流

DNS 決定規則引擎能看見什麼

DNS 設定不只是更換解析伺服器，也會影響網域解析路徑、規則能否保留網域、Fake-IP 對映，以及代理連線如何解析節點伺服器位址。系統先將網域交給哪個監聽器、查詢透過直連還是代理發出、回傳真實位址還是保留位址，都會改變後續規則行為。出現「節點可用但網頁打不開」「瀏覽器正常而命令列失敗」「同一網域反覆命中不同策略」時，應將 DNS 視為獨立鏈路檢查。

nameserver 負責一般網域查詢；default-nameserver 主要用於解析加密 DNS 伺服器本身的網域或建立初始連線，因此通常填寫可直接存取的 IP 型解析器；proxy-server-nameserver 可專門處理代理節點伺服器網域，避免節點網域經錯誤策略解析；nameserver-policy 則依網域指定解析器。欄位支援情況取決於核心，客戶端介面可能只提供其中一部分。

dns:
  enable: true
  listen: 0.0.0.0:1053
  ipv6: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  respect-rules: true

  default-nameserver:
    - 1.1.1.1
    - 8.8.8.8

  nameserver:
    - https://dns.google/dns-query
    - https://cloudflare-dns.com/dns-query

  proxy-server-nameserver:
    - 1.1.1.1
    - 8.8.8.8

  nameserver-policy:
    "geosite:private":
      - system

  fake-ip-filter:
    - "*.lan"
    - "*.local"
    - "time.*.com"
    - "stun.*.*"

範例用於展示欄位關係，不代表所有網路都應使用同一組公共解析器。選擇解析器時應先確認目前網路的可達性與隱私需求。加密 DNS 位址本身若是網域，核心仍需要初始解析途徑，這就是 default-nameserver 的作用。若初始解析器無法連線，加密查詢甚至無法開始。啟用 respect-rules 後，DNS 連線會參考規則路由；此時必須避免 DNS 查詢為了選擇策略，又依賴尚未完成的 DNS 結果而形成循環。

redir-host 與 fake-ip 的差異

redir-host 回傳真實 IP，行為接近傳統 DNS，對不相容 Fake-IP 的程式較友善，但網域完成解析後可能只剩目標位址，TUN 接管的純 IP 連線未必還能命中網域規則。fake-ip 則從保留位址範圍回傳對映位址，應用程式連線至該位址時，核心會還原原始網域並執行規則比對。如此可減少真實解析結果提前洩漏至系統路徑，也能讓網域規則在 TUN 情境中維持穩定。

Fake-IP 不等於代理位址，也不會直接出現在公網。它只在本機核心的對映表中代表某個網域。應用程式取得保留位址後，必須繼續將連線交給 Clash；如果系統路由、旁路由規則或安全軟體攔截該位址範圍，連線便會失敗。因此 Fake-IP 與 TUN 的路由接管應一起驗證，不能只看 DNS 查詢是否回傳位址。

fake-ip-filter 的適用範圍

區域網路探索、印表機、投放、時間同步、部分語音通話與依賴 STUN 的程式，可能要求真實位址或特殊 DNS 回應。這類網域可加入 fake-ip-filter，讓它們繞過 Fake-IP 對映。篩選範圍必須盡量具體。將過寬的萬用字元加入篩選清單，會讓大量網域回到真實解析，削弱網域還原與規則比對的穩定性。遇到應用程式異常時，應先從日誌或封包擷取確認實際查詢網域，再新增最小規則，而不是複製一份無法解釋的超長篩選清單。

部分核心支援黑名單或白名單式的篩選模式。黑名單表示清單內網域使用真實解析，是常見行為；白名單則可能只對清單內網域啟用 Fake-IP。遷移設定時必須同時遷移模式欄位，否則同一份網域清單會產生相反效果。若客戶端介面只提供開關，應查看匯出的最終設定確認實際值。

IPv6、快取與瀏覽器獨立 DNS

ipv6: false 通常表示內建 DNS 不回傳 AAAA 結果，但不等同於作業系統徹底關閉 IPv6。系統仍可能透過其他解析器取得 IPv6 位址，應用程式也可能直接連線至已快取的位址。如果網路沒有穩定的 IPv6 出口，可先在 Clash DNS 中關閉回傳，再分別檢查系統網卡與瀏覽器設定；如果網路具備正常 IPv6，則應同時準備 IPv6 路由規則，避免所有 IPv6 連線落入未設計的兜底路徑。

瀏覽器可能啟用獨立的安全 DNS，繞過系統指定的 Clash DNS。排查時可暫時關閉瀏覽器獨立解析，使用系統指令查詢指定監聽連接埠，並清除系統與瀏覽器快取。設定修改後仍看到舊位址，不一定代表新設定沒有生效，也可能只是快取尚未過期。重新啟動核心只能清除核心部分狀態，作業系統、瀏覽器與應用程式內部快取仍需分別處理。

TUN 接管、Fake-IP 對映與平台限制

TUN 與系統代理處理不同範圍的問題

系統代理依賴應用程式主動讀取作業系統代理設定，通常涵蓋瀏覽器與遵循系統設定的桌面程式。TUN 建立虛擬網路介面，透過系統路由將更多 TCP、UDP 以及不讀取代理設定的應用程式流量交給核心。因此，遊戲、命令列工具、商店程式或固定直連的應用程式在系統代理下沒有進入 Clash，不一定是規則問題；它們可能根本沒有經過代理入口。TUN 擴大接管範圍，但同時引入路由、權限、DNS 劫持與區域網路存取等額外變數。

啟用 TUN 前，應先確認一般系統代理模式可正常運作。若節點、策略與 DNS 基準尚未驗證，直接開啟 TUN 會將入口問題與出站問題疊加。建議順序是：關閉 TUN 驗證節點，啟用 TUN 但暫不調整複雜路由，確認一般網頁與命令列連線進入核心，再逐步處理區域網路、IPv6、應用程式排除與嚴格路由。

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

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

stack、auto-route 與 strict-route

stack 決定 TUN 封包由哪種網路堆疊處理。常見值包括系統堆疊、使用者態堆疊或混合模式。系統堆疊通常相容性較直接，使用者態堆疊便於核心完整處理連線，混合模式則嘗試在 TCP 與 UDP 情境間取得平衡。不同作業系統、客戶端封裝方式與應用程式協定的結果可能不同，沒有適用於所有裝置的固定最佳值。出現 UDP、區域網路探索或特定應用程式異常時，切換 stack 是有效的對照實驗，但每次只修改這一項。

auto-route 負責寫入系統路由，使目標流量進入虛擬介面；auto-detect-interface 用於識別實際出口網卡，避免資料再次回到 TUN 形成迴圈；strict-route 會更嚴格限制繞行路徑，減少部分系統查詢或流量繞過接管，但也可能影響多網卡、虛擬機器、企業網路與區域網路服務。裝置同時連接有線、無線、VPN 或容器橋接網路時，自動偵測可能選錯出口，應查看路由表確認預設路由。

DNS 劫持與 Fake-IP 位址範圍

dns-hijack 會將常見的 53 連接埠查詢交給內建 DNS，確保應用程式的一般 DNS 請求進入既定解析鏈路。它無法自動接管應用程式內建的加密 DNS，也不能修復已被其他安全軟體攔截的請求。若系統同時執行其他 VPN、過濾軟體或虛擬網卡工具，多個元件可能爭用 DNS 與預設路由。此時應一次只保留一個接管元件，確認 Clash 能單獨運作後再恢復其他軟體。

Fake-IP 預設使用專用保留網段建立網域對映。該網段必須由 TUN 路由接管，也不能與企業網路、實驗環境或其他虛擬網路的實際位址規劃衝突。若另一個元件將相同網段當成真實內部網路，應用程式連線會被送往錯誤介面。修改 Fake-IP 範圍後，需要清除 DNS 快取與核心對映，舊位址不會自動代表新的對映關係。

MTU 與連線可建立但傳輸停滯

MTU 過大時，某些路徑上的分片或路徑 MTU 探測可能受阻，表現為握手成功、少量資料可傳輸，但較大的頁面、上傳或特定協定長時間停滯。MTU 過小則會增加封包數量與處理負擔。預設值能涵蓋多數乙太網路環境；行動網路、疊加式隧道與部分寬頻撥號環境出現異常時，可逐步降低 MTU 進行對照，不應一開始就設定極端數值。測試時要涵蓋小型請求、大型回應、上傳與 UDP，不要只看首頁能否開啟。

如果只有部分網站載入到一半，先排除 DNS 與規則問題，再檢查 MTU。可觀察日誌中的連線是否已成功建立，以及失敗是否集中在大型回應。系統指令的具體參數因平台而異，但原則相同：傳送禁止分片且逐步調整大小的封包，找出穩定上限，再為隧道標頭預留空間。調整完成後應重新測試實際業務，不要只依賴單次探測。

Windows、macOS、Android、iOS 與 Linux 的差異

Windows 與 macOS 啟用 TUN 通常需要管理員權限或系統網路延伸功能授權；權限遭撤銷後，介面開關可能仍顯示已啟用，但路由並未成功寫入。Android 與 iOS 通常透過系統 VPN 介面實現接管，同一時間往往只能維持一個此類連線，電池最佳化、背景限制與按應用程式代理選項也會影響涵蓋範圍。Linux 需要檢查 TUN 裝置、路由寫入權限與防火牆規則；伺服器環境還要避免將遠端管理連線錯誤送入代理而造成失聯。

客戶端實作決定介面能否設定應用程式排除、路由繞過與自動復原。選擇客戶端時應以平台能力為準，下載入口可在下載頁查看；跨平台優先考慮 Clash Plus，桌面端也可依需求比較 Clash Verge Rev、FlClash 與 Clash Nyanpasu。已停止維護的 Clash for Windows 與 ClashX Meta 僅適合在相容舊環境時參考，不應依賴它們取得新增核心能力。

區域網路、虛擬機器與容器存取

啟用 TUN 後，私有網段通常應在規則前段直連，並依實際網路保留路由。只寫 GEOIP,LAN,DIRECT 不一定足夠，因為流量在進入規則引擎前可能已被系統路由送往錯誤介面。需要同時檢查系統路由、TUN 排除網段與 Clash 規則。區域網路存在多個私有網段時，應明確列出實際網段，不要假設所有裝置都在同一個子網路。

虛擬機器、容器與 WSL 類環境可能擁有獨立的虛擬交換器與 DNS。主機啟用 TUN 後，子系統流量可能經過主機，也可能走獨立 NAT。先在子系統中查看預設閘道與 DNS，再判斷是否需要將 Clash 監聽位址開放給區域網路。若啟用 allow-lan，應搭配防火牆限制可信網段，避免將代理連接埠暴露於不受控網路。排查 TUN 時，務必保留一條不經過該路由的管理通道，以便設定錯誤後復原。

網域嗅探的作用、設定與誤判控制

嗅探用於補回網域資訊

部分連線進入核心時只攜帶目標 IP，沒有可供網域規則比對的主機名稱。網域嗅探會從 HTTP Host、TLS ClientHello 中的伺服器名稱，或可識別的 QUIC 握手資訊提取網域，再用於規則判斷。它不是 DNS 查詢，也不會解密 HTTPS 內容；嗅探只讀取連線建立階段原本就可見的中繼資料。對於 TUN、透明代理與已由應用程式預先解析的連線，嗅探可以提高網域規則的命中率。

嗅探並非越強越好。連線中沒有網域、協定經過特殊封裝、應用程式使用加密的客戶端問候，或目標是純 IP 服務時，核心無法可靠還原名稱。錯誤覆寫目標位址也可能讓原本正常的連線走向不相符的網域。設定應限制協定與連接埠，並為已知不相容服務設定略過規則。

sniffer:
  enable: true
  force-dns-mapping: true
  parse-pure-ip: true

  sniff:
    HTTP:
      ports:
        - 80
        - 8080-8880
      override-destination: true
    TLS:
      ports:
        - 443
        - 8443
    QUIC:
      ports:
        - 443
        - 8443

  force-domain:
    - "+.example.com"

  skip-domain:
    - "Mijia Cloud"
    - "+.push.example.com"

parse-pure-ip 允許對目標為純 IP 的連線嘗試協定解析；force-dns-mapping 與 DNS 對映協同運作，協助還原先前由核心處理過的網域；override-destination 表示成功取得網域後，使用嗅探結果參與或取代後續目標判斷。欄位細節會隨核心實作變化，匯入前應查看客戶端最終產生的設定，避免介面開關與手寫段落同時存在並互相覆蓋。

HTTP、TLS 與 QUIC 的可見範圍

明文 HTTP 通常可從 Host 請求標頭取得網域，但不一定只在 80 連接埠執行。將連接埠範圍擴展至常見代理或開發連接埠，有助於識別內部服務；不過範圍越寬，核心嘗試解析非 HTTP 流量的機會也越多。TLS 嗅探主要讀取握手中的伺服器名稱；如果應用程式直接使用 IP、伺服器名稱被隱藏，或握手不是標準 TLS，就不會得到有效網域。QUIC 基於 UDP，排查時還要確認 TUN 與節點鏈路是否支援相應 UDP 流量。

連接埠清單應來自實際業務。將所有連接埠都加入每種協定，看似涵蓋更廣，實際上會增加誤判與處理成本。一般網頁優先涵蓋 80、443 與少數明確使用的替代連接埠。資料庫、遠端桌面、遊戲與語音協定若沒有網域規則需求，不應強制按 HTTP 或 TLS 解析。日誌中持續出現嗅探失敗不一定會影響連線，但表示目前連接埠範圍可能過寬。

force-domain 與 skip-domain

force-domain 用於指定需要優先嘗試嗅探的網域模式，適合 DNS 對映不完整但必須依網域分流的服務。skip-domain 用於排除已知不相容、網域結果不穩定或不應覆寫目標的連線。網域模式語法應依目標核心要求撰寫，常見的 +.example.com 表示包含根網域及其子網域。排除項目需要有實際故障依據，不要從陌生範本複製大量與本機應用程式無關的名稱。

若某個應用程式啟用嗅探後失敗，先比較關閉嗅探時是否恢復，再查看連線日誌中擷取的網域。若日誌網域與應用程式實際目標不符，將該網域或相關程序加入略過範圍；若根本沒有擷取到名稱，則應回到 DNS、規則與 IP 分流檢查，繼續增加強制網域不會產生真實資訊。嗅探是補充手段，不能取代正確的 DNS 接管。

嗅探與規則順序的協同

嗅探成功只表示規則引擎取得了網域，並不保證命中預期策略。更早的 IP 規則、程序規則或寬泛規則集仍可能先行比對。排查時應查看日誌回報的目標網域、目標位址、命中規則與策略組，而不是只看「sniff success」。若希望網域規則優先，應將具體網域規則放在可能攔截連線的通用 IP 規則之前。

程序規則在不同平台上的可用性差異很大。桌面端可能辨識程序名稱或路徑，行動裝置受系統限制，往往無法提供同等資訊。不要用程序規則取代所有網域規則；更穩定的方式是以網域規則為主，程序規則只處理專用客戶端或無法穩定辨識網域的流量。程序名稱也可能隨更新改變，應透過日誌取得實際名稱。

逐步啟用，而非一次涵蓋所有協定

建議先只啟用 TLS 443 連接埠，在常用網頁與應用程式中觀察命中變化；確認沒有異常後，再加入 HTTP 與 QUIC。每增加一類協定，都分別測試直連、代理、區域網路與長連線。若啟用 QUIC 後只有部分應用程式異常，可暫時關閉 QUIC 嗅探但保留 UDP 轉發，區分問題發生在協定識別還是傳輸鏈路。

網域嗅探最有價值的情境，是透明接管後遺失網域，而不是用來「猜測」所有目標。設定越明確，排錯越容易。長期維護時，應記錄每個強制或略過項目的原因，並定期刪除已無法重現的相容性項目。若某項服務必須依賴大量嗅探例外才能運作，應重新檢查 DNS 模式、Fake-IP 篩選與應用程式自身的解析方式，根因通常不在嗅探清單本身。

本機覆寫與多訂閱合併

先確認客戶端的合併層級

多訂閱合併通常由客戶端完成，而不是 Clash 設定格式中的單一通用欄位。客戶端可能提供基礎設定、全域覆寫、訂閱專屬覆寫、JavaScript 腳本或視覺化合併器。不同入口的執行順序會影響最終結果：後執行的同名純量通常會覆蓋前值，映射可以遞迴合併，陣列則可能整體取代、追加或依名稱去重。不能假設某個客戶端的合併行為適用於所有客戶端。

開始前先匯出客戶端最終交給核心的設定，並做一個小實驗：在訂閱中保留兩個策略組，在覆寫中加入一個組，觀察最終陣列是追加還是取代。確認行為後再遷移完整規則。Clash Plus 適合作為跨平台優先選擇，桌面端的 Clash Verge Rev、FlClash 與 Clash Nyanpasu 也提供不同形式的訂閱管理能力；具體入口應以客戶端目前介面為準。客戶端之間遷移時，先遷移標準 YAML，再重建客戶端專屬的合併邏輯。

純量、映射與陣列的處理差異

mixed-port、mode、log-level 屬於純量，後層設定通常會直接取代；dns、tun 屬於映射，可能依子欄位合併；proxies、proxy-groups、rules 屬於陣列，最容易出現意外。若合併器將陣列整體取代，一段只有三條本機規則的覆寫可能刪除訂閱原有的全部規則。若合併器執行追加，本機兜底規則又可能被放到訂閱的 MATCH 後面，實際上永遠無法命中。

因此，規則陣列需要明確定義「前置、後置或取代」語意。區域網路直連與業務精確規則通常前置，最終 MATCH 維持唯一並位於末尾。策略組陣列應依 name 去重；同名但類型不同的組不能簡單串接。節點陣列同樣需要處理重名，否則介面可能只顯示其中一個，規則引用也無法判斷實際目標。

# 本機基礎覆寫：只放長期穩定的純量與映射
mode: rule
log-level: info
ipv6: true

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

dns:
  enable: true
  enhanced-mode: fake-ip

tun:
  auto-route: true
  auto-detect-interface: true

上面的片段不包含節點、策略組與規則陣列，適合由支援遞迴映射合併的客戶端疊加至訂閱。若客戶端採用整段取代，仍需在合併預覽中確認 dns 的其他子欄位是否保留。最穩妥的做法不是猜測，而是查看最終 YAML。任何合併工具只要無法展示結果，就不適合直接用於正式設定。

多訂閱節點的命名與來源隔離

兩個訂閱可能包含相同的節點名稱。直接合併後，策略選擇、健康檢查與持久化狀態都可能指向錯誤節點。建議在合併階段依來源增加穩定前綴，例如「主要來源 / 節點名稱」與「備用來源 / 節點名稱」，並同步更新策略組引用。前綴不宜包含會隨訂閱標題變動的到期日期或流量資訊，否則每次更新都會被視為新節點，已儲存的選擇也會失效。

更清楚的方式是保留多個 proxy-providers，讓策略組透過 use 引用來源，而不是將所有節點展開成一個龐大的陣列。如此可以分別設定更新週期、健康檢查與篩選規則，也便於暫時停用某個來源。提供器路徑必須唯一，遠端位址失效時應保留最近可用的快取，並在介面中明確顯示更新失敗，不能將舊快取誤認為剛剛更新成功。

proxy-providers:
  primary:
    type: http
    url: https://sub.example.com/primary.yaml
    path: ./providers/primary.yaml
    interval: 86400
    health-check:
      enable: true
      url: https://www.gstatic.com/generate_204
      interval: 600

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

proxy-groups:
  - name: 主要訂閱
    type: select
    use:
      - primary
  - name: 備用訂閱
    type: fallback
    use:
      - backup
    url: https://www.gstatic.com/generate_204
    interval: 600

敏感欄位與設定分發

訂閱位址、外部控制金鑰與節點驗證資訊都不適合複製到公開儲存庫、截圖或線上格式化工具。多人維護時，可將不含敏感內容的規則與覆寫分開保存，把訂閱與驗證資訊留在客戶端本機。需要在裝置間同步時，應使用受控的私人儲存空間，並限制同步範圍。範例設定只能展示欄位結構，不應複製真實訂閱位址。

外部規則與本機覆寫最好分開管理：規則集負責「哪些目標屬於某類」，本機設定負責「該類目標採用哪個策略」。如此更換訂閱或客戶端時，規則資產仍可重複使用。若將節點、規則、DNS 與裝置專屬路徑全部寫入單一大型檔案，任何一項更新都會增加衝突機率。

更新後的自動檢查清單

每次訂閱更新後，先確認提供器狀態與節點數量是否合理，再檢查頂層策略組是否仍有成員、選取狀態是否指向現存節點、規則引用的策略名稱是否完整。接著驗證 DNS 設定未被訂閱覆蓋，TUN 與外部控制介面仍維持本機預期值。若客戶端支援設定預處理腳本，腳本發生異常時應停止套用新設定，而不是輸出部分合併的檔案。

多訂閱問題經常表現為「更新後沒有節點」或「策略組為空」。這不一定表示訂閱內容為空，也可能是篩選正規表示式排除了所有節點、同名去重邏輯錯誤、提供器檔案解析失敗，或合併器取代了完整陣列。應依原始回應、單份訂閱解析、合併前結構、最終設定與核心載入五個階段逐項檢查。具體復原步驟可參考訂閱失效與設定解析失敗。

外部控制介面、面板連接與安全界線

控制介面與代理連接埠不是同一項服務

external-controller 提供執行狀態、策略切換、連線管理、日誌與設定重新載入等控制能力。它不是 HTTP 或 SOCKS 代理連接埠，應用程式不能透過它轉發一般網路請求。常見控制面板會透過此介面讀取策略組並傳送選擇操作；客戶端本身也可能呼叫同一介面實現圖形介面。控制介面具備修改執行狀態的能力，應只向可信任的網路開放。

監聽在 127.0.0.1 時，只有本機程式可以存取，適合桌面客戶端與本機面板。監聽在 0.0.0.0 時會綁定所有可用介面，區域網路裝置可能存取，必須同時設定強密鑰與防火牆來源限制。將監聽位址改為所有介面並不等於完成遠端管理；還需要確認系統防火牆、路由、反向代理與瀏覽器來源限制。沒有遠端存取需求時，應維持本機監聽。

external-controller: 127.0.0.1:9090
secret: "change-this-secret"

# 僅在面板檔案由客戶端或本機部署提供時啟用
external-ui: ./dashboard

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

範例密鑰只用於說明欄位，部署時應在本機產生不可預測的獨立值。不要重複使用控制密鑰、訂閱位址、系統登入密碼或其他服務憑證。修改密鑰後，也要同步更新面板中的連線設定。若面板持續回傳未授權，先檢查請求是否攜帶正確的驗證資訊，再確認客戶端是否在啟動時以另一份設定覆蓋了 secret。

外部面板的連線流程

控制面板通常需要控制介面位址與驗證密鑰。面板會從介面讀取策略組、代理節點、目前連線與日誌，再依使用者操作傳送切換或關閉請求。若面板頁面可以開啟卻沒有資料，應將「靜態頁面載入」與「API 連線」分開檢查：前者取決於面板檔案或 Web 服務，後者取決於控制介面位址、驗證、瀏覽器同源限制與網路可達性。

面板部署在本機且介面也只監聽本機時，設定最簡單。面板位於其他裝置時，瀏覽器存取的 127.0.0.1 指向瀏覽器所在裝置，而不是執行 Clash 的主機，這是常見的位址誤判。此時應使用 Clash 主機在可信任區域網路中的位址，並透過防火牆限制來源。跨公網暴露控制介面的風險較高，應使用受控的安全存取層，不應直接開放連接埠。

常用狀態檢查與唯讀觀察

排障時先使用唯讀資訊確認控制面是否連線至正確的核心：查看目前設定模式、策略組清單、核心日誌與活動連線。多個客戶端或核心同時執行時，連接埠可能被占用，面板也可能連到舊執行個體。應透過程序、監聽連接埠與日誌啟動時間確認目標。切換策略後觀察新連線採用的出口；既有連線不會自動全部遷移，必要時需關閉相關連線後重新建立。

連線清單適合判斷應用程式是否進入核心、目標網域是否已還原、命中了哪條規則以及實際策略鏈。若應用程式完全沒有出現在連線清單中，優先檢查系統代理、TUN、應用程式繞過設定與防火牆；若已出現但策略錯誤，檢查規則順序與策略組；若策略正確但連線失敗，再檢查節點與目標網路。這種分層順序比反覆切換節點更容易定位問題。

設定重新載入與執行時狀態

透過介面重新載入設定時，應先完成語法驗證。錯誤設定可能被拒絕，也可能造成部分功能重新啟動。策略選擇、Fake-IP 對映與規則集快取是否保留，取決於設定與核心狀態。profile.store-selected 用於保存策略選擇，profile.store-fake-ip 用於保存對映狀態；更換 Fake-IP 位址範圍、清除快取或移動設定目錄時，應預期這些狀態會重新建立。

重新載入後要確認監聽連接埠、控制位址、DNS 與 TUN 是否仍正常。修改控制介面本身的位址時，目前面板連線會中斷，需要使用新位址重新連線。修改代理連接埠後，系統代理可能仍指向舊連接埠；修改 TUN 裝置名稱或路由設定後，舊路由也可能需要由客戶端清理。完整重新啟動雖然耗時較長，但涉及監聽器、虛擬介面與路由時，通常比連續熱重載更容易取得確定狀態。

日誌層級與故障定位

silent、error、warning、info 與 debug 提供不同的詳細程度。日常使用保留 info，較容易發現規則集更新、監聽失敗與連線錯誤。需要定位 DNS、嗅探或規則命中時，暫時使用 debug；重現一次問題後立即保存必要片段並恢復一般層級。日誌可能包含目標網域、區域網路位址與節點名稱，分享前應刪除敏感資訊。

閱讀日誌時，依時間線定位一條具體連線：先找入站類型與來源，再看目標網域或位址、命中規則、策略鏈、實際節點與最終錯誤。只截取最後一行「timeout」通常不足以判斷原因。逾時可能發生在 DNS、節點握手、代理連往目標、UDP 轉發或應用程式等待回應的任一階段。結合疑難解答中的分類問題，可以先判斷錯誤屬於入口、解析、規則或出站。

安全開放的最小原則

控制介面只綁定需要的位址，代理連接埠只開放給需要的裝置；allow-lan 與控制介面開放應分開判斷。允許區域網路裝置使用代理，不代表它們也需要切換策略或查看連線。系統防火牆應依來源位址限制控制連接埠，面板與介面之間使用獨立密鑰。裝置離開可信任網路或連線至公共網路時，應確認監聽策略不會繼續暴露服務。

外部面板檔案應來自已確認的客戶端元件或受控部署，面板更新與核心更新分開進行。面板顯示異常不代表代理核心停止工作，核心連線正常也不代表控制介面安全。維護時分別記錄核心設定、面板版本來源、監聽位址與存取界線，不要把所有問題都歸類為「面板無法連線」。

建立可重複的變更流程

穩定的進階設定應遵循固定流程：匯出目前可用的設定，修改單一功能範圍，完成 YAML 與引用檢查，在測試設定中啟動，驗證直連、代理、DNS、TUN 與控制介面，再替換正式設定。訂閱更新後重複關鍵檢查，並保留回復副本。首次設定連線流程可回到使用文件，客戶端安裝包與平台選擇請在下載頁查看。

最終設定不需要包含所有可用欄位。策略組只保留具有明確決策意義的層級，規則集只保留能說明來源與用途的集合，DNS 與 TUN 只啟用目前網路確實需要的能力，嗅探例外必須能夠解釋，控制介面則遵循最小開放範圍。設定越能清楚描述資料從入口到出口的路徑，發生問題時就越容易透過日誌定位，而不是依賴反覆重設或替換整份範本。