跳至正文

· 規則進階 · 預計閱讀 12 分鐘

Clash 自訂規則設定教學：DOMAIN-SUFFIX、IP-CIDR 與 RULE-SET 的比對順序

整理常用規則類型的語法，說明規則由上而下比對、命中即停止的機制，以及自訂規則放在訂閱規則前後的差異。

規則比對順序：由上而下，命中即停止

替某個網站指定直連，連線卻仍走代理，常見原因不是選錯規則類型，而是前面的規則已先命中。Clash 的 rules 是有順序的清單。核心會從第一條開始檢查，遇到適用且符合的規則，就使用該規則指定的出口，不會繼續往下找「更精確」的規則。

這裡所說的核心，是實際處理連線並執行分流的程式。Clash Meta 後續以 mihomo 之名持續發展；用戶端則是管理訂閱、開關與連線記錄的介面。以下以 mihomo 常見的 YAML 設定為例。YAML 是以縮排表示階層的文字格式，請使用空格縮排，勿混用定位字元。

具體規則不會自動取得較高優先順序

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN,docs.example.com,DIRECT
  - MATCH,PROXY

造訪 docs.example.com 時，第一條後綴規則已符合，因此會使用 PROXY。第二條即使寫得更具體，也不會有執行機會。若要讓文件網站直連，請將第二條移到第一條之前。

本文中的 PROXY 是範例策略群組名稱，並非所有設定都內建的固定關鍵字。請替換成目前設定中實際存在的策略群組名稱，大小寫與空格也須一致。DIRECT 是內建直連策略，REJECT 是內建拒絕策略，可直接使用。

DOMAIN 與 DOMAIN-SUFFIX：網域精確比對與後綴比對

常見規則格式為「類型、比對內容、目標策略」，欄位之間以英文逗號分隔。網域規則只填主機名稱，不要加上 https://，也不要填路徑、查詢參數或結尾斜線。網址中的 /account 並非網域的一部分。

規則類型範例比對範圍
DOMAINDOMAIN,docs.example.com,DIRECT只比對該主機名稱，不包含其子網域。
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.com,PROXY比對 example.com 本身及其各層子網域。
DOMAIN-KEYWORDDOMAIN-KEYWORD,example,PROXY比對網域中含有 example 的連線，範圍比後綴規則更廣。

後綴規則依網域邊界比對

DOMAIN-SUFFIX,example.com,PROXY 可比對 example.com、api.example.com 和 a.b.example.com，但不會比對 notexample.com。不必寫成 *.example.com，也不要在比對內容前加點。

如果只想讓登入主機直連，建議使用 DOMAIN,login.example.com,DIRECT。若同一組織的所有子網域都需要使用相同出口，再使用 DOMAIN-SUFFIX。關鍵字規則適用於確實需要廣泛比對的情況，不宜用來取代所有網域後綴規則，否則可能連不相關的網站也一起分流。

IP-CIDR 與 no-resolve：依目標位址分流

IP-CIDR 用來比對 IPv4 目標位址範圍。CIDR 是「位址加上前綴長度」的表示法，例如 192.168.50.0/24 表示從 192.168.50.0 到 192.168.50.255 的位址範圍，並非只比對最後寫出的單一位址。單一 IPv4 位址可用 /32 表示。

rules:
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - IP-CIDR,10.20.30.40/32,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - MATCH,PROXY

上例中的 IP-CIDR6 用於 IPv6。這三個位址範圍僅示範寫法，請依實際區域網路範圍調整。尤其不要將過大的位址範圍直接加入直連清單，否則可能改變原本預期透過代理連線的流量。

no-resolve 不等於關閉 DNS

DNS 是將網域名稱解析為 IP 位址的過程。對於有網域名稱、但尚未取得目標 IP 的連線，IP 類規則可能會觸發解析，以判斷是否符合條件。在結尾加上 no-resolve，表示不要只為了檢查這條規則而主動解析網域；若連線本身已有可用的目標 IP，仍可進行比對。

因此，no-resolve 不會關閉整個用戶端的 DNS，也不會讓特定網域自動繞過代理。若要讓某個網站固定直連，通常應先設定網域規則；若要讓某段內網位址直連，再設定 IP 規則。網域取得方式、DNS 模式與嗅探設定都會影響核心實際掌握的資訊，排查時應查看連線詳細資料，而非只看瀏覽器網址列。

RULE-SET：引用規則集合，不會改變先後順序

RULE-SET 用來引用規則提供者（rule-provider）。提供者負責載入一組網域或位址；rules 中的引用則決定這些內容符合條件後要使用哪個策略。集合名稱、提供者類型與檔案內容必須彼此相符，不能只貼上一條引用，就期待集合自動出現。

本機網域集合範例

以下是供合併使用的設定片段，並非可獨立執行的完整訂閱。請先確認現有設定中已有名為 PROXY 的策略群組，再將提供者與規則合併至各自的頂層欄位。

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

rules:
  - DOMAIN,login.example.com,DIRECT
  - RULE-SET,work-domains,PROXY
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,PROXY

接著在核心使用的工作目錄下建立 rules/work-domains.yaml。相對路徑是以用戶端實際使用的核心工作目錄為準，不一定是安裝目錄。檔案內容可如下：

payload:
  - 'example.com'
  - '+.example.org'

