Shadowrocket REJECT 規則設定：封鎖原理、匹配範圍與限制

一、REJECT 的作用位置：拒絕連線，不修改網頁

Shadowrocket（小火箭）的規則由匹配條件與目標策略組成。REJECT 位於策略欄位，表示拒絕命中的請求；它不是協定，也不需要另外新增伺服器。規則生效的前提是相關流量進入 Shadowrocket 的處理路徑，並依目前設定的規則進行判斷。

網域規則判斷的是目標網域，而不是網頁中的文字、圖片內容或按鈕位置。如果某個頁面從獨立網域載入統計資源，拒絕該網域可能會阻止取得相關資源；如果內文、登入功能與圖片都依賴同一個網域，拒絕該網域也可能讓這些功能一併失效。規則無法自動判斷哪些回應是使用者需要的內容。

請求遭拒後呈現的畫面由發出請求的應用程式決定，可能是空白區域、載入失敗、重試提示，也可能保留舊內容。不能只憑「頁面仍在顯示」就判定規則沒有執行，也不能把一次載入失敗直接歸因於 REJECT；網路中斷、DNS 異常與伺服器錯誤也可能造成類似現象。

二、基本語法：先用 DOMAIN，再決定是否擴大範圍

一般網域規則的結構是「規則關鍵字、匹配內容、策略」，各欄位以英文逗號分隔。以下是獨立的教學範例：第一條只拒絕指定主機，第二條拒絕指定後綴及其子網域，最後一條讓其他請求直接連線。實際使用時，請將需要的規則合併到現有設定中，不要用這段內容整份取代原本的分流設定。

[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,telemetry.example.com,REJECT
FINAL,DIRECT

請勿在 DOMAIN 或 DOMAIN-SUFFIX 的匹配內容中填入 https://、連接埠、路徑或查詢參數。https://example.com/banner?id=1 是 URL，不是網域；將整段填入網域規則，並不會因此取得依路徑封鎖的能力。

三、規則順序與 Global Routing：規則寫對，不代表正在使用

在 Home 檢查 Global Routing。驗證本機設定中的一般分流規則時，應選擇 Config；Proxy 與 Direct 是全域路由模式，不能用它們的結果證明 Config 中的 REJECT 規則有效。Scene 必須依實際情境設定判斷，不能簡單視為 Config 的同義項。接著在 Config 確認已選取並啟用剛修改的設定。

1. 在 Config 儲存目前設定的副本，再開啟要修改的本機設定。
2. 在 [Rule] 中新增一條範圍明確的 REJECT 規則，避免重複建立多個同名段落。
3. 將例外規則放在可能涵蓋它的廣泛規則之前，並讓 FINAL 留在規則末尾。
4. 儲存後確認目前使用的是修改過的設定，再回到 Home 核對 Global Routing 是否為 Config。
5. 重新發出目標請求，並依請求記錄中的目標、策略與命中規則檢查結果。

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

此例先為 account.example.com 設定 DIRECT 例外，再拒絕其他匹配 example.com 後綴的請求。一般規則依照由上而下的順序匹配，命中第一條後便採用對應策略；如果將廣泛的後綴規則移到前面，後面的例外就無法改變已做出的判斷。

四、DOMAIN-SUFFIX 與 URL Rewrite 的適用界線

DOMAIN-SUFFIX 不會檢查 HTTP 路徑。假設同一主機同時提供 /article/ 和 /banner/，網域規則無法只阻止後者。URL Rewrite 適用於可見的 HTTP 請求 URL，可依其支援的匹配與處理方式運作，但不能因此推論「所有 HTTPS 路徑都能直接讀取」。

HTTPS 的路徑與查詢參數受到 TLS 保護。若要檢查這些內容，通常需要為相關主機正確設定 HTTPS 解密、安裝並信任憑證；只新增一條 URL Rewrite 並不會自動滿足這些條件。有些應用程式使用憑證固定等機制，可能不接受這類處理。HTTP/3 等傳輸路徑也需另外確認支援情況，不能只根據連接埠推斷是否能改寫。

憑證與 HTTPS 解密會改變信任邊界，不應只為了測試一條封鎖規則就擴大到所有主機。本文不提供通配解密設定；若無法確認影響範圍，請優先保留精確的網域規則，或使用目標應用程式提供的內容設定。

五、IP-CIDR 與 GEOIP：位址匹配不是內容分類

目標可能直接使用 IP 位址，也可能使用共用的內容傳遞基礎架構。此時應區分「網域規則無法取得可匹配的主機名稱」與「IP 規則範圍過大」這兩種問題。GEOIP 判斷位址所屬地區，IP-CIDR 判斷位址是否位於指定網段；兩者都無法判斷某個回應是否為廣告或統計資料。

[Rule]
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
FINAL,DIRECT

192.0.2.0/24 是文件範例網段，不是建議封鎖的實際目標。no-resolve 表示不為這條 IP 規則主動觸發網域解析；已有可用目標位址時，仍可能依位址匹配。它不代表停用所有 DNS，也不代表能將 IP 規則轉成網域規則。

• 同一個 IP 可能承載多個網域，拒絕該 IP 可能同時影響正常圖片、登入介面或其他網站。
• 同一個網域可能對應多個 IPv4、IPv6 位址，只處理一個 IPv4 位址不代表已完整涵蓋該網域。
• GEOIP 的地區結果不代表內容用途，不能取代「整類內容都不需要」這種分類標籤。
• DNS、快取與連線重複使用都會影響觀察結果，應搭配新的請求記錄判斷，不能只看單次解析結果。

六、驗證與復原：透過請求記錄建立可重複的判斷

測試時一次只變更一個條件。先記錄尚未修改規則時的頁面狀況，再新增一條規則，重新開啟目標頁面或觸發相應操作。如果應用程式沿用現有連線，新規則未必會反映在舊連線上；如果內容已快取，也可能完全沒有新請求。必要時先關閉目標應用程式再重新開啟，並以新產生的請求記錄為準。

1. 確認目標：核對實際請求主機；重新導向後主機可能改變，不要只照抄瀏覽器網址列。
2. 確認流量接管：核對連線狀態與 Global Routing，確保測試請求走目前 Config 的處理路徑。
3. 確認命中：查看新請求是否採用 REJECT；若未命中，先檢查規則順序、網域拼字與目前使用的設定。
4. 確認影響：檢查登入、圖片、播放與付款等正常功能，不要只確認目標區域是否消失。
5. 確認可以復原：刪除或停用剛新增的項目，再次發出請求；若問題隨之恢復，再縮小匹配範圍。

不要用一次延遲測試取代內容請求驗證。連線測試成功，只能說明相應測試目標的結果；這既不能證明目標網域命中 REJECT，也不能證明某個網頁路徑已獲處理。若要整理排查資料，保留目標主機、命中策略與操作順序即可；分享前請移除訂閱網址、權杖及其他憑證。

七、常見問題：規則生效後仍看得到內容，怎麼辦？

最後保留的規則應同時符合三個條件：目標明確、可透過請求記錄核對、正常功能能夠恢復。規則數量多不代表涵蓋更準確。對於無法獨立區分的內容，停止擴大範圍，比依靠大量猜測性的後綴規則更容易維護。