規則分流 預計閱讀 12 分鐘

Clash 自訂規則設定教學：DOMAIN-SUFFIX、GEOIP 與 MATCH 的比對順序

整理常用規則語法，說明由上而下採用第一條符合規則的比對方式，並示範如何引用 rule-providers 及排解規則衝突。

先確認規則模式，再調整比對順序

將明確的例外規則放在前面，範圍較廣的規則放在後面，最後用 MATCH 接住其餘連線。Clash 會由上而下檢查一般規則清單，符合一條規則後便依該規則指定的策略處理，不會繼續尋找「更精確」的規則。規則寫得越具體，不代表優先順序就會自動提高。

修改前先確認用戶端處於規則模式。全域模式不會依這份一般分流清單決定連線出口；直連模式也無法用來驗證代理規則。各用戶端介面名稱可能不同，可在模式切換處選擇「規則」或「Rule」，並確認執行中的設定檔包含 mode: rule。

釐清規則、策略與實際出口

  • 規則：判斷連線是否符合條件，例如網域是否以 example.com 結尾。
  • 策略：決定由哪個項目處理，例如內建的 DIRECT、REJECT，或名為 PROXY 的策略群組。
  • 實際出口：策略群組目前選取的節點或直連項目。符合 PROXY 不代表一定會經過遠端節點，還要查看群組內的選擇。

本文中的 PROXY 是自訂群組名稱，並非所有設定檔都內建的策略。如果訂閱中的群組名稱是「節點選擇」，規則末尾就應引用這個確切名稱。名稱或大小寫不符，或缺少對應群組，都可能導致設定檔載入失敗。

辨別 DOMAIN、DOMAIN-SUFFIX 與 IP 規則

先依目標資訊選擇規則類型。網域規則適合用於網站與服務分流；IP 規則則適合固定位址、區域網路及地理 IP 判斷。一般格式為 類型,比對內容,策略；MATCH 沒有比對內容，因此只有兩個欄位。

類型 規則範例 比對範圍
DOMAIN DOMAIN,api.example.com,DIRECT 只比對這個完整網域
DOMAIN-SUFFIX DOMAIN-SUFFIX,example.com,PROXY 比對根網域及其子網域
DOMAIN-KEYWORD DOMAIN-KEYWORD,example,PROXY 比對網域中包含這段字串的目標
IP-CIDR IP-CIDR,192.168.0.0/16,DIRECT,no-resolve 比對指定的 IPv4 網段
GEOIP GEOIP,CN,DIRECT 依據 IP 資料判斷是否屬於 CN
MATCH MATCH,PROXY 接住前面未符合的連線

網域欄位只填主機名稱

使用 DOMAIN-SUFFIX,example.com,PROXY，不要寫成 https://example.com/path。這裡不填協定、路徑、查詢參數或連接埠，也不需要加上 *.example.com。後綴規則本身就涵蓋 example.com 和 www.example.com，但不會因為字串相似而比對到 notexample.com。

DOMAIN-KEYWORD 的比對範圍較廣。使用關鍵字 example，也可能比對到與目標網站無關的網域。只有確實需要字串比對時才使用；網站分流通常優先選擇完整網域或網域後綴。

分辨 IP-CIDR 與 GEOIP

IP-CIDR 會直接檢查位址是否落在指定網段內；GEOIP 則依賴核心載入的地理 IP 資料。後者只按目標 IP 的地理歸屬判斷，不依據網頁內容、網域註冊地或訪客所在位置。中文網站使用海外 CDN 時，也可能不符合 GEOIP,CN。

IPv6 網段應使用對應的 IP-CIDR6 規則，例如 IP-CIDR6,fc00::/7,DIRECT,no-resolve。不要只加入 IPv4 例外，就認定同一服務的 IPv6 連線也會使用相同出口。

依第一條符合規則的原則排列例外與兜底規則

先看一個明確的衝突案例：讓 api.example.com 直連，其餘 example.com 子網域則走代理。精確的例外規則必須放在網域後綴規則之前。

