Clash 自訂規則怎麼寫：DOMAIN 系列語法與比對優先順序詳解

先看懂一條 Clash 規則的結構

Clash 的規則系統會依據連線特徵決定流量去向。最常見的規則由規則類型、比對內容與策略三部分組成，各欄位以英文逗號分隔。以網域規則為例，以下這行表示存取 api.example.com 時使用名為 DIRECT 的策略：

DOMAIN,api.example.com,DIRECT

DOMAIN 是規則類型，api.example.com 是比對內容，DIRECT 是目標策略。目標策略可以是內建動作，也可以是設定中已存在的代理伺服器或策略群組名稱。常見的內建動作包括 DIRECT、REJECT；如果設定中有名為「節點選擇」的策略群組，規則末尾也可以直接寫「節點選擇」。名稱必須完全一致，空格、大小寫與符號都屬於名稱的一部分。

完整規則清單放在哪裡

傳統 Clash YAML 會將內嵌規則放在頂層 rules 欄位下。每一項以前置連字號開頭，排列順序就是實際的比對順序：

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,節點選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

在支援編輯設定的圖形化客戶端中，通常可從「設定」→選取目前設定→「編輯」開啟 YAML。不同客戶端的按鈕名稱可能是「編輯檔案」、「檢視設定」或「擴充設定」。儲存後還要重新載入該設定；只修改磁碟上的檔案卻沒有觸發重新載入時，目前執行中的內核仍會使用舊規則。

DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD 的差異

網域規則應優先用於網站分流，因為它能直接利用請求網域，不必先將網域解析成 IP。三種常用的 DOMAIN 系列規則涵蓋範圍不同，不能只因名稱相似就互相替換。

