· 規則進階 · 約 9 分鐘

Shadowrocket REJECT 規則教學：封鎖請求的作用與限制

了解 REJECT 如何搭配 DOMAIN-SUFFIX 等規則封鎖請求，以及規則比對範圍與可能影響正常功能的情況。

本文重點

REJECT 是請求的處理策略，不是網頁元素過濾器。本文適合已在 Shadowrocket 中使用自己的設定、服務商與訂閱，準備新增封鎖規則或排查誤擋情況的使用者。請先確認 Global Routing 設為 Config，再檢查命中的規則、目標範圍與回退方式；閱讀後即可分辨「規則未命中」、「命中後遭拒絕」及「頁面內容不在規則處理範圍內」這三種情況。

REJECT 在何處生效

Shadowrocket（小火箭）會依據設定中的規則決定如何處理流量。REJECT 表示拒絕符合條件的請求；它和 DIRECT、PROXY 一樣，都是可在規則結尾指定的策略，但處理結果不同。規則負責選擇目標，策略負責決定如何處理，兩者不可混為一談。

發起請求 接管流量 比對規則 命中拒絕規則 請求失敗

上述流程僅描述進入 Shadowrocket 處理範圍，且最後符合 REJECT 規則的請求。開啟應用程式開關，不代表目前一定會依設定規則分流。請先在 Home 查看 Global Routing；若要驗證目前設定中的拒絕規則，應選用 Config，並在 Config 中確認已選取剛才編輯的設定。

若使用 Global Routing 中的 Scene，也應先確認目前 Scene 的實際設定，不要只根據開關狀態推斷規則路徑。排查時將測試條件固定為 Config，可減少自動切換與不同模式造成的干擾。

規則如何選擇請求

一條基本規則由比對類型、比對內容與策略組成。例如 DOMAIN-SUFFIX,example.com,REJECT：比對類型是 DOMAIN-SUFFIX，目標是 example.com 這個網域後綴，處理策略是 REJECT。此處的 example.com 僅為保留示例網域，不代表應封鎖的實際服務。

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,PROXY

以下範例用於說明規則順序，不可整段取代現有設定。設定中的規則會依序參與比對：對於可識別為 login.example.com 的請求，前面的精確規則會先決定處理方式；其他符合 example.com 後綴的網域則會遭拒絕；未由前面規則處理的請求才會交由 FINAL 處理。DIRECT 僅用來示範例外策略，實際使用時應保留該服務原本可用的策略。

網域比對範圍

DOMAIN
DOMAIN,ads.example.com,REJECT，只比對這個完整網域。
DOMAIN-SUFFIX
DOMAIN-SUFFIX,example.com,REJECT，涵蓋根網域及其子網域。
不符合的名稱
notexample.com 並非 example.com 的子網域。

目標只有一個主機時，請先使用 DOMAIN，避免擴大拒絕範圍。

位址與最終規則

IP-CIDR
IP-CIDR,192.0.2.0/24,REJECT，依目標 IPv4 網段比對。
GEOIP
GEOIP,CN,DIRECT，依據 IP 位址歸屬資料庫比對。
FINAL
FINAL,PROXY，處理先前未命中的請求。

192.0.2.0/24 是文件專用的示例網段；位址規則不能取代網域規則。

網域規則需要可供比對的網域資訊，位址規則則依據目標位址。解析程序、DNS 快取，以及應用程式是否直接使用 IP，都可能影響實際觀察到的資訊。不能只看瀏覽器網址列，就認定每個相關連線都會帶著相同網域進入規則比對。

可以封鎖哪些內容

REJECT 的作用範圍是請求，而不是螢幕上的某個區塊。單一頁面可能同時請求主文件、圖片、字型、統計介面與登入介面；若其中某個獨立網域精確符合規則，該目標的請求即可遭拒絕。頁面其他部分是否仍能正常顯示，取決於是否依賴這個目標。

實際情境REJECT 的限制檢查重點
附加資源使用獨立網域可以拒絕該網域的請求，但不保證頁面會自動收起空白區域。確認實際資源網域，不要只看頁面名稱。
正文與附加內容共用同一網域DOMAIN-SUFFIX 無法依 URL 路徑區分兩者。拒絕整個網域，可能同時影響正文、圖片或互動功能。
內容已快取至本機新增拒絕規則不會清除應用程式已儲存的內容。確認是否真的發出了新請求，避免誤以為舊內容代表規則失效。
內容直接嵌入主要回應網域拒絕策略無法只移除回應中的某段文字或版面。分辨獨立網路請求與同一回應中的內容。
目標直接使用 IP 位址不能假設 DOMAIN-SUFFIX 一定能取得可供比對的網域。檢查連線記錄中的實際目標位址與命中規則。

HTTPS 常見使用 TCP 443，HTTP/3 常見使用 UDP 443，但連接埠號碼無法說明請求的服務用途。同一網域上的正常介面與其他資源可能都使用 443。DOMAIN-SUFFIX 本身也沒有連接埠篩選條件，不會因目標更換連接埠，就變成另一種服務識別機制。

結論：先找出獨立目標，再新增拒絕規則

只有確認目標可與正常功能分開時，才新增範圍最小的 DOMAIN 規則；若兩者共用同一網域，不要只因路徑名稱就擴大為整個後綴的 REJECT。

誤擋為何發生

