規則分流 預計閱讀 12 分鐘

Clash 自訂規則

整理 DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP、PROCESS-NAME 等規則類型，說明由上而下的比對順序、no-resolve 參數與 rule-providers 的搭配方式。

規則生效的三個前提

Clash 規則負責為連線選擇出口策略，不負責建立代理節點。設定中的節點、策略群組與規則各司其職：節點提供出口，策略群組整理可選出口，rules 則決定連線要交由哪個出口處理。排查時先釐清這三個層次，避免把節點無法使用誤判為規則未命中。

  1. 連線已進入核心。系統代理通常只會影響遵循代理設定的程式；遊戲、部分命令列工具與 UDP 流量可能沒有經過代理。TUN 可以擴大接管範圍，但仍須檢查路由、排除項目與權限。
  2. 目前模式為規則模式。設定中對應 mode: rule。全域模式與直連模式不會依照這裡的規則清單進行一般分流。
  3. 修改的是實際執行中的設定。用戶端的訂閱原文、覆寫設定與核心最終使用的設定可能不同。儲存後應檢查設定驗證結果，再重新載入。

規則語法與常見類型

多數規則採用 類型,比對內容,策略 的格式。逗號請使用英文半形字元；規則以 YAML 清單項目的形式放在 rules: 底下，每一項前方加上連字號。內建策略 DIRECT 代表直連，REJECT 代表拒絕；其他策略名稱必須與已定義的節點或策略群組名稱完全相同。

規則類型範例比對範圍
DOMAINDOMAIN,api.example.com,DIRECT只比對這個網域，不包含其子網域。
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.com,DIRECT比對根網域及其子網域，但不包含 otherexample.com。
DOMAIN-KEYWORDDOMAIN-KEYWORD,example,DIRECT比對網域中出現的字串，涵蓋範圍比後綴規則更廣。
IP-CIDRIP-CIDR,192.168.0.0/16,DIRECT,no-resolve比對 IPv4 目標網段，範例涵蓋 192.168.0.0 至 192.168.255.255。
IP-CIDR6IP-CIDR6,fc00::/7,DIRECT,no-resolve比對 IPv6 網段，範例為唯一本機位址範圍。
GEOIPGEOIP,CN,DIRECT,no-resolve依據本機 IP 地理資料庫比對位址，準確度取決於資料庫。
PROCESS-NAMEPROCESS-NAME,curl.exe,DIRECT比對核心識別到的程序名稱，結果會受作業系統與權限影響。
MATCHMATCH,出口接住前面都未命中的連線，不必填寫比對內容。

網域規則不填寫通訊協定、連接埠或路徑

要為 https://api.example.com:443/v1/status 分流時，網域規則只需填入 api.example.com。將整個 URL 填進 DOMAIN，不會依網頁網址進行比對。若要依目標連接埠區分，可以使用核心支援的 DST-PORT；但單獨一條 DST-PORT,443,出口 會涵蓋排在該位置之後、所有經過 443 連接埠的連線，並非只比對某個網站。

文中的 example.com 是保留用的示範網域，用來說明語法。正式設定時，請替換成實際需要分流的網域，不要預期範例項目會改變常用網站的連線路徑。

比對順序與例外規則

一般規則會依清單順序由上而下檢查，第一條成功命中的規則就會決定策略，之後不再繼續比對。核心不會自動挑選「更精確」的規則，也不會因為後面還有拒絕規則就重新計算結果。因此，例外通常要放在通用規則之前，MATCH 則放在最後。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN,ads.example.com,REJECT
  - DOMAIN-SUFFIX,example.com,出口
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,出口
  • api.example.com 命中第一條規則，採用直連。
  • ads.example.com 命中第二條規則，連線遭到拒絕。
  • www.example.com 命中第三條規則，交由「出口」策略群組處理。
  • 已知目標位址為 192.168.1.20，且未命中前面的網域規則時，連線會命中區域網路項目。
  • 其餘連線交由最後的 MATCH 處理。

如果把第三條後綴規則移到第一條，api.example.com 和 ads.example.com 都會先命中這條規則。後面的直連與拒絕項目即使語法完全正確，也不會有機會執行。

程序規則同樣遵循比對順序

將 PROCESS-NAME,curl.exe,DIRECT 放在清單最前面，代表這個程序的連線可能在檢查網站規則之前就被直連。若只想為特定網域設定例外，建議優先使用網域規則；若確實要讓整個程式固定使用某條路線，再使用程序規則。Windows 常見的程序名稱會帶有 .exe，Linux 與 macOS 常見名稱則不含此副檔名，請以連線詳細資訊中實際識別到的程序名稱為準。

no-resolve 的確切用途

no-resolve 的作用是：檢查這條 IP 類規則時，不會主動為只有網域資訊的連線額外進行一次網域解析。它不會停用 DNS，也不代表連線最終不會解析網域。網域解析仍可能由用戶端 DNS、其他規則，或實際建立出口連線的過程觸發。

rules:
  - DOMAIN-SUFFIX,example.com,出口
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,出口

假設某個連線只有網域資訊，而且沒有命中第一條規則。檢查後續 IP 規則時，no-resolve 會避免為了比對這些規則而額外解析。如果連線已經有可用的目標 IP，IP 類規則仍可據此比對。是否具備實際目標 IP，與 DNS 模式、連線入口及中繼資料有關；不能只看網域實際解析出的結果，就推斷一定會命中。

兩種常見的取捨

  • 優先採用網域分流：將主要網域規則放在前面，並為 IP 規則加上 no-resolve，減少規則比對時額外觸發的解析。缺點是部分只有網域資訊的連線可能會直接落入兜底規則。
  • 希望依解析出的位址分類：特定 IP 規則不加 no-resolve，允許比對時進行解析。但這會依賴 DNS 回應及解析所需時間，也應一併檢查 DNS 設定。