在這種網域集合中，example.com 代表該網域，+.example.org 代表 example.org 及其子網域。由於提供者的 behavior 是 domain，這裡應填網域比對內容，不應寫成 DOMAIN-SUFFIX,example.org,PROXY。

domain、ipcidr 與 classical 的差異

遠端提供者還需要設定 URL、更新間隔等資訊。使用訂閱附帶的遠端集合時，請先確認載入成功，再檢查命中順序。檔案下載失敗、內容格式不符、集合名稱拼錯，與規則被前面的項目搶先命中，是不同的問題。

自訂規則要放在訂閱規則前面還是後面？

訂閱更新通常會重新產生設定。直接編輯下載的 YAML，可能在下次更新時被覆寫。較穩妥的做法是使用用戶端提供的持續性覆寫或規則合併功能。覆寫是指在訂閱原始設定之外儲存自訂修改，啟用後再合併成核心設定。

不同用戶端的選單名稱、合併方向與指令碼介面各不相同。不要只因為「已新增」就認定規則已生效。重點是確認最終生效設定中的位置：是加在前面、加在末尾，還是整份取代。若需要了解介面基本操作，可先參閱使用手冊。

建議順序：例外規則在前、集合居中、兜底規則置末

rules:
  # 自訂例外：優先處理
  - DOMAIN,docs.example.com,DIRECT
  - DOMAIN,blocked.example.net,REJECT

  # 既有訂閱規則：以下僅示範其位置
  - DOMAIN-SUFFIX,example.com,PROXY
  - RULE-SET,work-domains,PROXY
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve

  # 最後處理未命中前述規則的連線
  - MATCH,PROXY

MATCH 是兜底規則，不需要比對內容。所有執行到這裡的連線都會使用其目標策略。如果用戶端將自訂規則附加在既有的 MATCH 之後，這些規則就不會有機會執行。請將自訂規則加在前面，或插入最終兜底規則之前，而不是繼續重複新增相同項目。

規則未生效：依連線記錄逐項檢查

修改規則後，請先重新載入設定，再關閉目標應用程式的舊連線並重新送出請求。瀏覽器可能會沿用已建立的連線；規則變更後，舊連線通常不會自動切換到新的出口。測試時一次只調整一兩條規則，較容易比較結果。

  1. 確認目前使用的設定與模式。檢查目前啟用哪一份訂閱，以及運作模式是否為規則模式。編輯未啟用的設定，不會影響目前流量。
  2. 確認流量已進入核心。開啟用戶端的「連線」頁面，搜尋目標網域或目標 IP。若沒有記錄，請先檢查系統代理、應用程式本身的代理設定，以及 TUN 接管範圍。
  3. 查看命中的規則。在連線詳細資料中查找規則類型、規則內容與策略鏈。各用戶端的欄位名稱可能不同，重點是找出實際命中的規則。
  4. 核對最終設定的規則順序。若顯示命中較廣泛的後綴規則或集合，請將更精確的例外移到前面；若顯示命中 MATCH，請確認規則內容與提供者是否真的符合條件。
  5. 確認出口是否符合預期。命中 PROXY 只表示流量交由該策略群組處理。如果群組目前選擇的是 DIRECT，最終仍會直連。
  6. 更新一次訂閱後重新測試。確認自訂規則仍然保留，且位置沒有變動。這能找出「暫時編輯成功，更新後卻消失」的問題。

用三次請求驗證規則先後順序

以先前的網域範例為準：造訪 docs.example.com，預期會命中精確網域規則並直連；造訪 api.example.com，預期會命中後綴規則並使用 PROXY；造訪未被其他規則涵蓋的目標，預期會套用 MATCH。這些網域僅用來說明規則關係，實際測試時請改用可連線且用途已確認的網域。

同一個網頁可能會連線至登入、圖片、影片與 API 等多個主機。只為主網站設定規則，不代表所有資源都會使用相同出口。若網頁能開啟但圖片載入失敗，請先從連線記錄找出失敗資源的網域，再決定要新增精確規則，還是擴大後綴比對範圍。

常見規則問題

DOMAIN-SUFFIX 與 IP-CIDR 同時符合時，哪一條優先？

通常取決於它們在規則清單中的先後順序，沒有固定的「網域一定優先於 IP」原則。同時也要確認連線是否具備判斷所需的網域或 IP，以及 no-resolve 是否阻止該規則主動解析。將明確的網域例外放在前面，通常會比較容易理解與維護。

切換至 TUN 後，還需要自訂規則嗎？

視分流需求而定。TUN 是透過虛擬網路介面接管流量的方式，不會建立一套新的比對優先順序。流量進入核心後，規則模式仍會依規則順序選擇策略。若特定區域網路目標甚至無法建立連線，也應一併檢查路由、TUN 排除範圍與防火牆。

為什麼 REJECT 規則沒有封鎖網頁？

先確認該網域是否被更前面的規則放行，再確認網頁是否使用其他資源網域，或仍有既存連線。REJECT 只會影響實際命中該規則的連線，不會根據網頁標題辨識整個服務。修改後請重新建立連線，並以連線詳細資料中的命中記錄為準。

維護規則時，建議優先保留少量且目的明確的例外。每次修改都記錄「比對什麼、交由哪個策略處理、放在哪裡」，再透過連線記錄驗證。只要分開檢查流量接管、規則命中與策略群組出口，大多數「寫了規則卻沒有變化」的問題都能定位到具體環節。

下載Clash