本文適合已在 Shadowrocket（小火箭）中使用自有配置，並需要依網域拒絕特定連線的使用者。先區分比對條件與 REJECT 策略，再以保留網域範例說明規則順序、例外設定與驗證方式，最後排查封鎖未生效及頁面異常。範例不含可用服務資訊，也不應直接取代現有配置。
1. REJECT 是策略，不是識別內容的條件
一條規則通常先描述「比對什麼」，再指定「符合後如何處理」。DOMAIN-SUFFIX 是網域後綴比對條件，REJECT 則是拒絕連線的策略。兩者搭配表示目標網域符合條件時，不再依代理或直連策略建立該連線；這並不是掃描頁面並移除其中某個元素。
驗證本文規則時，請在 Home → Global Routing → Config 使用配置分流，並確認目前啟用的是剛修改的配置。Proxy、Direct 與 Scene 的路由行為，不能直接視為本文所述的 Config 測試條件。即使連線開關已開啟，也不代表指定的規則檔已參與判定。
Settings → On Demand 用來設定系統依條件連線或中斷 VPN；它不會將特定網域改為 REJECT。排查時請分別確認「隧道是否連線」、「配置是否啟用」及「請求命中哪條規則」，不要把自動連線設定當成網域封鎖開關。
2. DOMAIN 與 DOMAIN-SUFFIX 的正確寫法
以下範例使用保留的示例網域，僅用於說明語法。規則應寫在配置的 [Rule] 區段中；若目前檔案已有該區段，請直接在原區段編輯，不要為了新增一條規則而重複建立區段。網域欄位不含通訊協定前綴、路徑、連接埠或查詢參數，欄位間以英文逗號分隔。
[Rule]
DOMAIN,account.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECT在這個最簡範例中，account.example.com 先命中精確例外，採用 DIRECT；example.com 與 img.example.com 命中網域後綴規則，採用 REJECT。notexample.com 不屬於該網域後綴，不能只因字串結尾相似就視為命中。最後一行僅說明兜底位置，不表示應將使用者現有的 FINAL 策略改為 DIRECT。
精確網域規則
- 關鍵字
- DOMAIN
- 目標
- metrics.example.com
- 策略
- REJECT
- 完整規則
DOMAIN,metrics.example.com,REJECT
只比對該網域，不會自動涵蓋其子網域。
網域後綴規則
- 關鍵字
- DOMAIN-SUFFIX
- 目標
- metrics.example.com
- 策略
- REJECT
- 完整規則
DOMAIN-SUFFIX,metrics.example.com,REJECT
比對該網域及其子網域，不包含同級網域。
若只需拒絕 metrics.example.com，不應直接擴大至整個 example.com。同一主網域可能同時承載登入、圖片、付款回呼與統計請求；後綴範圍越廣，誤封的影響就越大。先用 DOMAIN 驗證目標，再依實際請求判斷是否需要擴大到 DOMAIN-SUFFIX。
3. 規則順序：具體例外在前，FINAL 在後
一般依序比對時，由第一條命中的規則決定處理策略。後方較具體的規則不會自動覆蓋前方較寬泛的規則。因此，新增 REJECT 不會只因「檔案中有這一行」就生效；還要確認請求在到達該行之前，沒有先被其他條件攔截。
| 位置或條件 | 可能的判定結果 | 檢查方式 |
|---|---|---|
| 精確 DOMAIN 例外位於網域後綴規則之前 | 指定主機先套用例外策略 | 確認例外確實有其用途，且範圍僅涵蓋需要保留的主機 |
| 範圍較廣的 DOMAIN-SUFFIX 位於精確規則之前 | 後方的精確規則無法接手已命中的請求 | 調整規則順序，不要只重複新增同一條規則 |
| 較前面的 IP-CIDR 或 GEOIP 規則已命中 | 請求可能先依 IP 條件處理 | 搭配記錄確認實際目標資訊與命中項目 |
| FINAL 位於新增規則之前 | 請求已命中兜底規則，後續規則無法發揮預期作用 | 將需要參與判定的規則移到 FINAL 之前 |
結論：先找出首次命中的規則，再調整封鎖範圍
若請求記錄顯示命中前方的 DIRECT 或 PROXY 規則，應先調整順序；重複新增網域後綴規則，無法改變已完成的判定。
GEOIP 依 IP 的地理位置資訊比對，IP-CIDR 則依 IP 位址網段比對；兩者都不是網域類別識別工具。為了修正一條網域規則而封鎖整個共用 IP 網段，可能影響同一基礎設施上的其他網站。除非已有明確的位址層級需求，否則不要以擴大 IP 範圍取代網域與規則順序檢查。
4. 新增規則並驗證結果：逐步操作
每次只修改一項條件，才能將頁面變化與規則建立關聯。以下流程假設使用者已有自己的配置；若本來就需要代理連線，請繼續使用自有服務配置，本文不涉及取得或推薦服務。
- 保留可還原的副本。在 Config 中確認目前使用的配置，先儲存副本或記下原始內容，尤其保留原有策略名稱、DNS 設定與 FINAL。不要將本文的最簡範例當成完整可用的配置匯入。
- 確認實際目標。在連線或請求記錄中查看異常請求的目標網域。記下完整主機名稱，不要依網頁標題推測；頁面網址與圖片、介面實際請求的主機可能不同。
- 新增最精簡的規則。在目前配置的
[Rule]區段加入一條DOMAIN,metrics.example.com,REJECT格式的規則，並將示例網域換成已確認的目標。將規則放在相關的寬泛比對規則與 FINAL 之前。 - 確認測試狀態。儲存配置，在 Home 確認目前配置與
Global Routing → Config，再檢查連線狀態。若目前連線不穩定，請先完成基本連線排查，再測試規則。 - 重新送出請求。重新開啟頁面，或關閉後再次啟動目標 App，盡量建立新的連線。查看相關記錄中的目標、命中項目與策略，不要只憑頁面某個區塊是否消失來判斷。
- 一次只還原一項變更。只移除剛新增的那條規則，儲存後再執行相同操作。比較功能是否恢復；若變化無關，請繼續檢查其他請求，不要一次刪除整組規則。
目標網站使用 HTTPS 時，常見連接埠為 443，但 DOMAIN,metrics.example.com,REJECT 並未將條件限制在 443。這行表示網域條件，而非特定 URL、請求方法或連接埠條件。不要將帶有 :443 的完整網址直接填入網域欄位。
5. 規則無法處理的請求與頁面內容
網域規則作用於可供比對的連線目標，不等於分類頁面內容。同一網域可能傳回正文、圖片、推薦內容與登入介面；同一條連線也可能承載多個請求。僅憑 DOMAIN-SUFFIX，無法判斷其中哪些內容應予保留。
- 同一網域的內容無法依路徑細分。
example.com/news與example.com/banner的網域相同；此處的規則無法只依後半段路徑拒絕其中一項。 - 不會刪除 App 內已快取的內容。舊圖片或本機快取仍可能顯示。內容依舊可見，不足以證明新請求避開了規則；請確認是否真的建立了連線。
- 既有長連線不一定會立即重新判定。儲存規則後，已建立的連線可能繼續使用。請重新建立連線並檢查結果，不要只等待目前頁面自行變化。
- IP 直連不一定會提供網域條件。若用戶端可觀察到的目標只有 IP，就不能假設 DOMAIN-SUFFIX 規則一定會命中；請先確認記錄中的目標資訊。
- 未經過目前隧道的流量，不會由這條規則判定。隧道中斷、系統路由或其他繞過條件，都需要在規則內容之外另外檢查。
DNS 解析記錄也不等同於最終的連線處理記錄。網域取得解析結果後，後續連線仍可能遭到 REJECT；反之，解析失敗也可能使連線根本未進入預期的規則驗證階段。判斷時請分別記錄解析、比對與連線結果。
6. 頁面異常與封鎖未生效：常見問題
誤封常見的狀況包括登入反覆跳轉、圖片空白、按鈕持續等待或驗證流程無法完成。這些狀況只能表示某項相依請求可能失敗，不能單憑現象判定該請求應該放行。請對照新增規則與實際命中記錄，逐條縮小範圍。
新增 REJECT 後，為什麼頁面還是能正常開啟？
先確認目標是否真的請求了遭封鎖的網域，再核對 Home → Global Routing → Config 與目前配置。頁面主要內容正常，不代表規則失效；目標請求可能只是附加資源。請以新連線的命中策略為準。
封鎖統計網域後，為什麼連登入也失敗？
檢查是否誤用了主網域層級的 DOMAIN-SUFFIX。先移除剛新增的規則並重新登入；若功能恢復，再改用已確認的精確 DOMAIN。若需保留登入主機，可在前方設定明確例外，並沿用原配置中正常存取所使用的策略。
記錄已顯示 REJECT，為什麼還看得到 DNS 請求？
解析與連線是不同階段；出現解析記錄，不代表 App 已成功連上目標。請繼續查看相應連線是否遭拒，不要只為了消除 DNS 記錄就擴大網域或 IP 封鎖範圍。
更新配置後，自己新增的規則為什麼不見了？
確認更新的是節點訂閱還是整份配置檔，兩者並非同一個項目。遠端配置更新可能會取代本機編輯內容；請比對更新前後的副本、確認目前啟用的檔案，再還原已驗證且必要的規則。
若刪除單條規則後問題仍在，請繼續檢查網路、DNS 與伺服器回應，不要把所有故障都歸因於 REJECT。基本連線檢查請參閱排查手冊；若不熟悉 Config 與 Home 的分工，請先依入門指南確認配置啟用流程。