在 Shadowrocket（小火箭）中，自訂規則應先列出明確例外，再列適用範圍較廣的條件，最後才放 FINAL。本文適合已有可用設定檔、想調整流量分流的使用者：先確認 Global Routing 與目前使用的 Config，再參考範例理解語法，並透過新連線確認實際命中結果。涉及 PROXY 的操作，均以使用者已有自己的服務商與訂閱為前提。
一、先確認 Config 正在使用，再檢查規則順序
規則文字成功儲存，不代表目前連線正在使用這份設定。先在 Home 確認 Global Routing；若要依本文逐條規則分流，應選擇 Config，再到 Config 確認目前使用的設定檔。編輯未啟用的其他檔案，不會影響現用設定的匹配結果。
Global Routing 中的 Proxy、Direct、Config、Scene 是路由模式，不是四種規則關鍵字。Proxy 與 Direct 分別代表全域代理與全域直連；Config 依目前設定檔分流；Scene 則用來依情境安排路由行為，排查時也要確認實際的情境設定。請勿混淆路由模式與規則行末的策略。
- 在 Config 中保留目前設定檔的副本，並記下正在使用的設定檔名稱。
- 前往 Home → Global Routing 選擇 Config，確認不是在其他路由模式下檢視規則。
- 返回 Config，編輯目前選用的設定檔並儲存，然後重新發起測試請求。
- 查看 App 內連線記錄中的目標與策略；若仍沿用舊連線，先結束該連線再測試。
二、由上而下匹配：命中後不會再尋找「更具體」的規則
常見規則會依清單順序逐條檢查，由第一條符合的規則決定策略；後續規則不會為同一個請求重新排序。Shadowrocket 不會因為後面的網域更長，就自動將它移到前面。設定檔作者應將例外規則放在涵蓋範圍較廣的規則之前。
例如，先寫 DOMAIN-SUFFIX,example.com,PROXY，再寫 DOMAIN,api.example.com,DIRECT，對 api.example.com 的網域匹配會先命中第一條。若要讓這個子網域直連，應將 DOMAIN 那一行移到前面。以下網域僅用於說明語法，不代表有可用服務。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT結論：先移動例外規則，再新增重複規則
網域沒有依預期分流時，先檢查它上方是否已有涵蓋該網域的規則；在清單末尾重複新增相同目標，通常無法改變先前的匹配結果。
三、規則語法：分清匹配條件與策略
多數常見規則採用以逗號分隔的「類型、匹配值、策略」格式。FINAL 是特殊的預設規則，不需要匹配值。建議使用英文逗號，每行只寫一條規則，也不要將整段設定貼進單一匹配值欄位。
| 規則範例 | 匹配對象 | 確認要點 |
|---|---|---|
DOMAIN,api.example.com,DIRECT | 完整網域 | 只匹配該網域，不包含其所有子網域。 |
DOMAIN-SUFFIX,example.com,PROXY | 網域後綴 | 涵蓋 example.com 及其子網域，不是比對任意包含該文字的內容。 |
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve | IPv4 網段 | 匹配指定的 IP 位址範圍；no-resolve 不會為此 IP 規則主動觸發網域解析。 |
GEOIP,CN,DIRECT | IP 地理位置 | 依據所使用的地理資料庫判斷，網域後綴不能作為 IP 地理位置的依據。 |
FINAL,PROXY | 前面的規則都未命中 | 作為最後的預設策略；選用 PROXY 時，必須具備可用的代理出站條件。 |
網域規則不填寫通訊協定前綴、網頁路徑或連接埠。例如，目標網址包含 HTTPS、路徑與 443 連接埠時，DOMAIN 的匹配值仍只填主機名稱；若要依連接埠分流，應使用對應的連接埠規則，而不是把 :443 接在網域後面。
四、DOMAIN-SUFFIX、IP-CIDR、GEOIP 如何排列
沒有適用於所有設定檔的固定類型順序；需要遵守的是「例外規則要放在涵蓋它的規則之前」。一般可先列出精確網域例外，再列網域後綴、指定網段、範圍較廣的 GEOIP，最後放 FINAL。若某個網段必須優先處理，也可將它往前移，但要清楚它可能涵蓋哪些請求。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY這段範例只示範規則順序，不應直接取代完整設定檔：api.example.com 作為直連例外，排在後綴規則之前；metrics.example.com 作為拒絕例外，也放在前面；其餘 example.com 子網域則使用 PROXY。192.168.0.0/16 這一行只涵蓋指定的私有網段，不代表所有區域網路位址。
- 網域條件：適合用來描述明確的網站或子網域需求。若只想為某個子網域設例外，不要直接更改整個後綴的策略。
- IP-CIDR 條件：適用於已知的位址範圍。網域請求能否在此步驟取得 IP，會受到解析流程及 no-resolve 等選項影響。
- GEOIP 條件：涵蓋範圍通常較大，匹配結果取決於目標 IP 與資料庫。同一網域解析到不同位址時，匹配結果可能有所不同。
- FINAL 條件：放在所有具體條件之後；只有前面的規則都未命中的請求，才會套用此策略。
no-resolve 不代表整個 App 停止 DNS 解析，也不保證這條規則永遠不會匹配網域請求。它限制的是為匹配此 IP 類規則而主動觸發解析；若目標本身就是 IP，或解析流程中已有可用位址，仍應依實際記錄判斷。
五、FINAL 應選 PROXY、DIRECT 還是 REJECT？
FINAL 決定「尚未明確分類的請求」要如何處理，不是連線失敗後的重試開關。若前面的規則已命中 PROXY，即使代理連線失敗，也不會因此繼續套用 FINAL。需要備用出站時，應檢查對應策略組的行為，而不是依賴末尾的預設規則接手失敗請求。
| 預設規則寫法 | 未匹配請求的處理方式 | 使用前確認 |
|---|---|---|
FINAL,PROXY | 交由代理出站。 | 使用者已有的代理可正常使用；需要直連的目標已在前面的規則中明確列出。 |
FINAL,DIRECT | 直接連線至目標。 | 需要代理的目標已由前面的規則涵蓋；其餘目標可接受直接連線。 |
FINAL,REJECT | 拒絕其他請求。 | 已建立足夠完整的允許規則，並能排查登入、圖片與 API 遺漏的情況。 |
DIRECT 仍可能經由系統建立的 VPN 通道處理，但其出站策略是不使用代理伺服器；這不等於關閉 Shadowrocket。REJECT 則是在規則層拒絕請求，不會自動判斷請求是否「有用」。若同一網域承載多種功能，拒絕整個網域可能連正常功能也一併影響。
結論：依未分類流量的預期選擇預設策略
先列清楚哪些目標必須設為例外，再決定其餘請求的處理方式；不要只為了消除一次錯誤，就在三種策略之間反覆切換 FINAL。
六、修改後如何驗證與還原
驗證時應同時查看目標、命中的規則與出站策略，不能只憑網頁「開得起來」就認定設定正確。瀏覽器快取、既有長連線，以及網頁中多個不同網域的請求，都可能讓表面現象與新規則的實際作用範圍不一致。
- 保留基準設定：修改前先儲存原設定檔，記下一個可正常存取的目標與目前的路由模式。
- 縮小變更範圍：每次只調整一條規則或一個順序，儲存後確認目前 Config 仍選用該檔案。
- 建立新連線：關閉測試頁面後重新開啟；必要時結束相關 App 的舊連線，再重新發起請求。
- 檢查記錄：在 App 內的連線記錄中找到實際主機名稱或 IP，確認匹配規則與最終策略，不要只看網站的主網域。
- 還原基準設定：發生異常時，撤銷剛才新增的規則，或重新選用先前保留的設定檔，再以相同目標重新測試。
若設定檔來自遠端內容，也要確認更新後是否覆蓋本機修改。服務位址清單更新與 Config 規則檔更新並非同一件事，應分別確認更新項目。需要長期保留的自訂規則，應儲存在自己能管理並可還原的設定檔中。
七、自訂規則常見問題
已設定 DIRECT，為什麼流量還是走 PROXY？
先前往 Home → Global Routing 確認目前使用 Config，再到 Config 確認編輯的是現用檔案。接著檢查 DIRECT 上方是否有涵蓋相同目標的 DOMAIN-SUFFIX 或其他規則，將明確例外移到前面，再透過新連線重新測試。
把 FINAL 放在最前面會怎樣？
FINAL 會作為預設規則，處理到達該位置的請求，導致後面的具體規則無法發揮預期作用。請將它移到規則區段的末尾，只保留一條明確的最終預設規則，再檢查上方條件是否涵蓋需要特別處理的目標。
加入 REJECT 後，為什麼登入和圖片一起出問題？
確認遭拒絕的網域是否同時提供登入、圖片或 API 請求。先撤銷剛加入的 REJECT，還原基準設定，再依據連線記錄縮小匹配範圍。DOMAIN-SUFFIX 拒絕的是整組網域，不是單一網頁路徑。
GEOIP 沒有依網站所屬地區匹配，是規則失效了嗎？
不一定。GEOIP 判斷的是請求目標 IP 在資料庫中的歸屬，不是營運主體所在地。先確認實際解析位址與命中記錄；若要固定處理某個網域，可在 GEOIP 之前加入明確的網域規則。