Clash 自訂規則語法詳解：匹配順序、優先級與規則覆蓋

Clash 的規則系統負責回答一個具體問題：新的連線應交給哪個策略群組、代理節點或直連動作。多數「規則未生效」並非語法完全錯誤，而是連線先被較前面的規則匹配、修改內容寫入了會在訂閱更新時被替換的檔案，或測試流量根本沒有進入目前運作中的核心。

閱讀規則時，應將網域名稱、目標 IP、程序、連接埠與網路協定視為不同的匹配條件。規則清單不會依「看起來更具體」自動排序，也不會因為某一條寫得更長就取得更高優先級。實際判斷通常會沿著 rules 清單由上往下進行，首次匹配後立即採用該規則指定的策略，後續規則不再參與這條連線的判斷。

匹配模型：連線如何走到某條規則

應用程式發起存取後，Clash 或 mihomo 核心需要取得目標資訊。對於瀏覽器代理請求，核心通常可以直接看到目標網域；對於部分透明代理或 TUN 流量，核心可能先取得目標 IP，再結合 DNS 對應、嗅探結果與連線中繼資料還原網域。可用資訊不同，同一組規則在不同接管方式下也可能呈現不同的匹配結果。

假設規則清單依序包含某個完整網域的直連規則、該網域所屬後綴的代理規則，以及最後的兜底規則。存取完整網域時，第一條規則已經匹配，後綴規則不會再執行。若將後綴規則放在前面，它會先接管整個子網域範圍，後面的完整網域例外便會失去作用。這也是撰寫規則時通常將狹窄範圍的例外放在寬範圍規則之前的原因。

rules:
  - DOMAIN,updates.example.com,DIRECT
  - DOMAIN-SUFFIX,example.com,節點選擇
  - MATCH,漏網之魚

在上述範例中，updates.example.com 走直連，其他以 example.com 為後綴的網域進入「節點選擇」，其餘連線交給「漏網之魚」。這裡的「節點選擇」與「漏網之魚」必須是設定中實際存在的策略群組名稱；名稱中的中文、空格與大小寫都應與 proxy-groups 定義保持一致。

規則匹配與節點可用是兩個階段

規則匹配只決定將連線送往何處，並不保證策略群組中所選的節點一定可用。例如日誌顯示連線已匹配「節點選擇」，但頁面仍無法開啟，問題可能出在策略群組目前的選項、節點連通性、DNS 回應、TLS 交握或上游網路。反過來，節點測速正常也不能證明自訂網域規則已經匹配。測速使用的位址與實際存取目標往往不同，應分別驗證。

常用規則語法與適用範圍

經典規則通常採用逗號分隔格式：第一段是規則類型，中間部分是匹配內容，接著是目標策略，末尾可帶有該類型支援的附加參數。不同核心與客戶端版本支援的規則類型並不完全相同，尤其是程序、入站、規則集合與邏輯組合相關功能。編輯前應確認客戶端使用的是傳統 Clash 核心，還是 Clash Meta（mihomo）核心，並以該核心的設定文件與運作日誌為準。

DOMAIN：精確網域

DOMAIN 只匹配指定的完整主機名稱，適合設定單一例外。它不會自動涵蓋該網域的其他子網域。例如：

- DOMAIN,api.example.com,DIRECT

這條規則可以匹配 api.example.com，但不會匹配 img.api.example.com。如果一個網站同時使用主站、介面、圖片與下載等多個子網域，需要逐一列出，或改用後綴規則涵蓋整個網域範圍。

DOMAIN-SUFFIX：網域後綴

DOMAIN-SUFFIX 用於匹配某個網域及其子網域，適合網站層級的分流：

- DOMAIN-SUFFIX,example.com,節點選擇

它可以涵蓋 example.com、www.example.com 以及更深層的子網域。後綴規則範圍較廣，若需要讓其中一個更新網域走直連，應將對應的 DOMAIN 例外放在它前面。

DOMAIN-KEYWORD：網域關鍵字

DOMAIN-KEYWORD 會檢查網域中是否包含指定文字。寫法簡短，但誤匹配範圍通常比預期更大。例如關鍵字 music 可能匹配多個彼此無關的網域。除非目標網域結構經常變動且具有穩定特徵，否則應優先使用精確網域或網域後綴。

- DOMAIN-KEYWORD,example,節點選擇

IP-CIDR 與 IP-CIDR6：目標位址段

