REJECT 是規則比對成功後執行的拒絕策略，不是網頁元素選取器。本文適合已在使用 Shadowrocket（小火箭）、想限制特定網域連線的使用者，說明 DOMAIN 與 DOMAIN-SUFFIX 的寫法、Global Routing 的選擇、規則順序及誤擋排查方式。操作前提是使用者已有自己的服務商、訂閱與可用設定；請先備份設定，再用單一規則測試，不要直接匯入來源不明的大型清單。
REJECT 在哪個環節生效
一條分流規則包含比對條件，以及命中後採取的策略。以 DOMAIN,ads.example.com,REJECT 為例，DOMAIN 指定比對完整網域，ads.example.com 是比對值，REJECT 則指定拒絕處理。它與 DIRECT 的差別在於：DIRECT 仍會嘗試直接連線至目標；REJECT 則不會將命中的連線透過一般直連或代理路徑送往目標。
上述流程只涵蓋由 Shadowrocket 接管並進入規則判斷的請求。網域規則能否命中，也取決於連線是否有可供比對的網域資訊。如果連線記錄只有目標 IP、沒有關聯網域，就不能只憑瀏覽器網址列中的名稱，斷定 DOMAIN 規則一定會命中。
REJECT 不等於改寫 DNS，也不等於編輯網頁。它不會自動讀取 HTTPS 回應中的頁面結構，更不會依照按鈕文字或圖片位置刪除內容。瀏覽器可能顯示資源載入失敗、圖片空白或請求錯誤；實際呈現方式取決於網站本身的錯誤處理邏輯，不應把某種頁面外觀視為 REJECT 的固定效果。
網域規則的基本寫法
設定檔中的規則通常寫在 [Rule] 區段。以下網域僅供文件示範，並非可直接使用的封鎖清單。實際操作時，請先從自己的連線記錄確認目標名稱，再只加入範圍相符的規則。不要只因網域名稱含有 ads 或 track，就認定可以安全封鎖。
[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,metrics.example.net,REJECT
FINAL,DIRECT第一行只會比對 ads.example.com，不會一併涵蓋 img.ads.example.com。第二行會涵蓋 metrics.example.net 本身及其子網域，例如 event.metrics.example.net；不會將 notmetrics.example.net 這類任意包含相同字串的網域納入比對。網域欄位不填入通訊協定前綴、路徑、查詢參數或連接埠。
精確範圍
- 關鍵字
DOMAIN- 比對值
ads.example.com- 策略
REJECT- 適用條件
- 已確認單一主機的用途，先進行小範圍測試。
先使用完整網域，降低誤擋同一服務其他主機的可能性。
網域後綴範圍
- 關鍵字
DOMAIN-SUFFIX- 比對值
metrics.example.net- 策略
REJECT- 適用條件
- 已確認該網域及其子主機都可以一併拒絕。
擴大為後綴比對前，先確認其下沒有登入、圖片或 API 服務。
範例中的 FINAL,DIRECT 只用來展示完整的最小規則區段，表示前面的規則都未命中時使用 DIRECT。既有設定可能採用其他最終策略；不要為了加入 REJECT 而取代原本的 FINAL，也不要把整段範例接在既有 FINAL 後面。通常只需修改目標拒絕規則，並保留原有分流結構。
- 正確寫法：
DOMAIN,ads.example.com,REJECT。 - 不要將網域寫成
https://ads.example.com/banner；DOMAIN 不會比對 URL 路徑。 - HTTPS 常用連接埠是
443，HTTP 常用連接埠是80；這不代表應將:443或:80填入網域欄位。 - 不要用父網域
example.com的後綴規則取代單一主機規則，除非確實要拒絕整個網域範圍。
啟用 Config 並確認規則順序
寫入規則不代表目前連線已套用該規則。先前往 Config 確認編輯的是目前使用中的設定並儲存，再回到 Home → Global Routing 選擇 Config。Proxy 與 Direct 是全域路由選項，不適合用來驗證設定檔中的個別分流規則；Scene 會依情境設定決定實際路由。排查時，先確認目前選用的 Scene，不要將 Scene 視為 Config 的同義詞。
- 備份：在 Config 中保留原設定副本，並記下原有 FINAL 與目標網域附近的規則。
- 新增：將一條已確認的 DOMAIN 拒絕規則放在可能搶先命中的廣泛規則之前，並確保位於 FINAL 之前。
- 選擇：回到 Home，將 Global Routing 設為 Config，並確認連線開關已開啟。
- 重試：關閉目標頁面或 App 後重新存取；必要時重新連線，讓測試建立新的連線。
- 確認：查看這次請求的目標、命中規則與最終策略；若沒有相應的新記錄，先不要判定規則無效。
規則會依序判斷，最先命中的規則決定處理策略。例如先寫 DOMAIN-SUFFIX,example.com,DIRECT，再寫 DOMAIN,ads.example.com,REJECT，後者可能就沒有執行機會，因為目標已被前面的父網域規則接手。GEOIP 與 IP-CIDR 分別依據 IP 的地理位置及 IP 網段比對；它們不是網頁分類工具，也需要一併檢查前後順序。
[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,example.com,DIRECT
FINAL,DIRECT這個順序代表「先拒絕指定主機，再允許該網域範圍內的其他連線，最後套用兜底規則」。如果既有設定使用規則集或策略組，也要檢查它們是否已在前面攔截目標。不要只找到一條 REJECT 就結束排查；完整判斷需要確認目前設定、目前路由狀態與實際命中記錄彼此一致。
適用範圍與頁面殘留內容
較適合單獨封鎖的，是用途已確認、與主要服務相對獨立的請求網域。光看網域名稱像是統計服務，還不足以確認它沒有業務依賴。有些 API 同時負責工作階段初始化、功能開關或資源簽章；拒絕後可能不只少了一次統計，還會讓 App 無法進入下一步。
| 請求情況 | REJECT 可以處理什麼 | 注意事項 |
|---|---|---|
| 獨立資源主機 | 拒絕連往該主機的命中連線 | 先確認該主機沒有負責必要的資源傳送。 |
| 同一網域的不同路徑 | 網域規則會影響該主機的相關連線 | 無法只拒絕 /banner，同時保留同一主機上的 /login。 |
| 正文中嵌入的內容 | 無法透過獨立網域規則移除同一回應中的部分內容 | 正文中已包含的圖片資料或文字不會自動刪除。 |
| 本機快取資源 | 只會影響之後發生且命中規則的請求 | 命中快取時可能不會觸發新的目標連線。 |
| 共用 CDN 位址 | IP 規則會影響連往該位址的連線 | 同一 IP 可能承載多個無關網域，誤擋範圍會更大。 |
判斷方式：先縮小至單一主機，再決定是否擴大範圍
只有確認同一後綴下的所有主機都可以拒絕，才將 DOMAIN 改為 DOMAIN-SUFFIX。若目標內容與登入或正文共用同一主機，就不要擴大網域範圍，也不要改用更廣的 IP 網段來追求清空頁面。
HTTPS 加密內容不會因為設定 REJECT 就變成可逐段篩選的明文。本文的網域規則不需要為此啟用 HTTPS Decryption，也不需要安裝解密憑證。若目標是刪除頁面中的特定元素，這屬於內容層處理問題，不能以連線層規則是否成功取代判斷。
使用新連線測試並保留還原方式
測試應以一個已確認的實際請求為準，而不是開啟文件中的範例網域並期待特定結果。先記錄未新增規則時的存取狀態，再新增一條規則、發出新請求並檢查命中情況。每次只變更一個條件，才能判斷差異來自規則順序、快取、連線重複使用，還是目標本身已經改變。
- 建立基準：使用原設定完成一次目標操作，記下時間、網域，以及登入、圖片、播放等必要功能是否正常。
- 單條測試：加入精確的 DOMAIN 規則、儲存並確認目前使用的設定；不要同時切換服務、通訊協定與 DNS 設定。
- 發出新請求：重新開啟目標 App 或頁面。重新整理仍可能使用快取；既有長連線也不一定會立即重新進行分流判斷。
- 查看記錄：檢查新連線記錄是否顯示預期目標及 REJECT。若記錄指向其他主機，先確認請求鏈，不要大量新增猜測的網域。
- 測試還原：刪除或註解剛新增的規則，再重試相同操作。只有故障狀態會隨規則新增與撤銷而改變，才能將該規則列為主要疑因。
- 保留記錄：確認規則有效後，記下封鎖原因與影響範圍；設定更新後，再確認這項本機修改是否仍留在目前使用的檔案中。
如果混淆了購買來源或設定來源，請先區分用戶端與連線服務。Shadowrocket 是閉源商業 App，買斷用戶端 ≠ 購買線路方案。本文不提供、不販售也不推薦節點或訂閱；既有訂閱更新後，本機 REJECT 規則也不一定會同步保留，請分別檢查服務資訊與設定檔的更新結果。
常見問題與還原方式
已設定 REJECT，為什麼頁面上還看得到原本的圖片？
先確認是否有新連線產生。頁面可能使用本機快取，也可能從其他主機載入相同資源。重新開啟頁面後查看目標請求記錄；如果目標確實命中 REJECT，但圖片仍在，請確認圖片是否為嵌入內容，不要繼續擴大後綴範圍。
連線開關已開啟，為什麼規則完全沒有作用？
依序確認 Home → Global Routing 是否設為 Config、Config 中目前使用的檔案是否包含新規則，以及規則是否排在 FINAL 和其他可能提前命中的規則之前。接著重新發起連線；只儲存檔案但仍在使用其他設定，不會讓新規則生效。
封鎖後無法登入，需要刪除整份設定嗎？
先撤銷最近新增的規則，其他設定維持不變，再重新連線並測試登入。如果恢復正常，請將後綴規則縮小至已確認的單一主機，或讓該網域維持正常連線。共用的驗證、風險控管與 API 網域，不宜只憑名稱就直接拒絕。
換用其他通訊協定，REJECT 會封鎖得更徹底嗎？
不會因此取得篩選頁面內容的能力。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 涉及連線與傳輸方式；REJECT 的範圍取決於比對條件、規則順序與目前路由。請先修正规則，不要把切換通訊協定當成擴大封鎖範圍的方法。
最後保留的應是一組易於說明、驗證與還原的規則。遇到功能異常時，先撤銷最近的變更，再檢查命中記錄。如果目標沒有可獨立分離的主機範圍，接受連線層規則的限制，比持續擴大拒絕範圍更能維持正常使用。