規則分流 預計閱讀 14 分鐘

自訂規則怎麼寫：DOMAIN、IP-CIDR 等語法與比對優先順序詳解

逐條解析常用規則類型的語法與適用情境，重點說明規則由上而下的比對順序、no-resolve 參數用途，以及規則設定後未生效時的排查方法。

先看懂一條 Clash 規則的組成

Clash 與 mihomo 的基礎規則通常以逗號分隔，最常見的結構是「規則類型、比對內容、目標策略」。例如 DOMAIN-SUFFIX,github.com,PROXY 表示目標網域以 github.com 結尾時，將連線交由名為 PROXY 的策略群組處理。策略名稱區分大小寫，必須與 proxy-groups 中的名稱完全一致。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,github.com,PROXY
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,FINAL

這裡的 DIRECT、REJECT 是內建動作，PROXY 和 FINAL 則可以是使用者自訂的策略群組。規則不必直接指定某一台伺服器才有效；更常見的做法是讓規則指向策略群組，再由策略群組透過手動選擇、延遲測試或故障切換決定實際節點。

YAML 縮排與規則位置

rules 是設定檔的頂層欄位，清單項目前通常使用兩個空格縮排。不要使用 Tab 字元，也不要把規則寫進 proxy-groups 或 rule-providers 內部。修改後必須讓用戶端重新載入設定；只儲存檔案而未重新載入時，執行中的核心仍可能使用舊內容。

以常見的桌面用戶端為例，先在設定頁面開啟目前啟用的設定，完成編輯後執行「儲存」或「重新載入」。接著進入「連線」頁面存取目標網域，查看該連線顯示的規則類型與策略鏈。不同用戶端的選單名稱略有差異，但驗證重點相同：確認目前的設定檔、核心執行狀態與連線日誌三者一致。

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

DOMAIN：只比對完整網域

DOMAIN 適合單一主機名稱。以下規則只會比對 api.example.com，不會比對 www.example.com，也不會自動涵蓋 v2.api.example.com。

rules:
  - DOMAIN,api.example.com,PROXY

需要為登入介面、更新伺服器或某個固定 API 個別指定策略時，優先使用 DOMAIN。它的範圍明確，不容易誤傷同一主網域下的其他服務。

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

DOMAIN-SUFFIX,example.com,PROXY 通常會比對 example.com、www.example.com 和 a.b.example.com。這是自訂網域分流中最常使用的類型，適合網站的多個子網域需要採用相同策略的情況。

rules:
  - DOMAIN-SUFFIX,example.com,PROXY
  - DOMAIN-SUFFIX,example.net,DIRECT

後綴內容應填寫網域本身，不要附加 https://、路徑、連接埠或萬用字元。正確內容是 example.com，不是 https://example.com/path，也不是 *.example.com。Clash 比對的是連線目標，不會解析網頁 URL 的完整路徑。

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

DOMAIN-KEYWORD 會檢查網域是否包含指定字串。例如 DOMAIN-KEYWORD,google,PROXY 可以比對多個含有 google 的網域。寫法簡短，但範圍比後綴規則更廣，可能同時命中與目標服務無關的網域。

規則類型 範例目標 是否命中 適用情境
DOMAIN,api.example.com api.example.com 是 固定介面或單一主機
DOMAIN,api.example.com v2.api.example.com 否 不向下涵蓋子網域
DOMAIN-SUFFIX,example.com img.example.com 是 整個網站及子網域統一分流
DOMAIN-KEYWORD,example example-cdn.net 是 網域分散且具有穩定關鍵字

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

CIDR 表示一段位址範圍

IP-CIDR 用於比對 IPv4 位址或網段。192.168.1.0/24 涵蓋從 192.168.1.0 到 192.168.1.255 的位址；1.1.1.1/32 只比對單一 IPv4 位址。IPv6 使用 IP-CIDR6，例如 2001:db8::/32。

