Clash 進階設定指南

Chapter 01 / Baseline

設定骨架與除錯基準

Clash 設定不是彼此獨立的選項清單，而是一條具有先後關係的處理鏈。用戶端會先讀取監聽連接埠、運作模式與 DNS 等基礎項目，再載入代理節點與策略組，接著載入規則和規則集，最後由系統代理或 TUN 將流量送入核心。任何一層引用不存在的名稱，都會影響後續行為。最常見的例子是規則指向已重新命名的策略組：設定可能仍能解析，但符合條件的流量無法依預期選擇出口。因此，進階調整的第一步不是增加更多參數，而是先建立一份能說明、能驗證、能復原的基準設定。

先分清用戶端設定與核心設定

Clash Plus、Clash Verge Rev、FlClash、Clash Nyanpasu 等圖形化用戶端通常會把設定分成兩層。第一層屬於應用程式本身，例如開機啟動、系統代理開關、設定更新週期、介面主題與服務安裝狀態；第二層才是傳給 mihomo 核心的 YAML。系統代理按鈕通常不會改寫訂閱檔案，只會變更作業系統的代理入口。TUN 開關則可能由用戶端產生一段執行時覆寫，因此在原始訂閱中找不到完全相同的欄位。排錯時應同時查看目前生效的設定與訂閱原文，不能只盯著下載下來的 YAML。

適合除錯的基礎段落應保持精簡。日誌層級先使用 info，已足以查看連線、規則命中與 DNS 錯誤；只有需要追蹤特定請求時，再暫時切換到 debug。是否需要明確填寫連接埠，取決於用戶端的管理方式；桌面用戶端可能在啟動時注入自己的連接埠。若手動維護純設定檔，可使用下方結構，但應確認連接埠未被其他代理程式占用。

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

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

mode: rule 表示依規則決定直連、代理或拒絕；unified-delay 讓測速標準更接近完整連線流程，但不會改變真實網路品質；store-selected 用於儲存策略組選擇，重新啟動後不必逐組重新選取；store-fake-ip 儲存 Fake-IP 對應，減少重新啟動後短時間內對應變化造成的連線波動。行動裝置若由系統回收應用程式程序，持久化設定尤其重要，但仍須由用戶端獲得正常的背景執行條件。

用最短流程建立驗證閉環

每次修改後，先確認核心能載入設定，再確認代理節點能建立連線，接著查看一個測試請求命中了哪條規則，最後才檢查目標應用程式。若日誌在設定解析階段已報錯，繼續切換節點沒有意義；若節點交握失敗，應優先處理訂閱與網路，不要先修改 DNS；若瀏覽器正常而某個應用程式失敗，再檢查該應用程式是否繞過系統代理、使用獨立 DNS 或 QUIC。依照這個順序，可以把問題鎖定在單一層級。

設定檔中的縮排只使用空格，不要混入定位字元。包含冒號、井字號或特殊字元的文字可以加上引號；策略組名稱一旦被規則引用，就應保持穩定。若需要更換用戶端，先到下載頁選擇對應平台；跨平台使用可優先考慮 Clash Plus，再依作業系統與使用習慣選擇其他用戶端。遷移時先匯入同一份訂閱驗證基本連線，再遷移本機覆寫，避免直接把舊用戶端產生的執行時欄位當作通用設定複製。

Chapter 03 / Rules

以規則集訂閱管理

當規則從十幾條增加到數百條後，繼續把全部內容塞進主設定會迅速失去可維護性。rule-providers 用於將不同主題的規則拆成獨立資源，由主設定宣告下載網址、格式、更新週期與比對行為。主檔案只保留呼叫順序，規則內容則由對應規則集維護。如此可以單獨更新廣告攔截、區域網路、開發服務或串流媒體規則，也能在某個規則集異常時快速停用，不必重寫整份訂閱。

provider 定義與 RULE-SET 呼叫

