進階設定 閱讀時間約 11 分鐘

Clash 自訂規則

了解 Clash 規則的三段式語法與由上而下的比對順序，掌握規則集、MATCH 最後兜底，以及規則未生效時的排查方式。

規則優先級：先比對，再選出口

Clash 規則不會依網域精確程度自動排序，而是按照設定中的順序由上而下比對，符合後便停止。精確網域、網域後綴與規則集之間，沒有「精確規則自然優先」的隱藏排序。因此，例外規則放前面、通用規則放後面，並將 MATCH 放在最後，是最容易維護的排列方式。

還要分清兩個階段：規則決定連線交由哪個策略處理，策略組再決定使用哪個出口。如果規則命中「業務策略」，但該組目前選中 DIRECT，連線仍會直連。這不是規則失效，而是策略組的實際選擇與預期不同。

順序顛倒會有什麼影響

rules:
  - DOMAIN-SUFFIX,example.org,業務策略
  - DOMAIN,login.example.org,DIRECT
  - MATCH,業務策略

存取 login.example.org 時，第一條後綴規則已經命中，第二條精確直連規則就不會執行。將兩條規則對調後，登入子網域才會先命中 DIRECT。這裡的「更精確」只是維護設定時的排序依據，並不是核心會代替使用者執行的排序演算法。

三段式語法與網域比對範圍

常見規則的格式為 類型,比對內容,目標策略。逗號分隔的是規則欄位，行首的連字號則是 YAML 清單語法，兩者不要混淆。目標可以是內建策略 DIRECT、REJECT，也可以是設定中已定義的節點或策略組名稱。

常見規則寫法與比對範圍
類型範例說明
DOMAINDOMAIN,login.example.org,DIRECT只比對這個完整網域，不包含其他子網域。
DOMAIN-SUFFIXDOMAIN-SUFFIX,example.org,業務策略比對根網域及其子網域，不會比對 notexample.org。
DOMAIN-KEYWORDDOMAIN-KEYWORD,example,業務策略依網域中的字串比對，涵蓋範圍通常比後綴規則更廣。
IP-CIDRIP-CIDR,192.168.0.0/16,DIRECT,no-resolve比對目標 IPv4 位址所屬的網段，末尾可加上解析控制參數。
RULE-SETRULE-SET,work-domains,業務策略引用已定義的規則提供器，符合其中任一適用項目時，就交由指定策略處理。
MATCHMATCH,業務策略不需要比對內容，用來兜底處理前面規則都未符合的連線。

不要把網址直接填入網域規則

DOMAIN-SUFFIX 後面應填 example.org，而非 https://example.org/path。通訊協定前綴、連接埠、路徑和查詢參數都不屬於網域的一部分。一般網域規則也無法只讓同一網站的 /video 路徑走代理、卻讓 /account 直連；在 HTTPS 加密下，常規分流不會依完整 URL 路徑判斷。

後綴比對會遵循網域標籤邊界。example.org 和 api.example.org 都會符合上述後綴規則，但 example.org.other.net 不會。若要讓同一網域家族使用相同策略，優先採用後綴規則，避免範圍過廣的關鍵字誤判名稱相似的網站。

RULE-SET：引用位置決定優先級

rule-providers 用來宣告規則來源；只有在 rules 中加入 RULE-SET，才會將規則集納入比對流程。只下載規則檔，卻未在主規則清單中引用，不會自動產生分流效果。反過來說，引用不存在的提供器名稱，也會造成設定載入或規則初始化錯誤。

mihomo 本機 domain 規則集範例

以下示範檔案型規則提供器。路徑會以核心的工作目錄為基準解析，不一定是編輯器中開啟的設定檔所在位置；使用桌面客戶端時，應先確認實際採用的工作目錄。範例中的「業務策略」必須已存在於目前設定的 proxy-groups 或節點清單中。

rule-providers:
  work-domains:
    type: file
    behavior: domain
    path: ./rules/work-domains.yaml

rules:
  - DOMAIN,login.example.org,DIRECT
  - RULE-SET,work-domains,業務策略
  - MATCH,業務策略

對應檔案 rules/work-domains.yaml 的內容如下：

payload:
  - '+.example.org'
  - 'api.example.net'

在這種 domain 規則集格式中，+.example.org 涵蓋根網域及其子網域，api.example.net 則代表精確網域。第一個登入網域例外仍會優先，因為它排在 RULE-SET 前面。即使調換規則檔中的兩個項目，也不會改變這條外部直連例外的優先級。

behavior 必須與檔案內容相符

  • behavior: domain：內容應為網域比對項目，不能直接放入完整的 DOMAIN-SUFFIX,example.org,業務策略 三段式規則。
  • behavior: ipcidr：內容應為 IP 網段，例如 192.168.0.0/16，而不是網域清單。
  • behavior: classical：可使用 DOMAIN-SUFFIX,example.org 等規則表示式；出口策略由外層的 RULE-SET 指定，不必在每條 payload 後重複加入。

遠端提供器還需要正確的下載網址、更新設定，以及可寫入的本機儲存位置。更新成功只代表來源可取得，並不保證內容格式符合 behavior。排查時應同時查看提供器載入記錄與比對記錄，而不只是確認「更新時間」有沒有變動。

設定排列順序：例外、通用規則、兜底

以下是主規則清單的範例，並非完整的訂閱檔案。此範例假設前文的 work-domains 提供器和「業務策略」都已定義。合併至現有設定時，應修改原有的 rules 清單，不要在檔案末尾再建立第二個同名的頂層鍵。