rules:
  - 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,fc00::/7,DIRECT,no-resolve

這些規則常用於本機回送、家庭區域網路與企業內網直連。若電腦透過 HTTP 或 mixed 連接埠與同網段裝置共用代理，內網規則通常應放在大範圍代理規則之前，避免存取路由器管理頁面、NAS 或印表機時繞行代理節點。

no-resolve 不是「停用 DNS」

當連線目標仍是網域時，核心為了判斷某條 IP 類規則是否命中，可能需要先取得該網域對應的 IP。將 no-resolve 加在 IP-CIDR 或 GEOIP 規則末尾，表示不要只為了比對這條規則而主動觸發網域解析。如果目前連線目標本來就是 IP，規則仍可正常比對。

rules:
  - DOMAIN-SUFFIX,internal.example,DIRECT
  - IP-CIDR,10.20.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

在這組規則中，internal.example 先由網域規則決定；目標直接寫成 10.20.3.8 時，則由 IP-CIDR 規則決定。no-resolve 不會關閉設定中的 DNS 模組，也不會阻止應用程式自行發起 DNS 查詢，更不會把網域規則變成 IP 規則。

IP 規則為什麼可能不穩定

大型網站常使用 CDN，同一個網域在不同網路、時間與 DNS 伺服器下可能取得不同 IP。把某次暫時解析結果寫成 /32 規則，短期內可能命中，位址變更後就會失效。能用穩定網域描述的服務，優先使用網域規則；只有目標本身是固定位址、內網網段，或確實需要依位址地區判斷時，才使用 IP 規則。

規則優先順序：不是類型優先，而是由上而下首次命中

Clash 規則的核心原則是依序比對。連線從 rules 清單的第一項開始檢查，命中某一條後立即採用該條指定的策略，不再繼續檢查後續規則。不存在「DOMAIN 天生優先於 IP-CIDR」或「REJECT 自動優先於 DIRECT」這類固定的類型優先順序。

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

存取 download.example.com 時，第一條規則已經命中，因此結果是 DIRECT。存取 www.example.com 時，第一條不符合，第二條命中，結果是 PROXY。如果交換兩條規則的位置，下載網域會先被後綴規則攔截，原本精確的直連規則就沒有執行機會。

建議採用的排列順序

  1. 本機、區域網路與明確要求直連的固定目標。
  2. 需要優先於通用規則的精確 DOMAIN、DOMAIN-SUFFIX 或 IP-CIDR。
  3. 廣告攔截、服務分類、GEOSITE 或外部規則集。
  4. 地區類 GEOIP 規則及其他大範圍判斷。
  5. 最後使用 MATCH 接住先前未命中的連線。

這不是核心強制的格式，而是一種便於維護的組織方式。原則是「範圍越具體、例外優先順序越高，就越靠前」。如果某條例外規則需要覆蓋訂閱提供的大型規則集，就必須放在對應的 RULE-SET 之前。

MATCH 應放在末尾

MATCH 不帶比對內容，會接住所有尚未命中的連線。經典設定中也可能看到 FINAL 作為末尾規則類型；目前 mihomo 設定普遍使用 MATCH。無論使用哪一種，只要放在清單中間，後續規則就不會再有執行機會。

rules:
  - DOMAIN-SUFFIX,example.org,DIRECT
  - RULE-SET,private,DIRECT
  - RULE-SET,streaming,MEDIA
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

GEOIP、GEOSITE 與 RULE-SET 的界線

GEOIP 依目標 IP 的地區歸屬判斷

GEOIP,CN,DIRECT 的判斷對象是目標 IP，不是網域註冊地、伺服器營運公司或網頁語言。資料庫內容會影響結果，因此用戶端核心與地理資料庫都必須保持可用。CDN 邊緣節點、Anycast 位址與資料庫更新延遲，都可能造成與直覺不同的分類。

