本文適合已有可用設定檔，準備調整封鎖規則的 Shadowrocket（小火箭）使用者。先在 Home 確認 Global Routing，再到 Config 檢查目前設定檔的 [Rule]：以 DOMAIN 精確比對，透過 DOMAIN-SUFFIX 涵蓋子網域，並將例外規則排在封鎖規則前，再查看請求記錄驗證。文中的網域與位址僅供語法示範，不代表有可用服務。
先確認 Home 與 Config：REJECT 在哪裡生效
在 Home 查看 Global Routing，驗證本文規則時選擇 Config，再到 Config 確認目前使用的設定檔。開啟該設定檔的編輯畫面，檢查 [Rule] 區段。只將規則寫入某個檔案、卻未啟用該檔案，不會改變目前連線的處理方式；同樣地，若 Home 的連線開關已關閉，也不能根據瀏覽結果判斷這份規則是否生效。
REJECT 是規則比對成功後採用的策略，不是規則類型，也不是伺服器名稱。規則會先判斷請求是否符合條件，符合後才執行拒絕處理。它不需要先將請求送到某台代理伺服器再拒絕，也不會刪除已儲存在本機的網頁內容。
驗證步驟
- Home
- 確認連線開關已開啟
- Global Routing
- 選擇 Config
- Config
- 確認已啟用剛修改的設定檔
- [Rule]
- 檢查規則順序與最終策略
先確認設定檔有參與請求處理，再判斷規則本身是否正確。
Global Routing 模式
- Config
- 依目前設定檔中的規則分流
- Proxy
- 全域代理，不適用於驗證本文的規則分流
- Direct
- 全域直連，不適用於驗證本文的規則分流
- Scene
- 依場景設定運作，需另外確認目前使用的場景
排查期間固定使用 Config，避免場景變更干擾驗證。
Settings → On Demand 用來管理依條件建立或中斷連線的行為，不能取代 [Rule] 中的網域比對。若測試時連線狀態反覆變化，請先檢查 On Demand 的條件；不要一再新增 REJECT 規則，試圖解決連線本身無法維持的問題。
了解比對順序：符合前面的規則後即停止
在一般規則分流中，規則會由上而下依序檢查。請求符合某條規則後，就會採用該規則指定的策略，不會繼續往下尋找「更合適」的策略。因此，精確放行規則通常排在範圍較廣的封鎖規則前，而 FINAL 則用來處理前面都未符合的請求。
[Rule]
# 先允許這個精確網域直連
DOMAIN,help.example.com,DIRECT
# 再拒絕 example.com 及其子網域
DOMAIN-SUFFIX,example.com,REJECT
# 此片段中的其他請求直連，僅供語法示範
FINAL,DIRECT在這三條規則中，help.example.com 會先符合第一條並使用 DIRECT；media.example.com 符合第二條並使用 REJECT；其他未符合規則的網域則由 FINAL 處理。如果將第二條移到第一條上方，說明頁面也會遭到拒絕，因為它同樣是 example.com 的子網域。
選擇規則範圍：DOMAIN 與 DOMAIN-SUFFIX 的用法
只想封鎖明確的主機名稱時，優先使用 DOMAIN。若要涵蓋主網域及其所有子網域，再使用 DOMAIN-SUFFIX。兩種寫法的目標欄位都只填網域本身，不包含通訊協定、連接埠、路徑或查詢參數；例如不能將整個 https://ads.example.com/banner 當成網域欄位。
| 規則範例 | 比對範圍 | 使用前檢查 |
|---|---|---|
DOMAIN,ads.example.com,REJECT | 精確比對 ads.example.com | 確認請求記錄中的主機名稱完全相符 |
DOMAIN-SUFFIX,example.com,REJECT | 比對 example.com 及其子網域 | 確認登入、圖片與介面是否共用此網域後綴 |
IP-CIDR,192.0.2.7/32,REJECT,no-resolve | 比對單一 IPv4 目標位址 | 此處為文件示範位址，並非實際封鎖目標 |
IP-CIDR 依 IP 位址範圍比對，GEOIP 則依 IP 地理位置比對，兩者都不同於網域後綴比對。範例中的 no-resolve 表示不為這條 IP 規則額外觸發網域解析；若此時請求只有網域資訊，不能認定它一定會符合該位址規則。對共用位址直接使用 REJECT，也可能影響同一位址上的其他網站。
先精確比對，再擴大範圍
先依請求記錄中確認的單一主機名稱建立 DOMAIN 規則；只有確認其他子網域也應拒絕時，才改用 DOMAIN-SUFFIX，避免一次封鎖整個服務網域。
釐清適用範圍：REJECT 無法依網頁元素篩選
REJECT 適合拒絕可獨立識別的網路目標，例如頁面單獨請求的某個網域。它不是網頁元素篩選器：若本文、圖片與需要封鎖的內容共用同一個主機名稱，單純的網域規則就無法只針對其中一個路徑。拒絕該網域可能同時導致本文介面、登入驗證或靜態資源載入失敗。
- 同一網域、不同路徑：
example.com/news與example.com/banner無法透過 DOMAIN 規則分別處理；路徑不是此規則的比對欄位。 - 內容已快取：符合 REJECT 規則後，頁面仍可能顯示先前快取的圖片或文字。請查看新請求的處理記錄，而非只確認舊頁面是否消失。
- 目標網域變更：頁面可能改由另一個主機名稱重新請求內容。請確認實際發出的新請求，不要只因名稱相似就不斷擴大後綴範圍。
- 只看到目標 IP：若比對階段沒有可用的網域資訊，就不能假定 DOMAIN-SUFFIX 會符合；請先確認記錄中的目標類型。
- 共用基礎設施：同一個 IP 可能承載多個網域。改用 IP-CIDR 不代表比對就一定更精確，封鎖較大的網段尤其需要謹慎。
HTTPS 加密不代表所有網域規則都會失效，但 REJECT 本身也不會解密並檢查網頁內容。不要只為了封鎖某個網路目標，就先啟用 HTTPS 解密或安裝憑證；本文的規則驗證不需要這些操作。也不要因為網頁留下空白區塊，就認定規則失效：網路請求遭拒後，頁面版面不一定會自動移除原有區域。
驗證與復原：從實際請求找出誤擋原因
在 Config 儲存修改後，再次確認該設定檔已啟用。回到 Home 確認 Global Routing 設為 Config，必要時重新連線，再次開啟目標頁面以觸發新請求。在 App 內的請求記錄中查看目標網域或 IP、處理策略及可查看的規則資訊；記錄入口與欄位請以目前介面顯示為準。
- 先保留原始設定檔：修改前留存可還原的副本，並記下新增規則的位置，確保可以復原，不必只能繼續新增規則。
- 每次只修改一項：先新增一條精確規則，儲存並驗證；不要同時修改 Global Routing、DNS 和多條 IP 規則，否則難以判斷變化的來源。
- 確認是否出現新請求：若記錄中沒有目標請求，請重新載入頁面或重新開啟相關功能，避免將快取或舊連線誤認為新的規則結果。
- 核對實際策略：若記錄顯示 DIRECT 或其他策略，請檢查是否符合較前面的規則；若顯示 REJECT 但頁面仍有內容，請檢查快取及其他請求網域。
- 以最小範圍復原：先撤銷最近新增的規則。確認確實需要保留後綴封鎖時，再將精確例外放在它上方，並使用原有設定檔所需的放行策略。
放行不代表一定要使用 DIRECT。DIRECT 表示直連；如果某項服務在原設定檔中應使用代理，就應恢復原本採用的策略。前文的 DIRECT 只是用來示範例外規則的順序，不能直接套用到所有服務。如果要還原的策略名稱引用了策略群組，也要確認該名稱存在於目前的設定檔中。
設定 REJECT 後，為什麼還是能開啟？
先到 Home 確認 Global Routing 是否設為 Config，再到 Config 確認啟用的檔案。重新觸發請求後查看實際主機名稱；若符合前面的放行規則，請調整規則順序，而不是重複新增相同的 REJECT 規則。
新增規則後，登入按鈕一直轉圈怎麼辦？
撤銷最近新增的規則，重新開啟登入流程，並檢查請求記錄中的驗證或介面網域。若是範圍過廣的 DOMAIN-SUFFIX 造成誤擋，請縮小為精確的 DOMAIN，或在其前方加入必要的精確例外。
Connectivity Test 正常，就能證明封鎖成功嗎？
不能。Home 中的 Connectivity Test 用來檢查連線是否可達，不代表指定網域已符合 REJECT。請讓目標功能發出請求，再核對該次請求的處理記錄。
更新訂閱後，手動編寫的規則會保留嗎？
請先區分 Home 中伺服器訂閱的更新，以及 Config 中設定檔的更新。更新伺服器清單不等於編輯 [Rule]；重新取得遠端設定檔則可能覆蓋本機修改。操作前請保留副本，更新後核對目前使用的檔案與規則位置。訂閱連結請向你的服務供應商取得。
最終驗收需同時符合兩點：目標的新請求依預期使用 REJECT，且需要保留的登入、圖片與介面仍採用正確策略。只確認「某個頁面無法開啟」不足以證明規則準確；可重現的目標、明確的比對範圍，以及可還原的設定檔，才是後續維護的依據。