Shadowrocket（小火箭）的 REJECT 是規則命中後的拒絕策略，不是網頁內容編輯器。本文適合已有可用設定檔、準備新增網域封鎖規則的使用者：先確認 Config 模式與規則順序，再用單一網域測試是否命中，最後透過移除規則前後的對照，判斷是規則誤封、快取或頁面本身的行為。如涉及訂閱，均以使用者已有自己的服務供應商與訂閱為前提；請向你的服務供應商取得訂閱。
一、REJECT 在規則鏈中的位置
在依設定檔分流時，Shadowrocket 會根據連線可取得的資訊比對規則。比對條件與執行策略分屬兩個部分：DOMAIN、DOMAIN-SUFFIX、IP-CIDR 等用來判斷「是否命中」，末尾的 REJECT 則決定「命中後拒絕」。REJECT 不是通訊協定，也不需要另外選擇代理線路才能執行。
這裡說明的是命中 REJECT 的情況。若命中 DIRECT，連線會直接連線；若命中設定檔中有效的代理策略，連線則會經由相應的出口。規則會由上而下檢查，命中後便依對應策略處理，不會繼續往下尋找「更合適」的結果。因此，排查時不只要確認是否寫了 REJECT，也要檢查請求是否已先被前面的規則攔截。
- 先確認路由模式：在 Home 檢查
Global Routing → Config，讓這次測試使用目前設定檔中的規則。不要根據 Proxy 或 Direct 全域模式下的測試結果，推斷 Config 規則是否正確。 - 再確認設定檔：前往 Config 確認目前啟用的設定檔。編輯其他未啟用的檔案，不會改變目前正在使用的規則。
- 最後確認是否為新連線：已建立的連線可能會繼續沿用。修改後重新建立連線，再開啟目標頁面測試，比只在原頁面輕點重新整理更容易判斷。
二、從精確網域開始撰寫規則
先用 DOMAIN 指定單一主機名稱，再考慮擴大為 DOMAIN-SUFFIX。例如，只想拒絕 metrics.example.com，精確規則不會一併拒絕 www.example.com；而 DOMAIN-SUFFIX,example.com,REJECT 會涵蓋根網域及其子網域，可能連登入、圖片和 API 一起封鎖。以下網域僅用於說明語法，並非實際封鎖目標。
[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,blocked.example.org,REJECT
FINAL,DIRECT這是規則結構範例，不是可直接取代現有檔案的完整設定檔。請將所需規則加入既有的 [Rule] 區段，不要重複建立該區段；並保留原設定檔需要的其他規則與兜底策略。範例中的 FINAL,DIRECT 只用來示範末尾位置，不代表所有使用者都應將自己的 FINAL 改為 DIRECT。
精確拒絕
- 規則類型
DOMAIN- 比對值
metrics.example.com- 執行策略
REJECT- 完整寫法
DOMAIN,metrics.example.com,REJECT
比對值只填主機名稱，不要加上通訊協定、連接埠或頁面路徑。
後綴拒絕
- 規則類型
DOMAIN-SUFFIX- 比對值
blocked.example.org- 執行策略
REJECT- 完整寫法
DOMAIN-SUFFIX,blocked.example.org,REJECT
涵蓋該網域及其子網域；擴大範圍前，先確認正常服務是否共用這些網域。
不要將完整網址直接填入 DOMAIN 條件。例如，頁面網址中的 /banner/image 是路徑，不是網域的一部分；:443 是連接埠，也不屬於主機名稱。使用這些網域規則時，即使同一主機同時提供 HTTPS 443 和 HTTP 80 服務，也無法透過 DOMAIN 條件只區分其中一個連接埠。
三、檢查規則順序，排查「規則寫了卻沒封鎖」
規則不會自動依「越精確越優先」重新排序。假設設定檔先出現 DOMAIN-SUFFIX,example.com,DIRECT，後面才寫 DOMAIN,metrics.example.com,REJECT，存取該子網域時會先命中前面的 DIRECT。後面的精確規則即使範圍較小，也不會有執行機會。
[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,DIRECT上述範例將明確的拒絕目標放在較廣泛的直連規則之前。若要保留某個子網域，應將該子網域的允許規則放在相應的後綴拒絕規則之前。不要同時新增多條彼此重疊的規則，再只憑頁面外觀判斷；請先確認目標連線命中的具體規則與最終策略。
判斷方式：先調整規則順序，再擴大封鎖範圍
若目標連線命中前面的 DIRECT 或代理策略，請先將該條精確 REJECT 規則往前移，再重新測試；不要為了掩蓋順序問題而擴大封鎖整個根網域。
GEOIP 與 IP-CIDR 是根據目標 IP 位址進行比對的條件，不應用來取代已確認的精確網域條件。多個網站可能共用同一個 IP，依位址範圍拒絕會影響更大範圍；網域規則能否比對，也取決於連線是否有可用的網域資訊。不能認定只有 IP 位址的連線一定會命中某條 DOMAIN 規則。
四、同網域內容、快取與頁面留白的限制
REJECT 可以拒絕符合規則的連線，但無法辨識網頁區域是正文、廣告版位還是播放器。假設同一個 www.example.com 同時提供文章 API 和廣告 API，使用 DOMAIN 或 DOMAIN-SUFFIX 無法只拒絕其中一個路徑；直接拒絕該網域會同時影響正常內容。「無法封鎖同網域中的特定內容」準確來說，就是無法僅靠這類網域規則選擇性地區分內容。
| 請求情境 | 可以做到 | 無法據此保證 |
|---|---|---|
| 獨立資源網域 | 拒絕命中該網域規則的新連線 | 頁面上的其他網域不會提供替代內容 |
| 同網域、不同路徑 | 拒絕整個符合條件的網域 | 只移除其中一條路徑的內容 |
| 頁面已快取的資源 | 阻止後續符合條件的新請求 | 立即刪除本機已儲存的資源 |
| 伺服器合併回傳內容 | 拒絕承載該回應的連線 | 只移除回應中的指定片段 |
| 頁面預留區域 | 阻止該區域的遠端資源請求 | 自動調整頁面版面並消除空白 |
HTTPS 下的路徑與回應本文受到加密保護，一般網域規則不會以這些內容作為判斷依據。新增更多 DOMAIN-SUFFIX 規則，也不會讓它具備辨識網頁元素的能力。若瀏覽器已將資源保留在記憶體或本機快取中，即使新請求遭到拒絕，原有圖片仍可能顯示。
五、逐一驗證並保留還原方式
測試前，先備份目前可用的設定檔，並記錄新增規則及原本的順序。不要同時更換網路、切換代理、更新訂閱，又新增一整組拒絕規則；否則即使頁面行為改變，也無法判斷是哪項操作造成。以下步驟適用於連線正常、只驗證單一拒絕目標的情況。
- 建立基準：維持相同網路與設定檔，開啟目標頁面，記錄能否登入、圖片能否載入、影片播放是否正常等具體情況。
- 確認目標：在連線記錄中找到相關請求，核對目標主機名稱、命中的規則及執行策略。單一頁面可能會連線到多個網域，不要只因網域看起來像統計服務，就認定可以封鎖。
- 一次只改一條：在 Config 目前啟用的設定檔中，於
[Rule]區段加入一條精確 DOMAIN 規則，並放在可能優先命中的廣泛規則與 FINAL 之前；儲存後確認設定已生效。 - 重新建立連線：重新連線後再次開啟目標頁面，必要時關閉舊分頁並以新的連線工作階段測試。分別記錄是否命中 REJECT，以及登入、圖片、影片等功能是否受到影響。
- 移除規則進行對照：暫時移除剛新增的規則，再重新建立連線並測試。若異常隨規則新增而出現、移除後消失，應優先判斷是該規則造成誤封。
- 維持最小範圍：確認規則有效且不影響所需功能後，再保留該規則。需要涵蓋更多子網域時，請逐步擴大範圍，不要直接拒絕整個共用網域或位址範圍。
訂閱中的伺服器資訊與目前 Config 中的分流規則不是同一項內容。更新訂閱後若行為改變，應分別檢查所選連線與目前設定檔，不要假設更新一定會覆蓋或保留本機規則。透過遠端網址更新設定檔時，也要確認本機修改是否仍在；備份副本是用來還原，未確認差異前不要反覆覆蓋。
六、常見情況與處理順序
已看到 REJECT，為什麼頁面還有圖片？
先確認圖片實際使用的主機名稱是否就是遭拒絕的目標，再關閉舊頁面，以新的連線工作階段重新測試。圖片可能來自快取、其他網域，或內嵌於頁面回應中。不要只為了移除仍顯示的一張圖片，就直接將整個網站的根網域加入 REJECT。
新增規則後登入按鈕失效，該怎麼調整？
先移除最近新增的拒絕規則並重新建立連線，確認登入功能是否恢復。若恢復，請檢查認證 API 是否與被拒絕的網域共用；將範圍較廣的 DOMAIN-SUFFIX 縮小為已確認的 DOMAIN。若無法透過網域區分正常請求與目標請求，應保留正常功能，不要繼續擴大拒絕範圍。
規則完全沒有作用，是不是該換通訊協定？
先檢查 Home → Global Routing → Config，再前往 Config 確認啟用的檔案、規則順序及儲存結果。Shadowsocks、VMess、VLESS、Trojan 等出口通訊協定，與「是否先命中 REJECT」是兩回事；不要先更換通訊協定來處理規則比對錯誤。
開啟 On Demand 就能讓封鎖一直生效嗎？
Settings → On Demand 用於設定依條件建立或中斷連線，不會取代 Global Routing 的選擇，也不會替你修正規則順序。請先手動驗證 Config 下的拒絕規則，再檢查 On Demand 條件是否讓測試網路處於預期的連線狀態。
保留規則的標準應為：目標新連線確實命中 REJECT、所需功能仍可使用，且能透過移除規則還原原有行為。REJECT 適合拒絕目標明確的請求；頁面內容清理、回應內容篩選及版面整理，都不是這些網域規則能保證的結果。更多基本操作請參閱使用說明，規則術語請參閱名詞解釋。