先確認規則模式與目前生效的設定

若要讓某個網域固定直連，請先將用戶端的執行模式切換為「規則 / Rule」，再將自訂項目放在現有 rules: 清單前段。儲存並重新載入設定後，開啟連線清單，確認該網域命中的規則與最終出站方式。全域模式會依全域策略轉送，直連模式則一律直接連線，兩者都不適合用來驗證此處的分流順序。

Clash 是用戶端與核心生態系中常見的名稱；Clash Meta 後續改名為 mihomo。本文介紹的網域規則、CIDR 規則與依序比對，都是常見的設定功能；實際支援的規則集格式與其他規則類型，仍取決於使用中的核心。用戶端介面與核心是不同概念，排查問題時，請在「關於」或核心資訊區確認目前執行的核心。

  1. 開啟目前啟用的設定，先備份原始檔或匯出設定。
  2. 確認現有的策略群組名稱，例如 代理選擇，並留意大小寫、空格與中文字。
  3. 透過用戶端提供的覆寫、合併或自訂規則功能，新增少量規則。
  4. 重新載入後查看生效中的設定，確認新增規則確實已加入 rules，而非只儲存在編輯器中。

基本語法：類型、比對內容與出站目標

大多數一般規則的格式為 類型,比對內容,目標。目標可以是內建的 DIRECT、REJECT，也可以是目前設定中已有的代理節點或策略群組。MATCH 不需要比對內容，寫成 MATCH,目標，通常放在最後作為兜底規則。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,DIRECT
  - DOMAIN-KEYWORD,telemetry,REJECT
  - IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
  - IP-CIDR6,fd00::/8,DIRECT,no-resolve
  - MATCH,代理選擇

這段範例用於取代或合併現有規則清單，並假設預設設定中已定義 代理選擇。若現有策略群組名稱是 Proxy，就必須使用實際名稱；單獨貼上這段內容並不會建立策略群組或代理節點。範例中的保留網域用於說明比對範圍，實際使用時應換成需要控管的網域。

類型比對範圍適用情境
DOMAIN完整網域精確比對只調整單一 API 或登入入口
DOMAIN-SUFFIX網域本身及其子網域統一處理整個網域體系
DOMAIN-KEYWORD網域中包含指定字串確定要採用較寬鬆的比對範圍時
IP-CIDR目標 IPv4 網段區域網路、固定服務位址
RULE-SET引用已宣告的規則提供器集中管理大量網域或網段
MATCH前面的規則都未命中的連線清單末尾的預設出站方式

DOMAIN-SUFFIX 並非比對任意字串結尾

DOMAIN-SUFFIX,example.com,DIRECT 可比對 example.com 和 img.example.com，但不會比對 notexample.com。不需要寫成 *.example.com，也不要在網域欄位填入 https://、連接埠或路徑。規則比對的是連線目標資訊，而非瀏覽器網址列中的完整 URL。

若只想調整 api.example.com，使用 DOMAIN 更容易控管範圍。DOMAIN-KEYWORD,example,DIRECT 則可能連帶比對其他包含相同字串的網域；涉及登入、付款或企業內部系統時，建議優先採用精確比對，再視需求擴大範圍。

比對優先順序：由上而下，命中第一條即停止

一般的 rules 清單會依書寫順序逐條判斷，通常由第一條命中的規則決定出站方式，不會先收集所有結果，再自動挑選「更精確」的規則。網域規則並沒有天生高於 IP 規則的優先級，精確網域也不會自動排在網域後綴規則之前；需要優先套用的例外必須寫在前面。

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

依照這個順序，api.example.com 會使用 代理選擇，而 www.example.com 則會直連。如果對調前兩條，API 網域會先命中後綴規則，後面的精確規則便不會執行。這也是新增規則後「設定載入成功，流量卻沒有變化」的常見原因。

自訂規則應放在哪裡？

  • 將個別例外放在通用規則之前：單一網域的特殊出站方式，應排在涵蓋整個網域體系的規則之前。
  • 將自訂修正规則放在相關訂閱規則之前：若訂閱中的規則集已涵蓋目標網域，將規則附加在後面通常無法改變比對結果。
  • 將兜底規則放在末尾：MATCH 之後的一般規則，無法處理已被兜底規則命中的連線。
  • 保留明確的安全界線：放在前面的直連規則也可能略過訂閱中的封鎖規則，只應為確認需要放行的網域新增例外。

因此，「自訂規則放在訂閱規則之前」是處理規則覆蓋的方法，不代表所有自訂項目都必須一律放在最頂端。若已有必須優先執行的封鎖規則或本機網路規則，應依實際需求安排順序，最後檢查完整的生效清單，而不是只查看新增的幾行。

IP-CIDR 與 no-resolve：控制規則觸發的 DNS 解析

IP-CIDR,192.168.50.0/24,DIRECT,no-resolve 表示以該 IPv4 網段作為比對條件，並採用直連；/24 是網路前綴長度。單一 IPv4 位址可使用 /32，單一 IPv6 位址則可使用 /128。此處填寫的是目標位址，而非本機來源位址。