IP-CIDR 匹配 IPv4 位址段，IP-CIDR6 匹配 IPv6 位址段。它們適合內網、固定服務位址與明確公布的網路段：

- IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
- IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
- IP-CIDR6,fd00::/8,DIRECT,no-resolve

no-resolve 表示匹配這條 IP 規則時，不為了取得 IP 而額外解析網域。它常用於私有位址段等只需檢查現有目標 IP 的情境。是否加入此參數應依規則目的決定：如果希望網域連線解析後也參與某個 IP 段判斷，就不能機械式地為所有 IP 規則加上 no-resolve。

GEOIP、GEOSITE 與規則資料

GEOIP 會根據目標 IP 所屬的地理資料庫分類進行匹配；mihomo 的常見設定也會使用 GEOSITE 對網域集合進行分類。這類規則依賴客戶端載入的地理資料檔案，匹配結果也會受資料版本影響。它們適合作為大範圍分類工具，但不代表每個網域與位址都能永久維持相同的歸屬。需要穩定例外時，仍應在分類規則之前加入精確規則。

- GEOSITE,category-ads-all,REJECT
- GEOSITE,cn,DIRECT
- GEOIP,CN,DIRECT
- MATCH,節點選擇

傳統 Clash 分支未必支援相同的 GEOSITE 寫法或資料載入方式。若設定檢查提示未知規則類型，應先確認核心能力，而不是反覆調整縮排。

連接埠、網路協定與程序規則

DST-PORT 可依目標連接埠進行分流，NETWORK 可區分 TCP 與 UDP。程序規則可依程式名稱或路徑匹配，但取決於作業系統權限、核心實作，以及客戶端是否提供相關中繼資料。在行動系統、受限沙箱與某些透明代理環境中，核心不一定能可靠取得程序資訊。

- DST-PORT,22,工作線路
- NETWORK,UDP,低延遲線路
- PROCESS-NAME,example.exe,DIRECT

連接埠規則應謹慎放置。像 443 這類通用連接埠承載大量不同服務，若將它放在網域規則之前，幾乎所有 HTTPS 連線都可能被提前接管。程序規則同樣不宜只憑程式名稱處理安全邊界，因為應用程式可能呼叫其他系統程序發起連線。

順序與優先級：為什麼更精確的規則也會失效

規則清單沒有自動計算的「精確度優先級」。DOMAIN 不會天然優先於前面的 DOMAIN-SUFFIX，較小的 IP 網段也不會自動優先於前面的大網段。只要前面的規則已符合條件，目前連線就不會繼續向下查找。因此，自訂清單通常按照「明確例外、具體分類、寬範圍集合、地理分類、最終兜底」的順序組織。

1. 本機與必要直連例外：區域網路位址、路由器管理網域、企業內網或明確要求直連的更新服務。
2. 精確網域與程序例外：用於覆蓋後續的後綴規則、規則集合或地理分類。
3. 網站層級後綴規則：將一組穩定的子網域交給同一項策略。
4. 規則集合：維護較大規模的網域、位址段或服務分類。
5. GEOIP、GEOSITE 等寬範圍判斷：處理未被前面規則涵蓋的連線。
6. MATCH 兜底：接收仍未匹配的剩餘流量，並放在清單末尾。

MATCH 表示匹配剩餘連線，因此它後面的普通規則在實際運作中通常沒有機會生效。有些舊設定使用 FINAL 表達類似的兜底含義，但不同核心接受的名稱可能不同。遷移設定時不要只替換文字，應先執行設定驗證並檢查核心日誌。

同一網域可能產生多條連線

網頁存取不是單一請求。主文件、靜態資源、影片、統計介面與第三方登入可能來自不同網域，HTTP/3 也可能使用 UDP。看到主網域匹配預期策略，並不代表頁面涉及的所有連線都採用相同路線。排查某個網站時，應在連線清單或日誌中觀察實際失敗的主機名稱、目標連接埠、網路協定與匹配規則，而不是只為網址列中的網域新增一條規則。

DNS 結果會影響 IP 規則觀察

網域規則依據核心掌握的主機名稱判斷，IP 規則則依賴目標位址。若應用程式自行加密解析、直接連線至已快取的 IP，或 TUN 嗅探未還原網域，日誌中可能只出現 IP。此時網域規則未必具備可用的匹配條件。相反地，在 fake-ip 模式下，核心會維護虛擬位址與網域之間的對應，不能只憑連線介面顯示的位址判斷真實上游 IP。應結合 DNS 模式、日誌中的網域欄位與最終規則名稱一併分析。

