規則分流 預計閱讀 13 分鐘

Clash 自訂規則怎麼寫：DOMAIN、IP-CIDR、GEOSITE 語法與比對順序

逐類解析 Clash 規則欄位的寫法與適用情境，說明規則依序由上而下比對，命中第一條即停止，以及 no-resolve、MATCH 備援與規則集順序如何影響分流結果。

先了解 Clash 規則的執行方式

Clash、Clash Meta 與後續的 mihomo 核心都會將連線資訊交由規則模組處理。規則模組會讀取目標網域、目標 IP、連接埠、網路類型與程序等資訊，再決定使用代理群組、特定節點、DIRECT 或 REJECT。關鍵不在規則數量，而在排列順序。

規則會由上而下逐條檢查。第一條符合條件的規則一旦命中，後續規則就不再參與目前連線的判斷。因此，範圍較窄、意圖明確的規則通常放在前面，範圍較大的規則放在後面，最後再用 MATCH 接住未命中的連線。

rules:
  - DOMAIN,api.example.com,開發介面
  - DOMAIN-SUFFIX,example.com,境外網站
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,預設代理

在這段設定中，存取 api.example.com 會先命中第一條，使用「開發介面」策略群組。即使它也符合第二條的 DOMAIN-SUFFIX,example.com，第二條仍不會繼續執行。存取 www.example.com 則會跳過第一條，在第二條完成比對。

一條規則通常包含哪些欄位

常見規則以逗號分隔，基本結構是「規則類型、比對內容、策略」。部分規則可在結尾加入參數，例如 no-resolve。

規則類型,比對內容,策略
IP-CIDR,203.0.113.0/24,節點選擇,no-resolve

策略名稱區分字元，規則中的名稱必須與 proxy-groups 中的 name 完全一致。設定中定義的是「節點選擇」，規則卻寫成「節點選擇 」或「代理選擇」，都可能導致設定載入失敗或找不到策略。

DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD 怎麼選

網域規則最適合處理網站與 API 分流。它直接利用連線中的主機名稱判斷，不依賴目標伺服器目前解析到哪個 IP。面對使用 CDN、頻繁更換位址或同時分布在多個網段的服務，網域規則通常比固定 IP 更穩定。

DOMAIN：只比對單一完整網域

rules:
  - DOMAIN,login.example.com,登入服務
  - DOMAIN,cdn.example.net,靜態資源

DOMAIN 要求目標網域完全相同。第一條會比對 login.example.com，但不會比對 www.example.com、api.login.example.com 或根網域 example.com。它適合單一介面、登入網域、下載網域等界線明確的目標。

DOMAIN-SUFFIX：比對根網域及其子網域

rules:
  - DOMAIN-SUFFIX,example.com,境外網站
  - DOMAIN-SUFFIX,example.org,DIRECT

DOMAIN-SUFFIX,example.com 會涵蓋 example.com、www.example.com 與 a.b.example.com。撰寫規則時不需要在前面加上星號，也不應寫成 *.example.com。如果網站的網頁、圖片與 API 都位於同一主網域的不同子網域，使用 DOMAIN-SUFFIX 會更簡潔。

DOMAIN-KEYWORD：依網域中的字串比對

rules:
  - DOMAIN-KEYWORD,example,測試策略

這條規則會比對網域中包含 example 的連線，不要求它位於網域結尾。除了 example.com，example-cdn.net 和 notexample.org 也可能命中。它的涵蓋範圍較大，容易納入無關網域，應放在精確規則之後，並盡量使用足夠獨特的關鍵字。

規則 適用情境 主要界線
DOMAIN 單一 API、登入或下載網域 不包含其他子網域
DOMAIN-SUFFIX 整個主網域及所有子網域 可能涵蓋同一網域下用途不同的服務
DOMAIN-KEYWORD 網域結構變動但關鍵字穩定 誤比對機率較高

IP-CIDR、IP-CIDR6 與 no-resolve 的作用

IP-CIDR 依 IPv4 位址或網段比對，IP-CIDR6 用於 IPv6。CIDR 後綴表示網路前綴長度，例如 /32 是單一 IPv4 位址，/24 通常涵蓋連續 256 個 IPv4 位址；IPv6 的 /128 表示單一位址。

rules:
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,203.0.113.8/32,專用節點,no-resolve
  - IP-CIDR6,2001:db8::/32,專用節點,no-resolve

前兩條常用於私有網路直連。第三條只比對單一 IPv4 位址。範例中的 203.0.113.0/24 與 2001:db8::/32 屬於文件範例位址，不應直接當作真實服務網段使用。

no-resolve 不是「不使用 DNS」

當連線只有網域資訊時，IP 規則需要目標 IP 才能判斷。沒有 no-resolve 時，核心可能為了規則比對而觸發一次網域解析。加入 no-resolve 後，該 IP 規則不會僅為判斷規則而主動將網域解析為 IP；如果連線本身已提供目標 IP，規則仍可正常比對。

- DOMAIN-SUFFIX,example.com,境外網站
- IP-CIDR,203.0.113.0/24,專用節點,no-resolve
- GEOIP,CN,DIRECT,no-resolve
- MATCH,預設代理