GEOIP,CN 判斷的是資料庫中的 IP 歸屬地，不是網站的經營主體，也不等同於「所有中國大陸網站」。使用 CDN 的網站可能因解析位址不同而得到不同結果；若要穩定控制服務的路由，使用明確的網域規則會更合適。

使用 rule-providers 重複利用規則

多份設定需要共用相同的網域與網段時，可以將比對條件移到規則提供器，再透過 RULE-SET 引用。提供器負責載入規則內容；實際優先順序則由 RULE-SET 在主 rules 清單中的位置決定，而非提供器的宣告位置。

主設定：本機 classical 規則集

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

rules:
  - DOMAIN,api.example.com,出口
  - RULE-SET,local-direct,DIRECT
  - MATCH,出口

規則集檔案：rules/local-direct.yaml

payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,192.168.0.0/16,no-resolve
  - IP-CIDR6,fc00::/7,no-resolve

規則集中的項目不填寫 DIRECT 或策略群組名稱，目標策略由主設定中的 RULE-SET,local-direct,DIRECT 統一指定。此範例中，api.example.com 仍會先命中主清單的第一條規則；同一根網域下的其他子網域才會進入規則集並直連。

path 通常會以核心的工作目錄為基準解析，不一定是下載的訂閱檔案所在目錄。請確認用戶端允許存放規則檔案的位置，並先建立檔案；檔案不存在、目錄無法存取或內容格式錯誤，都可能導致提供器載入失敗。

behavior內容格式適用情境
classical帶有類型的規則，例如 DOMAIN-SUFFIX,example.com同一個集合需要包含網域、IP 等多種條件。
domain依照核心的網域規則集語法填寫網域項目專門維護網域集合，不使用 classical 的類型前綴。
ipcidr填寫 192.168.0.0/16 等位址範圍專門維護 IPv4、IPv6 網段集合。

三種格式不能只修改 behavior 就混用。若改用 HTTP 提供器，還需要可信的實際規則網址與更新週期；遠端規則會改變分流結果，請檢查來源與更新內容，不要把未知集合放在所有自訂例外之前。

可驗證的最小設定

以下設定用來驗證 mihomo 的語法與命中順序，不包含代理節點；「出口」群組中只有 DIRECT，因此除了拒絕項目之外，實際流量仍會直連。確認規則行為後，再將現有節點或節點提供器加入策略群組。

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

proxy-groups:
  - name: 出口
    type: select
    proxies:
      - DIRECT

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN,ads.example.com,REJECT
  - DOMAIN-SUFFIX,example.com,出口
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,::1/128,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - MATCH,出口

這裡明確使用 7890 連接埠，方便透過命令列測試；如果已被其他程序占用，請改用未占用的連接埠，並同步修改測試命令。allow-lan: false 代表不向區域網路開放代理入口。實際用戶端可能會覆寫監聽連接埠，請以執行中的設定與監聽狀態為準。

先驗證設定，再驗證請求

mihomo -t -f ./config.yaml
curl -I --proxy http://127.0.0.1:7890 https://example.com

第一條命令要求本機可執行檔名稱為 mihomo，且目前目錄中有 config.yaml。使用圖形介面用戶端時，可改用用戶端提供的設定檢查功能。第二條命令會明確透過 HTTP 代理送出請求，避免命令列是否沿用系統代理設定這個變因；在 Windows PowerShell 中，可使用 curl.exe 呼叫對應程式。

範例請求應命中 DOMAIN-SUFFIX,example.com,出口。請以連線詳細資訊或記錄中的規則類型、比對內容及策略鏈作為驗證依據，而非網頁開啟速度或單看出口 IP。不同規則可能指向相同策略，因此出口相同並不能證明命中的是同一條規則。

規則未生效時的排查順序

  1. 確認連線是否出現。如果用戶端的連線清單中看不到目標請求，請先檢查代理入口、TUN 路由與應用程式設定。請求根本沒有進入核心時，調整規則順序也無法解決問題。
  2. 確認實際使用的規則模式。確認目前不是全域模式或直連模式，並檢查實際啟用的是哪份設定，而不只是查看編輯器中的檔名。
  3. 確認第一條命中的規則。如果連線命中涵蓋範圍較廣的後綴、關鍵字或程序規則，請將必要的例外移到它之前。不要在 MATCH 後面追加需要生效的規則。
  4. 確認策略名稱。「出口」與「代理出口」是兩個不同的名稱。引用未定義的策略通常會導致設定驗證失敗，請先修正載入錯誤。
  5. 確認網域與程序中繼資料。連線只有 IP 時，網域規則未必有可用的比對對象；程序名稱為空時，程序規則也無法如預期運作。TUN 不會自動補齊所有連線的網域與程序資訊。
  6. 確認提供器狀態。確認檔案存在、格式與 behavior 相符，且用戶端已成功載入規則集。修改本機檔案後，請依用戶端要求更新提供器或重新載入設定。
  7. 重新建立測試連線。更新設定後，已建立的長連線可能仍沿用原本的出口。請停止原有請求，再建立新連線；必要時先關閉相關連線再測試。

整理規則時可採用固定順序：明確的拒絕與直連例外放在最前面，接著是服務網域集合，再依實際優先順序安排程序與 IP 類規則，最後保留清楚的 MATCH。每次只修改一類條件，再透過新連線確認命中結果，比同時調整 DNS、TUN 和整套規則更容易找出原因。

下載 Clash 用戶端