Clash 自訂規則設定教學：規則類型、比對順序與手機覆寫技巧

先確認規則模式、目標策略與核心

Clash 自訂規則用來決定「這條連線要交由哪個出站處理」，而不是建立代理節點。規則符合後，可以交由內建的 DIRECT、REJECT，也可以交由設定中已存在的節點或策略組。策略組再決定實際使用哪個出站，因此「規則符合代理組」不一定代表「最後透過代理節點連線」：該組也可能選擇直連。

修改前先檢查以下三項。這些項目會決定規則能否載入、能否參與判斷，以及符合後會交由哪個策略處理。

執行模式：切換至規則模式，介面通常會顯示「規則」或 Rule。全域模式與直連模式不會依照下方的一般規則清單逐條分流。
策略名稱：在設定的 proxy-groups 中確認目標組名，大小寫、空格與中文都必須一致。名稱有誤通常會導致設定載入失敗。
核心類型：確認用戶端使用的是原版 Clash、Clash Meta 或 mihomo。Meta 分支後來更名為 mihomo，不能因此推定新增的規則與規則集格式也適用於舊核心。

常見規則類型與基本語法

多數規則採用「規則類型、比對內容、目標策略」的格式，各欄位以英文逗號分隔。MATCH 不需要比對內容，直接填寫目標策略即可。YAML 中每條規則都是一個清單項目，請使用空格縮排，不要混用 Tab。

rules:
  - DOMAIN,example.com,DIRECT
  - DOMAIN-SUFFIX,example.org,出站選擇
  - DOMAIN-KEYWORD,example,出站選擇
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - GEOIP,CN,DIRECT
  - MATCH,出站選擇

這段程式碼用來示範語法，並不是可獨立執行的完整訂閱設定。合併至現有設定時，只保留一個頂層 rules 欄位，並確認每條規則都符合實際需求。

類型	比對內容	使用要點
`DOMAIN`	完整網域	`example.com` 不包含 `www.example.com`。
`DOMAIN-SUFFIX`	網域及其子網域	填寫 `example.com` 即可，不必加上 `*.`。
`DOMAIN-KEYWORD`	網域中的關鍵字	比對範圍比網域後綴更廣，容易一併納入無關網域。
`IP-CIDR` / `IP-CIDR6`	目標 IPv4 / IPv6 網段	比對的是目標位址，不是手機目前連線的 Wi-Fi 網段。
`GEOIP`	目標 IP 的地理資料庫分類	結果取決於資料庫中的 IP 歸屬紀錄，不代表營運公司的註冊地。
`RULE-SET`	規則提供者中的項目	名稱必須對應 `rule-providers` 中的定義。
`MATCH`	所有尚未符合規則的連線	通常放在清單末尾作為預設規則。

網域規則不填完整網址

若要比對 https://www.example.com/account，應填寫網域 www.example.com，不要把 https://、路徑或查詢參數放進 DOMAIN。一般網域規則不是 URL 路徑篩選器，也無法據此區分同一 HTTPS 網域下的不同頁面。

DOMAIN-SUFFIX,example.com,DIRECT 可涵蓋根網域與子網域，但不會把 notexample.com 視為該網域的子網域。若只要處理單一登入介面，建議使用精確網域，避免對整個網域後綴設定範圍過大的直連或拒絕規則。

IP 規則與 no-resolve 的差異

連線帶有網域名稱，卻沒有可供判斷的實際目標 IP 時，IP 類規則可能會觸發 DNS 解析。結尾的 no-resolve 表示不要只為了這條規則主動解析網域；若已有可用的目標 IP，仍可進行比對。它不是關閉 DNS 的總開關，也不代表「這條規則一定會生效」。

因此，GEOIP,CN,DIRECT,no-resolve 與不加該參數的寫法，對同一條網域連線可能會得出不同結果。遇到中國大陸網域未符合 IP 規則時，應先查看記錄中的網域、目標 IP 與 DNS 行為，而不是反覆更換節點。

比對順序：符合第一條規則後立即生效，精確規則應放前面

對本文列出的常見規則而言，Clash 會由上而下逐條比對，符合第一條規則後就採用對應策略，不會繼續往下尋找「更精確」的規則。規則類型本身沒有自動優先順序：寫在後面的 DOMAIN 不會自動優先於前面的 DOMAIN-SUFFIX。

rules:
  - DOMAIN,login.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,出站選擇
  - MATCH,出站選擇

login.example.com 符合第 1 條規則，交由直連處理。
www.example.com 不符合第 1 條，改由第 2 條規則處理。
example.net 未符合前兩條規則，由第 3 條作為預設處理。

如果對調前兩條規則，登入網域會先符合後綴規則，後面的精確直連規則便不會生效。排查「Clash 自訂規則新增後沒作用」時，先查看前面是否有範圍更廣的規則，不要只檢查剛新增的項目。

為什麼 MATCH 應該放在最後

MATCH 會接手所有先前未符合規則的連線。放在它後面的普通規則就沒有機會執行。建議依照「明確例外 → 服務或業務規則集 → 一般地區規則 → MATCH」的方式整理，再按實際需求調整；這是方便維護的組織方式，並非核心強制規定的分類順序。

RULE-SET：規則提供者與引用位置都要檢查

RULE-SET 會將一組比對條件放進獨立檔案，再由主規則清單引用。它不會跳過清單順序：引用寫在第幾行，這組規則就會在該位置參與比對。提供者名稱、行為類型、檔案格式與檔案內容都必須相互吻合。

