本文重點

本文適合已能正常連線，準備在 Config 中新增網域封鎖規則的使用者。先分清匹配條件與 REJECT 策略，再依序新增精確規則、查看連線記錄，最後確認同網域資源、快取與 App 內嵌內容是否超出網域規則的處理範圍。文中的網域和位址皆為語法示例，不能直接當作實際封鎖清單使用。

一、REJECT 是匹配後的處理策略，不是內容識別器

Shadowrocket（小火箭）的規則要分別回答兩個問題：連線符合什麼條件，以及符合條件後如何處理。DOMAIN-SUFFIX、DOMAIN、IP-CIDR 屬於匹配條件；REJECT 則是處理策略。將網域寫入規則，不代表能識別網頁中的廣告、統計程式碼或影片片段；它只會拒絕符合條件的連線。

App 發起連線 流量進入通道 依序檢查規則 符合拒絕策略 目標連線失敗

上述流程適用於確實經過 Shadowrocket，且由目前規則設定處理的流量。若流量未進入通道，規則就無法介入；若連線進入通道，但目前採用整體直連或整體代理，也不能據此判斷某條 Config 規則是否生效。排查時先在 Home 確認連線狀態，再檢查 Global Routing。

拒絕連線後的表現取決於 App：可能顯示資源載入失敗、空白占位，也可能不斷重試。REJECT 不會移除頁面版面、不保證載入速度變快，也不會將遠端內容改寫成其他內容。

二、DOMAIN 與 DOMAIN-SUFFIX 的寫法和適用範圍

網域規則只填主機名稱，不要填入 https://、連接埠、路徑或查詢參數。假設目標請求是 https://ads.example.com:443/banner?id=1，要確認的是 ads.example.com。其中 443 是連接埠，/banner 是路徑，兩者都不是 DOMAIN-SUFFIX 的網域參數。

DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,metrics.example.com,REJECT

精確主機匹配

關鍵字
DOMAIN
參數
ads.example.com
策略
REJECT
匹配範圍
僅限 ads.example.com，不含 img.ads.example.com

首次驗證建議使用精確主機名稱，方便限制影響範圍。

網域後綴匹配

關鍵字
DOMAIN-SUFFIX
參數
metrics.example.com
策略
REJECT
匹配範圍
metrics.example.com 及其下層子網域

確認整個網域分支用途一致後，再擴大至後綴範圍。

DOMAIN-SUFFIX,example.com,REJECT 會涵蓋 example.com 和 api.example.com 等下層網域，但不會匹配任意包含該字串的網域，不應將 notexample.com 視為匹配對象。也不要用 *.example.com 取代後綴參數；依規則語法填入不帶萬用字元的網域即可。

三、規則由上而下匹配：例外在前，FINAL 在後

規則順序會直接影響結果。同一連線會由第一條符合條件的有效規則決定處理策略；後面的精確規則不會自動取得較高優先順序。因此，允許連線的例外應放在涵蓋它的拒絕規則之前，而較寬泛的 IP、地區規則及 FINAL 通常放在相關網域規則之後。

[Rule]
DOMAIN,keep.metrics.example.com,DIRECT
DOMAIN-SUFFIX,metrics.example.com,REJECT
GEOIP,CN,DIRECT
FINAL,DIRECT

此片段僅示範規則順序：keep.metrics.example.com 先符合精確例外，其餘 metrics.example.com 網域分支再遭拒絕。FINAL,DIRECT 只是為了讓示例完整；實際設定應保留原有的兜底策略，不要只為新增一條封鎖規則，就把所有未匹配流量改成直連。

規則位置常見問題修正方式
拒絕規則排在 FINAL 之後連線已由兜底規則處理將拒絕規則移到 FINAL 之前
例外排在後綴拒絕規則之後例外主機先符合 REJECT將精確例外移到後綴規則之前
較寬泛的允許規則排在拒絕規則之前目標先符合允許策略查看匹配記錄，調整重疊規則的順序

結論：先查第一條匹配規則，再新增規則

如果目標連線已由較前面的規則處理，重複新增相同的 REJECT 不會改變結果。先確認目前使用的設定及匹配位置，再移動規則或縮小條件範圍。

若目標是 IP 位址，可參考 IP-CIDR,192.0.2.0/24,REJECT,no-resolve 這類語法來理解網段匹配；此處的網段僅為文件示例。no-resolve 表示不為這條 IP 規則主動觸發網域解析，並非關閉裝置 DNS。共用 IP 可能同時承載多個無關網域，因此網域封鎖無效時，不要直接拒絕整個網段。

四、網域封鎖無法區分同一網域的路徑與 App 內版面

