Shadowrocket（小火箭）的 REJECT 是連線處理策略，不是網頁元素過濾器。本文適合已使用自己的設定檔，並想確認網域拒絕規則的使用者：先確認 Global Routing 使用 Config，再檢查規則順序、網域資訊是否可見，以及新連線記錄；只有確定不需要存取整個目標網域時，才擴大 DOMAIN-SUFFIX 的拒絕範圍。
REJECT 的定位：規則決定匹配對象，策略決定處理方式
一條規則通常包含規則類型、匹配內容與處理策略。以 DOMAIN-SUFFIX,example.com,REJECT 為例，DOMAIN-SUFFIX 表示依網域後綴匹配，example.com 是匹配內容，REJECT 才是命中後拒絕連線的策略。REJECT 不是網域清單，也不能只因設定中出現這個詞，就認定目標連線一定會被拒絕。
一般的規則分流流程會由上往下檢查，命中後採用對應策略。因此，排在前面的寬泛放行規則，可能讓後面的拒絕規則沒有機會生效。FINAL 是前面的規則都未命中時的兜底項目，應放在規則清單末尾；它不會補做檢查，也不會在連線已命中前面的規則後覆寫結果。
DIRECT：對匹配的連線採用直連處理。REJECT：拒絕匹配的連線。應用程式可能顯示失敗、重試或等待逾時，實際情況取決於應用程式本身。- 代理策略或策略組：讓匹配的連線使用設定中對應的出站。策略名稱必須在目前的設定中有效，不能任意填入未定義的名稱。
規則是否參與判斷，也取決於目前的執行模式。請在 Home → Global Routing 確認目前選項；本文的排查前提是使用 Config。Proxy 與 Direct 不能作為驗證設定規則是否命中的同等測試條件；使用 Scene 時，應先確認該場景目前實際採用的分流設定。
DOMAIN-SUFFIX 的範圍：整個網域後綴，不包含網頁路徑
DOMAIN-SUFFIX,example.com,REJECT 會匹配 example.com 以及 img.example.com 等子網域，不會因為字串相似就匹配 notexample.com。如果只想處理特定主機名稱，可考慮使用 DOMAIN 精確匹配，避免一併拒絕相同後綴下的其他服務。
| 規則或目標 | 匹配結果 | 確認重點 |
|---|---|---|
example.com | 後綴規則命中 | 根網域也在範圍內 |
img.example.com | 後綴規則命中 | 子網域在範圍內 |
notexample.com | 未命中此後綴規則 | 網域標籤邊界不同 |
example.com/assets/banner.jpg | 無法依路徑區分處理 | 後綴匹配不檢查 URL 路徑 |
以下是規則片段，用來說明「精確例外在前、後綴拒絕在後、兜底規則最後」的順序。範例網域僅供說明語法，不代表實際要封鎖的服務，也不是可直接替換使用的完整設定。套用到現有設定前，請先確認直連例外是否符合實際需求。
[Rule]
DOMAIN,keep.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECT此處 keep.example.com 會先命中精確直連規則；其他屬於 example.com 的目標才會繼續匹配拒絕規則。若將兩條規則對調，例外就會被前面的後綴規則涵蓋。不要為了解決單一網頁問題，就直接拒絕整個公用網域後綴；應從已確認的最小目標開始。
開始驗證：固定執行模式與目前設定
排查時每次只變更一個條件。先儲存目前設定的副本，記錄測試前後的規則順序，再確認編輯的檔案確實是目前使用中的設定。只修改 Config 清單中的另一個檔案、卻沒有切換使用，不能據此證明規則語法有問題。
執行條件
- 分流入口
- Home → Global Routing
- 測試模式
- Config
- 設定確認
- 在 Config 中確認目前使用的檔案
- 連線前提
- 確認 VPN 已連線，再送出新請求
先固定執行條件，再判斷規則是否參與匹配。
規則條件
- 精確匹配
DOMAIN,ads.example.com,REJECT- 後綴匹配
DOMAIN-SUFFIX,example.com,REJECT- 兜底位置
FINAL放在規則末尾- 記錄欄位
- 目標主機、目標 IP、命中規則與處理策略
依據應用程式內實際顯示的記錄欄位進行確認，不要用網頁外觀代替命中證據。
- 選定一個用途明確、可自行確認的目標網域，先用精確規則測試，避免擴大影響範圍。
- 將測試規則放在可能先行命中的寬泛規則之前，儲存設定並確認目前使用狀態。
- 結束舊請求，再重新開啟目標網頁或觸發目標功能，讓應用程式建立新連線。
- 查看連線記錄，核對測試時間、目標資訊與命中策略；必要時保留設定並重新連線 VPN 後再測試。
- 移除測試規則，再重複相同操作並比較新連線結果，確認影響是否來自這條規則。
On Demand 管理的是自動連線條件，不是網域拒絕規則的另一種優先順序。若測試期間 VPN 會自動連線或中斷，可前往 Settings → On Demand 檢查相關條件，避免將隧道狀態變化誤認為 REJECT 間歇性失效。
同網域內容的限制：可以拒絕連線，不能只移除網頁中的一部分
當正文、圖片、登入介面與待處理內容都來自同一個主機名稱時，網域規則無法只靠請求的用途來區分。HTTPS 請求的路徑、回應本文與網頁元素，也不是 DOMAIN-SUFFIX 的匹配欄位。拒絕該網域可能同時影響登入、驗證碼、圖片載入或播放功能。
HTTP/3 通常使用 UDP 443，常見的 HTTPS 連線也可能使用 TCP 443。只看到連接埠 443，無法判斷該連線傳送的是正文、統計資料還是影片；更不能據此保證一條拒絕規則只會影響某一類內容。同樣地，連線遭拒後，應用程式可能改用其他網域、備用介面或現有快取，因此看起來仍顯示原有內容。
結論：無法區分服務用途時，先縮小匹配範圍
若加入後綴拒絕規則後，登入或正文也無法使用，請先移除該規則；只有在連線記錄確認存在獨立目標主機後，才使用 DOMAIN 單獨測試該主機，不要繼續擴大網域或 IP 範圍。
- 網頁出現空白區域：可能只是資源連線失敗，REJECT 不會重新排版網頁。
- 內容仍然出現：先排除本機快取、既有長連線與備用網域，不能直接判定規則未命中。
- 整個網頁無法開啟：檢查是否誤拒絕主站、驗證介面或共用資源網域。
加密 DNS 與 IP 規則：關鍵在匹配時可取得哪些目標資訊
網域規則需要在匹配時取得可用的網域資訊。DNS 解析方式、快取、應用程式是否直接連線 IP，以及設定中的 DNS 處理方式，都會影響記錄中能看到的內容。不能把「使用加密 DNS」直接等同於「所有網域規則都失效」，也不能假設每條 IP 連線都能可靠還原為原始網域。
使用 DoH 的應用程式可能透過 HTTPS 與解析端點通訊；這項請求不代表後續查詢的所有網域都會直接顯露。若後續服務連線只呈現 IP，且沒有可用的網域關聯資訊，網域規則就可能無法匹配。反之，若 Shadowrocket 已有可用的網域對應或其他目標資訊，仍可能依網域處理；請以該次連線記錄為準。
| 記錄或現象 | 優先確認 | 不建議直接採取的做法 |
|---|---|---|
| 看得到目標網域，但命中其他策略 | 規則順序、目前設定與拼字 | 立刻更換 DNS 碰運氣 |
| 只看到目標 IP | 解析路徑、網域關聯與應用程式連線方式 | 假設網域規則一定會命中 |
| 拒絕 IP 後多項功能異常 | 共用 IP、CDN 與其他服務連線 | 繼續擴大拒絕網段 |
IP-CIDR 匹配位址或網段，GEOIP 則依 IP 地理資料庫分類；兩者都不是依網頁內容分類。語法範例 IP-CIDR,192.0.2.1/32,REJECT,no-resolve 使用文件保留位址；其中 /32 表示單一 IPv4 位址，no-resolve 表示不為這條 IP 規則主動觸發網域解析。這不是用來補足所有缺失網域資訊的選項，也不應直接照用於實際封鎖。
排查結論：以新連線的命中記錄為依據
判斷 REJECT 規則是否有效，至少要分別確認「設定已啟用」、「目標已匹配」與「結果符合預期」。只看到網頁內容仍在，不能證明拒絕沒有發生；只看到某條連線失敗，也不能證明是 REJECT 所致。記錄中的目標、時間、命中規則與應用程式行為必須互相對應。
- 未命中 REJECT：檢查 Home → Global Routing 是否設為 Config，再確認目前設定、規則位置、網域邊界與可用的目標資訊。
- 已命中但內容仍在：重新送出請求，排除快取、舊連線與備用網域，並記錄實際承載內容的連線。
- 已命中且功能異常：移除該規則，再以更小的範圍驗證；若不同服務共用同一網域，就不要繼續嘗試用後綴規則區分網頁內容。
- 需要保留長期規則：記錄目標用途、加入原因與復原方式。更新設定後，重新確認規則是否仍存在及順序是否改變。
既有訂閱通常用於更新連線資料；Config 中的規則設定則是另一項需要確認的內容。更新訂閱不代表拒絕規則也已更新；更新設定檔也可能影響本機修改。若使用者已有自己的服務商與訂閱，排查時應分別確認連線資料及規則檔案的狀態，不必為了測試 REJECT 更換連線服務。