以下是 mihomo 的本機檔案範例。先在核心可存取的設定目錄中準備 ./rules/local-direct.yaml，再加入提供者定義。手機版能否寫入該目錄取決於用戶端，不能只把檔案留在系統的「下載」資料夾，就假設核心讀得到。

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

rules:
  - RULE-SET,local-direct,DIRECT
  - MATCH,出站選擇

對應的規則檔案內容如下。classical 項目保留規則類型，但不填寫目標策略；此處由主設定中的 RULE-SET,local-direct,DIRECT 統一指定目標策略。

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

behavior: domain：用於網域集合，項目寫法須遵循對應的網域集合語法，不要直接放入上方 classical 格式的內容。
behavior: ipcidr：用於 IP 網段集合，不適合混放網域規則。
behavior: classical：用於包含規則類型的項目，適合本文這種混合網域與 IP 條件的範例。

遠端提供者還需要設定下載網址、快取路徑與更新間隔。更新訂閱與更新規則提供者是兩回事：主訂閱更新成功，不代表每個外部規則檔案也都已更新。手機版若只有兩三條例外規則，直接新增一般規則通常比增加提供者更容易排查。

手機版覆寫訂閱：保留遠端來源，另行管理本機規則

遠端訂閱是設定來源，用戶端覆寫則是在載入設定時進行本機調整。直接編輯訂閱產生的 YAML，可能會在下次更新時被覆蓋。較穩妥的做法是保留原訂閱，並透過用戶端提供的設定覆寫、規則管理或擴充設定入口儲存本機規則。

Android 用戶端操作檢查順序

開啟目前使用的設定詳細資料，先確認實際執行的是哪一份訂閱。不要修改了備用設定，卻繼續測試另一份設定。
找出該用戶端的規則管理或覆寫入口，確認支援「前置規則」、清單合併，還是只能整段取代。不同 Android 用戶端的選單名稱並不一致。
先新增一條精確規則，例如 DOMAIN,example.com,DIRECT。不要同時修改 DNS、TUN 和十幾條規則。
儲存並重新載入設定，確認是否出現未知策略、YAML 解析失敗或規則提供者載入失敗。
更新一次原訂閱，再確認這條本機規則是否仍位於最終規則清單前段。能儲存一次，不代表訂閱更新後仍會保留。

若入口要求填寫「合併 YAML」，請先查看它如何處理陣列。rules 是陣列：有些合併工具會取代整個陣列，有些則支援前置或附加。直接貼上只有一條規則的 rules: 區段，可能會覆蓋訂閱原有的整套規則。覆寫格式取決於用戶端功能，並沒有適用於所有手機版的通用前置欄位。

iOS 用戶端先確認設定格式，再考慮移植規則

iOS 上不同代理用戶端的設定語法、模組與本機規則機制各有差異，不能只因為都支援訂閱，就認定它們都能直接執行 Clash YAML。請先確認用戶端明確支援的格式；若使用其他規則語法，應在其原生規則入口新增對應條件，而不是整段貼上 rules:。

系統 VPN 權限的用途是讓用戶端接管流量，並不會將 Clash 規則轉換成其他設定格式。如需選擇安裝方式，可先查看手機用戶端選擇指南，再依所選用戶端確認設定格式與覆寫功能。

規則未生效的排查方式：查看連線記錄，不只看網頁結果

網頁能否開啟，會同時受到 DNS、節點可用性、伺服器狀態與既有連線影響。驗證規則時，應在用戶端的連線或記錄頁面查看目標網域、符合的規則、策略組與最後使用的出站。只看到頁面變快或變慢，無法證明某條規則已經生效。

狀況	優先檢查	處理方式
儲存設定後無法載入	縮排、英文逗號、策略組名稱	還原最後一次修改，從單條規則重新驗證。
規則存在，但一直未符合	執行模式、前方的廣泛規則、MATCH 位置	切換回規則模式，並將測試規則移到適當的前置位置。
已符合代理組，但連線仍是直連	策略組目前的選擇與巢狀群組	沿著策略鏈檢查最後是否選到 DIRECT。
網域規則未能比對	連線記錄中是否有網域名稱	確認 DNS 與流量接管方式，不要只看瀏覽器網址列。
訂閱更新後規則消失	修改的是來源檔案，還是獨立覆寫設定	移至用戶端支援的持久覆寫入口，再測試更新後是否保留。

TUN / VPN 流量接管與規則比對是兩個步驟

啟用 TUN 或系統 VPN，只代表具備接管流量的條件，並不保證所有應用程式流量都會進入核心。Android 的分應用程式設定、略過應用程式清單與用戶端路由設定，都可能讓特定應用程式直接繞過。未進入核心的連線，自然不會符合設定中的規則。

另一個常見問題是核心只能看到 IP，無法取得網域名稱。應用程式內建的加密 DNS、直接連線至固定 IP，以及 DNS 接管設定的差異，都可能影響網域資訊。mihomo 的網域嗅探可在適用的通訊協定中協助辨識，但無法保證識別所有加密連線；請先了解目前的 DNS 設定，再決定是否啟用相關功能。也可參考DNS 技術參考釐清相關概念。

每次只修改一項，並建立新連線

修改規則後，舊連線可能繼續使用建立時的出站。儲存並重新載入後，應關閉相關應用程式的舊連線或重新開啟應用程式，再查看新建立的連線記錄。建議依序測試：「新增一條精確規則 → 確認規則符合 → 更新訂閱 → 再次確認」。發生異常時，請還原上一份可用設定，不要直接清除應用程式資料。