當連線目標仍是網域時，核心在判斷需要目標 IP 的規則是否命中時，可能會進行 DNS 解析。no-resolve 的作用是避免只為這條 IP 規則主動發起解析；它不代表「停用 DNS」，也不表示連線一定會直連，更不會阻止後續規則或實際建立連線時所需的解析。

  • 目標本身已是 IP，或核心已取得可用的真實目標 IP 時，仍可進行網段比對。
  • 目標是網域且當下沒有可用 IP 時，帶有 no-resolve 的 IP 規則通常不會為了比對而查詢位址，連線會繼續檢查後續規則。
  • 區域網路位址與明確的 IP 直連需求適合使用此參數；若想依據網域解析結果判斷網段，則需一併評估移除參數後的 DNS 行為。

以公司內網服務為例：若應用程式直接連線至 192.168.50.10，很容易驗證上方的網段規則；若連線目標是解析至該位址的內部網域，則建議優先新增明確的網域直連規則，並確認 DNS 能解析公司內部網域。路由選擇與 DNS 是否可連通是兩回事，單獨設定 DIRECT 無法修正錯誤的 DNS 伺服器。

RULE-SET 語法：定義與引用規則提供器

規則數量較多時，可在 rule-providers 中宣告規則提供器，再透過 RULE-SET,提供器名稱,目標 引用。它與提供代理節點的 proxy-providers 用途不同。以下以 mihomo 的本機 YAML 網域規則集為例，先準備檔案，再合併至主設定。

第一步：建立本機網域規則檔案

在核心可讀取的設定目錄中建立 rules/local-direct.yaml。檔案內容使用 payload；由於提供器宣告為 behavior: domain，此處只填寫網域比對內容，不必加入 DOMAIN-SUFFIX 類型或出站目標。

payload:
  - 'example.com'
  - '+.example.org'

此處的 example.com 用於精確比對網域，+.example.org 則表示網域本身及其子網域。規則集的網域寫法與主設定中的 DOMAIN-SUFFIX 語法屬於不同層級，不能直接混用。

第二步：宣告並引用提供器

rule-providers:
  local-direct:
    type: file
    behavior: domain
    format: yaml
    path: ./rules/local-direct.yaml

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,代理選擇

local-direct 在定義與引用處必須完全一致。相對路徑會依核心的工作目錄解析，不一定是目前編輯的訂閱檔案所在目錄；若讀取失敗，請查看核心日誌中的實際路徑與權限。此處的 type: file 會讀取本機檔案，不會自動從網路下載內容。

若改用 behavior: classical，規則集中的項目必須包含規則類型，例如 DOMAIN-SUFFIX,example.org，但仍不需填寫出站目標；目標由外層的 RULE-SET 指定。規則集中的所有比對項目會佔用主清單中引用位置的優先順序，不會額外取得更高優先級。若將引用放在 MATCH 之後，一樣無法達到分流效果。

驗證與排錯：先看命中規則，再看出站路徑

每次只新增一至三條規則，先檢查設定語法，再重新載入。YAML 使用空格縮排，避免使用 Tab；若已有 rules:，請直接合併清單，不要在檔案末尾再新增同名的頂層鍵。重複鍵可能導致前面的內容被覆蓋，或直接造成解析錯誤。

  1. 確認流量有進入核心。瀏覽器需使用系統代理、由應用程式明確設定代理，或由 TUN 接管相關流量。未進入核心的連線不會套用這些規則。
  2. 確認測試連接埠。若目前生效的設定中 mixed-port 為 7890，可使用以下指令明確透過本機 HTTP 代理連線；若連接埠不同，也請同步修改。
  3. 檢查新連線。在連線清單中搜尋目標網域，展開以查看規則類型、比對內容與出站路徑。既有的長連線可能仍沿用舊路徑，請關閉相關連線後再試一次。
  4. 區分策略群組與最終節點。命中 代理選擇 只代表連線進入該群組；若群組目前選擇的是 DIRECT，最終仍會直連。
curl --proxy http://127.0.0.1:7890 --head https://example.com

這個指令會產生一筆明確經由本機代理入口的測試請求，不能只憑 HTTP 狀態碼判斷分流是否成功。也應在用戶端中確認命中的規則；網域可能回傳重新導向，瀏覽器頁面也可能連線至多個不同網域，必須逐一檢查需要控管的連線。

三種常見故障的排查順序

  • 設定載入失敗：檢查縮排、逗號、策略群組名稱，以及 RULE-SET 所引用的提供器是否存在；優先查看日誌中的第一則錯誤。
  • 載入成功但規則未命中：檢查執行模式、規則順序、實際請求的網域與生效中的設定。若連線只有 IP，網域規則能否比對也取決於核心是否掌握網域資訊。
  • 規則命中但連線失敗：接著檢查 DNS、目前選用的節點、目標服務與本機路由。規則命中只代表已選擇連線路徑，不保證該路徑一定可用。

使用 TUN 時，部分系統流量、區域網路連線或設定中排除的路由，可能不會經過預期路徑；應用程式內建的代理也可能改變流量入口。先用明確指定代理的指令驗證規則，再回到瀏覽器或目標應用程式確認接管範圍，就能區分「規則設定錯誤」與「流量未進入核心」。

完成驗證後，再執行一次訂閱更新，確認規則是否保留。穩定的維護方式是：以本機覆寫儲存例外、由訂閱維護通用規則，並在末尾保留明確的兜底規則；每次修改後都以連線紀錄確認結果。完整設定欄位與流量接管方式，請參閱進階設定或說明中心。