· 進階設定 · 約 9 分鐘

Shadowrocket REJECT 規則設定：封鎖原理、比對順序與限制

了解 Shadowrocket 的 REJECT 策略如何在規則比對時拒絕連線、常見寫法與規則順序的影響，以及網域封鎖無法生效的情況。

本文摘要

本文適合已在 Shadowrocket（小火箭）中使用自己的現有設定，並想新增少量封鎖規則的使用者。先分清規則條件與 REJECT 策略，再依序備份設定、新增精確規則、檢查順序並驗證新請求。範例使用保留網域與文件專用位址，著重說明語法，並非可直接取代現有設定的封鎖清單。

一、REJECT 是策略，不是網域比對條件

一條規則通常由比對類型、比對內容與處理策略組成。例如 DOMAIN-SUFFIX,ads.example.com,REJECT 中，DOMAIN-SUFFIX 用來決定比對方式，ads.example.com 是要比對的網域後綴，REJECT 才是符合規則後的處理策略。只寫 REJECT，並不能指定要封鎖哪個網域。

當請求進入 Shadowrocket 的處理範圍，並依目前設定進行規則比對時，符合 REJECT 的連線會遭拒絕，不會繼續依該請求原本可能採用的 DIRECT 或代理策略轉送。這不等於刪除網頁元素，也不會重新排版頁面中的空白區域；App 可能顯示載入失敗、佔位區域或重試提示。

App 發出請求 進入處理範圍 比對設定規則 符合拒絕策略 拒絕這次連線

規則比對發生在連線處理過程中，但不要因此推論「符合 REJECT 就絕不會產生 DNS 查詢」。網域解析、快取，以及為 IP 類規則取得位址的流程，都會影響實際行為。REJECT 的作用是拒絕符合條件的連線，不是獨立的 DNS 隱私開關。

二、常見寫法：精確網域、網域後綴與 IP 網段

先從精確網域開始，只有確認整個子網域樹都應拒絕時，再擴大使用 DOMAIN-SUFFIX。規則中的網域不要包含 https://、路徑、查詢參數或結尾斜線。以下各行分別用來說明語法，不必全部加入同一份設定。

