Clash 自訂規則語法與優先順序：DOMAIN、IP-CIDR、MATCH

規則比對順序：由上而下，符合第一條即停止

Clash 用戶端使用規則模式時，核心會依照設定檔中 rules 清單的順序檢查連線。只要符合第一條規則，連線就會交由該規則指定的策略處理，不會繼續尋找「更精確」的規則。因此，規則的排列順序本身就是優先順序，DOMAIN 並沒有天生高於 IP-CIDR 的通用排序。

以下片段假設目前設定中已有名為「代理選擇」的代理群組。這個名稱必須與 proxy-groups 中的 name 完全相同。範例網域使用 example.com，僅用來說明語法，不代表必須對該網站採用特定策略。

mode: rule

rules:
  - DOMAIN,api.example.com,代理選擇
  - DOMAIN-SUFFIX,example.com,DIRECT
  - MATCH,代理選擇

連線至 api.example.com：符合第一條規則，交由「代理選擇」處理。
連線至 www.example.com：不符合第一條，符合第二條，交由 DIRECT 處理。
連線至其他未符合前兩條規則的目標：由最後的 MATCH 接手。

如果把第二條移到第一條前面，api.example.com 也會先符合後綴規則並直接連線。即使後面的精確網域規則寫得正確，也不會再被檢查。維護規則時，應先列出例外，再安排涵蓋範圍較大的規則。

DOMAIN 類規則：精確網域、後綴與關鍵字

網域規則通常由「規則類型、比對內容、目標策略」三個欄位組成。比對內容不是完整網址：不要加上 https://、連接埠、路徑或查詢參數。若要比對 https://api.example.com/v1/status，應填入 api.example.com，而不是把整段網址放進 DOMAIN。

三種常用網域規則的比對範圍
類型	範例	比對結果
DOMAIN	`DOMAIN,example.com,DIRECT`	只比對 example.com，不包含 www.example.com。
DOMAIN-SUFFIX	`DOMAIN-SUFFIX,example.com,DIRECT`	比對 example.com 及其子網域，但不比對 notexample.com。
DOMAIN-KEYWORD	`DOMAIN-KEYWORD,example,代理選擇`	比對網域中包含 example 字串的目標，涵蓋範圍比後綴規則更廣。

例外網域應排在後綴規則之前

rules:
  - DOMAIN,download.example.com,代理選擇
  - DOMAIN-SUFFIX,example.com,DIRECT
  - DOMAIN-KEYWORD,telemetry,REJECT
  - MATCH,代理選擇

這個順序會先為下載網域保留獨立出口，再處理整個網域後綴。關鍵字規則排在後綴規則之後，因此即使 telemetry.example.com 含有關鍵字，也會先符合 example.com 後綴規則並直接連線。若要封鎖該網域，應將精確拒絕規則移到前面，不要以為 REJECT 會自動取得最高優先順序。

謹慎使用關鍵字規則

DOMAIN-KEYWORD,ad,REJECT 會比對許多正常網域中的短字串，容易誤封。已知完整網域時，優先使用 DOMAIN；需要涵蓋一組子網域時，使用 DOMAIN-SUFFIX。關鍵字規則較適合用在確實具有一致命名特徵，且已確認比對範圍的目標。

網域規則需要連線中繼資料中有可用的網域名稱。應用程式直接連線到 IP、DNS 路徑不同，或網域嗅探未生效時，連線記錄可能只有目標位址。此時不能只憑瀏覽器網址列中的網域，就認定核心一定能符合相應的 DOMAIN 規則。

IP-CIDR 與 no-resolve：控制是否觸發解析

IP-CIDR 依目標 IPv4 位址比對網段；IPv6 通常使用 IP-CIDR6。CIDR 後面的數字代表網路前綴長度：IPv4 的 /32 表示單一位址，192.168.1.0/24 則涵蓋從 192.168.1.0 到 192.168.1.255 的位址範圍。

