REJECT 拒絕策略用來阻止符合規則的連線，不是網頁元素過濾器。本文適合已使用 Shadowrocket（小火箭）、準備修改 Config 設定的使用者：先了解網域比對方式，再新增一條可還原的規則，最後透過新請求確認是否命中，並分辨規則未生效、快取未清除與內容無法單獨封鎖等情況。
REJECT 的用途：拒絕連線，不修改頁面
一條規則由比對條件與處理策略組成。DOMAIN-SUFFIX,example.com,REJECT 的意思是：當用於規則判斷的目標網域為 example.com 或其子網域時，採用 REJECT 拒絕策略。它不會先下載頁面再移除某個區塊，也不會根據頁面文字判斷內容類型。
這個流程有兩個前提：請求確實由 Shadowrocket 處理，而且目前使用的路由模式會套用這份設定中的規則。只把規則文字存放在某個檔案裡，不能證明它已參與連線處理。應用程式已顯示的快取內容，也不一定會觸發新的網路請求。
REJECT、DIRECT 直連策略與 PROXY 代理策略的用途不同。DIRECT 仍會發起連線，只是不透過代理連出；PROXY 會使用代理路徑；REJECT 則拒絕該次連線。將 REJECT 改為 DIRECT 並不是另一種封鎖方式，而是允許連線嘗試透過直連路徑建立。
DOMAIN-SUFFIX 寫法：網域不含通訊協定與路徑
在設定檔的 [Rule] 規則區段中，每條規則各占一行，欄位之間以英文逗號分隔。以下是獨立的語法範例，不是要你用它覆蓋現有的完整設定檔。若現有檔案已有 [Rule]，請將規則加入該區段，不要重複建立規則區段。
[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,ads.example.com,REJECT
FINAL,DIRECT比對單一網域
- 關鍵字
- DOMAIN
- 比對值
- metrics.example.com
- 處理策略
- REJECT
- 比對範圍
- 僅限該網域，不會自動包含其子網域
若只想拒絕已確認的單一主機名稱，請先使用精確比對。
網域後綴比對
- 關鍵字
- DOMAIN-SUFFIX
- 比對值
- ads.example.com
- 處理策略
- REJECT
- 比對範圍
- ads.example.com 及其下層子網域
擴大範圍前，先確認子網域是否也用於登入、圖片或 API 請求。
DOMAIN-SUFFIX,example.com,REJECT 會比對 example.com 與 a.example.com，但不會只因為字母相同就比對 notexample.com。這是依網域層級判斷後綴，不是任意字串搜尋，也不需要寫成 *.example.com。
- 不要加入
https://：規則比對值是網域，不是完整網址。 - 不要加上
/banner/image.png：路徑不是 DOMAIN-SUFFIX 的比對欄位。 - 不要加上
:443：連接埠不是這條網域規則的組成部分。 - 不要使用全形逗號：
，與規則語法要求的,不同。
規則順序：先命中的條件決定處理結果
本文所用的一般規則會依設定檔中的排列順序，由上而下進行判斷；最先符合的規則會決定採用的策略。後面的拒絕規則不會推翻已命中的允許規則。因此，排查時要同時檢查目標規則及其前面的規則，而不只是確認檔案中有 REJECT。
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECT這個範例先允許 account.example.com 直連，再拒絕符合該網域後綴的其他請求。若將後綴拒絕規則移到第一行，帳號子網域也會先命中 REJECT，後面的精確例外便不再生效。實際編輯時請保留原設定中的連出策略；不要因為範例以 DIRECT 作為兜底，就把自己的 FINAL 最終規則也改成 DIRECT。
| 規則類型 | 判斷依據 | 排查重點 |
|---|---|---|
| DOMAIN-SUFFIX | 目標網域及其子網域後綴 | 是否已被前面的網域允許規則先行比對 |
| IP-CIDR | 目標 IP 是否位於指定網段 | 同一個位址可能承載多個不同網域 |
| GEOIP | 目標 IP 的地理位置分類 | 不能以地理位置分類取代具體內容辨識 |
| FINAL | 前面的規則都未命中時作為兜底 | 放在一般比對規則之後 |
網域規則與 IP 規則使用的資訊不同。若無法取得網域資訊，就不能假設後綴規則仍會命中；若前面已有一條比對目標 IP 的允許規則，也要檢查它對後續網域規則的影響。不要只因為請求最後連到某個 IP，就立刻拒絕整個網段；同一個位址上的其他服務也可能受到影響。
在 Config 中套用：每次只修改一個目標
修改與驗證請分開進行。先確認目前使用的設定與路由模式，再新增單一規則，最後觀察新請求。Global Routing 全域路由中的 Config 設定模式會依設定規則分流；Proxy 代理模式與 Direct 直連模式不能用來驗證這份設定中的 REJECT 規則是否生效。Scene 情境模式還需確認目前情境的實際設定；初次測試建議先切回 Config。
判斷方式：先確認設定，再擴大封鎖範圍
先用單一已知網域確認 REJECT 能命中，再決定是否改用 DOMAIN-SUFFIX；不要同時更換設定、切換連出策略並大量新增規則，否則難以判斷結果是由哪項變更造成。
- 確認檔案。前往 Config 設定頁面，確認目前選用的設定檔，先儲存備份，再開啟編輯功能。不要修改未被選用的同名檔案。
- 加入規則。在
[Rule]區段加入一條目標明確的 REJECT 規則，並放在可能先行放行該目標的寬泛規則之前，同時保留必要的精確允許例外。 - 儲存並套用。返回 Home 首頁，在 Global Routing 全域路由中選擇 Config 設定模式，並確認連線開關已開啟；必要時重新建立連線，讓後續測試使用已儲存的設定。
- 發出新請求。關閉原本的測試頁面後重新瀏覽目標，查看請求記錄中的目標網域、命中規則與處理策略。已建立的長連線不適合作為唯一測試依據。
- 確認可還原。刪除剛新增的規則並儲存、重新套用，再對同一個目標發出新請求。封鎖與還原後的結果應能對應變化，才能較清楚地判斷兩者的因果關係。
Settings → On Demand 按需連線設定控制的是自動連線行為，不是網域封鎖清單。若測試時嘗試手動關閉連線卻又自動連上，請先檢查 On Demand，避免將自動重新連線誤認為規則無法還原。若設定檔會被遠端更新覆蓋，也請保留自己的修改記錄，並在更新後確認規則是否仍存在。
封鎖限制：僅憑網域後綴無法區分同一網域的內容
網域層級的拒絕適用於「整個目標連線都不需要」的情況。若正常內容與要封鎖的內容來自同一個網域，DOMAIN-SUFFIX 看到的是相同的比對值，無法只允許其中部分路徑。對於 HTTPS 請求，也不能把這條規則當成讀取並分析加密頁面內容的工具。
- 同一網域、不同路徑：
example.com/article與example.com/banner對網域規則而言都是example.com。拒絕該網域可能導致整個頁面無法使用。 - 不同功能共用資源網域：圖片、驗證與統計功能可能使用相同的資源入口。封鎖後可能出現圖片載入失敗、登入驗證失敗或頁面持續等待，而不只是某個區塊消失。
- 網域輪替與備用入口：連線失敗後，應用程式可能會改向另一個網域發出請求。拒絕舊網域不代表所有備用入口都已涵蓋。
- 快取與既有連線：已快取的圖片、離線資料與已建立的連線都會影響觀察結果。頁面仍顯示內容，不能單獨證明規則沒有命中。
- 無法取得網域資訊：直接連線至 IP，或由應用程式自行處理解析等情況，都可能影響網域資訊的取得。請檢查實際請求記錄，不要只憑瀏覽器網址列推斷比對過程。
拒絕連線也不保證頁面上的空白區域會消失。頁面版面由應用程式或網站本身決定；資源載入失敗後，原先預留的區域可能仍會保留，也可能顯示錯誤訊息。REJECT 處理的是連線是否繼續，不負責修復版面。
常見情況：依命中記錄決定下一步
以下排查步驟以使用者已有可用設定為前提。若問題涉及訂閱，請向你的服務供應商取得訂閱連結；用戶端購買與線路方案是不同事項。不要為了解決一條 REJECT 規則的問題，同時更換整份訂閱與所有路由設定。
規則已寫好，為什麼網頁還是能開啟？
先在 Home 首頁確認 Global Routing 全域路由是否設定為 Config 模式，再前往 Config 設定頁面確認目前選用的檔案。重新開啟目標並查看新請求：頁面可能使用了另一個資源網域，也可能只是顯示快取；不能只看頁面是否出現。
記錄已顯示 REJECT，為什麼內容還在？
逐一比對記錄中的網域與實際載入內容的請求。拒絕某個統計網域，不代表內容資源也被拒絕；請關閉測試頁面、排除相關快取影響後再發出請求，並檢查是否出現備用網域。不要把多次失敗重試誤認為拒絕策略沒有執行。
新增規則後，登入和圖片都不能用了怎麼辦？
先撤回本輪新增的規則並重新套用設定，確認功能恢復。接著將 DOMAIN-SUFFIX 後綴比對縮小為 DOMAIN 精確比對；若確實需要保留允許例外，請將例外放在寬泛的拒絕規則之前。若同一網域承載多種功能，就應停止擴大封鎖範圍。
更新設定後，原本有效的規則不見了？
前往 Config 設定頁面檢查更新後的檔案內容，並與備份比較，確認本機修改是否遭到覆蓋，或是否切換到另一份設定。將單一規則加回原本的位置後，再執行一次新請求測試；不要直接貼上多個重複的規則區段。
最後請確認三項可查證的事實：使用的是哪一份設定、新請求命中了哪條規則，以及撤回變更後狀況是否恢復。若這三項都能穩定重現，再保留規則；若無法對應，請先縮小測試目標，而不是繼續疊加拒絕規則。