這種排列會先利用既有網域進行判斷，再檢查已知 IP，最後使用備援規則。它可以減少規則階段額外解析造成的延遲與 DNS 依賴。請注意，no-resolve 不會關閉 Clash 的 DNS 模組，也不會改變應用程式自身發出的 DNS 要求。

GEOIP 與固定網段的差異

GEOIP,CN,DIRECT 會使用 GeoIP 資料庫判斷目標 IP 所屬地區。它適合進行大範圍地區分流，但資料庫分類不等同於服務歸屬：境外品牌可能使用中國大陸 CDN，中國服務也可能連線到境外節點。因此，重要服務宜先寫 DOMAIN 或 DOMAIN-SUFFIX，將 GEOIP 放在後面進行較寬泛的地區判斷。

GEOSITE、GEOIP 與規則集如何搭配

mihomo 支援 GEOSITE 規則。GEOSITE 資料會依類別整理網域，例如地區、服務或用途分類。它能減少手動撰寫大量 DOMAIN-SUFFIX 的工作，但實際可用分類取決於用戶端隨附或下載的 geosite 資料檔。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,節點選擇

上述順序會先處理廣告類別，再處理私有網域與中國大陸網域，接著處理已取得 IP 的私有位址及中國大陸位址。未命中的連線交給「節點選擇」。如果把 GEOSITE,cn,DIRECT 放在自訂代理網域之前，只要該網域被 cn 分類收錄，就會提前直連。

規則集透過 RULE-SET 插入執行佇列

rule-providers 負責定義規則集來源、格式、更新週期與本機儲存位置，RULE-SET 決定該規則集在主要規則佇列中的位置。宣告 provider 並不代表規則會自動執行，仍需在 rules 中引用。

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

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

rules:
  - DOMAIN,api.example.com,專用節點
  - RULE-SET,service-rules,節點選擇
  - RULE-SET,direct-sites,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,節點選擇

interval: 86400 表示每 86400 秒，也就是 24 小時檢查一次更新。behavior: domain 的內容應是網域類項目；behavior: ipcidr 用於網段；behavior: classical 可承載包含類型的傳統規則。provider 的實際格式必須與檔案內容一致。

payload:
  - example.com
  - api.example.net
  - +.service.example.org

這是 domain 行為規則集常見的 YAML 結構。若使用 classical 行為，項目通常會包含規則類型，例如 DOMAIN-SUFFIX,example.com 或 IP-CIDR,203.0.113.0/24,no-resolve。策略不會寫在 provider 的每個項目中，而是由主要設定中的 RULE-SET,規則集名稱,策略 統一指定。

MATCH 備援與常見順序錯誤

MATCH 不包含比對內容，所有到達它的連線都會命中，因此通常只能放在規則列表最後。它決定未分類流量的預設去向。常見選擇是可手動切換的代理群組，而不是固定節點，這樣節點無法使用時更容易調整。

proxy-groups:
  - name: 節點選擇
    type: select
    proxies:
      - 自動選擇
      - DIRECT

rules:
  - DOMAIN-SUFFIX,intranet.example,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,節點選擇

錯誤一：MATCH 放得太早

rules:
  - MATCH,節點選擇
  - DOMAIN-SUFFIX,intranet.example,DIRECT

第二條永遠沒有執行機會。所有連線在第一條就完成比對。設定可能仍能載入，但分流結果會呈現「全部使用同一個策略」。

錯誤二：寬泛後綴覆蓋精確例外

rules:
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN,video.example.com,媒體節點

video.example.com 同時符合兩條規則，卻會先被第一條接手。正確做法是將精確例外移到前面：

rules:
  - DOMAIN,video.example.com,媒體節點
  - DOMAIN-SUFFIX,example.com,DIRECT

錯誤三：策略名稱與代理群組不一致

規則中的「節點選擇」必須已在 proxy-groups 中定義。如果代理群組的實際名稱是「代理選擇」，載入設定時通常會出現找不到策略之類的錯誤。中文名稱、空格與大小寫都應逐字核對。

錯誤四：把連接埠當成服務識別

DST-PORT,443,節點選擇 會涵蓋所有目標連接埠為 443 的連線，不只是一個網站。現代 HTTPS、應用程式 API 與部分加密 DNS 服務都會使用 443。連接埠規則適合明確的通訊協定界線，不適合取代網域規則。

rules:
  - DST-PORT,22,開發網路
  - NETWORK,udp,UDP 策略
  - MATCH,節點選擇

即使是連接埠 22，也可能用於非 SSH 服務；反過來，SSH 也可以執行在其他連接埠。涉及工作網路時，應結合目標網域、目標網段與連接埠，而不是只看單一欄位。

一套便於維護的規則排序範本

實際設定沒有唯一順序，但可以依「本機例外、精確服務、批次網域、IP 與地區、預設策略」組織。以下範本適用於常見桌面使用情境，名稱需替換為設定中已有的代理群組。

