先記住規則優先順序：由上而下比對，符合第一條就停止

Clash 自訂規則不是「寫得越精確就會自動排得越前面」，而是在規則模式下依清單順序逐條檢查：第一條符合的規則會決定連線使用哪個出站策略，後續規則不再參與判斷。因此，精確網域例外應放前面，網域後綴規則放後面，MATCH 則放在整份清單最後。調整順序通常比反覆更換節點，更能直接解決分流錯誤。

本文以 Clash 常見規則語法為基礎，談到規則集時會說明 mihomo（Clash Meta）的用法。不同用戶端的設定編輯入口、覆寫機制與核心版本各有差異，不能只看用戶端名稱就判定所有擴充欄位都能使用。建議先用 DOMAIN、DOMAIN-SUFFIX、IP-CIDR 和 MATCH 設定基本分流，確認比對結果後再逐步擴充。

系統代理與 TUN 模式決定流量如何進入核心；規則則決定流量進入後使用哪個出站策略。啟用 TUN 不會自動提高任何規則的優先順序；如果應用程式的流量沒有進入 Clash，即使規則寫對了，連線記錄中也不會出現。

規則基本格式：類型、比對內容、出站策略

規則通常放在 YAML 設定檔的 rules: 清單下。常見格式為 類型,比對內容,出站策略，部分類型可加上額外參數。清單項目前加上連字號，縮排使用空格，不要使用 Tab。以下是可加入現有設定檔的規則片段，並非包含節點、連接埠與 DNS 設定的完整檔案：

rules:
  - DOMAIN,login.example.org,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

此處的 DIRECT 代表直連，REJECT 代表拒絕連線，兩者都是內建的出站策略。範例使用保留的示例網域說明順序：login.example.org 直連，其他屬於 example.org 的網域則拒絕連線；未符合前面規則的連線，最後一律直連。

使用策略組時，名稱必須已存在於設定檔中

如果現有的 proxy-groups 中有名為「節點選擇」的策略組，就可以將某條規則的出站策略設為該名稱，例如 DOMAIN,api.example.org,節點選擇。不過這不是通用的內建名稱：若設定檔中沒有這個群組，直接照抄可能會導致設定檢查或載入失敗。

  • 整份設定檔只保留一個頂層 rules: 鍵，請在既有清單中插入規則，不要在檔案末尾重複新增同名鍵。
  • 複製規則時請使用半形逗號，避免全形逗號導致整行無法辨識。
  • 規則指向策略組後，實際使用的節點仍由該組的選擇或測速機制決定；規則是否符合與節點是否可用，是兩個不同的檢查環節。

DOMAIN 與 DOMAIN-SUFFIX：例外優先，範圍規則在後

類型規則範例比對範圍
DOMAINDOMAIN,api.example.org,DIRECT只比對這個完整網域
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.org,DIRECT比對根網域及其子網域
DOMAIN-KEYWORDDOMAIN-KEYWORD,example,REJECT比對網域中包含這段字串的連線

後綴不是任意字串結尾

DOMAIN-SUFFIX,example.org,DIRECT 可比對 example.org、www.example.org 和 a.b.example.org，但不應將 notexample.org 視為其子網域。若要涵蓋某個網域及其所有子網域，直接填入根網域即可，不要加上 https://、路徑或 *.。

規則中的網域不是完整 URL。https://example.org/account 含有通訊協定與路徑，不能直接用於 DOMAIN。一般網域規則也無法區分同一網站的 /account 與 /images 路徑；HTTPS 路徑屬於加密的應用層內容，因此網域分流不能用來依網頁路徑篩選。

使用關鍵字規則時，留意避免誤判

DOMAIN-KEYWORD 使用方便，但比對範圍往往比預期更廣。「example」可能出現在其他不屬於 example.org 的網域中。已知完整網域時，優先使用 DOMAIN；需要涵蓋整個網站網域時，使用 DOMAIN-SUFFIX。不要用過短的關鍵字取代明確的比對範圍。

rules:
  - DOMAIN,download.example.org,DIRECT
  - DOMAIN-SUFFIX,example.org,REJECT
  - MATCH,DIRECT

這個順序會讓下載子網域成為例外。如果把後綴規則移到第一行，下載網域也會先符合拒絕規則，後面較精確的 DOMAIN 就不會再有第二次判斷機會。Clash 不會自動將特定網域排到範圍較廣的規則之前。

IP-CIDR 與 no-resolve：分清目標位址與解析行為

IP-CIDR 會依目標 IPv4 位址所屬的網段進行比對，例如 IP-CIDR,192.168.1.0/24,DIRECT,no-resolve。其中 /24 是網路前綴長度，涵蓋 192.168.1.0 至 192.168.1.255；只比對單一 IPv4 位址時使用 /32。IPv6 則使用 IP-CIDR6，單一 IPv6 位址使用 /128。

rules:
  - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - IP-CIDR6,fc00::/7,DIRECT,no-resolve
  - MATCH,DIRECT

這些是常見私有位址範圍的例子，並非完整的特殊位址處理方案。企業網路、自建路由器與 VPN 可能使用其他網段；若目標網段必須透過公司隧道存取，不能只因為它是私有位址，就認定一般直連一定能連上。

no-resolve 不等於停用 DNS

連線帶有網域名稱，但尚無可供比對的實際目標 IP 時，IP 類規則可能會觸發解析，以判斷位址是否落在指定網段。加上 no-resolve 表示不為了這條規則額外發起網域解析。若已有可用的目標 IP，或應用程式原本就連線至 IP 位址，這條規則仍可比對。