規則提供者的名稱只是本機引用識別，真正影響解析的是 behavior、format 與資源內容。behavior: domain 適合只包含網域類項目的集合；ipcidr 用於 IP 網段；classical 可容納帶有類型前綴的傳統規則。格式必須與遠端檔案一致，常見純文字規則可使用 text，YAML 規則使用 yaml。不要將 classic 內容宣告為 domain，否則即使載入成功，也不代表比對語意正確。

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

  developer:
    type: http
    behavior: classical
    format: text
    path: ./ruleset/developer.list
    url: https://example.com/rules/developer.list
    interval: 86400

rules:
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,developer,開發服務
  - GEOIP,LAN,DIRECT,no-resolve
  - MATCH,總選擇

範例網域只用來表示欄位結構，實際使用時應替換為已確認可存取且內容可信的規則來源。path 是本機快取位置，不同提供者不要共用同一路徑。interval 以秒為單位，公共規則通常沒有必要每隔幾分鐘更新一次；過於頻繁只會增加請求與寫入。更新失敗時，核心通常會繼續使用既有快取，因此排錯時要區分「首次下載失敗」與「更新失敗但舊規則仍在生效」。刪除快取後重試會失去這個回復條件，不應作為第一步操作。

規則順序就是優先級

Clash 會由上而下尋找第一條符合的規則，命中後便不再繼續。具體規則應放在寬泛規則之前：私人網域與區域網路通常先直連，業務網域再進入對應策略，IP 規則放在需要解析位址的位置，最後由 MATCH 接住其餘流量。將大範圍代理規則放在頂部，後面的直連例外就永遠不會執行。排查錯誤分流時，日誌顯示的「命中哪條規則」比猜測網域屬於哪個分類更可靠。

no-resolve 表示比對 IP 類規則時，不要為了取得 IP 而主動觸發 DNS 解析。它可以避免不必要的解析，但不適合機械式地加在所有規則後面。若網域請求前方沒有網域規則，而後續又依賴 GEOIP 判斷，完全阻止解析可能使該規則無法取得所需位址。是否加入應依規則類型與 DNS 模式決定。對於已直接取得目標 IP 的連線，IP 規則仍可正常比對。

少量本機例外可以直接寫在 rules 頂部，不必為三五個項目建立遠端規則集。例如某個工作網域必須直連，或某個應用程式介面必須固定使用「開發服務」，將這些規則放在訂閱規則集之前即可。若例外數量持續增加，再移轉至本機 provider。如此既能保持主設定可讀，也能避免每次微調都發布遠端檔案。

rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,corp.example,DIRECT
  - DOMAIN-SUFFIX,github.com,開發服務
  - RULE-SET,private-domain,DIRECT
  - RULE-SET,developer,開發服務
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - MATCH,總選擇

規則集故障的定位順序

先查看 provider 狀態是否完成載入，再確認遠端回應內容與宣告格式相符，接著檢查規則集名稱是否與 RULE-SET 引用一致，最後檢查呼叫位置。狀態正常但始終未命中，常見原因是行為類型錯誤、規則被前面的寬泛項目攔截，或目標連線只暴露 IP 而規則集只有網域。更新後突然出現大量錯誤分流時，可以還原上一份本機快取或暫時註解該規則集，確認問題是否來自上游內容變更。

規則來源越多，更新節奏與命名越難統一。更穩妥的結構是依用途選擇少量規則集，每項業務只設定一個主要來源，本機例外則作為最高優先級。不要同時引入多個涵蓋範圍相近的全集規則，再期待順序自動解決衝突。需要同步多部裝置時，可參考多裝置設定同步方案，將主設定、訂閱連結與本機規則分開管理。

Chapter 05 / Network stack

TUN 模式與 Fake-IP 協同運作

