Shadowrocket 規則設定入門：DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD、GEOIP、IP-CIDR、FINAL 匹配方式

一、規則生效前：確認 Global Routing 與設定檔

規則寫在設定檔的 [Rule] 區段中。只有請求進入依設定分流的處理流程，調整這個區段的順序才有意義。先前往 Home → Global Routing 查看目前選項，不要只根據頂端的連線開關判斷規則是否生效。

Config 用於管理設定檔，Home 用於查看連線狀態與 Global Routing。Settings → On Demand 用來管理依條件觸發連線的行為，不會將 DOMAIN 改成其他匹配類型，也不能取代規則排序。排查時，應分開記錄「是否啟動連線」與「請求命中哪條規則」。

二、DOMAIN、DOMAIN-SUFFIX、DOMAIN-KEYWORD 的匹配範圍

這三類規則檢查網域，不檢查網頁內容，也不依 URL 路徑分流。規則中的網域欄位不加 https://，不加 /login，也不要把連接埠寫進主機名稱。存取 https://api.example.com:8443/login 時，用於網域匹配的對象是 api.example.com。

DOMAIN 適合單獨處理完整主機名稱。DOMAIN-SUFFIX 會依網域層級匹配根網域及子網域，填入 example.com 即可，不必寫成 *.example.com。DOMAIN-KEYWORD 會檢查網域中的關鍵字，匹配範圍比單一根網域廣，可能連名稱相似但隸屬不同的網域也一併匹配。

三、GEOIP 與 IP-CIDR：匹配目標 IP，而非網域文字

GEOIP 會根據目標 IP 在地理位置資料庫中的歸屬進行匹配。例如 GEOIP,CN,DIRECT 表示對資料庫歸類為 CN 的目標位址採用 DIRECT。它不會依頁面顯示的文字、網域後綴或使用者所在位置判斷；資料庫中的地理歸屬也不等於網站營運主體所在地。

IP-CIDR 用於匹配 IPv4 位址範圍。192.0.2.0/24 表示前 24 位固定的網段，涵蓋 192.0.2.0 至 192.0.2.255；192.0.2.8/32 則只涵蓋一個位址。這些位址屬於文件範例範圍，不能用來驗證真實服務是否連線正常。

IP-CIDR,192.0.2.8/32,REJECT,no-resolve
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• no-resolve 表示不要只為了匹配這條 IP 規則而發起網域解析；已有可用的目標 IP 時，仍可進行位址匹配。
• 網域請求遇到需要 IP 資訊的規則時，DNS 解析可能影響後續判斷。解析失敗不代表規則關鍵字拼錯。
• 網站可能會傳回多個位址，位址也可能變動。針對一次性的解析結果設定單一 IP 規則，不代表涵蓋整個網站。
• IP-CIDR 用於 IPv4。不要直接將 IPv6 位址套用到這個關鍵字，並沿用 IPv4 遮罩。

上述範例將單一位址規則放在整個網段之前。因此，目標為 192.0.2.8 時會先命中 REJECT，不會再套用後面的網段規則 DIRECT。這反映的是書寫順序，並非系統會自動賦予 /32 較高優先順序。

四、由上而下命中即停止，FINAL 放在最後

對本文列出的普通規則，核心原則是由上而下檢查；命中後便執行該條策略，不再以後續普通規則重新選擇。精確匹配不會自動排在寬泛匹配之前。需要設定例外時，請將例外規則提前。

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-KEYWORD,telemetry,REJECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

1. 請求 login.example.com 時，第一條規則已命中，因此採用 DIRECT。
2. 請求 img.example.com 時，第一條不匹配，第二條命中，因此採用 PROXY。
3. 請求 telemetry.example.com 時，第二條規則先命中，第三條不會再執行。若要拒絕此請求，應將相應的拒絕規則移到第二條之前。
4. 未命中前面規則的請求，最後會套用 FINAL,PROXY。FINAL 沒有網域或位址欄位，語法只有關鍵字與策略。

若將 FINAL 放在前面，後面的普通規則便不會有機會接受檢查。維護設定時，只保留一條明確的最終兜底規則，並將它放在最後。不要靠不斷追加重複規則來修正順序問題；應先找出已提前命中的規則。

上述設定用於說明匹配順序，並非通用分流清單。套用至現有設定前，請確認每條策略都符合自身需求，並保留原設定檔副本。

五、PROXY、DIRECT、REJECT 各自的作用

規則最後一個主要欄位會決定命中後的處理方式。關鍵字決定「匹配什麼」，策略決定「如何處理」，兩者不能互換。本文假設使用者已有自己的服務商與連線設定，不提供、不銷售，也不推薦節點、訂閱或其他連線服務。

PROXY 不是協定名稱。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 是連線設定涉及的協定，不能直接取代此處的基本策略寫法。規則命中 PROXY 也無法證明目標服務可連線，仍須分別檢查連線參數、DNS 與遠端狀態。

DIRECT 不代表略過 Shadowrocket 的規則判斷，而是命中後選擇直接連線。若 REJECT 導致網頁或資源載入失敗，可能正是預期結果；如果誤拒絕登入介面，即使網頁主體能開啟，也不代表整個網站功能正常。

六、在 Config 中修改，再以新請求驗證

建議每次只修改一條規則或調整一次順序，驗證無誤後再繼續。訂閱更新主要涉及使用者已有的伺服器清單，不代表目前啟用設定檔的 [Rule] 區段已修改。遠端設定再次更新時，也可能覆蓋本機變更，因此測試前應先儲存副本。

1. 保留原設定檔

   進入 Config，確認目前啟用的檔案，並先儲存一份可還原的副本。記下原本的 Global Routing 設定，避免測試結束後忘記還原。

2. 編輯規則區段

   在 Config 中開啟目標檔案的編輯功能，找到 [Rule]。將單一主機的例外規則放在網域後綴規則之前，將 FINAL 留在最後，欄位之間以半形逗號分隔。

3. 確認已啟用

   儲存後，在 Config 確認啟用的是修改後的檔案。返回 Home → Global Routing，選擇 Config，並確認 Home 中的連線狀態。

4. 重新發出請求

   關閉測試頁面後重新開啟；必要時重新建立連線，以免沿用已建立的長連線。查看連線記錄中可取得的目標網域、目標 IP、命中規則與策略資訊。

5. 確認命中項目

   如果實際策略與預期不同，請從命中位置往上檢查範圍較廣的規則。若命中正確但仍無法存取，請再檢查 DNS、既有代理參數與目標服務，不要繼續盲目調整順序。

七、分層排查規則未生效與存取錯誤

先分清「未依預期命中」和「已命中但連線失敗」。前者優先檢查 Global Routing、目前使用的檔案與規則順序；後者則檢查解析及連線流程。Home → Connectivity Test 的結果，無法單獨證明特定網域的所有網頁請求都能順利完成。

以上是 Apple 網路錯誤代碼的含義，並非 Shadowrocket 所有介面都會顯示的固定提示。若記錄中沒有出現這些原文，請依照實際錯誤訊息排查，不要只因頁面一直轉圈，就判定為同一種錯誤。