規則集合與 RULE-SET：拆分大規模設定

當規則數量較多時，mihomo 等核心可透過 rule-providers 定義外部規則集合，再在主規則清單中使用 RULE-SET 引用。這樣可以將網域分類、位址段與主設定分開維護。規則集合不會自動取得更高優先級；它在主 rules 清單中的引用位置，仍決定何時參與匹配。

rule-providers:
  work-services:
    type: http
    behavior: classical
    format: yaml
    path: ./ruleset/work-services.yaml
    url: https://example.com/rules/work-services.yaml
    interval: 86400

rules:
  - DOMAIN,intranet.example.com,DIRECT
  - RULE-SET,work-services,工作線路
  - GEOIP,CN,DIRECT
  - MATCH,節點選擇

behavior 用來說明集合內容的組織方式。常見值包括 classical、domain 與 ipcidr。經典集合可以容納帶有類型的規則項目；網域集合與位址段集合則要求內容符合對應格式。若集合宣告為 domain，卻放入完整的經典規則字串，提供器可能下載成功但解析失敗，或在設定檢查階段直接報錯。

遠端集合還涉及更新時間、快取路徑與網路可達性。首次啟動時若集合尚未下載，而目前設定又依賴它，客戶端可能提示初始化失敗。排查時應查看提供器狀態、最後更新時間與解析錯誤，不要只測試集合 URL 是否能在瀏覽器中開啟。URL 可存取只能表示檔案可下載，不能證明其內容格式符合目前核心的要求。

多個集合重疊時如何決定

兩個規則集合可以包含相同網域或相交的位址段。決定結果的不是集合更新時間，也不是集合中的項目數量，而是兩個 RULE-SET 引用在主規則清單中的先後位置。需要覆蓋公共集合時，可以先放置本機精確例外，再引用自己的小型集合，最後引用範圍更廣的公共集合。

rules:
  - DOMAIN,build.example.com,DIRECT
  - RULE-SET,my-exceptions,專用線路
  - RULE-SET,public-services,節點選擇
  - MATCH,漏網之魚

這種結構比直接複製並修改大型公共集合更容易維護：例外清楚可見，公共集合更新時也不需要重新合併整份檔案。

訂閱更新、覆寫與設定持久化

許多桌面與行動客戶端會將遠端訂閱下載為本機設定檔。直接編輯這份產生的檔案雖然可能立即生效，但下一次自動更新、手動重新整理或切換訂閱時，修改內容常會被新內容取代。穩定的做法是使用客戶端提供的覆寫、合併、擴充腳本或本機設定功能，將自訂規則儲存在訂閱檔案之外。

不同客戶端對「前置規則」「後置規則」與「合併規則」的處理方式不同。前置規則通常適合精確例外，因為它們需要排在訂閱規則之前；後置規則若被追加到訂閱內建的 MATCH 後面，就不會產生實際效果。使用覆寫介面後，應開啟最終產生的設定或運作日誌，確認規則確實插入預期位置。

策略群組名稱也屬於依賴項目

自訂規則引用了「工作線路」，最終設定就必須存在同名策略群組。訂閱提供者更改群組名稱、客戶端轉換設定或合併腳本重新命名策略群組後，規則可能指向不存在的目標並導致載入失敗。較穩妥的方式是讓自訂策略群組也透過同一套持久化機制注入，並避免依賴經常變動的顯示名稱。

修改後需要重新載入運作設定

儲存 YAML 檔案不一定會讓正在運作的核心立即採用新規則。部分客戶端會自動重新載入，部分客戶端則需要點選套用、重新選擇設定或重新啟動核心。判斷是否成功重新載入，可以查看設定更新時間、核心日誌與連線詳情中的規則變化。既有長連線可能繼續沿用建立時的路徑，測試時應關閉相關應用程式的連線、重新整理頁面或等待舊連線結束。

自訂規則未生效的分層檢查

排查應從「目前到底運作了什麼」開始，再逐步檢查匹配條件。頻繁修改 DNS、切換 TUN、變更節點與重新安裝客戶端會同時引入多個變數，反而難以確認問題來源。以下順序適用於網域規則、IP 規則與規則集合的大多數故障。

