Shadowrocket（小火箭）的 REJECT 是請求分流策略，不是網頁元素過濾器。本文適合已有可用設定、需要自行維護規則的使用者：先確認 Global Routing 設為 Config，再以範圍最小的規則封鎖目標，並透過連線紀錄確認比對結果；若發生誤封，只撤回這次修改。範例中的網域與位址僅用來說明語法，並非封鎖清單。
一、REJECT 在規則比對中的作用
重點是：當請求進入 Shadowrocket 的規則處理流程，並符合策略為 REJECT 的規則時，該請求就會遭到拒絕，不會繼續透過代理或直連存取目標。應用程式可能顯示資源載入失敗、連線錯誤或持續重試，實際提示取決於發出請求的應用程式。不能只因頁面空白，就認定 REJECT 已成功比對。
規則通常依設定中的排列順序比對；一旦某條適用規則決定策略，後續規則便不會再改變這次請求的結果。因此，「寫了規則」不代表「請求套用了這條規則」。前方較寬泛的放行規則、實際生效的設定檔，以及目前的分流模式，都會影響最終結果。
- DOMAIN：比對指定的完整網域，適合先以最小範圍進行測試。
- DOMAIN-SUFFIX：比對指定網域及其子網域，涵蓋範圍大於單一完整網域。
- IP-CIDR：依 IPv4 位址或網段比對，不適用於網頁路徑或頁面元素。
- FINAL：作為最後的兜底規則，放在規則末尾；策略應配合現有設定的設計。
例如，同一網域下的文章內容、圖片與統計請求可能共用連線目標。只靠網域規則無法判斷這些內容的用途。將整個網域設為 REJECT，可能連頁面必要資源也一併封鎖。
二、先確認 Config 與 Global Routing
操作前先保留目前設定的副本。在 Config（設定檔）中確認目前選用的檔案，進入該檔案的編輯介面並檢查規則區段；編輯介面的實際顯示方式以目前 App 為準。不要只修改未啟用的檔案，就直接根據網頁顯示判斷規則是否正確。
| 介面項目 | 意義與預設狀態 | 本文測試建議 |
|---|---|---|
| Home → Global Routing → Config | 依目前設定進行分流；預設選項以目前 App 顯示為準。 | 使用 Config，確認設定中的 REJECT 規則。 |
| Global Routing → Proxy | 全域代理模式；不是本文規則測試的基準。 | 測試前切回 Config，不要用此模式判斷規則區段是否符合。 |
| Global Routing → Direct | 全域直連模式；不是本文規則測試的基準。 | 測試前切回 Config。 |
| Global Routing → Scene | 依設定的場景套用相應分流行為；實際結果取決於場景設定。 | 先記錄原本狀態，測試時使用 Config，完成後視需要還原。 |
| Settings → On Demand | 按需連線設定；預設開關與條件以目前 App 顯示為準。 | 測試期間確認連線狀態維持開啟，避免自動連線條件影響重現。 |
- 記錄目前使用的設定檔、Global Routing 狀態，以及目標 App 的正常運作情形。
- 在 Config 中保留副本，再修改實際生效檔案的規則區段。
- 返回 Home，確認連線已啟用，並將 Global Routing 設為 Config。
- 儲存並確認修改已載入，再讓目標 App 重新發出請求。
Home 中的連線項目與 Config 中的規則檔案屬於不同層級的設定。更新連線訂閱，不代表剛編輯的規則一定已載入。若設定會從遠端更新，也應確認更新後本機修改是否仍然保留。
三、DOMAIN-SUFFIX 與 IP-CIDR 的正確寫法
文字規則的欄位之間以英文逗號分隔，不要使用中文逗號。以下提供四條獨立的語法範例，並非可直接整份取代的完整設定。網域使用保留作為範例的網域；192.0.2.0/24 是文件示例位址範圍，這些值並非實際需要封鎖的目標。
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.18/32,REJECT,no-resolve
IP-CIDR,192.0.2.0/24,REJECT,no-resolve網域規則欄位
- 規則類型
- DOMAIN 或 DOMAIN-SUFFIX
- 比對值
- metrics.example.com 或 example.com
- 目標策略
- REJECT，拒絕符合條件的請求
- 預設值與建議
- 比對值沒有通用的預設值；建議先用 DOMAIN 測試。
網域欄位只填主機名稱，不要填 https://、路徑或連接埠。
位址規則欄位
- 規則類型
- IP-CIDR，比對 IPv4 位址範圍
- 比對值
- 192.0.2.18/32，代表單一位址
- 目標策略
- REJECT，拒絕符合條件的請求
- 選用參數
- no-resolve，避免為比對此 IP 規則而主動進行網域解析
- 預設值與建議
- 位址範圍沒有通用的預設值；建議先確認單一位址，再考慮網段。
no-resolve 不會關閉全域 DNS，也不是「拒絕所有解析」的開關。
DOMAIN-SUFFIX,example.com,REJECT 可比對 example.com 及 img.example.com 等子網域，不代表網域名稱中只要含有這段字串就會符合。若只打算封鎖 metrics.example.com，先用 DOMAIN 即可，不必擴大到整個主網域。
結論：從單一網域或單一位址開始
若以 DOMAIN 或 /32 就能鎖定目標，先不要擴大成網域後綴或整段位址；只有連線紀錄證實確有必要涵蓋更大範圍時，才擴大比對範圍。
四、規則順序、例外與 FINAL 兜底
若要保留某個子網域，例外規則應放在範圍較廣的拒絕規則之前。以下僅示範排列順序：讓 account.example.com 直連，拒絕其他 example.com 請求，最後讓未符合規則的請求直連。此處的 DIRECT 是明確的範例選擇，不代表所有使用者都應將兜底策略改成直連。
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECT實際使用時應保留現有設定所需的策略。若此例外必須透過代理連線，不要照抄 DIRECT，應使用設定中已存在且正確的策略。也不要把第二個 [Rule] 區段直接附加到檔案末尾；應編輯原有的規則區段，並確認最終順序。
- 拒絕規則放在 FINAL 之後：前面的兜底規則已處理請求，後面的拒絕規則便無法如預期生效。
- 範圍較廣的放行規則在前：若目標先符合其他 DOMAIN-SUFFIX、IP-CIDR 或 GEOIP 規則，後面的 REJECT 就不會生效。
- 例外規則放在拒絕規則之後：目標已遭拒絕，後置的放行例外無法補救。
- 將 FINAL 設為 REJECT：所有未符合規則的請求都會遭到拒絕；這屬於預設拒絕設定，並非局部封鎖的常見做法。
GEOIP 依位址所屬地區參與比對，不是用來判斷「某個網站是否應該封鎖」的業務分類。為了處理單一網域而調整大範圍 GEOIP 策略，通常會造成不必要的影響。優先調整或縮小與目標直接相關的規則範圍。
五、規則封鎖無法處理的情況
REJECT 是針對連線目標作出決定，不會解析頁面版面。HTTPS 請求中的網頁路徑、參數與內文，也不能直接作為 DOMAIN-SUFFIX 的比對值。若同一網域承載不同內容、內容已快取，或多個服務共用基礎設施，應先釐清影響範圍，再決定是否使用拒絕策略。
| 情況 | 可能出現的現象 | 處理建議 |
|---|---|---|
| 同一網域承載不同內容 | 封鎖一個目標時，文章內容、登入或圖片也受到影響。 | 確認是否有獨立子網域；若無法區分，請保留必要功能。 |
| 多個網站共用同一個位址 | 使用 IP-CIDR 拒絕後，其他網域也無法連線。 | 優先使用網域規則，避免直接封鎖共用網段。 |
| 頁面內容已快取 | 規則符合後，仍看得到舊內容。 | 重新發出請求，並透過連線紀錄確認；不要只查看已開啟的頁面。 |
| 目標同時使用 IPv4 與 IPv6 | 只設定 IPv4 規則，仍有其他位址成功連線。 | 查看實際目標位址；IP-CIDR 不涵蓋 IPv6，相關語法需另外確認。 |
| App 自動重試或切換網域 | 一個目標遭拒絕後，接著又出現新的目標。 | 逐一確認請求用途，不要因為重試就擴大為拒絕整段位址。 |
連線已建立時，後續頁面行為不一定會立即反映新規則。測試規則時，應以修改後建立的新連線為準。關閉目標頁面後重新開啟，必要時結束目標 App 再重試；同時留意連線重複使用的情況，避免把舊連線上的傳輸誤認為新規則失效。
六、依連線紀錄排查規則未生效或誤封
排查時一次只修改一項。先重現失敗的請求，再查看 App 內的連線紀錄與 Log（記錄）；相關入口及可顯示欄位以目前 App 為準。重點記下目標網域或 IP、發出時間、最終策略，以及紀錄中可見的比對規則。分享紀錄前，請遮蔽訂閱網址、權杖及其他帳戶資訊。
- 確認請求進入處理範圍：檢查 Home 的連線狀態與 Global Routing。若紀錄中沒有新請求，先排查連線狀態、快取，以及目標是否確實發出請求。
- 確認目標：頁面顯示的網站名稱不一定是發生錯誤的資源網域。依據對應時間的連線紀錄，確認實際主機名稱與位址。
- 確認生效檔案：返回 Config，確認編輯的是目前使用的設定檔，並確認儲存、載入後規則仍然存在。
- 確認規則順序：由上往下檢查可能先行比對的放行規則，以及 FINAL 的位置。
- 撤回這次修改：只移除新加入的 REJECT，再重現相同操作。功能恢復表示這次規則值得優先檢查，但仍須根據紀錄判斷實際依賴。
- 縮小範圍後再測試：將網域後綴規則改成單一網域，或將網段改成單一位址；分別測試登入、圖片、搜尋、播放等實際受影響的功能。
規則已儲存，為什麼目標還是能開啟？
先在 Home → Global Routing 選擇 Config，再確認 Config 中目前使用的檔案。重新發出請求，檢查目標是否與規則相符、規則是否位於 FINAL 之前；已快取的頁面不能作為規則已比對的證據。
加入 DOMAIN-SUFFIX 後登入失敗，該怎麼調整？
先撤回新增規則並重新測試登入。再從失敗時的連線紀錄確認必要網域，將拒絕範圍縮小到實際目標；若確實需要保留例外，請將例外放在拒絕規則之前，並沿用該網域原本需要的路由策略。
加入 no-resolve 後，就不會有 DNS 請求嗎？
不是。它限制的是為了比對該 IP 規則而觸發的主動解析，不會停用其他 DNS 行為。若要依網域拒絕請求，請先使用 DOMAIN 或 DOMAIN-SUFFIX，不要以此參數取代網域規則。
設定更新後封鎖規則消失，需要重新匯入訂閱嗎？
先檢查 Config 中生效檔案的規則區段是否仍保留本機修改。遠端設定更新可能會取代檔案內容；請保留副本，確認更新前後的差異後，再還原必要規則。重新匯入連線訂閱無法取代這個步驟。
完成確認後，保留最精簡的修改並記錄用途；不要將暫時排查用的全域模式、整段位址拒絕或大範圍網域後綴規則留作長期設定。下次遇到相同問題時，能準確撤回單一規則，比維護一份來源不明的長清單更容易找出問題。