如果設定使用 Fake-IP DNS 模式，網域連線仍可保留網域資訊供規則系統判斷；具體解析與映射由核心處理。不要因為連線清單中出現 198.18.0.0/16 範圍的 Fake-IP，就把整個位址段寫成代理規則。這個保留網段是供 Fake-IP 映射使用，並不代表網站真實伺服器的位址。

GEOSITE 依網域分類

mihomo 支援 GEOSITE 規則，依地理資料檔中的網域分類進行比對。例如 GEOSITE,cn,DIRECT 使用的是網域集合，而 GEOIP,CN,DIRECT 使用的是 IP 地區資料。兩者名稱相似，但判斷階段與資料來源不同。

rules:
  - GEOSITE,category-ads-all,REJECT
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve
  - MATCH,PROXY

GEOSITE 分類名稱取決於目前使用的資料集，並非每個舊版 Clash 核心都支援。將設定在不同用戶端之間搬移時，應先確認核心類型與規則支援狀況。可在用戶端「設定」中的核心資訊頁查看實際執行的核心，也可以在命令列執行 mihomo -v 檢查版本輸出。

RULE-SET 引用規則提供者

RULE-SET 不是直接填寫網域，而是引用 rule-providers 中定義的規則集合。以下的 private 必須與提供者的鍵名一致。提供者的 behavior 可能是 domain、ipcidr 或 classical，檔案內容必須符合對應的行為類型。

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

rules:
  - RULE-SET,private,DIRECT
  - MATCH,PROXY

interval: 86400 表示每 86400 秒檢查一次更新，也就是 24 小時。規則提供者下載失敗時，先檢查 URL 是否可存取、檔案格式是否符合 behavior，再確認用戶端是否允許寫入 ./ruleset/。只把遠端網址貼進 rules 並不會自動變成規則集。

連接埠、程序與網路入口規則

DST-PORT 與 SRC-PORT

DST-PORT 依目標連接埠比對，例如 DST-PORT,443,PROXY 會涵蓋大量 HTTPS 與其他使用 443 連接埠的連線，範圍通常很廣。SRC-PORT 依本機來源連接埠判斷，但應用程式的暫時來源連接埠經常變動，因此較少作為長期分流依據。

rules:
  - DST-PORT,22,DIRECT
  - DST-PORT,853,PROXY
  - MATCH,FINAL

連接埠規則中的連接埠是目標服務的連接埠，不是 Clash 的監聽連接埠。設定中的 mixed-port: 7890 表示本機代理入口監聽於 7890；它與存取網站時的目標連接埠 80 或 443 是不同概念。不要使用 DST-PORT,7890 試圖比對所有經過 mixed-port 的流量。

PROCESS-NAME 的支援取決於平台與接管方式

mihomo 可在部分桌面平台依程序名稱或程序路徑分流，例如 PROCESS-NAME,curl,DIRECT。程序規則依賴作業系統提供的連線與程序資訊，在 Android、iOS、容器或權限受限的環境中可能無法使用。不同系統的可執行檔名稱也不相同，Windows 常見名稱可能帶有 .exe，搬移設定時需要重新核對。

rules:
  - PROCESS-NAME,curl,DIRECT
  - PROCESS-NAME,backup-client.exe,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - MATCH,FINAL

系統代理模式主要接收遵循 HTTP 或 SOCKS 代理設定的應用程式流量；TUN 模式則透過虛擬網路介面接管更廣泛的 IP 流量。兩種模式下的規則順序不變，但核心能看到的目標資訊可能不同。排查程序規則前，先確認該連線確實進入 Clash，並檢查連線詳細資料中是否顯示程序名稱。

規則設定後未生效：依這個順序排查

第一步：確認編輯的是目前啟用的設定

用戶端可能同時儲存訂閱設定、本機設定與覆寫設定。先查看目前啟用項目的名稱與更新時間，再確認規則最終寫入執行中的設定。有些用戶端更新訂閱時會替換原設定，自訂內容應放入用戶端支援的覆寫、合併設定或獨立本機設定中。

