Shadowrocket（小火箭）的 REJECT 是請求處理策略，不是網頁元素過濾器。本文適合已有可用設定檔、準備新增本機封鎖規則的使用者：先區分比對條件與處理策略，再於 Config 模式檢查規則順序，最後透過啟用或停用單一規則，比較是否誤封。範例使用示意網域與文件專用 IP 位址，請依實際請求替換，並非可直接套用的封鎖清單。
REJECT 是什麼：命中後拒絕連線
REJECT 的作用是拒絕符合該策略的請求，而不是替請求選擇代理伺服器。規則前半段描述比對條件，最後指定處理策略。例如 DOMAIN,ads.example.com,REJECT 中，DOMAIN 是規則類型，ads.example.com 是比對值，REJECT 才是請求符合規則後採取的動作。請勿將 REJECT 填入伺服器位址或連接埠欄位。
規則只能處理進入相應分流流程的流量。在 Home → Global Routing 選用 Config，才是依目前設定檔檢查本文規則的常見測試方式。Proxy 和 Direct 是全域處理模式，不能視為驗證設定檔內 REJECT 的等效條件；Scene 則須依所選場景的實際設定判斷。若請求未進入 Shadowrocket 的處理流程，修改設定檔中的 REJECT 也不會影響該請求。
DIRECT：請求採用直接連線策略，不代表拒絕連線。PROXY：請求交由對應的代理策略處理；能否使用仍取決於目前設定與伺服器。REJECT：拒絕請求，這條拒絕規則不需要設定代理出口。
規則怎麼寫：從精確網域開始
優先使用 DOMAIN 精確比對，再依需求擴大到 DOMAIN-SUFFIX 或 DOMAIN-KEYWORD。以下是設定檔 [Rule] 區段的語法範例。三條規則用來對照比對範圍；實際排查時，先只啟用需要的規則，避免範圍重疊而無法判斷是哪一條生效。
[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,tracker.example.net,REJECT
DOMAIN-KEYWORD,telemetry,REJECT
FINAL,DIRECT網域條件與範圍
- DOMAIN
- ads.example.com,REJECT：只比對完整網域。
- DOMAIN-SUFFIX
- tracker.example.net,REJECT：比對該網域本身及其子網域。
- DOMAIN-KEYWORD
- telemetry,REJECT：比對網域中含有此關鍵字的請求。
網域條件不填寫 https://、頁面路徑或查詢參數。
位址條件與兜底規則
- IP-CIDR
- 192.0.2.7/32,REJECT：比對單一 IPv4 位址。
- GEOIP
- CN,DIRECT：依 IP 地理資料庫中的地區結果比對。
- FINAL
- DIRECT：處理未符合前面規則的請求。
位址規則仰賴可用的目標 IP 資訊，無法取代精確網域規則。
網域規則比對主機名稱，不比對完整 URL。若目標位址是 https://ads.example.com/banner?id=1，網域規則比對的是 ads.example.com，而不是 /banner 或 id=1。將整段 URL 填入 DOMAIN-SUFFIX，無法達到「只封鎖這個頁面」的效果。
範例中的 FINAL,DIRECT 僅用來示範完整的規則結尾。它會讓未命中的流量直接連線，不應用來取代你原有的 FINAL 策略。將範例合併至現有設定檔時，只加入需要的拒絕規則，並保留原有的兜底方式與有效策略名稱。
如何安排比對順序：例外在前，寬泛條件在後
一般規則會依由上而下的順序判斷，請求採用第一條符合規則的策略。同一網域可能同時符合精確網域與後綴條件，系統不會自動選擇「看起來更精確」的規則。因此，允許存取的例外必須放在範圍較廣的拒絕規則前面，FINAL 則放在一般規則的末尾。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECT- 前往
login.example.com：先符合第一條，採用 DIRECT，不再比對後面的後綴拒絕規則。 - 前往
ads.example.com：不符合第一條，但符合第二條，因此採用 REJECT。 - 前往
example.com：網域本身也在第二條的比對範圍內，因此同樣會被拒絕。 - 前往
example.org：不符合前兩條，最後由 FINAL,DIRECT 處理。
結論：先調整例外位置，再擴大封鎖範圍
若要保留登入網域，請先將允許規則移到後綴拒絕規則上方，再測試登入與業務頁面。若將兩條規則順序對調，即使精確例外仍留在設定檔中，請求也會先符合範圍較廣的規則，導致例外失效。
排查「規則已設定卻沒生效」時，應先檢查前面的比對條件。例如上方已有 DOMAIN-SUFFIX,example.com,DIRECT，下方再新增 DOMAIN,ads.example.com,REJECT，該請求仍會先直接連線。解決方式是調整順序或縮小上方條件範圍，而不是反覆新增相同的 REJECT 規則。
如何新增與驗證：一次只修改一條規則
先複製目前的設定檔，再修改副本並選用該副本。以下操作以 iPhone / iPad 的 Home、Config 介面為例，其他平台請依實際選單操作。請使用自己已有的設定檔與服務；本文不提供、不販售或推薦節點或訂閱。
- 進入 Config，確認目前使用中的設定檔，並保留修改前的副本，以便還原。
- 開啟待修改設定檔的編輯介面，找到規則區段；若以文字方式編輯，請在既有的
[Rule]區段新增規則，勿重複建立彼此分開的同名區段。 - 先新增一條精確規則，例如
DOMAIN,ads.example.com,REJECT，並將它放在可能符合該網域的寬泛規則前面；保留原有的 FINAL 不變。 - 儲存並選用修改後的設定檔，返回 Home → Global Routing，確認已選用 Config，並確認連線開關已開啟。
- 關閉目標 App 或頁面的舊連線，再重新發出請求；分別記錄目標功能與應保留功能的狀況。
- 暫時刪除或停用剛新增的規則，再發出相同請求。若功能會隨規則啟用或停用而改變，再進一步確認規則範圍是否合適。
既有連線與本機快取可能使測試結果延遲反映。已載入頁面的圖片不會因新增 REJECT 而自動消失；App 也可能沿用先前建立的連線。請先發出新請求，再比較啟用與停用規則的差異。不要因快取仍顯示舊內容就認定規則失效，也不要將單次網路逾時直接歸因於 REJECT。
封鎖的適用範圍：拒絕網域不等於過濾內容
REJECT 適合封鎖可獨立識別的請求目標，不適合依頁面文字或元素進行精細過濾。若廣告、登入與正文使用相同網域，拒絕該網域可能同時影響這些功能。對 HTTPS 請求而言，僅靠 DOMAIN 類規則無法辨識特定 URL 路徑；本文所述的網域拒絕也不需要為此啟用 HTTPS 解密。
- 同網域資源：拒絕整個業務網域，可能連正文圖片、帳號驗證或付款回呼一併阻擋；應優先尋找能獨立識別的目標。
- 關鍵字範圍過廣：
DOMAIN-KEYWORD,ad,REJECT的涵蓋範圍遠大於單一廣告網域；一般業務網域只要包含這段字元也可能符合，不適合作為初次測試規則。 - 共用 IP：多個網站可能共用同一個 CDN 位址。使用 IP-CIDR 拒絕某個位址時，影響範圍未必只限於原先觀察到的網站。
- 動態位址：伺服器位址變更後，手動記錄的 IP 可能不再涵蓋目標；反過來說，舊位址也可能已供其他服務使用。
- 比對資訊不足：若處理流程只有目標 IP，沒有可供比對的網域資訊，網域規則可能不會命中。請核對實際請求記錄，而非不斷擴大關鍵字範圍。
結論：無法區分資源時，優先維持服務正常
若目標內容與必要服務共用網域，且找不到可獨立識別的請求目標，就不要繼續擴大 DOMAIN-SUFFIX 或 IP-CIDR 的範圍。撤回造成誤封的規則，比用更多例外修補過於寬泛的條件更容易維護。
常見問題：誤封、更新覆蓋與自動連線
多數問題應從目前設定、路由模式與最近一次變更開始排查。先暫停擴充規則清單，保留可重現的單一測試條件，再依照以下順序處理。App 介面顯示的連線狀態只能說明通道狀態，無法單獨證明某條 REJECT 已命中。
新增 REJECT 後，為什麼目標仍然可以開啟？
先在 Home → Global Routing 確認已選用 Config，再前往 Config 確認選中修改後的檔案。檢查拒絕規則上方是否已有 DIRECT 或其他先命中的條件；最後關閉舊連線並重新發出請求，排除快取與沿用既有連線的影響。
封鎖後無法登入，應新增什麼例外？
先撤回最近新增的拒絕規則，確認登入是否恢復，再核對登入流程實際使用的網域。若該網域與封鎖目標不同，請將精確的允許規則放在寬泛拒絕規則前面；若兩者共用網域，單靠網域規則無法可靠區分。
更新後，本機新增的規則為什麼不見了？
先確認更新的是 Home 中的伺服器訂閱，還是 Config 中的遠端設定檔。更新伺服器清單與更新規則檔案是兩回事；重新整理遠端設定檔可能會取代本機編輯內容。更新前請先儲存副本，更新後再檢查規則區段與順序，並選用需要的設定檔。
Settings → On Demand 可以取代規則開關嗎？
不行。On Demand 用於依照設定條件觸發連線，不負責指定特定網域要採用 DIRECT 還是 REJECT。測試時請先確認通道已連線，再檢查 Global Routing 與目前設定檔；若要取消某項封鎖，應修改對應規則。
維護規則時，應記錄修改原因與還原方式。每次只處理一個目標，記下實際網域、使用的規則類型，以及必須保留的服務功能。若設定檔來自遠端來源，重新整理後也要再次確認本機變更。如此才能分開判斷「拒絕範圍是否正確」與「目前連線是否正常」，避免將所有網路問題都歸咎於封鎖規則。