mode: rule

rules:
  - DOMAIN,login.example.org,DIRECT
  - DOMAIN-SUFFIX,example.net,業務策略
  - RULE-SET,work-domains,業務策略
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - 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
  - MATCH,業務策略

這個範例將網域策略排在私有 IP 規則之前，代表已識別的業務網域優先使用業務策略。若目標是「任何私有 IP 位址都先直連」，就應將私有 IP 規則移到前面；但也要考量當時是否已知目標 IP，以及是否允許觸發 DNS 解析。規則排序反映實際政策取捨，沒有一份適用於所有網路的固定清單。

no-resolve 不會停用所有 DNS

IP-CIDR 末尾的 no-resolve，表示不會為了比對這條 IP 規則而主動發起網域解析。連線已有目標 IP 時，仍可比對網段；若只有網域、沒有可用的目標 IP，這條規則就不會為了自身比對而額外解析。它不會禁止瀏覽器解析，也不會關閉 mihomo 的 DNS 模組。

上述 IPv4 私有網路範例也不代表涵蓋所有區域網路情境。IPv6 目標須考慮 IP-CIDR6；區域網路的單標籤主機名稱則牽涉本機 DNS。TUN 排除路由屬於流量接管層的設定，不能只憑幾條 DIRECT 規則，就推定所有本機流量都會繞過虛擬網卡。

MATCH 提前會截斷後續規則

MATCH 沒有篩選條件，若放在清單第一行，就會接住所有進入這份清單的連線。後續規則即使語法正確，也不會有機會執行。通常只在清單末尾保留一條兜底規則，並明確指定交由哪個策略處理；不要依賴缺少兜底時的隱含行為，來判斷設定是否符合預期。

Clash 自訂規則未生效的排查順序

  1. 確認流量有進入核心。只有由系統代理、應用程式代理或 TUN 接管的連線，才有機會符合規則。未由系統代理接管的程式，不會因為新增網域規則就自動連上 Clash。
  2. 確認目前使用的設定檔。在客戶端的「訂閱」或「設定」頁面確認選取的項目，再確認運作模式為規則模式。選單名稱會因客戶端而異，不要將某個客戶端的設定路徑套用到所有產品。
  3. 檢查實際載入的規則順序。訂閱合併、覆寫或腳本可能會把自訂規則加到 MATCH 後面。編輯介面中的位置，不一定等同於最終執行設定中的位置。
  4. 檢查名稱與縮排。業務策略 和 業務代理 是兩個不同名稱；提供器鍵名也必須完全相符。YAML 使用空格縮排，請勿混用定位字元。
  5. 建立新連線後再觀察。已建立的 HTTP/2、HTTP/3 或 WebSocket 連線可能會繼續沿用原本的出口。套用設定後，請關閉對應連線或重新啟動目標應用程式，再進行測試。
  6. 比對命中規則與實際出口。在連線詳細資訊中，同時查看目標主機、規則類型、規則內容與策略鏈。只看到出口節點變動，無法證明連線命中預期的規則。

先明確透過代理連接埠測試一次

若目前設定明確指定 mixed-port: 7890，可以使用下方指令，讓請求經過此 HTTP 代理入口。7890 只是此處的範例連接埠，並非所有客戶端的固定值，請以實際設定為準。-q 用來略過使用者的 curl 設定檔；--noproxy "" 則可避免環境中的略過清單干擾測試。

curl -q --noproxy "" --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  --head https://example.org/

這個指令只是建立一條方便定位問題的測試連線，不是效能實測數據。請求失敗時，先區分是代理連接埠拒絕連線、DNS 錯誤、出口連線失敗，還是遠端 HTTP 回應；不能只憑逾時就判定規則語法有誤。收到的頁面狀態也不能取代規則命中記錄。

如果 curl 命中正確規則，但瀏覽器連線到同一網域時沒有出現在記錄中，請先檢查瀏覽器是否使用代理、是否沿用舊連線，以及相關流量是否由其他擴充功能接管。DNS 快取可能影響目標位址，但「清除快取」不能取代對接管方式和運作設定的檢查。

訂閱更新與規則維護

直接修改由訂閱產生的設定，下一次更新時可能會被遠端內容覆蓋。較穩妥的做法是使用客戶端支援的覆寫、合併或腳本機制，將少量例外規則保存在本機。具體機制取決於客戶端，驗收時只需確認兩點：自訂規則是否仍存在，以及是否排在通用規則和 MATCH 之前。

每次修改只驗證一個目標

  • 先加入精確網域：使用一條 DOMAIN 規則，確認規則入口和策略名稱都有效，再視需求擴大為後綴規則。
  • 再移至規則集：確認單條規則運作正常後，再放入符合 behavior 的檔案，以便區分語法問題與來源問題。
  • 最後處理例外：將登入、公司內網等例外規則放在會涵蓋它們的通用規則之前；不要一直追加重複規則，而應先整理順序。
  • 更新後再次確認：重新開啟最終規則清單，分別為一個例外網域和一個一般網域建立新連線，核對命中規則與出口。

Clash 自訂規則的關鍵不在數量，而在比對範圍、清單順序與出口設定彼此一致。先確認流量進入核心，再檢查最終規則位置，最後確認策略組選擇，通常比反覆切換節點更容易找出問題。若要了解特定客戶端的流量接管與設定匯入方式，可參閱客戶端使用教學；規則類型與核心功能則可查閱協定手冊。

下載Clash依平台選擇客戶端