rules:
  # 1. 本機網路與明確例外
  - DOMAIN,router.lan,DIRECT
  - DOMAIN-SUFFIX,home.arpa,DIRECT
  - 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

  # 2. 單一服務的精確策略
  - DOMAIN,api.example.com,專用節點
  - DOMAIN-SUFFIX,example.net,媒體節點

  # 3. 外部規則集
  - RULE-SET,work-services,工作網路
  - RULE-SET,streaming-services,媒體節點
  - RULE-SET,direct-sites,DIRECT

  # 4. 大範圍網域與地區判斷
  - GEOSITE,private,DIRECT
  - GEOSITE,cn,DIRECT
  - GEOIP,private,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve

  # 5. 最終備援
  - MATCH,節點選擇

私有 IPv4 網段包括 10.0.0.0/8、172.16.0.0/12 與 192.168.0.0/16。回送位址 127.0.0.0/8 通常也應直連。是否需要明確寫入這些規則，取決於設定既有的私有網路規則集與用戶端設定，重複規則不會增加比對能力。

控制規則數量與更新範圍

修改設定後如何驗證規則是否生效

修改 YAML 後，第一步是確認設定能夠重新載入。桌面用戶端通常提供設定編輯與重新載入入口。例如在設定管理頁面開啟目前設定，編輯檔案並儲存，再執行「重新載入」或切換至該設定。不同用戶端的選單名稱可能不同，不應只儲存檔案而跳過重新載入。

如果使用 mihomo 的外部控制器，常見監聽位址是 127.0.0.1:9090；HTTP 與 SOCKS 混合連接埠常見為 7890，DNS 監聽連接埠常見為 1053。這些數字只是常用預設值，應以目前設定中的 external-controller、mixed-port 與 dns.listen 為準。

分四步檢查命中結果

  1. 重新載入設定：確認用戶端沒有 YAML 縮排、未知規則類型或策略不存在等錯誤。
  2. 清除舊連線：關閉目標應用程式的現有連線，必要時退出後重新開啟。已建立的長連線不會因新增規則而自動重新分流。
  3. 發起單一測試：只存取一個目標網域，減少背景同步、更新與推播連線的干擾。
  4. 查看連線詳細資料：在用戶端的「連線」頁面檢查 Host、目標 IP、命中規則與使用的代理鏈。

假設新增了 DOMAIN,api.example.com,專用節點，但連線詳細資料顯示命中 DOMAIN-SUFFIX,example.com，應先檢查精確規則是否確實位於後綴規則之前。如果顯示的是 IP-CIDR，可能是應用程式直接連線 IP，或網域資訊沒有傳遞給核心。

TUN 模式下仍遵循相同的規則順序

TUN 模式改變的是流量進入核心的方式，不會將規則改為平行比對。系統代理通常只涵蓋遵循代理設定的應用程式，TUN 模式則可接管更多 TCP、UDP，以及不讀取系統代理設定的程式。流量進入核心後，仍會從第一條規則開始向下檢查。

啟用 Fake-IP DNS 增強模式時，應用程式可能先取得保留位址，核心會利用對應關係還原網域並參與規則判斷。因此在連線頁面看到 Fake-IP，不代表 DOMAIN 規則失效。若某個應用程式只連線至硬編碼 IP，仍應使用 IP-CIDR、GEOIP 或程序規則處理。

規則未生效時的排查順序

規則問題適合從設定載入、流量入口、連線資訊與規則位置四個層面排查。先確認核心採用了新設定，再判斷目標流量是否進入 Clash，最後檢查規則本身。直接反覆調整語法，往往會掩蓋系統代理未啟用或設定未重新載入的問題。

設定能否載入

目標流量是否進入核心

在系統代理模式下，應用程式可能忽略系統代理設定；在 TUN 模式下，也可能存在路由排除、介面衝突或權限問題。連線列表完全看不到目標應用程式時，應先檢查入口，而不是繼續修改規則。瀏覽器既有連線也可能透過連線重用繼續運作，關閉分頁未必會立即中斷底層連線。

核心取得的是網域還是 IP

DOMAIN 類規則需要網域資訊。若應用程式直接存取 IP，規則只能依靠 IP-CIDR、GEOIP、連接埠、網路類型或程序資訊。反過來，為 IP-CIDR 加上 no-resolve 後，如果目前連線只有網域，該條規則會跳過，而不是主動解析後再進行比對。

前面是否已有更寬泛的規則

依序查看目標規則上方是否有 DOMAIN-SUFFIX、DOMAIN-KEYWORD、RULE-SET、GEOSITE、GEOIP 與 MATCH。任何一條先命中，目標規則都不會執行。排查時可以暫時將精確規則移到規則列表最前面；確認成功後，再放回結構合理的位置。

撰寫規則時可直接遵循的結論

一套可維護的規則不依賴大量項目，而是讓每條規則的界線與位置都能清楚解釋。先寫精確例外，再放批次規則集，最後進行地區判斷與 MATCH 備援，出現偏差時就能沿著執行順序快速定位。

下載 Clash 用戶端 查看 Windows、macOS 與行動裝置版本