rules:
  - DOMAIN,api.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,PROXY
  - GEOIP,CN,DIRECT
  - MATCH,PROXY
  1. 連線至 api.example.com 時，符合第一條規則，直接選擇 DIRECT。
  2. 連線至 www.example.com 時，第一條不符合、第二條符合，交由 PROXY 處理。
  3. 連線至其他網域時，繼續檢查 IP 歸屬；符合 CN 條件便直連。
  4. 前面的規則都不符合時，最後一條 MATCH 會將連線交給 PROXY。

如果將前兩條規則對調，網域後綴規則就會先比對到 api.example.com，精確網域規則便不會再執行。若把 MATCH 放在第一條，結果更直接：後面的所有一般規則都不會有比對機會。

用可載入的最小設定檔確認名稱

以下結構用於示範設定項目之間的關係，不含遠端代理節點。為了引用 PROXY，範例建立了同名的選擇群組，並暫時只加入 DIRECT。因此，即使規則符合這個群組，最後仍會直連；實際使用時應保留訂閱中已有的節點與策略群組。

mixed-port: 7890
mode: rule
log-level: info

proxy-groups:
  - name: PROXY
    type: select
    proxies:
      - DIRECT

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

mixed-port: 7890 在此僅代表本機 HTTP/SOCKS 混合代理連接埠，並非規則比對條件。如果目前用戶端使用其他連接埠，測試時應以實際監聽的連接埠為準。修改現有設定時，也不要重複新增第二個頂層 rules:，應調整原有清單或使用用戶端提供的合併功能。

了解 GEOIP、DNS 與 no-resolve 的關係

先讓明確的網域規則完成比對，再考慮是否需要依 IP 判斷。連線只有網域、尚無可用的目標 IP 時，IP 規則可能會觸發解析。將常用的網域例外放在 GEOIP 之前，有助於清楚表達分流意圖，也能減少不必要的 IP 判斷。

no-resolve 並非停用 DNS

在支援此選項的 IP 規則末尾加上 no-resolve，表示不要為了檢查這條規則而主動解析網域。如果連線已帶有可用 IP，仍可據此判斷。這不會停用系統 DNS，也不保證後續處理連線時完全不進行解析。

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

這段設定與未加上 no-resolve 的版本，不一定會得到相同結果。如果尚無目標 IP，帶有此選項的 GEOIP 可能無法符合，請求便會繼續交由 MATCH 處理。不要只為了減少解析，就不加判斷地替所有 IP 規則加入這個參數。

核心未取得網域資訊時，網域規則無法憑空比對

應用程式可能直接連線至 IP，或自行透過加密 DNS 解析。這種情況下，連線記錄未必包含原始網域。TUN 接管網路流量，不代表一定能保留每個請求的網域資訊。設定正確的 Fake-IP 對應或嗅探功能，在符合條件時或許能協助還原網域資訊，但不能假設所有協定都能還原。

  • 先查看連線詳情中的主機名稱與目標 IP，確認核心實際取得哪些資訊。
  • 再檢查 DNS 請求是否依預期進入核心，避免應用程式與系統各自使用不同的解析路徑。
  • 最後再調整 DNS 或嗅探設定；不要一直新增網域規則，藉此掩蓋網域資訊缺失的問題。

使用 rule-providers 拆分規則檔

將需要重複維護的規則放入獨立檔案，再以 RULE-SET 引用。rule-providers 用來宣告規則來源，而在 rules 中的引用位置則決定優先順序。只宣告提供器卻未加以引用，這份規則不會自動參與分流。

在主要設定檔中宣告本機規則集

以下範例使用 mihomo 支援的本機檔案提供器，檔案路徑會相對於核心工作目錄解析。用戶端可能使用自己的設定目錄，因此請先確認核心工作目錄，再建立 rules/local-direct.yaml。

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

rules:
  - DOMAIN,api.example.com,PROXY
  - RULE-SET,local-direct,DIRECT
  - GEOIP,CN,DIRECT
  - MATCH,PROXY

規則檔中只寫比對條件

將以下內容儲存至上述路徑。classical 格式可包含網域、網段等規則條件；每條規則不必再填寫最終策略，因為策略已由主要設定檔中的 RULE-SET,local-direct,DIRECT 指定。

payload:
  - DOMAIN-SUFFIX,example.com
  - DOMAIN,intranet.example.net
  - IP-CIDR,192.168.0.0/16,no-resolve

