Shadowrocket（小火箭）的 REJECT 是拒絕連線的策略，不是移除頁面元素的工具。先在 Config 選用含有目標規則的設定檔，再前往 Home → Global Routing 選擇 Config。本文適合已有自己的服務商資料與訂閱、準備調整本機規則的使用者：從網域比對開始，了解 URL 可見性、規則順序與快取的影響，並透過小範圍測試降低誤擋風險。
1. REJECT 的作用位置：比對請求，而非修改頁面
App 發出網路請求後，只有進入 Shadowrocket 接管範圍的流量，才會套用目前設定檔中的規則。規則會以可取得的網域、目標 IP 或 URL 等資訊作為條件；符合使用 REJECT 的規則時，該連線就會遭到拒絕，不會繼續交由 DIRECT 或代理策略處理。App 可能顯示載入失敗或重試提示，也可能自行改用其他網址。
這個流程不會解析頁面版面，也無法辨識圖片或文字「是不是廣告」。如果目標內容由獨立網域載入，拒絕該網域的連線可能讓內容無法顯示；如果內容已包含在主頁面的回應中，REJECT 就無法只移除其中一部分。空白佔位、載入圖示與 App 自行顯示的提示，也不是連線規則可以直接清除的項目。
先確認「要封鎖的內容是否有獨立的網路請求」，再選擇比對條件。頁面仍有佔位內容，不代表請求沒有遭到拒絕；頁面暫時沒有顯示內容，也不代表規則已成功命中。
2. DOMAIN-SUFFIX 用法：先從獨立網域小範圍封鎖
DOMAIN-SUFFIX 會比對指定網域及其子網域。以下的 ads.example.com 僅為語法示例，並非可直接使用的封鎖清單。它會涵蓋 ads.example.com 和 img.ads.example.com，但不會涵蓋 notads.example.com。不要只為了比對一個子網域，就直接將整個主網域設為 REJECT。
[Rule]
DOMAIN-SUFFIX,ads.example.com,REJECT
FINAL,DIRECT上述片段用來說明「拒絕目標網域、其他連線維持直連」的邏輯。它不是適用於所有網路需求的完整設定；若現有設定檔的 FINAL 指向其他策略，請保留原本的預設處理方式，不要直接改成 DIRECT。現有設定檔若已包含 [Rule]，將規則加入該區段即可，不要重複建立同名區段。
- 在 Config 中備份目前的設定檔，並確認正在編輯的檔案就是準備啟用的檔案。
- 將目標網域的 REJECT 規則放在可能先行命中的寬泛放行規則之前，並讓 FINAL 保持在規則清單末尾。
- 儲存並選用設定檔，返回 Home → Global Routing，選擇 Config。
- 確認連線已開啟，再重新發出目標請求；同時檢查登入、圖片和正文等功能是否正常。
一般依序比對規則時，較前面的命中規則會決定策略。例如先加入 DOMAIN-SUFFIX,example.com,DIRECT，再加入針對 ads.example.com 的 REJECT，後者可能就沒有機會執行。應先安排具體條件，再安排範圍較廣的條件；前面的規則都未命中時，則由 FINAL 決定最後的處理方式。
3. Global Routing 與比對條件：連線觸發不等於封鎖規則
排查規則未生效時，先檢查 Home → Global Routing。Proxy、Direct、Config、Scene 是不同的路由模式，不能只因連線開關已開啟，就認定正在使用設定檔規則。本文以 Config 作為基本測試條件，讓所選設定檔中的規則參與分流。Scene 的場景設定需另外確認，不列入這項基本測試的前提。
基本網域測試
- 設定檔入口
- Config → 選用測試設定檔
- 路由入口
- Home → Global Routing → Config
- 目標規則
- DOMAIN-SUFFIX,ads.example.com,REJECT
- 預設處理示例
- FINAL,DIRECT
示例僅用於說明語法；測試時請使用已確認的實際目標網域。
連線與比對限制
- 自動連線入口
- Settings → On Demand
- On Demand 的作用
- 依條件觸發連線，不會取代 REJECT 規則
- IP-CIDR 條件
- 依目標 IP 所屬網段比對
- GEOIP 條件
- 依目標 IP 的地理位置資料比對
先確認連線與 Config，再檢查請求實際提供了哪些比對資訊。
網域規則需要取得請求對應的網域資訊。若 App 直接存取 IP、採用不同的解析路徑，或可觀察的請求資訊有限，就不能假設網域條件一定會命中。IP-CIDR 可設定網段條件，GEOIP 可設定地理位置條件，但兩者都無法判斷某個 IP 上的內容用途；共用伺服器或內容傳遞位址尤其容易造成誤擋。
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 是連線協定名稱，不是用來「辨識頁面內容」的規則條件。請求一旦命中 REJECT，切換協定也不會讓遭拒絕的請求改為放行。請先檢查命中的規則與策略，再判斷是否另有連線問題。
4. URL-REGEX 用法：路徑比對取決於 URL 是否可見
URL-REGEX 使用正規表示式比對 URL，可比網域規則更精確地描述路徑。以下只會比對示例主機中以 /banner/ 開頭的路徑；^ 限定 URL 開頭，\. 表示字面上的句點，https? 則表示 HTTP 或 HTTPS。正規表示式可以描述比對條件，但不代表用戶端在所有連線中都能取得完整 URL。
URL-REGEX,^https?://ads\.example\.com/banner/,REJECT| 條件 | 所需資訊 | 主要限制 |
|---|---|---|
DOMAIN-SUFFIX |
目標網域 | 無法區分同一網域下的不同路徑。 |
URL-REGEX |
可供比對的 URL | 通常無法直接讀取 HTTPS 加密路徑。 |
IP-CIDR |
目標 IP 與網段 | 同一 IP 上的多個服務可能同時受到影響。 |
HTTPS 會加密 HTTP 請求內容，包括路徑與查詢參數。即使連線使用常見的 443 埠，知道主機名稱也不代表能讀取 /banner/。若要比對 HTTPS 路徑，通常需要讓相應流量接受 MITM 處理，並符合目標主機範圍、憑證信任及 App 相容性等條件。不能把 URL-REGEX 當成無須其他設定就能讀取加密路徑的規則。
部分 App 使用憑證固定或其他驗證機制，可能會拒絕經 MITM 處理的連線。遇到這種情況，應停止處理該範圍並還原原設定，不要把 App 錯誤一概歸因於正規表示式寫錯。明文 HTTP 在用戶端支援的處理方式下，可能提供 URL 資訊；是否命中仍應以實際請求與記錄為準。
結論：網域獨立時，優先使用網域規則
確認目標內容由獨立網域載入後，先測試一條 DOMAIN-SUFFIX 規則；只有確實需要區分同網域下的路徑，且能確認 URL 可見時，再考慮使用 URL-REGEX。
5. 能攔截與無法攔截的情況：同網域內容、快取與 App 內嵌請求
REJECT 最適合處理可明確辨識，且拒絕後不會影響必要功能的獨立連線。「App 內嵌請求」不會自然避開規則：只要進入接管範圍並符合比對條件，同樣可能遭到拒絕。難處在於這些請求可能共用主要服務網域、變更位址、使用既有長連線，或根本沒有重新連線。
- 獨立資源網域：拒絕該網域可阻止新連線，但請檢查它是否也提供驗證碼、圖片或登入功能。
- 同網域的不同路徑：DOMAIN-SUFFIX 會影響整個網域，無法只區分特定頁面區域；URL-REGEX 則受 URL 可見性限制。
- 同一回應中的內容：正文與附加內容若由同一個回應提供，拒絕連線就會一併阻斷，無法只保留正文。
- 本機快取與內建素材：App 不需建立新連線就能顯示的內容，不會因新增 REJECT 規則而自動消失。
- 備用位址與重複請求：某個位址遭拒後，App 可能改向另一個位址發出請求；請觀察後續請求，不要不斷擴大主網域的封鎖範圍。
- 既有連線：新增規則不應被視為能立即清除所有已建立連線的指令。測試時，請讓目標 App 重新發起連線。
例如，若登入介面與待封鎖資源都位於 api.example.com，對該網域使用 REJECT 可能也會造成登入失敗。若多個網域共用同一個 IP，改為拒絕整個網段也不一定更精準。規則範圍應依請求結構決定，不能用擴大封鎖範圍來彌補證據不足。
6. 測試與還原：每次只修改一項
有效的測試應同時確認「目標請求是否遭到拒絕」以及「必要功能是否仍可使用」。Connectivity Test 用於診斷所選連線是否可達，不是用來測試 REJECT 是否命中。測試結果正常，無法證明封鎖規則已生效；結果異常，也不能直接證明目標網域遭到拒絕。
- 記錄基準狀態：保留原設定檔，記下目標內容出現的位置、已確認的請求網域，以及登入等正常功能。
- 一次修改一項：只新增一條明確的網域規則，不要同時更換協定、預設策略與 DNS 設定。
- 確認狀態：確認 Config 選用的檔案、Home → Global Routing → Config，以及連線開關狀態。
- 重新發出請求：重新載入目標頁面或重新開啟目標 App，排除既有連線與快取造成的干擾。
- 核對依據：查看可用的請求記錄或日誌，確認目標網域、命中的規則與最終策略，不要只觀察頁面外觀。
- 對照並還原：移除該規則或還原備份，再重複相同步驟。必要功能受到影響時，請先恢復正常使用。
加入 REJECT 規則後，內容為什麼還在？
先前往 Home → Global Routing 確認已選擇 Config，再檢查 Config 中選用的檔案。接著重新發出請求；若沒有新的目標請求記錄，應先考慮快取、內建素材或既有連線，而不是繼續新增範圍更廣的規則。
一封鎖就無法登入，該如何還原？
在 Config 中移除剛新增的 REJECT 規則或還原備份，儲存後重新選用。檢查目標網域是否與登入介面共用；未經驗證前，不要改為拒絕整個主網域或共用 IP 網段。
URL-REGEX 寫對了，HTTPS 路徑還是無法比對？
先確認實際請求 URL 是否符合表示式，再確認該流量是否能顯示完整 URL。若只能看到網域，就沒有足夠資訊供路徑規則比對；不要只憑 443 埠或連線成功，就推定 MITM 已生效。
更新設定檔後，自行加入的規則為什麼不見了？
請區分伺服器資料訂閱與遠端設定檔更新。前者主要更新伺服器資料，後者則可能取代設定檔內容。修改前請另存備份；更新後重新檢查 Config 中的規則、順序與選用狀態，不要只查看 Home 的伺服器列表。
如需進一步了解分流條件，請參閱技術參考；首次連線與路由模式設定，請參閱入門指南中的 Global Routing 說明。本站不提供、不銷售，也不推薦節點或訂閱；購買用戶端與使用者已有的線路服務是兩件不同的事。