Shadowrocket 規則語法入門：DOMAIN、DOMAIN-SUFFIX、GEOIP、IP-CIDR、FINAL 的匹配範圍

一、先分清匹配條件與連線動作

一條規則通常由「類型、匹配值、動作」組成，欄位之間以英文逗號分隔。例如 DOMAIN,example.com,DIRECT 表示：當可供匹配的目標網域正好是 example.com 時，選擇 DIRECT。規則不會建立可用的代理連線；選擇 PROXY 後，仍須確認既有連線項目的位址、連接埠與協定參數正確。

PROXY 表示透過代理連線至外部，DIRECT 表示直接連線至目標，REJECT 表示拒絕連線。這些不是 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard 這類協定名稱。協定決定如何建立代理連線；規則則決定哪些目標使用哪種連線策略，兩者屬於不同層次。

以下操作說明使用 iPhone / iPad 上的 Home、Config 與 Global Routing 介面名稱。測試 Config 規則前，請在 Home → Global Routing 選擇 Config；Proxy 或 Direct 是全域路由模式，不能用來驗證同一份 Config 規則是否依預期逐條命中。Scene 涉及情境設定，也不應直接視為 Config 的同義詞。

二、DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD

這三種類型都以網域為匹配對象，但涵蓋範圍不同。DOMAIN 匹配完整網域；DOMAIN-SUFFIX 包含指定網域本身及其子網域；DOMAIN-KEYWORD 則檢查網域是否包含指定字串。規則中的網域不需加入 https://、路徑、查詢參數或連接埠。

DOMAIN-SUFFIX 依據網域層級匹配，不是比對任意字元結尾，因此 notexample.com 不屬於 example.com 的子網域。DOMAIN-KEYWORD 則沒有這種層級界線。使用 ads 等短字串可能會涵蓋原本不想處理的網域，不能把「名稱包含某個詞」直接等同於「已確定連線用途」。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,telemetry,REJECT
FINAL,DIRECT

在上例中，api.example.com 先命中 DOMAIN，因此走 DIRECT；www.example.com 未命中第一條規則，會在第二條選擇 PROXY。這裡的 telemetry 只是字串匹配範例，不能據此判斷實際連線內容或用途。若要拒絕已確認的網域，建議優先使用範圍較明確的 DOMAIN 或 DOMAIN-SUFFIX。

三、GEOIP 與 IP-CIDR：依目標 IP 判斷

GEOIP 依據 IP 資料庫中的歸屬資訊匹配目標位址，常見寫法為 GEOIP,CN,DIRECT。CN 是資料庫使用的地區代碼，不是網域後綴；同一個網域也可能因 DNS 回傳不同位址而得到不同的 IP 匹配結果。

IP-CIDR 使用網段描述位址範圍。/24 表示前 24 位固定；/32 表示單一 IPv4 位址。以下以文件範例網段說明語法，並非可供連線的伺服器，也不需要將這些項目加入日常設定。

[Rule]
IP-CIDR,192.0.2.8/32,DIRECT,no-resolve
IP-CIDR,198.51.100.0/24,PROXY,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• 192.0.2.8/32 只匹配這個 IPv4 位址，不包含 192.0.2.9。
• 198.51.100.0/24 表示從 198.51.100.0 到 198.51.100.255 的位址範圍，但不代表這些位址都能作為主機使用。
• no-resolve 表示不要只為了匹配這條 IP 規則而觸發網域解析；它不是關閉整個應用程式 DNS 的開關。
• 若目前只有網域，尚未取得可用的目標 IP，含有 no-resolve 的 IP 規則可能無法命中。排查時請確認連線當下實際具備哪些資訊。

IP-CIDR 不會檢查連接埠。同一個目標 IP 的 TCP 443 與 TCP 8443 都可能命中同一條網段規則；如果 443 可用而 8443 連線失敗，單靠修改網段遮罩無法解決。IPv6 位址應使用相應的 IPv6 規則類型，不要直接套用本文的 IPv4 範例。

