Shadowrocket REJECT 規則設定與封鎖範圍：能封鎖什麼、不能封鎖什麼

本文重點

Shadowrocket（小火箭）的 REJECT 是連線處理策略，不是網頁元素過濾器。本文適合已能正常連線、準備自行調整 Config 的使用者：先說明網域與 IP 規則的比對範圍，再介紹局部修改、確認命中及還原設定的步驟，最後釐清規則未生效與資源本身無法單獨封鎖這兩種情況。

REJECT 的作用對象是連線，不是網頁中的特定區塊

一條規則包含比對條件和處理策略。用戶端取得目標網域或 IP 等資訊後，會依目前設定判斷如何處理連線；符合 REJECT 規則時，該連線就會遭到拒絕。它不會先讀取網頁、判斷哪張圖片屬於推廣內容，再只移除那張圖片。因此，是否適合使用規則，首先要看目標資源能否在連線層級與必要資源分開。

例如，頁面主體來自 www.example.com，附加資源來自獨立的 metrics.example.com，就能針對後者建立網域規則。若登入、內文和附加資源都來自同一個網域，只是路徑不同，拒絕該網域通常會一併影響這些功能。

3 個欄位

常見網域規則：類型、比對值、策略

TCP 443

HTTPS 常用連接埠，不代表資源類別

UDP 443

HTTP/3 常用連接埠，不代表獨立網域

連接埠只是連線資訊的一部分。不能因為某條連線使用 443，就認定它一定是需要封鎖的資源；拒絕所有相關連接埠會影響大量正常連線。以下網域與 IP 均為文件範例，不能當成實際封鎖清單。

常見寫法：先用 DOMAIN，再考慮 DOMAIN-SUFFIX 與 IP-CIDR

以下是可放入設定檔 [Rule] 區段的局部範例。每一行代表一個獨立條件；請勿直接用這幾行取代完整設定，也不要為了照抄範例而刪除既有策略群組和預設規則。

[Rule]
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,telemetry.example.com,REJECT
IP-CIDR,192.0.2.0/24,REJECT,no-resolve

規則類型	範例範圍	使用前檢查
`DOMAIN`	只比對 `metrics.example.com` 這個網域。	適合先驗證單一主機，確認它不會影響必要功能。
`DOMAIN-SUFFIX`	比對 `telemetry.example.com` 及其子網域。	包含 `a.telemetry.example.com`，比對範圍比精確比對大。
`IP-CIDR`	`192.0.2.0/24` 代表一個 IPv4 網段。	同一網段可能承載多個網域，不宜據此推測內容用途。

DOMAIN-SUFFIX,example.com,REJECT 會一併比對主網域及其子網域，不能解讀成「只封鎖這個網站的某類附加資源」。網域欄位不需填入 https://、路徑或查詢參數；DOMAIN 和 DOMAIN-SUFFIX 不會比對 URL 中的 /banner/ 等路徑。

no-resolve 表示這條 IP 規則不會額外觸發網域解析，並不代表它一定無法比對網域連線：若用戶端已掌握對應 IP，仍須依實際連線資訊判斷。只有 IPv4 網段規則，也不代表涵蓋同一服務的 IPv6 位址；若目標使用 IPv6，應檢查實際位址，而非任意擴大 IPv4 網段。

結論：從明確的網域開始

先用一條 DOMAIN 規則確認目標和副作用；只有確認整個子網域樹都應拒絕時，才擴大為 DOMAIN-SUFFIX。不要只因某次觀察到一個 IP，就直接拒絕整個共用網段。

規則順序與 Global Routing：語法正確還不夠

在依 Config 規則處理的模式中，規則通常依序比對，由第一條符合的規則決定策略。若前面已有涵蓋目標的允許規則，後面的 REJECT 就不會處理該連線。FINAL 是前面規則都未符合時的預設處理，不應放在仍需參與比對的一般規則之前。

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

上例先拒絕一個精確網域，再讓同一主網域下的其他連線使用 DIRECT。若把前兩行對調，metrics.example.com 就會先符合範圍較大的 DIRECT 規則。末尾的 FINAL,DIRECT 僅用來示範比對順序；實際設定應保留所需的預設策略，不要據此更改所有未符合規則的流量去向。

Config

建議

依目前啟用設定中的規則決定策略。若要驗證自訂 REJECT，請先在 Home → Global Routing → Config 確認目前採用此模式。

適用情況：日常規則分流、確認自訂規則是否命中。

Proxy

流量會經由代理路徑處理，不會逐條依照 Config 的一般分流規則決定去向。切換到此模式後，不能再用網頁是否遭拒絕來驗證剛編輯的 Config 規則。

適用情況：暫時檢查代理連線，排除一般分流規則的影響。

Direct

流量會經由直連路徑處理，同樣不適合作為自訂 Config 規則的命中測試環境。直連能開啟網頁，不代表 REJECT 語法有誤。

適用情況：對照直連連線狀況，檢查網路環境差異。

若正在使用 Scene，也要先確認場景最後採用的設定與處理方式。排查時暫時固定使用 Config，可減少場景切換造成的變數。此處比較的是三種常見測試模式，並非 Global Routing 所有可選項目的完整清單。

局部修改與驗證：一次只新增一條規則

以下步驟假設已有可用設定。Home 中的伺服器項目、Config 中的設定檔，以及 Settings 中的一般設定用途各不相同；編輯未啟用的設定檔，不會自動改變目前連線的處理規則。

保留原始設定

前往 Config，確認目前啟用的設定，並先保留副本或匯出備份。記下原本的 Global Routing 模式，確保可以還原到修改前的狀態。
固定處理模式

