Shadowrocket 規則類型詳解：DOMAIN、DOMAIN-SUFFIX、GEOIP、IP-CIDR、FINAL 的比對範圍

1. 規則生效條件：Config 與第一條符合的規則

規則類型說明「依據什麼條件比對」，行尾策略則說明「符合後如何處理」。兩者要分開看：DOMAIN,example.com,DIRECT 的條件是完整網域必須等於 example.com，結果是直連，並非將該網域加入某份固定的代理清單。

本文討論的是 Home → Global Routing → Config 下的分流。Proxy 與 Direct 分別用於全域代理、全域直連，不能用來驗證本文的規則順序；Scene 是依情境選擇路由的另一種模式，不在本次測試範圍內。在 Config 頁面還要選用實際修改的設定檔；只儲存未啟用的檔案，不會改變目前的分流方式。

在本文的一般規則範例中，符合第一條條件後就會執行該策略，不會繼續尋找「更精確」的下一條。精確比對不會自動優先於較寬泛的比對；優先順序取決於排列位置。

2. DOMAIN、DOMAIN-SUFFIX 與 DOMAIN-KEYWORD

這三種規則都以網域為比對對象，不適用於比對網頁路徑或查詢參數。造訪 https://example.com/docs?q=test 時，網域是 example.com；不能把 /docs 或 ?q=test 填入 DOMAIN 來篩選頁面。

DOMAIN：限定完整網域名稱

若只想讓 api.example.com 走代理，其他子網域維持原有策略，建議使用 DOMAIN。規則值只填網域，不加通訊協定前綴、連接埠或萬用字元。HTTPS 常用的目標連接埠 443 不屬於網域字串，因此 DOMAIN,example.com:443,PROXY 並非本文所需的寫法。

DOMAIN-SUFFIX：涵蓋主網域及其子網域

需要涵蓋整個網域樹時，請使用 DOMAIN-SUFFIX。它會依照網域層級邊界比對，而非任意比對字串結尾；example.com 可涵蓋 static.example.com，但不會包含 notexample.com。值通常直接填入 example.com，不要寫成 *.example.com。

DOMAIN-KEYWORD：比對網域中的字串片段

DOMAIN-KEYWORD 的比對範圍比後綴規則更難掌控，因為字串出現在網域的任何位置都可能符合。只有在確實需要依名稱片段分類，且能接受誤判風險時才使用。若實際目標只有單一主網域及其子網域，DOMAIN-SUFFIX 更容易檢查。

3. GEOIP 與 IP-CIDR：檢查目標 IP 位址

網域規則檢查名稱，GEOIP 與 IP-CIDR 則檢查位址。GEOIP 依據本機 IP 地理資料庫分類，例如 GEOIP,CN,DIRECT 表示目標 IP 若被資料庫歸類為 CN，就採用直連。它不會檢查網頁語言或網域註冊地，也不保證能辨識伺服器的實際所在地。

[Rule]
DOMAIN,api.example.com,PROXY
IP-CIDR,192.168.50.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

IP-CIDR 以網路前綴描述 IPv4 位址範圍。192.168.50.0/24 涵蓋 192.168.50.0 至 192.168.50.255；若只指定一台裝置，可使用 192.168.50.10/32。範例中的區域網路位址不是遠端服務位址，請依實際網路調整。

• 直接連線至 IP：目標本身已是位址時，可直接檢查它是否落在 IP-CIDR 範圍內。
• 透過網域連線：評估 IP 類規則時，可能需要先取得解析結果；DNS 回應、快取及連線重用都可能影響觀察結果。
• no-resolve：表示不會只為判斷這條 IP 規則而主動解析網域；這不代表停用整個 App 的 DNS，也不保證該規則會取得位址以供比對。
• IPv6：本文的 IP-CIDR 範例僅討論 IPv4。若目標實際使用 IPv6，應檢查相應位址系列的規則，不能依據 IPv4 網段推斷結果。

