本文重點

REJECT 是拒絕符合條件的連線，不是網頁元素過濾器。本文適合已使用 Config、準備新增封鎖規則的使用者：先確認連線是否經過規則判斷，再以單一精確規則測試，最後查看連線記錄找出誤封原因並還原原設定。範例僅用於說明語法，不能直接套用為封鎖清單。

REJECT 的作用：拒絕連線，而非移除頁面內容

Shadowrocket（小火箭）的規則由比對條件與處理策略組成。條件用來判斷「哪些連線符合」，策略則決定「符合後如何處理」。例如 DOMAIN,blocked.example.com,REJECT 表示：規則判定的目標網域與該名稱相符時，對這條連線套用 REJECT，而不再依照後續規則選擇輸出路徑。

應用程式提出請求 由隧道接管 規則判斷 符合 REJECT 拒絕連線

這個流程的前提是相關流量進入 Shadowrocket 的處理範圍，且目前的路由模式使用相應規則。這不代表裝置上的所有通訊都受到全域保證，也不表示網頁中所有不想看到的內容都會消失。應用程式可能保留載入中的佔位畫面、顯示錯誤訊息，或在請求失敗後繼續重試。

因此，判斷規則是否生效，應確認連線是否符合規則並遭到拒絕，而不是只看頁面是否留下空白區域。空白、持續轉圈或錯誤訊息，都可能是資源載入失敗後的頁面呈現；這些現象不能證明 REJECT 自動調整了頁面排版。

先確認 Global Routing，再檢查規則順序

在 Home 查看 Global Routing。測試目前設定中的規則時，先使用 Config，並在 Config 確認已啟用剛才編輯的設定檔。Proxy 與 Direct 是全域處理模式，不能直接用其結果判斷目前設定中的 REJECT 是否正確；使用 Scene 時，也要確認場景實際採用的設定檔與路由設定。

3 項
本文說明的策略：PROXY、DIRECT、REJECT
4 行
以下範例：精確網域、網域後綴、GEOIP、FINAL
1 條
每次測試只新增或修改一條封鎖規則

判斷原則：先確認設定生效，再擴大比對範圍

如果無法確認目前啟用的設定檔，請先停止新增規則；確認 Config 與請求記錄相符後，再測試單一目標網域，避免把路由模式問題誤判為語法問題。

規則會依序判斷，符合後便套用相應策略，不會為了尋找「更精確」的寫法而自動跳到後面的規則。因此，精確例外應排在範圍較廣的規則之前，FINAL 則放在最後。以下是獨立的語法範例，所有網域僅供說明；請勿據此變更既有設定的整體輸出策略。

[Rule]
DOMAIN,allowed.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
GEOIP,CN,DIRECT
FINAL,PROXY

依照這個順序，allowed.example.com 會先符合第一行，不會被第二行拒絕；blocked.example.com 則會符合第二行。若將第一行移到第二行之後，精確例外便不再生效。GEOIP 依目標 IP 的地區資訊判斷，不代表頁面語言或網站營運者所在地。

DOMAIN、DOMAIN-SUFFIX 與 IP-CIDR 的適用範圍

已知單一問題網域時，建議先用 DOMAIN 進行最小範圍測試。確認整組子網域都應拒絕後，再考慮使用 DOMAIN-SUFFIX。後者會涵蓋指定網域及其子網域，不是只比對名稱中剛好含有某段字串的網域；若填入主站網域，可能連登入、圖片與 API 請求也一併受到影響。

網域範圍範例

精確比對
DOMAIN,blocked.example.com,REJECT
後綴比對
DOMAIN-SUFFIX,example.com,REJECT
精確例外
DOMAIN,allowed.example.com,DIRECT

例外規則應放在範圍較廣的規則之前；DIRECT 僅為語法示意，實際上應維持該目標原本需要的策略。

IP 範圍範例

單一 IPv4 位址
IP-CIDR,192.0.2.8/32,REJECT
一段 IPv4 位址
IP-CIDR,192.0.2.0/24,REJECT
位址用途
192.0.2.0/24 是文件範例位址範圍

此處僅展示語法；實際位址必須根據自己的連線記錄確認，不能直接照抄並當成有效的封鎖目標。

網域規則需要有可供規則判斷使用的目標網域資訊。若應用程式直接連線至 IP、網域關聯資訊不完整，或實際請求改用其他目標，原有網域規則可能無法符合。此時應先查看連線記錄中的實際目標，不要因為「網域沒擋住」就直接拒絕整個大型網段。

哪些內容能封鎖，哪些無法只靠 REJECT 處理

若不需要的資源來自獨立網域，且該網域不負責必要功能，以網域為單位拒絕通常較容易控制範圍。反之，如果同一網域同時提供正文、登入驗證及其他資源，網域規則無法只根據 URL 路徑區分用途。HTTPS 連線中的個別頁面內容，也不會因為新增 DOMAIN 規則就自動成為比對條件。