在 Home → Global Routing → Config 選擇依設定檔處理。確認 Home 的連線開關已開啟，避免用戶端尚未接管連線時就開始測試規則。
加入精確規則

在 Config 中開啟目前設定的編輯入口，找到 [Rule] 區段。在涵蓋目標的廣泛規則與 FINAL 之前，加入一條針對已確認目標的 DOMAIN 規則，然後儲存。
建立新連線

確認修改後的設定仍為啟用狀態，必要時重新連線。關閉目標網頁或 App 後重新開啟，再查看用戶端的連線記錄中該網域對應的策略與命中資訊。
檢查並還原

分別測試登入、內文、圖片和播放等必要功能。若出現異常，先移除剛新增的那一行並儲存，再重新建立連線；不要同時更換 DNS、伺服器和多組規則。

驗證時要同時確認「目標連線是否命中 REJECT」和「必要功能是否仍可使用」。頁面某個區塊消失只能視為現象，不能單獨證明規則正確；伺服器暫時異常、App 快取和資源載入逾時也可能造成類似狀況。反過來說，頁面仍顯示舊圖片，也可能只是本機快取尚未更新，不代表新請求已成功通過。

封鎖範圍：同網域內容、加密路徑與內嵌資源

一般網域與 IP 規則不需要讀取完整網頁內容，但也因此無法依內容選擇性處理。HTTPS 會加密請求路徑、查詢參數和內容等資訊；網域規則無法辨識完整的加密 URL。用戶端能否取得目標網域，也取決於連線方式、解析路徑及可用的連線中繼資料。

同網域、不同路徑：example.com/article 與 example.com/promo 使用相同主機時，DOMAIN 無法只拒絕後者。改用 IP 規則也不會因此取得路徑辨識能力。
共用同一連線：HTTP/2、HTTP/3 可在同一連線中承載多個請求。REJECT 不是用來從同一連線中挑出特定網頁模組的工具；拒絕連線可能連帶影響一同傳輸的正常資源。
App 內建資源：已隨 App 儲存的圖片、介面或文字不需要新建遠端連線，網路規則無法移除這些本機內容。
伺服器合併內容：若內文和其他內容由同一個介面一次回傳，拒絕該介面可能使內文一併消失，無法保證只保留其中一部分。
共用基礎設施：多個服務可能共用 CDN 或 IP。封鎖某個位址範圍後若其他網站也無法開啟，應先縮小範圍或撤銷位址規則，而不是繼續擴大封鎖範圍。

即使命中 REJECT，App 仍可能顯示預留空白、錯誤訊息或快取內容，也可能改用其他網域重試。拒絕連線與介面重新排版是兩回事。若目標與付款、帳戶驗證或媒體介面共用基礎設施，應優先確保必要功能正常，不宜追求封鎖所有異常請求。

常見排查：規則未命中，還是目標無法單獨處理？

設定 REJECT 後，為什麼還是能開啟？

先確認 Home → Global Routing → Config，再到 Config 核對實際啟用的檔案。檢查規則是否排在涵蓋目標的 DIRECT、策略群組規則或 FINAL 之後。重新建立連線後查看記錄；不要只根據螢幕上仍顯示的快取內容判斷。

能否只封鎖一個 URL，不影響同網域的其他頁面？

DOMAIN 和 DOMAIN-SUFFIX 只依網域比對，無法把完整 URL 貼到網域欄位來過濾路徑。先確認資源是否使用獨立主機；若只有路徑不同，就不要再擴大網域規則，以免連同網域內的正常連線也遭拒絕。

新增規則後，登入和圖片都出問題，該怎麼辦？

先撤銷最後一條規則並重新連線，確認功能是否恢復。若使用 DOMAIN-SUFFIX 或 IP-CIDR，請檢查規則是否涵蓋共用主機或位址；只有從連線記錄確認目標獨立時，才改用範圍較窄的 DOMAIN 規則。

更新訂閱後，本機規則會自動更新嗎？

Home 中的 Subscribe 伺服器訂閱與 Config 設定檔並非同一項目。更新伺服器清單不代表本機規則也已更新；更新遠端設定檔則可能覆蓋手動修改。請分別確認更新項目與目前啟用的設定，並為本機調整保留副本。

也不要用 Settings → On Demand 判斷規則是否命中。On Demand 負責設定符合條件時何時建立連線；REJECT 則是在連線進入規則判斷後，決定採用何種策略。排查期間若連線狀態自行改變，也要確認 On Demand 條件，但不要把按需連線設定當成編輯封鎖規則的入口。

保留規則的標準：命中明確、副作用可接受、能夠還原

規則維護並非項目越多越好。每條新增規則都應有明確目標、可重現的現象和撤銷方式。對於來源不明的大範圍規則，尤其是整段 IP 或廣泛拒絕主網域的規則，若無法說明用途，就不應直接加入日常設定。

保留修改前的設定，並註明新增規則的目標網域與原因。
新增規則後檢查新連線記錄，再測試帳戶、付款、播放及其他實際使用的功能。
App 或網站更換資源網域後，應重新驗證；不能把過去有效視為長期保證。
需要更新遠端設定時，先確認是否會覆蓋本機調整，更新後再檢查啟用狀態。

Shadowrocket 是透過 App Store 取得的閉源商業 App，主要供 iPhone、iPad 使用，開發者為 Shadow Launch Technology Limited。用戶端一次買斷 ≠ 連線方案；本文不提供連線服務，既有訂閱連結請向你的服務商取得。價格、系統需求及購買適用範圍以 App Store 頁面標示為準。