系統代理只能涵蓋主動遵循代理設定的應用程式。命令列工具、部分遊戲、獨立網路堆疊應用程式，以及直接發起 UDP 的程式，可能完全繞過系統代理。TUN 模式透過虛擬網路介面接管系統路由，將這些流量送入 Clash 核心，因此涵蓋範圍更完整。Fake-IP 則在 DNS 階段回傳一段對應位址，讓核心在收到連線時還原原始網域並執行網域規則。兩者經常一起使用，但負責的是不同工作：TUN 負責把流量帶進來，Fake-IP 負責保留網域語意。

TUN 欄位與系統權限

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

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

stack 決定 TUN 使用的網路堆疊實作。mixed 在支援的核心中兼顧相容性與效能；若特定平台出現異常，可分別測試 system 或 gvisor，但不要在沒有對照的情況下頻繁切換。auto-route 會自動寫入路由，auto-detect-interface 會嘗試識別目前的出口網卡；裝置在 Wi-Fi、行動網路與有線網路之間切換時，這項功能能減少手動指定介面的維護。strict-route 會更嚴格地防止流量繞過，但可能暴露與其他 VPN、虛擬機器及容器網路之間的路由衝突。

TUN 啟動需要系統層級 VPN 或網路延伸功能權限。Windows 用戶端可能透過服務模式提升網路操作權限；macOS 需要允許網路延伸功能；Android 與 iOS 會顯示系統 VPN 授權。權限遭拒時，介面開關可能短暫開啟後恢復，日誌中也會出現建立裝置或寫入路由錯誤。此時反覆匯入訂閱沒有作用，應先處理系統授權。macOS 的具體彈窗與復原步驟可參考網路延伸功能與鑰匙圈處理指南。

Fake-IP 的對應流程

Fake-IP 模式收到網域查詢後，不會立即將真實位址直接交給應用程式，而是從保留位址範圍分配一個對應值。應用程式連線至該位址時，核心會依對應表還原網域，然後比對 DOMAIN、DOMAIN-SUFFIX 或規則集。它的優點是，即使應用程式只將目標位址交給網路層，Clash 仍能掌握原始網域。對應位址不是遠端伺服器位址，也不應拿來進行公網路由測試。看到 198.18.0.0/16 範圍的結果，通常表示 Fake-IP 正常參與解析。

某些區域網路探索、時間同步、列印裝置、遊戲平台或依賴真實 DNS 回應的程式不適合使用 Fake-IP，需要加入 fake-ip-filter。過濾範圍應盡量具體。直接排除過大的網域集合，會讓大量請求回到真實位址模式，削弱網域還原效果，也可能使規則依賴 IP 比對。出現相容性問題時，先從日誌確認網域，再加入單一後綴並重新測試，不要複製來源不明的超長過濾清單。

MTU、UDP 與網路切換

頁面能開啟，但部分圖片、上傳或特定應用程式卡住時，可能是路徑 MTU 不合適。TUN 封裝會增加額外負載，底層網路若已存在 VPN、PPPoE 或行動網路限制，1500 位元組可能導致分片或封包遺失。在保留其他設定不變的前提下，可以逐步降低 MTU，例如先測試約 1400 的範圍，並觀察問題是否穩定消失。MTU 不是越小越安全；過小會增加封包數量與處理負載，確認有效後應選擇能穩定運作的較大值。

UDP 問題要區分三個層面：應用程式是否發出 UDP、TUN 是否接管，以及節點協定與網路是否支援對應傳輸。DNS 查詢、QUIC、遊戲與語音都可能使用 UDP。關閉 QUIC 後瀏覽器恢復，只能說明故障集中在 UDP 路徑，不代表 DNS 或節點整體不可用。行動裝置在 Wi-Fi 與行動網路切換後，舊工作階段可能仍綁定原介面；必要時重新連線 TUN，不要立即清除全部設定。

建議的啟用順序是：先使用系統代理確認節點與規則可用，再單獨開啟 TUN，確認路由與權限正常，最後啟用 Fake-IP 並處理少量相容性例外。若開啟 TUN 後整台裝置斷網，先關閉它以恢復網路，再檢查預設路由、DNS 劫持與其他 VPN。Windows 的服務模式、連接埠衝突與系統代理步驟可查看Windows 安裝設定完整流程。