常見的誤擋原因不是語法錯誤，而是比對範圍超出預期。將 DOMAIN-SUFFIX,example.com,REJECT 加入設定後，login.example.com、static.example.com 與 api.example.com 都會受到影響。登入頁可以開啟卻無法送出資料，或正文正常顯示但圖片無法載入，都可能是因為不同子網域負責不同功能。

  1. 根網域範圍過廣：原本只想拒絕 ads.example.com，卻寫成 example.com，連帶影響帳戶、圖片與介面。
  2. 共用位址遭整體拒絕：多個網域可能共用同一個代管或分發位址。將單次觀察到的 IP 擴大為 IP-CIDR 網段，可能會拒絕無關服務。
  3. 正常依賴項被當成附加資源：驗證碼、帳戶驗證、付款轉址與媒體授權可能依賴其他網域。頁面看似正常，關鍵操作卻可能無法完成。
  4. 例外規則順序錯誤：精確的允許規則寫在範圍較廣的拒絕規則之後；前面的規則一旦命中並決定處理結果，後面的例外就無法補救。
  5. 編輯與實際使用的設定不同：修改了 Config 中的一份檔案，實際使用的卻是另一份設定，導致排查方向偏離。

遇到「偶爾可以使用」的情況，也不要立刻認定 REJECT 隨機失效。應用程式可能沿用既有連線、讀取快取，或切換至其他服務網域。請固定同一項操作並重新發出請求，再依據該次記錄確認目標；不要直接比較兩次不同頁面或不同帳戶狀態下的結果。

一次只排查一個變因

驗證拒絕規則前，請先保留一份可還原的設定，再一次只修改一個目標。不要同時切換策略、調整 DNS、更新訂閱並新增多條規則，否則即使功能恢復，也無法判斷是哪項變更造成影響。以下步驟不需變更既有服務商，只需檢查本機規則與實際請求。

  1. 記錄基準狀態：記下失敗的操作，例如「開啟登入頁後送出表單」，以及發生時間。確認修改前該操作是否正常。
  2. 固定連線模式：在 Home → Global Routing 選擇 Config，再到 Config 確認目前使用的設定。若測試期間連線遭自動變更，請再檢查 Settings → On Demand 的條件。
  3. 重現一次：重新執行相同操作，並在應用程式可用的連線記錄或日誌中，查找該時間點的目標網域、IP、命中規則與策略；只記錄實際顯示的欄位，不要自行推測補齊。
  4. 縮小規則範圍：若命中範圍較廣的 DOMAIN-SUFFIX，請先在測試副本中移除這條規則，再依實際目標改用 DOMAIN。其他規則與原本的最終策略維持不變。
  5. 套用並重新測試：儲存設定並確認變更已套用；必要時選擇可中斷網路作業的時機重新連線，再執行相同操作，避免沿用既有連線。
  6. 回退比對：移除該規則後問題恢復，重新加入後又失敗，才有較充分的依據將問題歸因於該規則。若沒有這組比對結果，請繼續檢查其他規則與目標，不要接連擴大允許範圍。

日誌只顯示連線失敗，不代表已證明命中 REJECT。DNS 解析失敗、連線逾時或遠端回傳錯誤，也可能造成「無法開啟」的情況。請優先檢查策略與規則欄位；若記錄資訊不足，只能將原因列為待確認。分享排查資料前，請遮蔽訂閱網址中的憑證、帳戶資訊及不必要的瀏覽記錄。

結論：功能恢復後再收緊規則

先撤銷已確認造成故障的單一拒絕規則，恢復原本可用的策略，再逐一驗證更精確的目標；不要用永久放行整個父網域來掩蓋尚未找出的誤擋原因。

常見問題與處理方式

新增規則後，為什麼頁面內容還在？

先到 Home → Global Routing 確認已選擇 Config，再到 Config 檢查目前使用的檔案。接著重新載入頁面並查看實際目標；若內容來自快取、主要回應或其他網域，新增的 DOMAIN-SUFFIX 規則不一定涵蓋得到。REJECT 也不會移除頁面留下的占位區域。

一封鎖就無法登入，該允許哪些項目？

先在測試副本中撤銷最近新增的拒絕規則，再重複登入操作。若登入恢復，請依據記錄確認登入所需的完整網域，使用 DOMAIN 規則並將它排在範圍較廣的拒絕規則之前，策略則採用該服務原本可用的設定；不要直接將所有相關父網域改為 DIRECT。

把網域改成 IP-CIDR，封鎖會更精準嗎？

不一定。位址可能變動，也可能由多項服務共用。只有明確要處理特定目標位址或網段時，才使用 IP-CIDR；不要把某次解析取得的位址視為該服務永久且專用的識別資訊。請先保留網域層級的測試，再確認位址規則是否擴大影響範圍。

更新自己的訂閱後，需要重寫 REJECT 規則嗎？

先檢查實際變動的是連線項目還是設定檔。訂閱更新本身無法證明本機規則已變更；若目前設定也經過遠端更新，請比較規則內容、順序與選取狀態。只有確認修改遺失或目標變更後才調整，不要每次更新都重複新增相同規則。

日常維護可保留三項紀錄：完整的拒絕目標、新增原因及撤銷方式。正常功能出現異常時，先檢查最近的變更，再一次只調整一個變因進行測試。規則數量並非成效指標；範圍明確、命中結果可解釋且能及時回退，才便於長期維護。

App Store 正版核對