第二步：從連線日誌讀取實際命中項目

開啟用戶端的「連線」或「日誌」頁面，再重新發起一次請求。瀏覽器可能重複使用既有的 TCP、QUIC 或 HTTP/2 連線，因此修改規則後只重新整理頁面不一定會建立新連線。可以關閉對應分頁，等待幾秒後重試，或在連線清單中終止舊連線。

假設希望 api.example.com 直連，但日誌顯示命中 DOMAIN-SUFFIX,example.com 並進入代理群組，表示較寬泛的規則排在前面。若日誌直接顯示 MATCH，通常代表網域拼寫、規則格式或規則集載入存在問題。

第三步：確認看到的是網域還是 IP

應用程式直接存取 IP 時，DOMAIN 類規則自然不會命中。應用程式使用自有的加密 DNS、內部快取或透過 QUIC 建立連線時，核心看到的資訊也可能與瀏覽器網址列不同。連線詳細資料中的 Host、目標位址、網路類型與程序欄位，比根據網頁網域猜測更可靠。

如果設定啟用 TUN，可以暫時比較系統代理模式與 TUN 模式下的連線紀錄，但不要同時反覆修改 DNS、規則與節點。每次只修改一個變數：先確認流量進入核心，再確認目標資訊，最後確認規則順序。

第四步：驗證策略群組，而不只看規則名稱

規則命中 PROXY 只代表連線被交給該策略群組。如果 PROXY 目前手動選擇的是 DIRECT，實際出口仍是直連；如果選擇的是延遲測試群組，實際節點會由群組內的測試結果決定。連線詳細資料通常會顯示類似「規則 → 策略群組 → 節點」的完整鏈路。

第五步：用最小規則集重現問題

大型訂閱可能包含數萬條規則，直接在完整設定中移動項目不易判斷衝突。可以建立一份臨時本機設定，只保留必要代理、一個策略群組、兩三條測試規則與末尾的 MATCH。測試成功後，再把精確規則放回正式設定中相應規則集之前。

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

測試時記錄目標網域、連線時間、命中規則與最終策略。連續測試 3 次，每次先關閉舊連線；如果三次結果一致，才能表示規則順序穩定生效。若第一次命中舊策略、後兩次命中新策略，通常是連線重複使用或 DNS 快取造成的，而不是比對演算法隨機變化。

一份便於維護的完整規則範例

以下結構先處理內網與明確例外，再處理廣告、業務分類、中國大陸網域與中國大陸 IP，最後將剩餘連線交給代理群組。這裡展示的是排列方式，策略群組名稱與規則集網址需要依實際設定調整。

rules:
  # 本機與區域網路
  - 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,fc00::/7,DIRECT,no-resolve

  # 明確例外
  - DOMAIN,updates.example.com,DIRECT
  - DOMAIN-SUFFIX,work.example,WORK
  - DOMAIN-SUFFIX,github.com,PROXY

  # 分類規則
  - GEOSITE,category-ads-all,REJECT
  - RULE-SET,private,DIRECT
  - RULE-SET,streaming,MEDIA

  # 大範圍規則
  - GEOSITE,cn,DIRECT
  - GEOIP,CN,DIRECT,no-resolve

  # 兜底
  - MATCH,PROXY

維護時為規則分組加上註解，並將人工例外集中放在大型規則集之前。每次修改後，先驗證一個明確網域、一個中國大陸網站、一個代理網站與一個區域網路位址，例如路由器的 192.168.1.1。四類連線都符合預期後，再繼續擴大規則範圍。

規則分流的關鍵不是堆疊更多項目，而是確保每條規則的範圍可解釋、順序可驗證、命中結果能從日誌重現。遇到異常時，從目前設定、連線目標、首次命中規則、策略鏈與實際出口五個面向逐層檢查，通常可以快速找出問題所在。

下載 Clash 依平台選擇用戶端