[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,metrics.example.com,REJECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
IP-CIDR6,2001:db8::/32,REJECT,no-resolve
規則類型比對範圍使用注意事項
DOMAIN指定的完整網域。適合只拒絕一個已確認的主機名稱。
DOMAIN-SUFFIX指定網域及其子網域。metrics.example.com 也會涵蓋 a.metrics.example.com，但不涵蓋 othermetrics.example.com。
IP-CIDRIPv4 位址網段。共用位址可能同時承載正常服務，不能把某個網域解析出的位址直接當成專用位址。
IP-CIDR6IPv6 位址網段。只設定 IPv4 規則，無法涵蓋 IPv6 目標位址。

no-resolve 用來避免為了這條 IP 類規則主動將網域解析為 IP；這不代表關閉所有 DNS 解析，也不會阻止目標原本就是 IP 的請求參與比對。範例中的 192.0.2.0/24 與 2001:db8::/32 是文件專用位址，不能據此期待封鎖任何實際服務。

4 種
上表區分兩種網域比對與兩種 IP 網段比對。
/32
IPv4 單一位址的前綴長度，例如 192.0.2.8/32。
/128
IPv6 單一位址的前綴長度，例如 2001:db8::8/128。

判斷原則：先縮小比對範圍，再擴大封鎖範圍

如果只觀察到一個主機名稱發出不需要的請求，先新增 DOMAIN 規則；確認各子網域的用途後，才改用 DOMAIN-SUFFIX。不要一開始就封鎖整個共用網段。

三、規則順序：例外放前面，FINAL 放最後

在一般規則清單中，請求會依序比對，由第一條符合的規則決定處理策略。把 REJECT 放在清單末尾，不代表它會覆蓋前面的允許規則；同樣地，前面已符合的廣泛封鎖規則，也不會被後面的例外規則取消。

[Rule]
DOMAIN,assets.ads.example.com,DIRECT
DOMAIN-SUFFIX,ads.example.com,REJECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT

在這段範例中，assets.ads.example.com 會先符合精確例外；video.ads.example.com 則會符合下一條網域後綴封鎖規則。GEOIP 依目標 IP 的地理位置參與比對，不會辨識內容用途；若放在封鎖規則之前，符合條件的請求可能會先採用 DIRECT。FINAL 是前面的規則都未符合時使用的備援項目，應放在規則清單末尾。

精確例外

類型
DOMAIN
目標
assets.ads.example.com
策略
DIRECT
位置
放在涵蓋該網域的後綴封鎖規則之前。

DIRECT 只表示直接連線；實際例外應沿用該服務所需且可用的策略。

後綴封鎖

類型
DOMAIN-SUFFIX
目標
ads.example.com
策略
REJECT
位置
放在精確例外之後、廣泛放行規則與 FINAL 之前。

本文中的 FINAL,DIRECT 僅用於說明備援處理，不代表應取代原有分流策略。

合併規則時，請在現有 [Rule] 區段中插入對應行，不要重複貼上整個區段，也不要直接刪除原有代理策略、規則引用或備援設定。如果設定中還有外部規則引用，應依引用所在位置檢查整體順序，不能只看剛新增的幾行。

四、在 Config 中修改並驗證

規則儲存在設定檔中；現有節點訂閱主要提供連線資訊，更新訂閱不能取代規則編輯。操作前先保留一份目前可用的設定，再進入 Config，確認正在編輯的設定與目前使用的設定相同。遠端設定更新可能覆蓋本機修改，請保留自訂規則副本。

  1. 記錄原有狀態。記下 Home → Global Routing 目前的選項，以及 Config 中啟用的設定，並保留原始檔案以便還原。
  2. 只新增一條測試規則。在 Config 中開啟目標設定的編輯功能，於 [Rule] 中新增已確認目標的 DOMAIN 規則，並放在可能先符合的廣泛規則之前，儲存後啟用該設定。
  3. 使用規則模式。在 Home → Global Routing 選擇 Config。Proxy 與 Direct 是不同的全域處理模式，不能用來驗證同一份 Config 規則是否正常符合；若使用 Scene，應先確認場景實際採用的設定與路由狀態。
  4. 重新發出請求。確認連線開關已開啟，關閉目標頁面後再重新開啟。必要時先中斷再重新連線，以建立新連線；只重新整理既有長連線中的畫面，可能看不到規則變更。
  5. 核對記錄。查看連線或日誌記錄中的目標網域、目標位址、符合的規則與處理策略。應以新請求符合 REJECT 為依據，不要只憑頁面某個區域暫時消失來判斷。

五、網域封鎖的限制與誤封原因

DOMAIN 與 DOMAIN-SUFFIX 處理的是主機名稱，不是網頁中的特定內容。HTTPS 請求中，同一主機的不同路徑，例如 https://example.com/news 與 https://example.com/promo，無法只靠這兩種網域規則區分；直接拒絕 example.com，會同時影響這兩個路徑的連線。

依網域拒絕通常不需要為此啟用 HTTPS 解密。新增憑證或修改其他無關設定，無法解決「同一網域承載多種內容」造成的比對粒度限制。對無法個別區分的資源，應保留必要功能，不要期待一條 REJECT 規則就能完整移除某類頁面內容。

六、常見問題：未符合、誤封與更新後還原

新增 REJECT 後，頁面為什麼還是能開啟？

先確認目標是整個頁面的主機，還是頁面中的某個資源主機。返回 Home → Global Routing 檢查是否選用 Config，再到 Config 核對啟用的檔案。重新發出請求後查看記錄；如果實際請求使用了另一個主機名稱，請依記錄新增精確規則，不要反覆新增同一行。

規則符合後，正常圖片也不見了，該怎麼辦？

先還原備份或移除最近新增的封鎖規則，確認圖片恢復。接著將 DOMAIN-SUFFIX 縮小為已確認的 DOMAIN；若確實有獨立的正常主機，請將其精確例外放在封鎖規則之前。如果圖片與待拒絕內容共用同一主機，單靠網域規則無法區分。

更新現有訂閱後，為什麼規則沒有變化？

先確認更新的是 Home 中的節點訂閱，還是 Config 中的遠端設定。前者不等於更新規則；後者則可能覆蓋本機編輯內容。返回 Config 檢查實際檔案中的 [Rule] 內容，分別備份自行維護的規則與原始設定，更新後逐項核對。

把 FINAL 改成 REJECT，就能省去逐條封鎖嗎？

FINAL,REJECT 會拒絕所有未符合前序規則的連線，影響範圍遠大於封鎖單一網域。除非正在維護明確的允許清單，否則不要用它取代指定目標的規則。請先還原原本的 FINAL 策略，再新增範圍明確的 DOMAIN 或 DOMAIN-SUFFIX。

七、儲存前的基本檢查清單

一份方便維護的 REJECT 設定，應能回答「拒絕哪個目標、為何採用這種比對方式、例外在哪裡、如何還原」這四個問題。每次只變更一項比對條件，並保留修改前後的記錄，比一次匯入大量未確認的規則更容易找出問題。

App Store 正版確認 →