本文適合已在 Shadowrocket 啟用設定檔，並想新增或排查封鎖規則的使用者。先分清「比對條件」與「處理策略」，再透過最精簡的規則範例檢查比對順序，最後瞭解同網域請求、加密連線與快取如何限制封鎖效果。所有網域與位址皆為示範值；若需測試連線，請以使用者已有的服務商與訂閱為前提。
一、REJECT 是處理策略，不是內容辨識規則
Shadowrocket（小火箭）的規則通常包含比對條件與處理策略。例如 DOMAIN-SUFFIX,example.com,REJECT 中，前兩個欄位決定哪些連線符合條件，最後的 REJECT 則表示比對成功後拒絕連線。它不會因為頁面上出現某個詞、某張圖片或某種版面，就自動辨識並移除相關內容。
在依設定檔分流的情境中，可將流程分成以下五個步驟。這裡說明的是規則處理邏輯，不代表用戶端總能從每條連線取得完整網域，也不代表能讀取加密請求的內容。
規則通常由上而下檢查，命中第一條符合的規則後就會執行相應策略。因此，寫在檔案末尾的精確封鎖規則可能永遠不會執行：連線可能已在更前面的廣泛規則命中 DIRECT 或其他策略。排查時必須同時確認「命中哪條規則」與「最後執行什麼策略」，不能只搜尋檔案中是否出現 REJECT。
二、用最精簡的規則核對 DOMAIN 與 DOMAIN-SUFFIX
先在 Config 備份目前的設定檔，再編輯測試用副本。以下片段只示範 [Rule] 的比對關係，不是可直接取代現有設定的完整設定檔。範例使用保留作示範用途的網域，不對應任何真實封鎖目標。
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECT依照這個順序，account.example.com 會先命中精確例外；media.example.com 與根網域 example.com 則會被後綴規則拒絕；不屬於該後綴的其他連線則交由 FINAL 處理。此處使用 DIRECT 只是為了說明邏輯，不代表實際使用時應將所有未命中的流量改為直連。
精確例外
- 關鍵字
- DOMAIN
- 比對值
- account.example.com
- 策略
- DIRECT
- 放置位置
- 放在廣泛後綴規則之前
只允許此主機名稱，不會自動允許其子網域。
後綴封鎖
- 關鍵字
- DOMAIN-SUFFIX
- 比對值
- example.com
- 策略
- REJECT
- 涵蓋範圍
- 根網域及其子網域
後綴欄位不需填入 https://、路徑或連接埠，也不必加上星號。
儲存後，還要確認已在 Config 中選取此副本作為目前設定檔，並在 Home → Global Routing 選擇 Config。不能將 Proxy 或 Direct 視為啟用設定檔規則的替代方式；若使用 Scene，則需先確認該場景最後套用的路由行為。修改後請重新建立測試連線，避免沿用修改前已存在的連線。
結論：先用精確主機名稱驗證，再擴大範圍
先新增一條 DOMAIN 規則並檢查命中紀錄；確認目標與影響範圍後，再決定是否改用 DOMAIN-SUFFIX。不要一開始就封鎖整個平台的根網域。
三、REJECT 與 REJECT-DROP：差別在拒絕方式
REJECT 與 REJECT-DROP 都是拒絕連線的策略，但回應方式不同。一般使用 REJECT，連線會較快失敗；REJECT-DROP 則傾向靜默丟棄，讓發起端等待逾時。實際錯誤狀況也會受到 TCP、UDP、App 重試機制及目前實作方式影響，無法保證所有 App 都會立即停止請求。可用策略名稱請以目前用戶端的規則編輯器及支援情況為準。
| 策略 | 處理方式 | 需留意的情況 |
|---|---|---|
REJECT | 拒絕連線，通常會較快回報失敗 | App 可能立即顯示錯誤，或立刻改試備用網域 |
REJECT-DROP | 靜默丟棄，等待發起端逾時 | App 可能長時間顯示載入中，也可能重複送出請求 |
兩者都不會自動將拒絕結果轉變為「頁面內容已正確隱藏」。App 收到失敗回應後，可能留下空白區域、顯示錯誤圖示，或改用備用介面。也不要把 REJECT-DROP 當成更強的網域比對方式：如果連線根本沒有命中這條規則，替換最後的策略也不會擴大比對範圍。
- 需要確認規則是否命中時，先查看請求紀錄，不要靠載入動畫持續多久來猜測。
- 若畫面持續轉圈，先排查遭拒絕的請求是否為登入、驗證或初始化介面。
- 切換拒絕策略時，每次只修改一個變因，並重新執行相同操作，記錄行為差異。
四、網域封鎖的限制：同網域內容、HTTPS 與共用位址
若要拒絕的資源使用獨立網域，通常較容易透過網域規則劃定範圍。但若一般內容與目標資源都來自 api.example.com，只是分別使用 /content 與 /promotion 路徑，DOMAIN 和 DOMAIN-SUFFIX 就無法區分兩者。拒絕該主機名稱，可能連正文、登入與帳戶狀態也一併中斷。
對於常見的 HTTPS 連線，例如目標連接埠 443，網域規則不等於解密 HTTP 請求。URL 路徑、查詢參數與回應內容都在加密資料中，無法只在網域規則中加上路徑，就達到內容層級的篩選。本文的規則範例也不涉及 HTTPS 解密。
| 請求類型 | 網域規則能否區分 | 操作限制 |
|---|---|---|
track.example.com 與 api.example.com | 可依不同主機名稱分別比對 | 仍需確認前者是否負責必要功能 |
| 同一主機名稱下的兩個 HTTPS 路徑 | 無法只靠 DOMAIN 區分路徑 | 不要將完整 URL 填入網域欄位 |
| 多個網域共用同一個服務位址 | 以 IP 封鎖時無法保留網域層級的區分 | 可能連其他正常服務也一併影響 |
| App 讀取本機快取 | 沒有新連線就無從比對 | 頁面仍顯示不代表規則失效 |
將網域規則改成 IP-CIDR 也無法解決同網域內容混用的問題。例如 IP-CIDR,192.0.2.10/32,REJECT 表示拒絕這個示範用 IPv4 位址，並非只拒絕某個網站；192.0.2.0/24 的涵蓋範圍則更大。實際服務也可能使用多個位址或 IPv6，任意擴大位址範圍容易誤封，也不保證能完整涵蓋。
結論：同網域內容混用時，先保留功能，再評估是否值得封鎖
一般功能與目標資源共用主機名稱時，先撤銷範圍過廣的拒絕規則，恢復必要功能。只有找到可獨立驗證的請求網域後，才新增範圍較小的規則；不要用整段位址封鎖取代內容判斷。
五、規則沒有作用時，依據證據逐步排查
「仍然看到原本的內容」本身不足以證明規則失效。App 可能沒有重新送出請求、請求可能轉向備用主機名稱，或目前連線並未經過預期的規則路徑。建議保留修改前後的設定檔副本，並記錄測試時間、操作步驟、目標主機名稱與最後執行的策略，以便重現問題。
- 確認目前使用的設定檔與路由模式。進入
Config確認啟用的檔案，再核對Home → Global Routing → Config。只儲存檔案但未啟用，無法影響目前連線。 - 重新觸發網路請求。儲存後中斷連線再重新連線，必要時關閉目標 App 後重新開啟。重新整理頁面時，確認是否真的產生新請求，而非只讀取快取。
- 檢查請求紀錄。在用戶端的連線或請求紀錄中，依測試時間找到目標，核對可見的主機名稱、目標位址、命中規則與最後執行的策略。只看到 REJECT 字樣還不夠，還要確認它對應的是本次目標請求。
- 核對規則順序與可見資訊。查看是否先命中範圍較廣的放行規則；若紀錄中只有 IP，不能假定 DOMAIN-SUFFIX 一定取得得到可用的網域資訊。確認 App 是否自行透過加密 DNS 解析，或直接連線至位址。
- 進行單一項目的對照測試。暫時停用剛新增的一條規則，再重複相同操作。停用後功能恢復，表示該規則可能與問題有關；接著應縮小比對範圍，而不是繼續疊加拒絕規則。
檢查規則順序時，也要一併檢視 GEOIP、IP-CIDR 與 FINAL。它們不是內容分類器：GEOIP 依位址歸屬比對，IP-CIDR 依位址範圍比對，FINAL 則處理前面都未命中的連線。若範圍較廣的規則先命中，後面的目標網域規則就不會執行。
六、常見問題：誤封、快取與設定檔更新
新增規則後無法登入，應先移除哪一條？
先暫時停用這次新增的 REJECT 規則並重新嘗試登入，確認功能是否恢復。接著查看登入時的請求紀錄，優先檢查涵蓋根網域的 DOMAIN-SUFFIX。若已確認某個驗證主機名稱必須保留，可在範圍較廣的規則之前新增精確例外，並沿用原本可用的路徑策略；不要在未驗證前直接放行整個平台。
紀錄已顯示 REJECT，為什麼頁面仍有內容？
先確認紀錄是否對應該頁面本次發起的請求，而非背景中的其他連線。接著重新開啟頁面，觀察是否出現新連線。已快取的圖片、已下載的內容與 App 內建素材，不會因連線遭拒絕就自動消失；規則也不會移除頁面上的預留區塊。
App 改用其他網域發出請求，需要把所有新網域都封鎖嗎？
不要依照網域出現的順序批次新增規則。先比對各主機名稱出現時執行的操作，判斷是否與目標功能相關，再一次測試一個主機名稱。備用介面可能同時提供正常內容；尚未確認用途的登入、付款或同步請求應先保留。
更新訂閱後，自訂的 REJECT 規則為什麼不見了？
先分清 Home 中連線項目的訂閱更新與 Config 中設定檔的更新，兩者並非同一件事。檢查目前啟用的檔案是否已變更，以及遠端設定檔更新是否覆蓋手動修改。保留本機測試副本與自訂規則清單，每次更新後比對檔案內容及規則順序；不要只因連線項目仍在，就認定規則也保留下來。
判斷封鎖是否適用，最終要看三項條件：請求是否經過目前的規則路徑、用戶端是否取得足夠的比對資訊，以及目標能否與必要功能分開。條件都符合時，使用精確規則並保留回復用副本；若無法分開，就應接受網域層級處理的限制，而不是用範圍更廣的規則掩蓋問題。