Shadowrocket（小火箭）自訂規則應在 Global Routing 的 Config 模式下驗證：具體例外放前面，範圍規則放後面，FINAL 放最後。本文適合已有可用設定、需要調整分流的使用者，依序說明規則語法、策略差異、排列方式與驗證步驟；範例使用保留用示例網域，不提供任何服務連線資料。
一、規則優先順序：依序比對，不是先比精確度
Shadowrocket 會依設定中的順序檢查規則。連線命中某條規則後，就會套用該規則指定的策略，不再繼續尋找後面「更精確」的規則。網域規則不會自然優先於 IP 規則，單一網域規則也不會自動排在網域後綴規則之前。需要設定例外時，應由規則編寫者將例外移到前面。
例如，希望 login.example.com 使用 DIRECT，而 example.com 及其他子網域使用 PROXY，請依照以下順序排列。若調換前兩行，連線到登入網域時就會先命中 DOMAIN-SUFFIX，後面的 DOMAIN 無法改變已做出的選擇。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT結論：先移動例外，再新增規則
精確規則看似沒有生效時，先檢查它上方是否已有涵蓋相同目標的規則；將必要的例外移到涵蓋規則之前，再建立新連線測試，避免不斷新增重複規則。
二、PROXY、DIRECT、REJECT：決定如何處理連線
規則前半段決定「比對什麼」，最後的策略則決定「如何處理」。PROXY 代表交由代理路徑處理，實際出口仍取決於目前選用的伺服器或設定中的策略安排；DIRECT 代表直接連線至目標，不經代理出口；REJECT 則會拒絕符合條件的連線。這些不是 Shadowsocks、VMess、VLESS 或 Trojan 等協定名稱，也不是連線品質的等級。
| 策略 | 規則範例 | 需確認的條件 |
|---|---|---|
PROXY | DOMAIN,api.example.com,PROXY | 代理設定有效，且選用的伺服器可正常使用。 |
DIRECT | DOMAIN,printer.example.com,DIRECT | 目前的網路可以直接連到目標，且網域解析結果正確。 |
REJECT | DOMAIN,blocked.example.com,REJECT | 該網域確實需要封鎖，而不是登入或載入資源所需。 |
DIRECT 不代表連線一定成功。目標拒絕存取、本地網路無法連線，或 DNS 回傳錯誤位址時，直連仍會失敗。同樣地，PROXY 命中只代表規則選擇了代理路徑，不表示一定能連上遠端服務。排查時應分別確認「規則是否選對路徑」與「該路徑是否實際可用」。
三、Global Routing：使用 Config 驗證自訂規則
先前往 Home → Global Routing 確認目前的模式，再判斷規則是否生效。Config 會依目前設定中的規則分流；Proxy 和 Direct 適合用來對照連線路徑，不能證明特定自訂規則已命中。Scene 涉及情境選擇，初次排查時不要同時切換情境，否則測試條件容易改變。
Config
建議使用目前啟用設定中的規則。各規則可選擇 PROXY、DIRECT 或 REJECT；未命中的連線則由 FINAL 處理。
適用情況：編輯並驗證自訂規則，保留不同目標之間的分流差異。
Proxy
將流量交由代理路徑處理。暫時切換後，可檢查相同目標是否能經代理連線，但這不代表目前規則清單中的規則已命中。
適用情況：與 Config 的結果對照，檢查代理路徑本身是否可用。
Direct
將流量交由直連路徑處理。若結果與 Config 不同，應回頭檢查規則與記錄，而不是立刻更換協定。
適用情況：暫時檢查目前網路能否直接連到目標。
完成對照後，應切回 Config。Settings → On Demand 用來管理隨選連線條件，不會重新排列規則；啟用後也不會讓 FINAL 後方的規則重新生效。測試期間請維持網路與連線狀態穩定，避免同時進行自動連線、切換網路與編輯規則。
四、常見規則語法：網域、IP 範圍與 FINAL
常見規則的欄位以半形逗號分隔，不要使用全形逗號。網域比對欄位只填網域，不包含 https://、連接埠或 URL 路徑。例如，存取 https://api.example.com:443/v1 時，DOMAIN 對應的目標是 api.example.com，不是整個網址；443 是此範例連線的連接埠，不屬於網域欄位。
| 關鍵字 | 有效寫法範例 | 比對範圍與注意事項 |
|---|---|---|
DOMAIN | DOMAIN,api.example.com,PROXY | 比對完整網域，不會自動涵蓋其子網域。 |
DOMAIN-SUFFIX | DOMAIN-SUFFIX,example.com,PROXY | 比對 example.com 及其子網域；不要寫成 *.example.com。 |
IP-CIDR | IP-CIDR,192.168.0.0/16,DIRECT,no-resolve | 比對 IPv4 位址範圍；/16 表示前 16 位是網路前綴。 |
GEOIP | GEOIP,CN,DIRECT | 依據 IP 地理資料庫判斷，不是根據網域後綴判斷。 |
FINAL | FINAL,PROXY | 沒有目標欄位，會處理前面規則都未命中的連線。 |
IP-CIDR 後的 no-resolve 表示不會為了比對這條規則而主動觸發網域解析。因此，不能將它理解為「所有網域都會先解析，再檢查這個位址範圍」。測試區域網路裝置時，應分別驗證直接存取 IP 與使用裝置網域名稱的情況，並留意 DNS 回傳的是公用位址還是內網位址。
GEOIP 依據 IP 歸屬資訊判斷，結果不等同於頁面內容、網域後綴或營運主體所在地。若某項服務必須使用固定路徑，明確設定網域規則並放在 GEOIP 之前，會比依據 IP 歸屬間接判斷更容易確認。
- 字元檢查：確認關鍵字、半形逗號與策略欄位完整，避免複製時帶入全形符號。
- 範圍檢查：
DOMAIN-SUFFIX,example.com不會比對notexample.com，也不代表某個 URL 子目錄。 - 位址檢查：
192.168.0.0/16是私有位址範圍的範例，不代表目前的區域網路一定使用這個範圍。 - 備援檢查：通常應保留一條有效的 FINAL，並將它放在有效規則清單的最後。
五、建議排列方式：具體例外在前，FINAL 在後
以下規則範例方便理解排列順序：先讓指定的登入網域直連，再拒絕另一個指定網域，接著處理整個網域後綴；之後處理私有位址範圍與地理位置規則，最後交由 FINAL 處理。此範例說明的是排列方式，不是適用於所有網路的通用設定，請依實際目標調整或刪減。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
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
GEOIP,CN,DIRECT
FINAL,PROXY這個順序體現「具體例外優先」，但不代表網域規則永遠都要排在 IP 範圍規則之前。若明確要求所有區域網路目標都直連，也要確認網域規則是否可能先將解析到區域網路的目標送往 PROXY，並配合 DNS 行為調整。規則順序應符合實際需求，不應將單一範本視為固定優先順序。
- 存取 login.example.com：命中第一條 DOMAIN 規則並執行 DIRECT，後面的網域後綴規則不再比對。
- 存取 blocked.example.com：命中第二條規則並執行 REJECT；將它移到網域後綴規則下方，結果就會不同。
- 存取 api.example.com：前兩條規則皆不符合，接著命中 DOMAIN-SUFFIX 並執行 PROXY。
- 直接存取 192.168.1.1：若前面的網域規則均未命中，就會符合對應的私有位址範圍並直連。
- 存取其他目標：接著檢查 GEOIP；仍未命中時才交由 FINAL 處理。
FINAL,PROXY 與 FINAL,DIRECT 都是有效的備援設定，差別在於未識別的目標預設使用哪種連線路徑。FINAL 不是連線失敗後的重試機制：若前面已命中 PROXY，但代理連線失敗，不會因此跳過該規則再執行 FINAL。若要變更連線失敗時使用的路徑，應修改相關規則或修復所選的連線。
六、編輯與驗證：每次只修改一個條件
以下操作以 iPhone / iPad 的介面用詞為準。規則屬於 Config 中啟用的設定檔；Home 中的伺服器清單變動，不代表規則檔案也已更新。編輯前請保留一份原始設定，並確認修改的是本機檔案，還是可能遭遠端更新覆蓋的檔案。
-
確認模式
前往 Home → Global Routing，選擇 Config。記下目前選用的伺服器，測試期間不要同時更換連線出口。
-
確認檔案
前往 Config，確認目前啟用的設定檔。先保留原始內容再編輯；若修改的是另一份未啟用的檔案，目前連線的分流不會改變。
-
調整順序
在設定中的規則內容找到 [Rule]，將具體例外放在涵蓋範圍更廣的規則之前，並確認 FINAL 位於最後。只複製規則行時，不要在現有的 [Rule] 中重複插入區段標題。
-
儲存並重新連線
儲存後確認已啟用修改過的設定，必要時重新連線。關閉舊測試頁面或結束舊連線，再送出新的請求，避免沿用編輯前已建立的連線。
-
確認結果
在連線記錄或日誌中查找目標網域、目標 IP 與實際套用的策略。記下測試目標、命中結果和存取狀況，再決定是否繼續修改。
可用三種目標建立精簡測試組：一個預期使用 DIRECT、一個預期使用 PROXY，以及一個沒有專屬規則、預期交由 FINAL 處理的目標。若要測試 REJECT，再新增一個明確的封鎖測試。不要只憑網頁能否開啟判斷規則是否正確，因為 DIRECT 與 PROXY 都可能成功，頁面也可能沿用快取。
結論：依命中記錄區分兩種故障
記錄中的策略與預期不符時，優先檢查模式、啟用的檔案與規則順序；策略相符但連線失敗時，改查 DNS、選用的伺服器與目前網路，不要繼續堆疊相同規則。
七、規則未生效：依實際狀況逐項檢查
規則出問題時，通常不是缺少更多規則，而是測試條件沒有固定。先保留一個可重複測試的目標，再依照以下現象逐項檢查；如需更完整的網路排查資訊，請參閱故障排查。
修改規則後，結果完全沒有變化？
先確認 Home → Global Routing 是否選為 Config，再檢查 Config 中啟用的是否為剛才編輯的檔案。儲存後建立新連線；長連線、頁面快取及既有工作階段都可能讓舊結果持續出現。
為什麼精確的 DOMAIN 規則沒有優先於網域後綴規則？
確認它是否排在 DOMAIN-SUFFIX 或其他已命中的規則之後。規則依排列位置執行，不會依精確程度重新排序。將例外移到涵蓋規則之前，再核對實際請求的網域，確認頁面是否轉址至其他網域。
可以在 FINAL 後面新增例外嗎？
不建議這樣排列。FINAL 會處理所有到達該規則的未命中連線，後面的例外便沒有機會比對。請將新規則插入 FINAL 上方，並再次確認是否仍被更前面的範圍規則涵蓋。
為什麼連到同一個網站，連線會使用不同策略？
頁面可能分別向登入網域、靜態資源網域和 API 網域發出請求，每條連線都會個別比對規則。請檢查實際失敗請求的網域，不要只根據網址列中的主網域推斷所有資源都會使用相同策略。
更新後自訂規則消失，該檢查哪些項目？
請區分 Home 中既有訂閱的伺服器更新，以及 Config 中遠端設定檔的更新。遠端設定檔更新可能會替換檔案內容；先與備份比對，確認哪些內容有變化，再決定如何保留本機修改。不要將所有更新視為同一種操作。
最後確認三個條件：目前使用 Config、已啟用正確的檔案、例外位於範圍規則之前。確認這三項後，再用新連線檢查最終策略。規則只負責選擇處理路徑，無法取代對現有服務可用性的檢查，也不會自動修復失效的連線參數。