進階原理 閱讀時間約 10 分鐘

Clash 自訂規則設定：規則類型、比對順序與 MATCH 後備規則

整理 DOMAIN、DOMAIN-SUFFIX、IP-CIDR、GEOIP 等常見規則語法，說明規則由上而下比對、命中第一條即停止，以及覆寫規則時的排序技巧。

1. 規則語法：比對條件與出口策略

Clash 自訂規則用來決定「這條連線要交由哪個出口處理」。用戶端提供編輯介面，核心負責實際比對；原版 Clash 與 Clash Meta（現名 mihomo）的規則功能並不完全相同。本文先介紹兩者常見的基礎語法，談到規則集時再說明相容條件。

常見規則會寫在 YAML 頂層的 rules: 清單中，每行通常由「規則類型、比對內容、策略」組成，部分類型也允許附加參數。MATCH 不需要比對內容，只要填寫出口策略即可。

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,DIRECT

這是規則設定片段，不是完整的訂閱設定。DIRECT 代表直連，REJECT 代表拒絕連線。如果策略填入 代理出口，目前設定中就必須已經有同名節點或策略組；名稱必須完全相符，不會依照中文含義自動建立出口。

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

類型範例實際比對範圍
DOMAINDOMAIN,api.example.com,DIRECT只比對 api.example.com，不包含其子網域。
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.com,DIRECT比對 example.com，以及 api.example.com 等子網域。
DOMAIN-KEYWORDDOMAIN-KEYWORD,example,REJECT比對網域中包含 example 的連線，涵蓋範圍比後綴規則更廣。

網域規則不填網址路徑

要處理 https://api.example.com/v1/status，請填入網域 api.example.com，不要連同 https://、/v1/status 或連接埠一起填入。一般網域規則無法依 HTTPS 頁面路徑分流；同一網域的不同路徑不會因此使用不同出口。

  • 只想為單一 API 設定例外：優先使用 DOMAIN。
  • 希望主網域及所有子網域使用相同策略：使用 DOMAIN-SUFFIX。
  • 關鍵字規則容易比對到不相關網域，長期啟用前請先在連線記錄中確認涵蓋範圍。

網域比對也取決於核心能否取得目標網域。若應用程式直接連線至 IP、DNS 未依預期經過核心，或連線中繼資料未包含網域，就不能假設 DOMAIN 規則一定會生效。mihomo 的網域嗅探在部分情境下可以補足資訊，但並非適用於所有協定的通用解法。

3. 規則順序：由上而下比對，命中第一條即停止

Clash 不會先收集所有符合條件的規則，再挑選「看起來最精確」的一條。一般規則清單會依序檢查，第一條符合條件的規則就會決定出口，後續規則不再參與這條連線的選擇。因此，精確例外通常放前面，範圍較廣的分類規則放後面。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,REJECT
  - MATCH,DIRECT

在這個範例中，連線至 api.example.com 會直連，連線至 www.example.com 則會遭到拒絕。如果將前兩行對調，api.example.com 會先符合網域後綴規則，後面的精確直連規則就沒有機會生效。這不是 DOMAIN 的優先順序降低，而是比對已經結束。

方便維護的排序方式

  1. 明確的單一網站例外：需要個別放行、拒絕或指定出口的網域。
  2. 區域網路與內部服務：確認屬於本地網路的位址區段與內部網域。
  3. 用途分類與規則集：依用途整理的大範圍分流規則。
  4. 地區等廣泛判斷：例如依據地理資料庫判斷的 IP 規則。
  5. MATCH：處理前面所有規則都未命中的連線。

這是便於維護的排序思路，不是必須照抄的固定範本。如果安全需求規定某類連線必須優先拒絕，就應將拒絕規則放在相關放行規則之前，並檢查是否有衝突。最重要的原則是：每條排在前面的規則，都必須是你希望它能優先於後續規則生效的規則。

4. IP-CIDR 與 GEOIP：目標位址、解析與 no-resolve

IP-CIDR 依目標 IPv4 位址範圍比對，IP-CIDR6 則用於 IPv6。例如 192.168.50.0/24 涵蓋該網段中的位址，適合設定家用 NAS、印表機或內部服務直連；它不是用來篩選「來源裝置」位址的條件。

rules:
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,DIRECT

GEOIP,CN,DIRECT 會依目前使用的 IP 地理資料庫，判斷目標 IP 是否歸類為 CN，並不代表完整列出「中國網站」。網站可能使用跨地區 CDN，同一網域也可能解析至不同位址。資料庫內容、更新時間與 DNS 查詢結果都會影響判斷，應以實際解析出的目標 IP 與資料庫分類確認命中的 GEOIP 規則。

no-resolve 的適用範圍

連線只有網域、沒有可用的目標 IP 時，IP 類規則可能會觸發 DNS 解析。加上 no-resolve 表示不要為了比對這條規則而主動解析網域；若連線中繼資料已有可用 IP，仍可進行位址比對。這不代表關閉 DNS，也不代表所有網域連線都會略過 IP 判斷。

  • 區域網路 IP 直連規則常會加上 no-resolve，避免為了檢查內網網段而提前解析其他網域。
  • 若希望 GEOIP 判斷尚未解析的網域，就不應不加思索地附加 no-resolve。
  • 若要依發起連線的裝置位址分流，請查看核心支援的來源位址規則，而不是把來源 IP 填入 IP-CIDR。