反過來說，若要讓已知的內網 IP 流量直連，no-resolve 可避免這條網段規則額外觸發解析。它不會阻止應用程式自行查詢 DNS，也不代表建立連線時永遠不需要解析。Fake-IP、DNS 對應與嗅探設定都會影響核心可取得的資訊；排查問題時，請查看實際連線記錄。

MATCH 與規則集：兜底規則放在最後

MATCH 會無條件比對剩餘連線，因此主要只需要兩個欄位：MATCH,出站策略。若將它放在清單開頭，後續的網域規則、IP 規則與規則集都會失效。常見順序是「精確例外 → 分類規則 → 必要的位址規則 → MATCH」，但不同類別之間仍以實際清單順序為準。

規則集沒有獨立的優先順位

mihomo 支援透過 rule-providers 管理規則集，再以 RULE-SET 引用。規則集在 rules 中出現的位置，就是它參與比對的位置。規則集檔案再大，也不會自動排在前面的單條規則之前。

  • 若要讓某個網域略過特定規則集，請將該網域的精確規則放在對應的 RULE-SET 引用之前。
  • 使用前先確認 provider 名稱已經定義，並檢查 behavior 是否符合實際內容，例如網域集與 CIDR 集的內容格式就不相同。
  • 規則集更新失敗，與「沒有任何項目符合」是兩回事。請先查看載入記錄，再檢查規則順序。

原版 Clash 的不同分支與 mihomo，在規則集格式、邏輯規則及其他擴充功能上各有差異。切換核心時，不要只複製 RULE-SET 那一行；也要一併檢查 provider 定義，並使用目前核心提供的設定檢查功能確認是否支援。

兜底直連或代理，取決於目標策略

本文片段使用 MATCH,DIRECT，是為了讓範例不依賴任何外部策略組，不代表所有訂閱都應以直連兜底。日常使用若要讓未分類的連線走代理，請將最後一條改為已存在的代理策略組名稱。先保留訂閱原有的兜底設定，再逐步加入局部例外，通常更容易找出變更造成的影響。

更新訂閱後規則消失：檢查覆寫位置與合併順序

直接修改用戶端下載的訂閱 YAML，下一次更新時可能會被遠端內容覆蓋。較適合長期維護的方式，是使用用戶端提供的本機覆寫、合併設定或腳本功能。各用戶端的選單與合併方式並不一致，請先到目前訂閱的操作選單確認本機擴充設定入口；不要假設所有「編輯」按鈕都會永久保存覆寫內容。

  1. 先備份目前可用的設定。記下已啟用的訂閱、目前模式與原本的最後一條規則，避免測試後無法還原。
  2. 先加入一條便於觀察的精確規則。例如暫時拒絕自己用於測試的網域，不要一次新增數百條規則。
  3. 檢查最後生效的設定。如果合併後自訂規則被加在原有 MATCH 之後，即使檔案中有這條規則，也不會比對到。
  4. 重新載入後，再更新一次訂閱。確認本機規則仍存在且位置正確，才算完成持久性驗證。

覆寫工具可能會取代清單、將內容置於前方或追加到後方，三種結果完全不同。整份取代 rules 會刪掉訂閱原有的分流邏輯；單純追加則可能排在兜底規則之後。弄清楚用戶端的合併方式，比只確認「儲存成功」更重要。

規則無效時的排查順序：模式、連線、比對結果、出站

確認修改是否生效，不要只看網頁能不能開啟。快取、既有長連線與瀏覽器重用連線都會影響觀察結果。重新載入規則後，先關閉目標網站的舊連線，再發起新請求；必要時可在用戶端的連線清單中結束相關連線，不必先中斷所有正常運作的應用程式。

狀況優先檢查處理方式
沒有目標連線記錄應用程式是否使用系統代理、TUN 是否確實接管流量先排除流量入口問題，不要繼續修改比對規則
連線顯示 Global 或直連模式策略目前的代理模式切換至規則模式後，重新建立連線
顯示符合 MATCH網域是否一致、IP 是否可用、規則是否已載入核對連線詳細資訊與最終規則清單
符合範圍較廣的後綴規則精確例外規則是否排在後面將例外規則移至範圍較廣的規則之前
符合預期策略，但請求失敗策略組目前選用的節點及目標連線狀況區分分流成功與出站連線失敗

使用相同目標進行修改前後比較

如果目前的混合連接埠確實設為 7890，可以使用以下指令，讓單次請求明確經由本機 HTTP 代理送出；若實際連接埠不同，請使用用戶端顯示的數值。Windows 可使用 curl.exe，避免 PowerShell 舊版本中同名別名造成混淆。此指令僅用於測試請求，不保證固定延遲或成功率：

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

接著在連線詳細資訊中核對目標網域、符合的規則、策略組與最終出站。這項測試驗證的是明確指定的 HTTP 代理連線，不等於驗證 TUN 接管或 UDP 轉送。若應用程式直接連線至 IP，網域規則可能缺少比對所需的網域名稱；在支援的協定與設定下，mihomo 的嗅探功能可以補足資訊，但無法保證還原所有加密流量的網域名稱。

穩妥的維護順序是：保留已知可用的設定，每次只修改一小批規則，確認新連線的比對記錄，再驗證訂閱更新後設定仍會保留。若要繼續設定訂閱、DNS 或 TUN 模式，請參閱Clash 完整手冊；遇到常見連線問題，可先查看常見問題，避免把所有網路故障都歸咎於規則語法。