請求情況REJECT 的限制確認方式
獨立資源網域可拒絕連往該網域且符合規則的連線確認該網域沒有同時提供登入或業務 API
同一網域下的不同路徑DOMAIN 無法只拒絕其中一條路徑比較異常請求與必要請求的主機名稱是否相同
已快取的內容沒有新的網路請求，就不會觸發新的規則判斷重新載入，並確認是否出現新的連線記錄
既有長連線修改規則不代表既有連線會立即重新比對儲存設定後重新建立連線，再重現相同操作
共用服務位址拒絕該位址可能連帶影響其他服務優先確認網域及其用途，避免擴大封鎖整段 IP

如果網頁上仍顯示某個區塊，可能是內容已嵌入主文件，也可能是應用程式的本機快取；請求遭拒後，介面也可能保留固定高度的容器。不要為了消除這些畫面殘留，繼續新增涵蓋主站與靜態資源網域的規則。規則層負責處理連線去向，不負責隱藏頁面元素。

從新增到驗證：每次只測試一條規則

修改前，先在 Config 保留一份可還原的原始設定，並記下原本的 Global Routing、所選輸出與測試頁面。若設定來自遠端管理或更新來源，也要確認本機修改是否會被後續更新覆蓋。使用者既有的服務與訂閱內容由其提供者負責；本文只說明本機規則的測試方式。

  1. 記錄基準狀態。先不要新增 REJECT，開啟目標頁面，記錄登入、圖片與 API 的正常狀況；原本就有的故障不應歸因於新規則。
  2. 修改設定。在 Config 開啟目前使用的設定檔進行編輯，於規則區段新增一條精確的 DOMAIN 規則，並放在可能先行比對的廣泛規則之前。
  3. 確認已啟用。儲存修改並確認目前使用的設定檔，再返回 Home 確認 Global Routing → Config。不要只儲存了未啟用的副本。
  4. 重新建立連線。必要時關閉再開啟 Home 的連線開關，接著讓目標應用程式重新發出請求。此操作會暫時中斷目前的連線，請避開正在進行的工作。
  5. 核對記錄。查看應用程式內可用的連線或請求記錄，找出同一時間的目標網域與處理策略；若詳細資料有提供命中規則資訊，也一併記錄。若沒有目標請求記錄，不應直接下結論。
  6. 重新測試功能。測試一般頁面、登入、搜尋與圖片載入等相關功能。只有在目標確實遭拒且必要功能仍正常時，才保留這條規則。

不要只憑回應速度變快就認定規則有效，也不要把單次逾時當成命中規則。同一頁面的資源載入會受到快取、登入狀態與伺服器回應影響。可靠的判斷需要同時確認目標請求、實際套用的策略，以及移除規則後的對照結果。

頁面異常時，先以最小範圍復原

誤封常見於登入驗證網域、圖片服務、共用 API，以及應用程式啟動時需要的設定請求。表面上可能只是按鈕沒有反應、內容持續載入或登入不斷跳轉，實際遭拒的卻是後端依賴的連線。先撤銷最近新增的規則，比繼續增加「修復規則」更容易確認原因。

新增規則後登入一直轉圈，該先修改哪裡？

在 Config 撤銷最近新增的 REJECT，儲存並重新建立連線，再次嘗試登入。如果恢復正常，檢查登入時連線的目標網域；將範圍過廣的 DOMAIN-SUFFIX 縮小為已確認的單一 DOMAIN，不要直接放行所有請求。

已新增規則，目標仍然可以開啟？

依序檢查 Home 的 Global Routing 是否設為 Config、Config 中啟用的檔案是否正確，以及前面是否已有 DIRECT 或 PROXY 規則先行符合。接著重新載入目標頁面，排除快取與舊連線的影響，再確認實際請求是否改用了其他網域。

請求已遭拒，為什麼頁面還有空白區塊？

空白區塊可能是頁面原有的版面容器。查看連線記錄確認 REJECT 生效後，就不必再擴大封鎖範圍；不要連主頁網域也一併拒絕，否則正常的頁面內容可能也無法載入。

可以把 FINAL 改成 REJECT，省去逐條設定嗎？

FINAL,REJECT 會拒絕所有未符合前述規則的連線，不只是不需要的某類資源。除非正在維護經過完整驗證的允許清單，否則請保留原本的 FINAL；排查時還原原始設定，比臨時變更預設策略更穩妥。

若撤銷規則後仍有異常，請還原修改前保留的完整設定，再確認目前啟用的檔案、連線狀態，以及目標服務本身是否正常。只有在某條規則存在時能穩定重現問題，才繼續縮小該規則的範圍。需要設定例外時，將精確規則放在廣泛的 REJECT 之前，並使用該目標原本需要的 DIRECT 或 PROXY；不要預設一律改成 DIRECT。