上面的 fd00::/8 只是 IPv6 本地位址範圍的範例，並未涵蓋所有本地網路情境。實際設定時應依裝置位址規劃選擇網段，也要確認 DNS 回傳 IPv6 位址後，流量是否仍使用預期的策略。

5. MATCH 後備規則：選擇最後一條規則的出口

MATCH 是無條件比對規則。若放在清單中間，後面的普通規則就無法再透過這套一般比對流程觸發。因此，通常只保留一條，並放在清單末尾。將自訂規則加在 MATCH 後面，是「設定載入成功、實際卻未生效」的常見原因。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - MATCH,代理出口

此範例假設設定中已經有名為 代理出口 的策略組。未符合前三條規則的連線都會交由該策略組處理，但最後的出口仍取決於組內目前選取的項目：如果選的是 DIRECT，連線仍會直連。規則命中某個策略組，與最後使用某個代理節點，是兩個不同層面的結果。

6. 訂閱覆寫：前置插入、後續追加與整份替換

訂閱通常會定期更新，直接編輯下載後產生的設定檔，修改可能在下次更新時被覆蓋。較穩妥的方式是使用用戶端提供的本機覆寫、合併設定或規則編輯功能。不同用戶端與版本的操作入口、欄位及合併方式各不相同，不要將某個用戶端的覆寫語法當成通用的 Clash YAML。

先檢查最終設定，再確認是否儲存成功

  1. 備份目前可用的設定，記下原有策略組名稱與最後一條後備規則。
  2. 在目前訂閱所連結的本機覆寫中，選擇將自訂規則前置插入；若介面只提供追加功能，請確認插入位置不在 MATCH 之後。
  3. 查看合併後實際生效的設定，搜尋測試網域，確認它確實出現在 rules 中，且排在範圍較廣的規則之前。
  4. 重新載入設定後建立新連線，再確認命中的規則。不要只查看編輯器中的原始片段。

「替換 rules」會移除原有規則清單，可能連同訂閱中的規則集參照、區域網路例外與後備策略一併刪除。只需修改單一網域時，優先考慮前置一條精確規則，而不是複製整份訂閱自行維護。

RULE-SET 的位置同樣會影響順序

支援 rule-providers 的核心可透過 RULE-SET 引用規則集；支援範圍須依核心與版本確認，不能一概認定所有原版 Clash 建置版本都支援。以下片段假設已定義名為 work-domains 的 provider，以及名為 代理出口 的策略組：

rules:
  - DOMAIN,status.example.com,DIRECT
  - RULE-SET,work-domains,代理出口
  - MATCH,DIRECT

即使規則集內含有 status.example.com，前面的 DOMAIN 例外仍會先命中。規則集不會因為自身類型而在 rules 清單中取得額外優先權。也要確認 provider 的 behavior 與檔案內容格式：domain、ipcidr、classical 的資料格式不能任意混用。

7. 自訂規則未生效：依連線記錄逐步排查

驗證規則時，最好一次只修改一項。可以先為自己的測試網域新增一條暫時的 REJECT 規則，放在清單最上方，重新載入後發出新請求；確認連線記錄顯示命中該規則，再改回實際需要的出口。測試結束後請刪除暫時的拒絕規則，以免影響後續使用。

狀況優先檢查項目下一步
完全看不到新規則目前啟用的訂閱、覆寫關聯與生效設定確認正在編輯的設定，就是核心目前載入的設定。
命中其他規則清單中排在前面的 DOMAIN-SUFFIX、RULE-SET、MATCH將精確例外移到相關廣泛規則之前。
命中策略組，但出口不符預期該組目前選取的項目與巢狀策略組沿著策略鏈確認最後使用的節點或 DIRECT。
只有部分請求符合預期重新導向網域、資源網域、IPv6 與既有連線逐一檢查新連線，不要只看瀏覽器網址列。
重新載入時發生錯誤YAML 縮排、規則拼寫、策略名稱與 provider 名稱先通過設定檢查，再重新載入。

使用核心檢查設定語法

直接使用 mihomo 命令列時，可在設定檔所在目錄執行以下檢查；執行檔必須位於命令搜尋路徑中，設定引用的資源也必須能正確找到：

mihomo -t -f config.yaml

檢查通過表示設定符合該核心的載入要求，不代表分流結果符合預期。仍須開啟用戶端的連線記錄或日誌，查看目標網域、目標 IP、命中規則與策略鏈。使用圖形介面用戶端時，也要確認它實際載入的是哪一份產生的設定，而不是只檢查手邊的備份檔。

最後要注意，修改規則通常不會讓已建立的長連線立即改走新的出口。瀏覽器的 HTTP/2 連線、下載工作與即時通訊連線可能會繼續沿用原本的通道。儲存並重新載入後，請先建立新的測試連線；必要時先關閉對應的舊連線再測試，避免將連線重用誤判為規則失效。

維護規則時，保留少量用途明確的例外，並記下它們為何排在目前的位置。遇到問題時，依序確認「流量是否進入核心、是否處於規則模式、生效清單的順序、命中的策略、最後使用的出口」，通常比反覆切換節點更容易找出原因。

下載Clash選擇適合裝置的用戶端