Shadowrocket REJECT 規則設定：封鎖原理、比對順序與適用範圍

一、REJECT 何時生效：先比對目標，再執行策略

每條規則都要回答兩個問題：請求是否符合比對條件？符合後要採取什麼策略？例如 DOMAIN-SUFFIX,example.com,REJECT 中，DOMAIN-SUFFIX 是比對類型，example.com 是比對值，REJECT 才是動作。命中後，該連線會遭拒絕，不會因為連線失敗就繼續套用下一條規則。

這個流程的前提是目標流量會經過 Shadowrocket 處理。若連線開關關閉、流量未經通道，或目前路由模式未使用這份規則，修改 REJECT 就不會直接改變該請求的去向。因此，請依序確認連線狀態、路由模式、設定檔與命中規則，而不是先大量新增封鎖項目。

REJECT 主要影響網路請求，不會刪除頁面上已顯示的文字、圖片佔位區或應用程式的本機內容。請求遭拒時，可能會出現資源載入失敗、圖片空白、應用程式重試或錯誤提示。實際情況取決於應用程式本身的錯誤處理方式，不能認定所有應用程式都會出現同一種畫面變化。

二、REJECT 規則語法：優先使用網域，謹慎設定 IP 範圍

只封鎖單一完整主機名稱時，使用 DOMAIN；要涵蓋某個網域及其子網域時，使用 DOMAIN-SUFFIX。比對值請填主機名稱，不包含 https://、連接埠、斜線路徑或查詢參數。例如，要比對 https://ads.example.com/banner 的主機，應填入 ads.example.com，而不是整段網址。

DOMAIN-SUFFIX,example.com,REJECT 可涵蓋 example.com 和 img.example.com，但不代表會比對任何含有這段字元的網域。若只想封鎖單一資源主機，請勿直接擴大到整個主網域；登入、圖片與 API 可能分布在同一主網域的不同子網域。

IP-CIDR 用來比對 IPv4 位址或網段，/32 表示單一 IPv4 位址，/24 則表示包含 256 個位址的網段。若對共用基礎設施套用大範圍網段的 REJECT，可能連帶影響多個無關網域。網域背後的 IP 位址也可能變更，因此記錄一次解析結果後長期封鎖該 IP，並不等同於穩定封鎖該網域。

三、規則比對順序：精確例外在前，FINAL 在後

使用依設定檔規則處理流量時，系統會由上而下檢查規則，第一條命中的規則就會決定採用的策略。後面較精確的項目不會自動取代前面已命中的寬泛規則。最常見的錯誤，是先設定整個網域後綴的 REJECT，再把要保留的子網域放在後面；如此一來，例外規則就永遠不會生效。

[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.8/32,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

在這段順序範例中，account.example.com 會先命中第一條規則，不再繼續比對第二條；只有 img.example.com 會遭後綴規則拒絕。GEOIP,CN,DIRECT 依據目標 IP 的地理位置資料庫進行比對，而非依網頁語言判斷。若它排在 REJECT 前面，符合條件的請求可能會先直接連線。

FINAL 是最後的兜底規則，不需要填入網域比對值。此處使用 FINAL,DIRECT 只是為了讓範例完整，不代表你應將原設定的最終策略改為 DIRECT。實際操作時，請保留原有的最終策略，只將已確認的精確規則插入適當位置；同一份設定中也不要為了新增封鎖項目而重複加入 FINAL。

四、在 Config 中修改並驗證：一次只新增一條規則

以下依 Home、Config、Settings 的介面結構說明檢查位置，實際編輯入口仍以目前的應用程式介面為準。請先備份目前可正常使用的設定，再編輯目前選取的 Config。不要只憑檔案名稱判斷是否正在使用，也不要把訂閱清單更新誤認為設定規則已更新。

1. 確認使用模式。在 Home 檢查連線狀態與 Global Routing。驗證設定規則時請選擇 Config；Proxy、Direct 不適用於本文的規則命中驗證。若使用 Scene，請先確認目前場景實際採用的路由設定。
2. 確認目標設定。前往 Config，確認目前選取的檔案，先備份，再找到 [Rule] 區段。若已有此區段，請直接編輯其中的項目，不要在檔案末尾另外建立一組重複結構。
3. 新增最精簡的規則。先選定確實需要拒絕的完整主機名稱，使用 DOMAIN 規則，並將它放在相關的寬泛規則之前；其他既有策略則保持不變。
4. 儲存並套用。確認儲存後的檔案仍是目前選取的設定，並依介面提示套用。若需要重新建立連線，請留意其他正在進行的網路工作可能受到影響。
5. 重新發出請求。關閉後重新開啟目標頁面或相關應用程式，盡可能建立新連線。記錄目標網域、命中的規則與策略；若記錄中沒有足夠資訊，請勿只憑頁面空白就判定已命中 REJECT。
6. 一次只回復一項變更。移除剛新增的這條規則，儲存後以相同操作重新測試。比較前後狀況，再決定要保留規則、縮小範圍或繼續排查。

既有連線、瀏覽器快取與應用程式本機快取，都可能讓規則修改後的畫面與預期不同。請優先重新發出目標請求，而不是連續修改多項設定。記錄時應區分「新請求遭拒」、「沒有發出新請求」及「請求已成功但畫面未變」；這三種情況需要採取不同的後續處理。

五、封鎖能力的限制：同網域內容、快取與共用 IP

網域規則只能依據它能辨識的目標資訊來分流。如果正常 API 與要封鎖的內容使用相同主機名稱，只有 URL 路徑不同，DOMAIN 和 DOMAIN-SUFFIX 就無法區分兩者。將該主機名稱設為 REJECT，往往也會一併拒絕正常 API。

• HTTPS 路徑不是網域比對條件。https://api.example.net/feed 與 https://api.example.net/banner 的主機名稱相同。無法在 DOMAIN-SUFFIX 後加上 /banner 來過濾路徑，443 連接埠本身也不能區分這兩類服務。
• 本機內容不會產生可供封鎖的請求。已下載的資源、離線頁面和應用程式內建內容，不會因新增網路規則而立即消失。
• 共用 IP 無法精確代表單一網站。同一個 IP 可能承載多個網域。請優先驗證可辨識的網域規則，不要為了封鎖某項資源就直接拒絕整個位址範圍。
• 連線資訊不一定完整。直接使用 IP 的請求無法只靠網域規則比對；網域資訊是否可用也取決於實際解析與連線路徑，需搭配連線記錄判斷。
• 伺服器端的資源位置可能變動。目標可能更換網域、位址或請求方式。若舊規則沒有命中，請重新確認請求目標，不要盲目擴大到整個主網域。

因此，REJECT 可用來拒絕明確的目標連線，但無法保證清除所有推廣內容，也不能保證封鎖後頁面版面依然完整。改用 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard 等協定，不會讓 DOMAIN-SUFFIX 自動具備讀取並篩選網頁內容的能力；出站協定與規則比對各自負責不同工作。

六、常見問題：規則未生效、誤封與更新後變化

長期維護時，請記錄每次修改的目標主機、修改原因與回復方式。發現誤封時，先恢復正常使用，再分析目標請求；不要同時修改 DNS、出站協定與整套規則，否則難以判斷是哪個步驟改變了結果。若要繼續查找問題，可參考排查手冊，核對目前設定與連線記錄。

本文假設使用者已有自己的服務供應商與訂閱，僅說明本機規則的管理方式。本網站不提供、不販售也不推薦節點、訂閱或連線服務。買斷客戶端 ≠ 線路方案；新增 REJECT 也不會產生新的連線設定。