四、由上而下匹配，FINAL 放在最後

規則不會依關鍵字的「精確程度」自動排序。DOMAIN 不會自然優先於 DOMAIN-SUFFIX：如果範圍較廣的後綴規則先命中，後面的精確網域規則就不會執行。編排原則是將確實需要優先處理的例外放前面，涵蓋範圍較廣的規則放後面。

[Rule]
DOMAIN,download.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

1. 目標是 download.example.com：命中第一條，選擇 DIRECT，不再檢查第二條。
2. 目標是 docs.example.com：第一條未命中，第二條命中，選擇 PROXY，不再檢查 GEOIP。
3. 目標不屬於上述網域，但資料庫將目標 IP 歸類為 CN：在 GEOIP 規則選擇 DIRECT。
4. 前面的規則都未命中：使用 FINAL,PROXY，將其餘連線交由代理連線。

FINAL 不含網域或網段欄位，格式為 FINAL,動作，而不是 FINAL,example.com,PROXY。它匹配先前尚未處理的連線，通常放在規則末尾。若將 FINAL 放在前面，後續一般規則便沒有匹配機會。

五、在 Config 中修改並驗證規則

測試規則的前提是已有自己的服務商與訂閱。Home 中的 Subscribe 連線項目與 Config 中的分流設定並非同一份內容：更新連線訂閱不能證明新規則已載入，修改 Config 也無法修正錯誤的協定密碼或伺服器連接埠。修改前請先保留原設定，避免同時更新連線參數與路由規則。

1. 備份設定

   開啟 Config，找到目前使用的設定，透過該項目的操作選單匯出備份。記下原先選取的設定，測試時使用副本，並保留可還原的原始檔。

2. 編輯規則

   在 Config 開啟測試設定的編輯入口，找到 [Rule]。若該區段已存在，請勿重複新增區段名稱；將一條明確的 DOMAIN 規則插入 FINAL 之前，然後儲存。

3. 選取設定

   返回 Config，確認選取的是剛修改的設定；接著前往 Home → Global Routing 選擇 Config，並確認 Home 中目前使用的連線項目。

4. 建立新連線

   關閉目標頁面後重新開啟；必要時中斷連線再重新連線。既有的長連線可能沿用原本的連線狀態，因此不能將儲存規則後仍存在的舊連線當成驗證結果。

5. 核對記錄

   查看連線記錄或日誌中的目標網域、目標 IP 與實際策略。每次只調整一處；若結果異常，請還原備份，再比較修改前後的規則順序。

驗證時先用可控的完整網域測試 DOMAIN，再擴大到 DOMAIN-SUFFIX。不要一開始就加入很短的 DOMAIN-KEYWORD，否則難以判斷哪些目標受到影響。若應用程式的請求只顯示 IP，也不能假設網域規則一定有足夠資訊可供匹配。

六、分開排查連線錯誤與規則錯誤

「網頁無法開啟」本身不能證明規則語法有誤。先確認實際連線策略是否符合預期，再逐步檢查連線層。以下是連線診斷或底層日誌中可能出現的錯誤文字；各平台與系統顯示的完整提示可能不同，這些都不是固定的規則解析錯誤訊息。

• 規則未命中：確認 Global Routing 設為 Config、已選取正確設定、沒有被上方項目提前匹配，再確認目標實際上是網域還是 IP。
• 命中後連線失敗：保留正確規則，檢查目前連線的協定、連接埠與認證參數。TLS 類型的連線也應確認系統時間與伺服器名稱設定。
• 儲存後出現異常：檢查英文逗號、欄位數量、[Rule] 區段位置與動作名稱；先還原為已知有效的規則，再逐條加入新項目。
• 結果偶爾不同：記錄 DNS 回傳的位址。GEOIP 與 IP-CIDR 依據實際目標 IP 判斷；CDN 回傳不同位址時，不能只根據瀏覽器網址列判斷結果。

七、規則語法常見問題