同一網域可能解析出多個位址，位址也可能隨網路環境改變。若需求是「這個網站始終採用某種策略」，通常可先考慮網域規則；只有在明確需要依目標網段或位址歸屬分類時，再使用 IP 類規則。

4. FINAL 與規則順序：例外優先、一般規則其次、最後兜底

FINAL 不需要填入網域或網段，負責處理前面的規則都未比對到的流量。FINAL,DIRECT 表示其餘請求直連，FINAL,PROXY 則表示其餘請求走代理。兩者適用於不同目的，沒有哪一種能脫離設定需求而被視為固定的正確答案。

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

這組規則會讓「只有介面網域走代理，同一網站的其他網域直連」。請求 api.example.com 會先符合 DOMAIN；請求 www.example.com 不符合第一條，但會符合 DOMAIN-SUFFIX；請求 example.net 則會落入 FINAL。

若加入 DOMAIN-KEYWORD,example,PROXY，還要確認它是否提早涵蓋了原本應直連的網域。檢查規則時，不要只搜尋目標網域是否存在，也要從檔案前段開始，確認所有可能先行符合的條件。

5. 在 Config 中修改並驗證規則

以下片段僅示範 [Rule] 區段，不能直接取代現有的完整設定檔。PROXY 使用目前已有的代理選擇；若設定檔引用自訂策略群組名稱，也必須確認對應群組確實存在。一次買斷用來購買 App，不等於購買連線方案；購買 App 不會自動提供代理連線參數。

1. 保留原始設定：進入 Config，先保留目前檔案的副本或匯出備份，並記下目前選用的設定檔。
2. 編輯目標檔案：開啟要修改的設定檔，找到現有的 [Rule] 區段，將一條明確的 DOMAIN 測試規則放在可能涵蓋它的規則之前，不要再新增重複的區段。
3. 儲存並選用：確認 Config 目前選用的是修改後的檔案，再返回 Home → Global Routing → Config。
4. 準備連線：確認 Home 已選取自己現有且可用的連線。若目標策略是 PROXY，可先執行 Connectivity Test；但測試通過不代表網站的所有資源都能存取。
5. 建立新請求：關閉舊網頁後重新開啟目標頁面；必要時可在允許中斷連線的情況下重新連線。已建立的長連線不適合用來驗證剛修改的規則。
6. 檢查記錄：查看本次請求的連線記錄，核對目標網域、目標 IP、符合的規則及實際採用的策略；每次只修改一項，再發出新請求比較結果。

本文以 example.com 說明語法界線，表格呈現的是規則邏輯推演，並非實際網路速度測試。正式測試時，請換成自己有權存取且確實會使用的目標網域。不要只憑頁面開啟速度判斷分流結果，網路延遲無法證明符合了哪條規則。

6. 無法存取：先區分 DNS、連線與規則問題

網頁出錯不代表規則語法有誤。先確認請求是否符合預期策略，再檢查該策略所使用的解析與連線路徑。以下兩項是 DNS 回應中的標準錯誤代碼，不是 Shadowrocket 固定顯示的彈出訊息；只有在實際診斷結果中出現時，才依相應情況處理。

若已解析出 IP，但連線仍逾時，接著要分辨 DIRECT 與 PROXY 兩條路徑。符合 DIRECT 時，檢查目前網路是否能連上目標；符合 PROXY 時，先確認目前代理可連線，再檢查代理到目標的連線路徑。反覆切換 FINAL 只能作為控制變因的對照測試，不能取代問題定位。

• 符合錯誤規則：檢查 Global Routing、目前使用的設定檔、規則順序及實際請求的網域。
• 符合正確規則但無法連線：檢查 DNS、目標連接埠、現有連線是否可用，以及目標服務的狀態。
• 部分頁面資源載入失敗：檢查各個失敗資源所使用的網域，不要只查看網址列中的主網域。

7. 規則寫法常見問題