1. 確認目前使用的是正確設定。

   檢查客戶端目前選取的訂閱或設定名稱，以及最後載入時間。若有多個設定副本，請確認修改的檔案就是核心目前讀取的檔案。

2. 先執行設定驗證。

   查看客戶端的設定檢查結果與核心啟動日誌。重點關注 YAML 縮排、逗號分段、未知規則類型、重複鍵、規則集合解析失敗，以及不存在的策略群組。

3. 確認流量已進入 Clash。

   系統代理關閉、應用程式繞過代理、內建代理設定覆蓋系統設定，或 TUN 未啟動時，連線不會經過規則引擎。連線清單完全看不到測試流量時，通常應先檢查接管方式。

4. 查看實際匹配的規則。

   在連線詳情或日誌中找出目標網域、目標 IP、程序、連接埠、網路協定、規則類型與策略名稱。若匹配了前面的寬範圍規則，應調整順序，而不是重複新增相同網域。

5. 檢查網域與 IP 條件是否可見。

   日誌只有 IP 時，網域規則可能缺少匹配資訊；網域已經匹配時，則無需繼續懷疑後面的 IP 規則。請結合 DNS 模式、嗅探設定與應用程式行為進行判斷。

6. 檢查策略群組目前的選項。

   規則送入正確的策略群組後，確認群組內目前選擇的是具體節點、自動測試群組、直連還是拒絕動作。策略群組選擇錯誤與規則順序錯誤，表面上可能呈現相同結果。

7. 排除舊連線與快取。

   關閉測試應用程式現有的連線，必要時清除應用程式 DNS 快取，再發起一次新連線。規則主要在建立連線階段判斷，已存在的工作階段不會因清單變更而自動重新匹配。

8. 驗證訂閱重新整理後的結果。

   手動更新一次訂閱，確認自訂規則仍然存在且位置沒有變動。若重新整理後消失，應移轉至客戶端支援的覆寫或合併功能。

最小化測試比整份設定更容易定位問題

面對上千條規則時，可以暫時新增一條足夠精確、策略結果明顯的測試規則，並放在清單前部。例如為測試網域指定一個獨立的策略群組，再觀察新連線的匹配記錄。測試完成後移除該規則，避免長期留下只用於診斷的分流項目。

rules:
  - DOMAIN,test.example.com,診斷線路
  - RULE-SET,main-services,節點選擇
  - GEOIP,CN,DIRECT
  - MATCH,漏網之魚

若最前面的精確規則仍未出現匹配記錄，應優先檢查流量是否經過目前的核心、網域是否與實際請求一致，以及設定是否已成功重新載入。若它可以匹配，但原有規則無法匹配，則繼續比較規則位置、類型與目標資訊，不必先修改網路底層設定。

可維護的規則清單：從能用到容易複查

長期設定不應只追求規則數量。每增加一條寬範圍規則，都應說明它涵蓋哪些情境、為何位於目前位置，以及是否會與現有集合重疊。對於只有少量例外的使用者，一組精確網域加上穩定兜底，通常比堆疊多個來源相近的大型集合更容易判斷。

• 將區域網路、企業內網與裝置管理位址放在明確的直連區域。
• 將單一網域例外放在對應的後綴、關鍵字與規則集合之前。
• 避免以通用連接埠規則取代網域分類，尤其不要過早匹配 80、443 等常見連接埠。
• 為規則集合選擇與內容一致的 behavior，並定期檢查更新與解析狀態。
• 確保 MATCH 位於末尾，且其目標策略群組確實存在。
• 透過客戶端覆寫儲存個人化規則，避免直接依賴訂閱產生的檔案。
• 修改後重新載入設定，並使用新連線核對日誌中的實際匹配項目。
• 遷移至 mihomo 或更換客戶端時，重新確認規則類型與擴充語法的支援情況。

一份清晰的規則設定，應能由上而下說明每個階段：先處理哪些例外，再進入哪些分類，最後由誰接收剩餘流量。只要掌握首次匹配、資訊可見性、最終設定與策略群組狀態這四個檢查點，多數規則覆蓋問題都能在日誌中找到直接線索。

如果還在熟悉訂閱匯入、系統代理、TUN 與 DNS 的關係，可以繼續查看本站的使用手冊與設定教學。規則只負責分流決策，完整連通仍取決於客戶端接管方式、DNS 設定與策略節點共同運作。