rules:
  - IP-CIDR,192.168.1.10/32,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - MATCH,代理選擇

no-resolve 的作用是：不要只為了檢查這條 IP 規則，就主動解析尚未解析的目標網域。它不是「關閉 DNS」，也不是「禁止所有網域套用這條規則」。如果目標 IP 已經存在，核心仍可據此比對網段；如果沒有可用的目標 IP，這條規則不會為了比對而觸發解析。

兩種連線路徑的差異

應用程式直接連線至 192.168.1.10:443：目標 IP 已知，因此可以符合單一位址規則；no-resolve 不會阻止這次比對。
應用程式連線至 nas.example.com：若核心尚未取得可用的實際目標 IP，含有 no-resolve 的網段規則就不會主動解析，連線可能繼續比對後續規則。

如果這個 NAS 網域必須直連，通常應另外新增 DOMAIN,nas.example.com,DIRECT，不要依賴不一定會觸發的 IP 判斷。若網域需要依解析結果分流，則應配合 DNS 設定，判斷是否移除該規則的 no-resolve。

在 fake-ip 情境下，用戶端看到的合成位址也不能直接視為網站的實際伺服器位址。應搭配連線詳細資訊、網域對應與 DNS 記錄判斷；不要為了修復單一網站，就把整個 fake-ip 位址池加入直連規則。

策略目標與 MATCH：選擇出口及設定兜底

規則最後指定的是策略，不一定是特定代理節點。DIRECT 代表直連，REJECT 代表拒絕連線；自訂名稱則可指向已定義的代理或代理群組。規則符合「代理選擇」後，實際出口取決於該群組目前選取的成員。

因此，連線詳細資訊顯示「符合代理群組」，但實際仍然直連，不一定代表規則失效。還要確認群組內是否選了 DIRECT、是否經過另一個包含 DIRECT 的群組，以及自動選擇群組目前的結果。規則符合與最終出口是前後相連、但不同的判斷步驟。

rules:
  - DOMAIN,blocked.example.com,REJECT
  - DOMAIN,intranet.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,代理選擇
  - MATCH,代理選擇

MATCH 應放在兜底位置

MATCH 不需要網域或網段參數，語法只有 MATCH,策略。所有到達這一行的連線都會符合。若放在規則清單第一行，後面的規則都不會有機會執行；若放在兩個規則集之間，第二個規則集也不會再被檢查。

希望未分類流量交由代理群組處理：使用 MATCH,代理選擇。
希望未分類流量直接連線：使用 MATCH,DIRECT。
希望只允許明確列出的連線：可使用 MATCH,REJECT，但必須先補齊必要依賴，否則登入、更新與資源載入可能一併遭到拒絕。

更換兜底策略會影響大量尚未分類的流量。修改前先儲存目前設定，修改後完整測試實際使用流程，不要只確認網站首頁能否開啟。

mihomo 規則集：清單位置仍決定優先順序

mihomo 支援透過 rule-providers 管理規則集，再以 RULE-SET 引用。規則集並不是獨立於主清單之外的優先順序系統：RULE-SET 放在哪一行，就會在該位置參與比對。若前面的普通規則已符合，後面的規則集便不會執行。

以下是 mihomo 本機檔案規則集的片段，需要與現有設定合併，並保留原有節點和「代理選擇」群組。./rules/work.yaml 必須實際存在於核心的設定工作目錄中；不要只新增宣告，卻忘了建立檔案。

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

rules:
  - DOMAIN,login.example.com,DIRECT
  - RULE-SET,work,代理選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,代理選擇

對應的 work.yaml 內容如下。策略由引用位置的 RULE-SET 指定，因此 classical 集合中的每個項目都不必再附加「代理選擇」：

payload:
  - DOMAIN-SUFFIX,example.com
  - IP-CIDR,203.0.113.0/24