Chapter 07 / Merge

本機覆寫與多重訂閱合併

訂閱負責提供遠端維護的節點與基礎設定，本機覆寫則負責儲存裝置或個人環境特有的調整。若直接在同一檔案中修改兩者，下一次訂閱更新很可能覆蓋本機內容；完全複製成靜態設定又會失去節點更新。更合理的結構是將訂閱視為上游輸入，把連接埠、DNS、策略組補充、規則前置與 TUN 設定放入可重複套用的覆寫層。不同用戶端支援的覆寫機制名稱可能不同，例如 Merge、Mixin、Script 或全域擴充，但目標都是在更新後重新產生生效設定。

區分取代、追加與深度合併

YAML 物件可以依鍵合併，但陣列有不同語意。修改 dns.enable 通常只會取代單一欄位；處理 rules 時，則要明確是前置規則、後置規則，還是取代整個陣列。若合併器直接以新陣列覆蓋舊陣列，一段只含三條本機規則的覆寫，可能讓訂閱原有規則全部消失。使用用戶端內建合併功能前，應查看最終生效的設定，而不是只確認覆寫片段是否成功儲存。

prepend-rules:
  - DOMAIN,router.local,DIRECT
  - DOMAIN-SUFFIX,corp.example,DIRECT

append-rules:
  - MATCH,總選擇

override:
  mode: rule
  log-level: info
  ipv6: false

上方結構用於說明「前置、後置、取代」三種意圖，具體鍵名取決於用戶端的合併實作，未經確認不能直接當作 mihomo 原生設定載入。mihomo 最終接收的仍是一份完整設定。驗證方式是開啟用戶端產生的執行時設定，確認本機規則位於預期位置、策略組沒有重複，且最終只保留一個 MATCH。若用戶端提供設定檢查功能，應在每次更新後執行一次。

多重訂閱合併以節點層為主

同時使用多份訂閱時，最穩定的方式通常是將它們宣告為不同的 proxy-providers，由本機策略組透過 use 引入，而不是直接拼接多份完整設定檔。完整設定往往各自帶有連接埠、DNS、策略組與規則，同名鍵會互相覆蓋，同名組會產生衝突，最後結果取決於合併工具的實作。節點提供者只負責節點集合，本地主設定負責統一策略與規則，職責更清楚。

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

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

proxy-groups:
  - name: 總選擇
    type: select
    use:
      - primary
      - backup
    proxies:
      - DIRECT

範例中的訂閱網址只是結構示意，使用時應換成自己的有效網址，並避免將包含存取憑據的連結公開於文件、截圖或共用儲存庫。兩個 provider 必須使用不同的快取路徑。健康檢查間隔可依裝置與節點數量調整，行動裝置不宜高頻輪詢大量節點。若上游節點名稱重複，介面可能難以區分來源，可以在合併層使用用戶端支援的前綴功能，或讓不同 provider 進入獨立地區組，而不是直接混在同一個長清單中。

更新失敗與設定漂移

多重訂閱環境常見的問題，不是某次設定無法載入，而是執行一段時間後逐漸偏離預期。上游可能修改節點命名，導致篩選運算式失效；刪除某個地區後，策略組變成空組；新增同名節點後，手動選擇指向另一個來源。更新後應檢查 provider 狀態、策略組成員數量是否合理，以及關鍵業務規則是否仍指向存在的組。不要用虛構的固定節點數量作為監控條件，應關注「組是否為空」「引用是否存在」及「關鍵請求是否命中」。

跨裝置同步時，不建議直接同步用戶端的整個資料目錄。桌面端與行動端的權限、路徑、TUN 介面名稱及快取位置都不同。更適合同步的是訂閱入口、本地主設定範本、規則集與覆寫邏輯，裝置專屬項目則留在各自用戶端。WebDAV、訂閱分發與手動匯入的差異，可繼續閱讀Clash 多裝置設定同步方案。