Shadowrocket（小火箭）的 REJECT 是連線分流策略，不是網頁內容過濾器。本文適合已能正常連線、準備編輯規則的使用者：先確認 Global Routing 設為 Config，再依網域或 IP 新增範圍最小的規則，透過請求記錄確認是否命中，最後釐清規則遺漏、快取與同網域內容等限制。
REJECT 拒絕的是連線，不是頁面中的特定元素
應用程式存取網路時，Shadowrocket 會比對進入其處理路徑的連線規則。符合 REJECT 後，就不會再依 DIRECT 或 PROXY 為該請求建立通往目標的正常對外連線。這裡所說的「建立連線前」是指連線至目標的對外階段，並不表示應用程式尚未送出請求，也不代表比對前一定沒有進行 DNS 查詢。
應用程式如何呈現，取決於自身的錯誤處理方式：圖片可能載入失敗，獨立的統計請求可能結束，也可能出現重試或逾時提示。REJECT 不會替應用程式產生正常頁面，也不會自動收起網頁中的空白區域。因此，「某個請求遭拒」和「整個頁面看起來沒有變化」可能同時發生。
DIRECT：直接連線至目標位址，仍允許該請求存取網路。PROXY：透過所選的代理策略連線，不代表會攔截請求。REJECT：拒絕符合條件的請求，不負責替換內容或調整頁面版面。
這些策略與使用的代理協定屬於不同層級。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 描述的是代理傳輸或隧道方式；更換代理協定，不會讓 REJECT 因而取得辨識 HTTPS 頁面內部內容的能力。
網域與 IP 規則各自能辨識哪些內容
比對階段能取得目標網域時，可以使用 DOMAIN 或 DOMAIN-SUFFIX。前者比對完整主機名稱，後者比對指定網域及其子網域。若只想拒絕單一請求端點，建議先從完整主機名稱著手，不要直接擴大到整個主網域。
網域比對範圍
- DOMAIN
- metrics.example.com,REJECT
- DOMAIN-SUFFIX
- example.com,REJECT
- 比對依據
- 目標主機名稱，而非 URL 路徑
example.com 及其子網域僅用於說明語法，並非可直接套用的封鎖清單。
IP 比對範圍
- IP-CIDR
- 192.0.2.10/32,REJECT,no-resolve
- GEOIP
- CN,DIRECT
- 比對依據
- 目標 IP、網段或 IP 地理位置資料庫
192.0.2.10 是文件範例位址；GEOIP 範例說明的是直接放行的設定方式，並非封鎖建議。
/32 代表單一 IPv4 位址，而非一段不明確的範圍。no-resolve 可避免僅為這條 IP 規則額外進行網域解析；不要將它理解為「所有請求都不再使用 DNS」。如果應用程式直接存取 IP，且沒有可用的網域關聯資訊，單靠網域規則未必能命中。
IP 規則也有其限制。多個網域可能共用同一個 CDN 位址，而同一個網域也可能因地區、網路或時間不同而回傳不同位址。拒絕某次解析取得的所有 IP，可能漏掉之後新增的位址，也可能影響共用該位址的其他服務。GEOIP 依據位址歸屬資料庫判斷，同樣無法辨識網站的實際內容或營運主體。
擴大範圍前先確認相依服務。登入、驗證碼、圖片與內文可能使用同一主網域下的不同子網域。將 DOMAIN 規則直接改成 DOMAIN-SUFFIX，可能從阻止單一端點變成阻止整組必要請求。
規則依序比對，REJECT 沒有額外優先權
使用 Config 分流時，規則會由上而下依序檢查，符合條件後便採用該條規則的策略。REJECT 不會因為具有拒絕意義，就自動優先於前面的 DIRECT 或 PROXY。範圍較精確的例外應放在較廣泛的規則之前；FINAL 則應放在規則區段最後，用來處理尚未命中的連線。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY在這段僅用來說明規則順序的範例中，login.example.com 會先符合 DIRECT，metrics.example.com 會先符合 REJECT，其他屬於 example.com 的請求則會再符合 PROXY。若將 DOMAIN-SUFFIX 移到最上方，前兩個主機名稱都會先被該規則攔截，後面的細分規則便不會生效。
| 設定情況 | 結果 | 修正方式 |
|---|---|---|
| 範圍較廣的放行規則排在 REJECT 前 | 目標先符合放行規則 | 將精確的 REJECT 規則移到相關廣泛規則之前 |
| REJECT 排在 FINAL 後 | 請求已由 FINAL 接手處理 | 將 FINAL 留在規則區段末尾 |
| 同一主機名稱有多條策略 | 以最先符合的規則為準 | 檢查完整規則順序，不要只搜尋 REJECT |
判斷方式：先找出實際命中的規則，再擴大封鎖範圍
如果請求記錄顯示 DIRECT 或 PROXY，應先修正前面的規則或目前的分流模式；繼續新增類似的 REJECT 項目，無法解決同一請求已經先符合其他規則的問題。
確認 Config 已生效，再進行一次最小範圍測試
規則檔存在於 Config 中，不代表目前的請求一定會依該檔案處理。先檢查 Home 中的 Global Routing。Proxy 和 Direct 是整體對外連線模式；測試規則時，應明確選擇 Config。Scene 是依情境設定的路由模式，不能只因看到 Scene，就認定它等同於目前設定檔的規則結果。
- 先備份副本。在 Config 中確認目前使用的設定檔，並在編輯前保留可還原的副本。不要直接覆寫尚未理解的完整規則。
- 只新增一條精確規則。使用請求記錄中實際出現的主機名稱，依
DOMAIN,主機名,REJECT的格式填寫；此處的「主機名」僅說明欄位位置，並非可直接貼上的規則。 - 確認規則已生效。儲存修改並確認目前使用的是剛編輯的設定檔，在 Home 將 Global Routing 設為 Config，同時確認連線開關已開啟。
- 觸發新的請求。離開目標頁面後重新進入；必要時，完全關閉目標應用程式再重新開啟。不要只觀察已載入的圖片或舊分頁。
- 檢查記錄。在請求記錄中搜尋目標主機名稱或 IP，確認實際命中的規則與策略。只有新請求顯示 REJECT，才能證明這次測試確實進入拒絕流程。
- 還原驗證。暫時移除剛新增的規則，再以相同方式觸發請求。比較移除前後的連線結果與功能變化，確認影響確實來自這條規則。
Settings → On Demand 用來控制是否依條件自動連線，不是 REJECT 的開關。若測試期間隧道中斷，後續請求可能不再經過相同的處理路徑；應先確認連線狀態，再判斷「規則失效」。對於持續保持的連線，不應認為修改規則就已中斷所有既有工作階段；測試時需要建立新的連線。
記錄驗證條件，不是速度結論。建議記下目標主機名稱、Global Routing 模式、命中的策略，以及是否重新啟動應用程式這四項資訊。缺少這些條件時，光憑「頁面還能開啟」無法判斷 REJECT 是否生效。
HTTPS、快取與同網域內容的限制
網域或 IP 規則處理的是連線目標。假設一般內容位於 https://example.com/article，另一類內容位於 https://example.com/promo，兩者的主機名稱相同。單靠 DOMAIN 或 DOMAIN-SUFFIX 無法區分這兩個路徑；拒絕該主機名稱可能連一般文章也一併阻止。
連接埠只能提供傳輸用途的線索。一般網頁和其他 HTTPS 請求都可能使用 443，無法透過拒絕整個連接埠來精細篩選。即使能取得目標網域，也不代表能讀取加密連線中的 URL 路徑、請求本文或回應內容；REJECT 本身不負責解密。
- 內容已快取：應用程式直接顯示磁碟或記憶體中的資料，沒有新的網路請求可供拒絕。重新進入頁面後，也可能繼續使用快取。
- 內容隨主要回應傳回：一般內文與其他內容隨同一個請求一起傳回；連線層級的拒絕無法只保留其中一部分。
- 頁面結構仍然存在：遠端圖片請求即使失敗，網頁預留的容器、標題或按鈕仍可能顯示。
- 請求改用其他端點：應用程式遇到失敗後，可能改為連線至其他網域；原有規則只負責已符合條件的目標，不會自動判斷新端點的用途。
- 請求未經過處理路徑：若連線未啟用或存在排除路徑，增加規則也無法補救；應先確認流量是否經過目前的設定。
URL Rewrite 是另一類請求改寫機制，不應將其功能歸於 REJECT。若無法只靠連線規則分離特定內容，就應保留必要功能並縮小目標範圍，而不是不斷擴大網段，試圖移除頁面元素。
常見狀況與復原步驟
新增 REJECT 後，為什麼頁面還是顯示？
先在 Home 確認 Global Routing 設為 Config，再重新觸發請求並檢查記錄。若新請求已顯示 REJECT，但舊圖片仍然存在，請檢查應用程式快取；若完全沒有新記錄，就不能根據目前頁面判斷規則結果。
為什麼封鎖後連登入也失敗？
先撤銷最近新增的 DOMAIN-SUFFIX 或 IP-CIDR 規則，再重新開啟應用程式測試登入。若登入恢復正常，請確認登入功能與目標內容是否共用網域或位址；若能區分，改用精確的 DOMAIN 規則；若無法區分，請保留登入所需的連線。
更新訂閱後，剛新增的規則為什麼沒有效果？
回到 Config 檢查目前啟用的檔案，以及 Rule 區段是否仍保留本機修改。更新伺服器訂閱與替換遠端設定檔是不同操作；若更新程序替換了整份設定檔，本機規則可能已被覆蓋。請從副本還原，並重新檢查規則順序。
可以直接複製大量 IP 來封鎖嗎？
先不要批次新增。記錄一個實際目標，確認它是否共用 CDN 位址，以及之後是否還會回傳其他位址，再決定是否使用 IP-CIDR。每次只修改一組相關規則並保留可還原的副本，避免無法找出是哪條規則造成異常。
本文以使用者已有自己的服務商與訂閱為前提，訂閱請向自己的服務商取得。服務商提供的連線參數用於解決連線問題，REJECT 則用於處理目前設定中的規則比對與拒絕，兩者不能互相取代。完成測試後，保留精確、易於理解且可還原的規則，比持續新增用途不明的項目更容易維護。