203.0.113.0/24 是文件範例網段，不是可直接用於實際服務的目標位址。實際設定應使用服務提供的網段。這裡的 login.example.com 會先符合主清單的第一條規則，因此即使它屬於 work 集合中的網域後綴，仍會直接連線。

behavior 必須與檔案內容相符

classical：項目包含 DOMAIN-SUFFIX、IP-CIDR 等規則類型，適合混合規則。
domain：項目是網域比對內容，不應直接複製含有類型前綴的 classical 項目。
ipcidr：項目是 IP 網段，不是網域清單。

以上設定依 mihomo 語法編寫。不同 Clash 核心對規則集格式及擴充類型的支援各異，請以用戶端顯示的核心資訊和設定檢查結果為準。檔名相同，不代表舊版核心就能解析所有欄位。

自訂規則排序與訂閱覆寫

規則增加後，建議依「明確例外 → 分類規則 → 兜底策略」整理，不要一味加在清單末尾。以下提供一種便於檢查的排序方式；拒絕規則是否置頂，則應視實際需求允許哪些例外而定。

必須優先於其他分類的精確規則。例如，指定單一登入網域直連，或拒絕連線至特定追蹤網域。發生衝突時，應明確決定哪條規則先比對。
本機服務與區域網路目標。已知網域就用網域規則，已知網段則用 IP 規則，並確認是否需要主動解析。
服務分類與規則集。依辦公、媒體或其他用途分類；若規則集範圍重疊，應將優先套用的分類排在前面。
範圍較廣的網域、地區或 IP 分類。涵蓋範圍大的規則集容易遮蔽後續例外，調整時應抽樣檢查。
最後一條 MATCH。明確指定未分類連線的去向，後面不要再放需要執行的規則。

訂閱更新可能會重新產生主設定檔。直接修改由訂閱產生的 YAML，即使目前生效，也可能在下次更新後遺失。若用戶端提供覆寫、合併或持久化自訂規則功能，應使用這些功能；選單名稱依用戶端而異，不要把特定介面的選單路徑當成所有 Clash 用戶端的通用設定。

特別要留意「追加」與「前置」的差異：如果自訂規則被加在訂閱原有的 MATCH 後面，規則雖然存在，卻永遠不會符合。應查看核心最後載入的規則清單，確認合併後的實際位置，而非只檢查編輯器中的片段。

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

排除問題時一次只更改一個條件。先選定明確目標，例如 api.example.com，記下預期策略，再檢查新連線符合的規則與最終出口。瀏覽器重用的持久連線可能沿用舊路徑，重新載入頁面不一定會建立新連線。

確認流量確實經過核心。系統代理只會影響遵循系統代理設定的應用程式。未進入核心的連線不受 rules 控制；TUN 也必須有實際涵蓋目標流量的路由。
確認執行中的設定與模式。檢查是否已載入修改後的設定、執行模式是否為規則模式，以及切換訂閱後是否載入了另一份設定。
檢查解析錯誤。YAML 使用空格縮排，不使用定位字元；確認規則類型拼寫、逗號數量與策略名稱。重複的頂層 rules 鍵應合併為同一份清單。
檢查更早符合的規則。查看是否有涵蓋目標的 DOMAIN-SUFFIX、關鍵字、RULE-SET，或更早出現的 MATCH。記錄中實際符合的規則，比預想中的規則更能說明狀況。
核對目標中繼資料。確認記錄中的是網域還是 IP、是否為 IPv6，以及是否已有解析結果。只有 IPv4 網段規則時，不會符合 IPv6 目標。
重新建立測試連線。若可以中斷連線，請關閉對應的舊連線，或結束後重新開啟測試應用程式，再查看新的規則比對記錄。

一份易於維護的規則設定，應能回答三個問題：目標為何符合這一行、這一行將連線交給哪項策略，以及策略最後使用哪個出口。分別驗證這三個層次，就能將 DOMAIN、IP-CIDR、規則集與 MATCH 的關係對應到實際連線，而不只是看設定文字的排列順序。