規則類型	範例	可以比對	不會比對
`DOMAIN`	`DOMAIN,api.example.com,DIRECT`	`api.example.com`	`www.example.com`、`v2.api.example.com`
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,DIRECT`	`example.com` 及其子網域	`example.com.test`
`DOMAIN-KEYWORD`	`DOMAIN-KEYWORD,example,DIRECT`	網域中包含 `example` 的連線	不包含該連續字串的網域

DOMAIN：只比對完整主機名稱

DOMAIN 適合只想處理單一明確主機名稱的情況。例如讓軟體更新介面直連，但不改變同一主網域下其他服務的路由：

DOMAIN,updates.example.com,DIRECT
DOMAIN,telemetry.example.com,REJECT
DOMAIN-SUFFIX,example.com,節點選擇

請求 updates.example.com 時，第一條規則會命中並停止；請求 telemetry.example.com 時，第二條規則會命中；請求 store.example.com 才會繼續比對第三條後綴規則。精確規則放在寬泛規則之前，才能保留例外。

DOMAIN-SUFFIX：涵蓋主網域與所有下級網域

DOMAIN-SUFFIX,example.com,節點選擇 會涵蓋 example.com、www.example.com 和 cdn.assets.example.com。它不會因一般文字結尾而誤比對 fakeexample.com，比對過程會遵循網域標籤邊界。

一個網站往往同時使用登入、API、圖片與靜態資源子網域。確認這些子網域應採用相同策略時，一條後綴規則比逐一列出完整網域更容易維護。如果某個子網域需要例外處理，就將對應的 DOMAIN 放在該後綴規則上方。

DOMAIN-KEYWORD：涵蓋範圍廣，使用前先評估誤比對

DOMAIN-KEYWORD 會檢查網域中是否包含指定字串。它適合網域經常變動、但都帶有穩定品牌片段的服務，也可能將名稱相近卻無關的網域一併納入。關鍵字越短，涵蓋範圍越大。例如關鍵字 cdn 可能同時比對大量彼此無關的內容傳遞網域。

DOMAIN-KEYWORD,company-service,節點選擇

能用 DOMAIN 或 DOMAIN-SUFFIX 表達時，應優先使用涵蓋範圍更明確的類型。關鍵字規則適合放在精確網域與後綴規則之後、IP 類規則之前。

規則優先順序只有一個核心：由上而下，首次命中

Clash 不會收集所有比對結果後再挑選「更具體」的規則。內核會從 rules 第一行開始檢查，遇到第一條符合的規則後立即採用其策略，後續規則不再參與。所謂優先順序，本質上就是設定檔中的排列順序。

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

在這段設定中，api.example.com 會先命中第一條 DOMAIN-SUFFIX，因此第二條精確規則永遠沒有機會生效。正確寫法是將例外放在寬泛規則之前：

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

一套便於維護的排序方式

最明確的拒絕、直連或指定節點例外，例如單一 DOMAIN。
涵蓋一組服務的 DOMAIN-SUFFIX、DOMAIN-KEYWORD 或 GEOSITE。
區域網路、保留位址與已知網段的 IP-CIDR、IP-CIDR6。
依國家或地區分類的 GEOIP。
最後放置兜底規則 MATCH。

這不是語法強制範本，而是用來減少規則互相遮蔽的實用順序。真正需要優先處理的規則仍應放得更前面。例如某個 IP 網段必須拒絕存取，就不應排在可能提前命中的寬泛直連規則之後。

IP-CIDR、GEOIP 與 no-resolve 的實際作用

IP-CIDR 會依目標 IPv4 位址或網段進行比對，IP-CIDR6 則處理 IPv6。CIDR 後的數字表示網路前綴長度：192.168.1.0/24 涵蓋 192.168.1.0 到 192.168.1.255，而 10.0.0.0/8 涵蓋整個 10.0.0.0 私有位址範圍。

IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR6,fd00::/8,DIRECT,no-resolve
GEOIP,CN,DIRECT
MATCH,節點選擇

GEOIP 會根據目標 IP 在地理資料庫中的歸屬進行比對。例如 GEOIP,CN,DIRECT 表示將資料庫判定為中國大陸位址的連線直連。判斷品質取決於內核實際載入的 GeoIP 資料；雲端服務、Anycast 與位址變更都可能使個別結果與伺服器實際所在地不一致。

為什麼 IP 規則可能觸發 DNS 解析

應用程式發起連線時，內核取得的目標可能是網域，也可能已經是 IP。檢查 IP-CIDR 或 GEOIP 時，如果目前只有網域，內核可能需要解析該網域以取得目標 IP，再判斷是否屬於指定網段或地區。這就是 IP 規則與 DNS 查詢之間的關聯。

在支援此參數的 IP 類規則末尾加入 no-resolve，表示不要為了檢查這條規則而額外解析網域。如果連線本身已提供目標 IP，這條規則仍可正常比對；如果只有網域且沒有可用的目標 IP，則略過需要解析才能完成的判斷，繼續檢查後面的規則。

IP-CIDR,203.0.113.0/24,節點選擇,no-resolve

no-resolve 不是通用的效能開關，也不應附加在 DOMAIN、DOMAIN-SUFFIX 或 MATCH 後。它主要用於 IP 類規則。是否使用取決於規則目的：區域網路網段通常可以加入，因為目標原本就是私有 IP；如果必須根據網域解析後的位址判斷歸屬，就不能用它來阻止這次解析。

Fake-IP 模式下仍要保留網域規則在前

使用 Fake-IP DNS 模式時，客戶端可能先收到一個對應位址，但內核會保留網域與對應位址的關係，仍能依網域規則進行分流。將明確的網域規則排在 IP 地理規則之前，可以避免同一服務因 CDN 位址變動而被導向不同策略。只有在缺少可用網域資訊或網域規則未命中時，IP 類判斷才更重要。

mihomo 常用擴充規則：GEOSITE、連接埠與程序

Clash Meta 目前使用的內核 mihomo 支援比早期 Clash 更豐富的規則類型。設定需要在不同內核間使用時，應先確認客戶端實際啟動的是哪一種內核；不受支援的規則類型可能直接導致設定載入失敗。

規則	用途	範例
`GEOSITE`	使用網域分類資料庫比對一組網站	`GEOSITE,category-ads-all,REJECT`
`DST-PORT`	依目標連接埠比對	`DST-PORT,22,DIRECT`
`SRC-IP-CIDR`	依發起連線的來源位址比對	`SRC-IP-CIDR,192.168.1.50/32,DIRECT`
`PROCESS-NAME`	依程序名稱比對	`PROCESS-NAME,backup.exe,DIRECT`

GEOSITE 比對的是資料庫中的網域集合，不是依伺服器 IP 所在國家判斷；GEOIP 則以 IP 資料庫為依據。兩者名稱相近，但處理的對象完全不同。在設定中使用 GEOSITE 前，需確保客戶端已設定並能載入相應的 GeoSite 資料。

程序規則取決於作業系統，以及內核取得程序資訊的能力。在 TUN 模式下，不同平台對程序識別的支援程度並不完全一致。需要在 Windows、macOS 和 Linux 共用設定時，網域與 IP 規則通常更穩定；程序規則更適合用作特定裝置上的補充，而不是唯一的判斷條件。

自訂規則應該插入哪一行

自訂規則是否生效，通常不取決於它「寫得對不對」，而取決於是否放在會提前命中的規則之前。尋找插入位置時，先找設定檔末尾的 GEOIP、大範圍 RULE-SET 與 MATCH，再判斷新增規則要覆蓋哪一層行為。

情境一：讓單一網域繞過代理伺服器

如果原本的設定已用 DOMAIN-SUFFIX,example.com,節點選擇 接管整個主網域，新加入的直連例外必須放在它上方：

rules:
  - DOMAIN,office.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,節點選擇
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

情境二：讓一個網段固定經由代理伺服器

如果該網段可能先被 GEOIP,CN,DIRECT 命中，就應將網段規則插入 GEOIP 之前：

rules:
  - IP-CIDR,198.51.100.0/24,節點選擇,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

情境三：在訂閱設定中長期保留規則

直接編輯訂閱產生的 YAML，通常只能維持到下一次更新。訂閱重新整理後，客戶端通常會以遠端內容覆蓋本機副本。更穩妥的做法是使用客戶端提供的設定覆寫、合併設定或擴充腳本，將自訂規則插入訂閱規則之前。具體入口應以目前使用的客戶端為準，常見操作路徑是「設定」→「設定管理」→「覆寫」，或在目前訂閱的選單中選擇「擴充設定」。

如果需要維護數十條以上的規則，可以使用 rule-providers。規則集獨立更新，主設定只透過 RULE-SET 引用：

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

rules:
  - RULE-SET,private-sites,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

behavior: domain 表示規則集負載是網域類內容；如果規則集同時包含 DOMAIN、IP-CIDR 等完整規則，應使用適合完整規則的 classical 行為。提供者類型、檔案格式與實際內容必須相互對應，不能把完整的 Clash 規則直接放進只接受網域負載的集合。

儲存後如何確認規則確實命中

驗證規則不能只看網頁是否能開啟。網頁成功可能來自直連、代理、快取或其他網路路徑。應同時檢查設定載入狀態、連線記錄與實際命中的規則。

儲存設定並執行重新載入，確認介面沒有 YAML 解析或規則類型錯誤。
清除目標應用程式現有的連線，必要時完全結束後重新開啟應用程式。
在客戶端的「連線」頁面依網域篩選目標請求。
查看該連線顯示的規則類型、規則內容與最終策略群組。
分別測試主網域、子網域與一個不應命中的相似網域，確認涵蓋範圍符合預期。

例如測試 DOMAIN-SUFFIX,example.com,DIRECT 時，可以依序觀察 example.com、api.example.com 與 example.com.test。前兩者應命中，第三者不應命中。測試精確規則時，再加入 v2.api.example.com；它不應被 DOMAIN,api.example.com,DIRECT 視為同一個網域。

規則未生效時，依照這個順序排查

先確認是否被上方規則攔截：在連線詳情中找到實際命中的規則，而不是反覆移動末尾的自訂項目。
再確認策略名稱：規則末尾必須與策略群組名稱完全一致。
檢查目前設定：編輯的檔案可能不是客戶端目前正在使用的設定。
檢查舊連線：規則變更通常不會重新分流已建立的 TCP 連線。
檢查 DNS 與目標類型：應用程式可能直接連線至 IP，也可能使用不同子網域或 QUIC 的 UDP 連線。
檢查內核相容性：GEOSITE、邏輯組合與部分程序規則需要 mihomo 支援。

一份可直接檢查順序的規則範例

以下結構展示「單一網域例外、網域集合、私有網段、地區規則、最終兜底」的順序。策略群組名稱需與自己的設定保持一致：

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN,ads.example.com,REJECT
  - DOMAIN-SUFFIX,example.com,節點選擇
  - GEOSITE,category-ads-all,REJECT
  - 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
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

在這份範例中，登入網域優先直連，廣告子網域優先拒絕，其餘 example.com 服務則使用「節點選擇」。接著才檢查通用廣告分類、私有位址與地區 IP。最後，所有未命中的連線交由 MATCH 處理。新增規則時，只要先回答「它應該覆蓋哪一條現有規則」，通常就能確定插入位置。

規則維護的重點不是堆疊數量，而是控制涵蓋範圍。優先使用精確網域，確認整組子網域策略一致後再使用後綴；IP 規則要明確是否允許解析；大範圍分類與兜底規則放在後面。完成修改後，透過連線詳情驗證命中項目，會比單純觀察網頁結果更快找到問題。