本文適合已使用 Config 分流，並想封鎖特定連線目標的使用者。先確認 REJECT 的作用，再依序使用完整網域、網域後綴或目標 IP 編寫規則，最後查看連線記錄，確認規則是否命中及有無誤封。範例網域僅用於說明語法，實際目標請依自己的連線記錄判斷。
REJECT 的作用：封鎖符合條件的連線
REJECT 是一種策略，不是獨立的比對條件。規則前半段用來判斷目標是否符合條件，末尾的 REJECT 則指定命中後的處理方式。例如 DOMAIN,metrics.example.com,REJECT 表示比對完整網域，並拒絕該連線；它不會自動辨識所有統計服務，也不會自動產生網域清單。
這個流程的前提是連線進入 Shadowrocket 的處理範圍，而且目前使用規則分流。REJECT 不是先把完整內容傳送到目標，再隱藏回傳頁面；它是在處理連線時阻止後續通訊。發出請求的 App 可能顯示連線失敗、重試或逾時，實際情況取決於 App 本身的處理方式，不能只憑畫面提示判斷是哪條規則生效。
規則通常由上而下比對，第一條命中的規則會決定採用哪種策略。因此，「已寫入 REJECT」不代表「連線實際採用 REJECT」：若前面已命中範圍較廣的放行規則，後面的封鎖規則就不會處理這次連線。排查時必須一併確認目標、規則順序及目前生效的設定。
先確認 Config，再新增範圍最小的規則
在 Home 的 Global Routing 中選擇 Config，再到 Config 確認目前使用的設定檔。Proxy 和 Direct 都不能取代這個步驟；若使用 Scene，也要確認目前場景實際採用的設定檔與路由方式，不能只因某個設定檔內有 REJECT，就認定它已生效。
- 先在 Config 保留目前設定檔的副本，並記下原有規則順序與
FINAL策略，以便還原。 - 開啟目前使用的設定檔，透過編輯功能找到
[Rule]區段。先新增一條完整網域規則，不要急著擴大到整組網域。 - 將這條規則放在可能先命中的廣泛規則之前，同時保留業務所需的精確例外。
- 儲存設定檔，並確認它仍是目前使用中的設定檔。關閉目標 App 的既有連線，再重新執行相同操作。
- 查看這次連線的目標與策略；只有新連線實際命中
REJECT，才能確認封鎖規則運作正常。
若設定檔會從遠端來源更新，請先確認本機修改是否會被後續更新覆蓋。訂閱與節點請向你的服務商取得；伺服器訂閱更新和 Config 規則修改是不同操作，重新整理伺服器清單不代表新規則已載入。
DOMAIN、DOMAIN-SUFFIX 與 IP-CIDR 的寫法
優先採用足以涵蓋目標、且範圍最小的條件。完整網域適用於單一主機；網域後綴適用於需要一併處理的網域及其子網域；IP 網段則適用於已確認地址範圍的目標。網域欄位不要填入 https://、路徑、查詢參數或連接埠。
依網域比對
- 完整網域
DOMAIN,metrics.example.com,REJECT- 網域後綴
DOMAIN-SUFFIX,metrics.example.com,REJECT- 比對差異
- 前者只比對指定主機；後者也會比對其下的子網域。
後綴依網域層級比對，不是比對任意包含該文字的內容。
依目標 IP 比對
- 單一 IPv4 位址
IP-CIDR,192.0.2.8/32,REJECT- IPv4 網段
IP-CIDR,192.0.2.0/24,REJECT- 範例用途
- 此處使用文件範例位址，並非實際封鎖目標。
請依實際連線位址確認範圍，勿將共用位址誤認為單一服務。
DOMAIN-SUFFIX,metrics.example.com,REJECT 可比對 metrics.example.com 和 img.metrics.example.com，但不會比對 othermetrics.example.com。也不必寫成 *.metrics.example.com；萬用字元不是這條規則的後綴參數寫法。
IP 規則與網域規則不能互相取代。同一網域可能解析到多個位址，同一個位址也可能承載多個網域；用戶端也可能改用其他位址或 IPv6。只拒絕某個 IPv4 位址，不能據此認定相關網域的所有連線都已封鎖。GEOIP 依位址歸屬比對，範圍較廣，不適合取代針對特定網域的精確封鎖。
規則順序：先設例外，再封鎖，FINAL 保留在末尾
以下示範一組刻意保留例外的規則：允許指定主機直接連線，再拒絕同一後綴下的其他主機。範例中的 PROXY 必須是設定檔內可用的策略或策略組名稱；若目前設定檔使用其他名稱，請保留原有 FINAL 行，不要直接照抄範例作為兜底策略。
[Rule]
DOMAIN,health.metrics.example.com,DIRECT
DOMAIN-SUFFIX,metrics.example.com,REJECT
FINAL,PROXY| 連線目標 | 第一條命中的規則 | 結果 |
|---|---|---|
health.metrics.example.com | 第一條 DOMAIN | 採用 DIRECT |
img.metrics.example.com | 第二條 DOMAIN-SUFFIX | 採用 REJECT |
www.example.com | 末尾的 FINAL | 採用範例中的 PROXY |
若把後綴封鎖規則放在第一行，健康檢查主機也會先命中 REJECT，後面的 DOMAIN 例外便無法放行。相反地，若在封鎖規則前加入 DOMAIN-SUFFIX,example.com,DIRECT，這些目標就會先被放行。FINAL 負責處理其餘連線，若放在封鎖規則之前，後續規則就沒有比對機會。
判斷方式：需要例外時，先縮小規則範圍
先將必要主機的精確規則移到廣泛封鎖規則之前，再重新驗證。不要為處理單一誤封而刪除所有 REJECT 規則，也不要用範圍更廣的 DIRECT 規則掩蓋順序問題。
封鎖的適用範圍與限制
REJECT 適合封鎖目標明確、可依網域或位址區分的連線，例如使用者已確認不需要存取的獨立資源主機。它比對的是連線目標，不是頁面中的每個視覺元素，更不會辨識所有內容的語意。
- 無法依路徑區分同網域內容：如果業務請求與不需要的資源都來自
api.example.com，DOMAIN 規則會一併處理；它無法只拒絕其中的/metrics路徑。 - 不會因此解密 HTTPS：REJECT 不需要讀取加密內容，也不會自動取得頁面結構。封鎖某項資源的連線，不代表頁面版面中預留給它的空白區域會消失。
- 快取可能讓結果不易判斷：App 可能直接顯示已快取的圖片或內容，這不代表剛才的連線成功通過。請搭配新的連線記錄判斷，不要只看畫面是否改變。
- 既有連線也需留意：修改規則後，已建立並持續重用的連線不一定會立刻依新規則重新比對；測試時應讓 App 重新建立連線。
- 連線目標可能變動：重試時改用備用網域、位址輪替及共用基礎架構都會影響封鎖範圍。請根據實際記錄補足判斷依據，不要直接封鎖整個共用網段。
DNS 解析失敗與命中 REJECT 也要分開判斷。前者可能發生在取得目標位址之前；後者則應有對應的規則策略記錄。看到網域無法開啟，不能直接歸因於 REJECT。另外，網域資訊是否能用於比對，取決於實際請求與解析流程；若只有位址資訊，請搭配連線記錄檢查 IP 相關規則，不要假設一定有網域條件可供比對。
規則未生效、誤封與還原方式
驗證時一次只調整一個變數：使用同一個 App、執行相同操作，並維持相同網路環境，比較修改前後的新連線。以下依「是否使用正確設定檔、規則是否命中、結果是否受快取影響」的順序排查。
規則已儲存，為什麼目標還是能開啟？
先確認 Home → Global Routing 是否選擇 Config，再檢查 Config 中實際使用的設定檔。接著查看目標的新連線是否先命中前面的 DIRECT、PROXY 或其他廣泛規則；不要只檢查檔案中有沒有 REJECT 這一行。
顯示命中 REJECT，為什麼頁面仍有原本的內容？
關閉目標 App 後重新開啟，確認畫面內容是來自快取，還是由新請求取得。檢查頁面是否改從其他網域載入資源，並記錄這些連線；快取內容仍顯示在畫面上，不代表命中的請求已獲放行。
新增後綴規則後，登入或圖片也失效了，該怎麼辦？
先停用剛新增的單條規則並重新測試，確認問題是否與它有關。接著從失敗記錄找出必要主機，改用範圍更小的 DOMAIN 封鎖，或在後綴規則前加入精確的放行例外；不要直接放行整個父網域。
更新設定檔後，先前的封鎖為什麼不見了？
對照已儲存的副本，檢查目前設定檔的 [Rule] 區段，確認本機修改是否遭遠端內容覆蓋。重新加入已驗證且範圍最小的規則，並保留原有 FINAL；不要把伺服器訂閱更新當成規則還原操作。
需要還原時，優先移除最後新增的封鎖規則，儲存後重新建立目標連線；如果已修改多處而無法確認先後順序，請還原先前保留的設定檔副本。記下測試目標、命中規則與還原結果，比反覆切換所有設定更容易找出原因。