依照此順序，api.example.com 會先符合主要設定檔中的精確規則，交由 PROXY 處理；其餘符合規則集條件的連線則走 DIRECT。如果將 RULE-SET 移到最前面，規則集中的網域後綴條件就會先比對到該 API 網域。

behavior: domain、ipcidr 與 classical 的內容格式各不相同，不能只修改宣告而保留不相容的檔案內容。使用他人提供的規則集時，請先確認格式、路徑及核心支援狀況，再重新載入並查看記錄。遠端提供器還涉及下載與更新狀態；若下載失敗，應先排查提供器，不要直接認定是規則順序有誤。

從連線記錄找出規則衝突

使用同一個目標建立新連線，並記錄「符合的規則、策略鏈、實際出口」三項資訊。不要只根據頁面能否開啟來判斷規則是否生效：快取、舊連線與策略群組的選擇，都可能讓結果看起來沒有改變。

  1. 確認流量已接管：開啟用戶端的連線清單並發起一次連線。如果沒有對應的連線，請先檢查系統代理、應用程式代理或 TUN 接管狀態，而不是繼續修改規則。
  2. 確認模式：檢查目前是否為規則模式，並確認啟用的是剛修改的設定檔。
  3. 找出第一條符合的規則：在連線詳情或記錄中查看規則類型與比對內容，並找出主要設定檔或規則集中對應的位置。
  4. 檢查策略鏈：確認群組內目前選取的項目。例如符合 PROXY，但群組內選的是 DIRECT，實際結果仍是直連。
  5. 重新建立連線：儲存並重新載入設定檔後，關閉測試目標的舊連線再試一次。規則更新後，既有連線通常不會自動更換出口。

透過指定的本機連接埠進行測試

如果混合代理實際監聽於 127.0.0.1:7890，可使用以下指令透過該連接埠發出請求。測試目標應選擇需要檢查的實際服務；此處保留的範例網域僅用來示範指令格式，不能代表你的連線狀況。

curl --proxy http://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com

若要透過 SOCKS 測試，並將網域交由代理端解析，可使用 socks5h。這與先在本機解析的測試方式可能提供不同的網域資訊，比較結果時應記錄所用的協定。

curl --proxy socks5h://127.0.0.1:7890 --connect-timeout 10 --max-time 20 -I https://example.com
狀況 優先檢查 調整方式
所有連線都符合 MATCH MATCH 的位置、目標是否有網域，以及前置規則是否已載入 將兜底規則移到末尾，並確認執行中的設定檔與連線中繼資料
精確網域例外未生效 前面的網域後綴、關鍵字或 RULE-SET 規則 將明確的例外規則移到會涵蓋它的規則之前
符合代理群組但仍然直連 策略群組目前的選擇及巢狀策略鏈 選擇所需的出口，再建立新連線
設定檔重新載入失敗 YAML 縮排、策略名稱、規則集路徑與格式 根據錯誤記錄找出欄位問題，還原可用設定檔後再逐項修改

保留訂閱更新後的自訂規則

優先使用用戶端明確支援的持久化覆寫、合併或自訂規則功能。直接編輯訂閱下載產生的設定檔，可能會在下次更新時遭到取代。不同用戶端的選單名稱與處理方式各異，請先確認該功能是修改來源設定檔、產生設定檔，還是只編輯一次執行中的結果。

確認最終執行的設定檔，而非只看編輯器中的內容

  • 檢查插入位置：「前置規則」適合放置精確例外；追加在 MATCH 後面的規則不會有比對機會。
  • 檢查陣列處理方式：有些合併方式會將規則附加到 rules，有些則會直接取代整份清單。請先用一條測試規則確認實際行為。
  • 確認名稱是否固定：訂閱更新若變更策略群組名稱，本機規則也要同步調整，避免引用不存在的策略。
  • 檢查提供器狀態：主要設定檔中的引用、提供器檔案與路徑都必須有效，缺少任何一項都可能影響載入。

每次只調整一種類型的規則，並在修改前後各保留一份可用設定檔。先驗證一個精確網域，再擴展至網域後綴或規則集。如此一來，便能分辨「規則未符合」、「符合了錯誤的策略」和「出口本身連線失敗」，訂閱更新後也更容易重新檢查。

下載最新版 Clash