假設正文 API 是 api.example.com/article，推廣內容 API 是 api.example.com/promotion。兩者使用相同主機名稱，DOMAIN 或 DOMAIN-SUFFIX 無法只拒絕後一個路徑。若將 api.example.com 設為 REJECT，正文、登入狀態及留言 API 也可能一併遭到阻擋。

內容傳遞方式網域規則能處理的內容不能據此保證的結果
由獨立主機載入素材拒絕該主機的新連線無法保證 App 會移除空白占位
同一主機的不同路徑以主機為單位處理無法用網域規則只選取特定路徑
推廣內容與正文位於同一回應拒絕整條連線無法只從回應內容中挑出某個部分
本機快取或內建素材沒有新連線就無從匹配無法保證已顯示的內容立即消失

HTTPS 通常會隱藏 URL 路徑和回應本文。即使規則能取得目標網域，也不代表能讀取加密連線中的每項資源。網域層級的 REJECT 不必解密內容就能拒絕主機連線，但能力也僅限於相應的連線範圍。本文不將路徑處理、回應改寫或隱藏頁面元素視為網域規則的功能。

五、新增與驗證：一次只改一條，保留還原方式

測試應以已能正常使用的設定為基礎。本文假設使用者已有自己的服務商與訂閱，不提供或推薦任何連線服務。若測試目標原本就能直接存取，可維持現有連線方式不變，只觀察新增規則造成的差異。

  1. 備份目前設定。在 Config 確認目前使用的檔案，儲存副本或記下原始內容。不要用整段示例內容覆寫現有檔案。
  2. 固定路由模式。在 Home 確認連線已啟用，將 Global Routing 設為 Config，並確認使用的是剛才編輯的設定。
  3. 新增精確規則。先在該設定的 [Rule] 區段中新增一條 DOMAIN,ads.example.com,REJECT 格式的規則，將示例主機換成自己記錄的目標主機，並放在相關的寬泛規則及 FINAL 之前。
  4. 儲存並重新發起請求。重新開啟目標頁面或 App；必要時重新建立連線，讓新請求依新設定進行判斷。既有長連線和本機快取不適合作為唯一的驗證依據。
  5. 查看連線記錄。依目標主機搜尋新請求，確認實際策略是否為 REJECT，同時檢查登入、正文、圖片和播放等必要功能。
  6. 若誤擋功能，先還原。刪除或停用剛新增的規則，再重新測試。若功能恢復，再決定新增精確例外、縮小為 DOMAIN，或放棄封鎖整個網域。

若裝置啟用了自動連線，也請檢查 Settings → On Demand，避免測試期間連線自動恢復或狀態切換而未察覺。On Demand 決定何時觸發連線，不會調整 REJECT 的匹配優先順序，兩者應分開排查。

六、常見問題：規則未匹配、內容仍顯示與誤擋後還原

已設定 REJECT，為什麼網頁還是能開啟？

先確認拒絕的是網頁主機，還是某個附屬素材主機。只拒絕素材網域時，正文仍能開啟可能正是預期結果。接著確認 Home 的 Global Routing 是否設為 Config、選用的設定是否正確，以及規則是否排在 FINAL 之前。最後查看新連線實際採用的策略，不要只看整個頁面能否開啟。

記錄顯示 REJECT，為什麼 App 仍顯示原有內容？

重新開啟目標頁面，並確認是否出現新請求。已下載的圖片、預先載入的內容和本機內建素材仍可能繼續顯示；App 也可能改用另一個主機。先比對請求時間與目標網域，不要只因畫面上仍有內容就擴大拒絕範圍。

新增規則後無法登入，該如何還原？

先撤銷最近新增的規則，再重新嘗試登入。若登入恢復，表示該規則可能涵蓋必要的 API。比對登入前後的主機記錄，將後綴規則縮小為精確主機規則；確認某個主機確實應允許連線後，再於拒絕規則前新增對應的精確例外。

改用另一種代理協定，REJECT 會更精準嗎？

不會。切換 Shadowsocks、VMess、VLESS、Trojan、Hysteria2 或 WireGuard，並不會因此取得依內容識別的能力。REJECT 是否匹配，取決於流量是否進入規則處理、可用的目標資訊及規則順序。先維持原有連線方式完成規則驗證，避免同時修改協定和規則而無法判斷原因。

判斷一條規則是否值得保留，需同時符合三個條件：目標新請求確實匹配、預期資源受到限制，且必要功能沒有遭到誤擋。若網域層級無法區分需要保留與需要拒絕的內容，就應接受網域匹配的限制，而不是不斷增加範圍更廣的拒絕規則。