本文適合已在使用 Shadowrocket，並想調整現有設定的使用者。先釐清規則條件與 REJECT 策略，再用教學網域確認比對順序，最後透過連線記錄找出誤封。操作以使用者已有自己的服務商與訂閱為前提；範例僅用來說明語法，並非可直接取代日常設定的完整方案。
1. REJECT 是處理策略，不是內容辨識工具
Shadowrocket（小火箭）是 Apple 平台的付費用戶端，唯一取得管道為 App Store，開發者為 Shadow Launch Technology Limited，App ID 為 932747118，採一次買斷。以 iPhone / iPad 為主，其他裝置的相容性與系統需求請以 App Store 頁面標示為準。用戶端買斷 ≠ 連線服務方案；本文討論的是本機設定的比對與處理，不涉及提供連線服務。
在一條 DOMAIN-SUFFIX,example.com,REJECT 規則中，DOMAIN-SUFFIX 是比對類型，example.com 是條件，REJECT 才是符合條件後採用的策略。這會拒絕符合條件的請求，不會繼續比對下方規則，也不會自動改用代理重試遭拒的請求。
這個流程只描述進入 Shadowrocket 處理範圍的新請求。已建立的連線、App 快取中的內容，以及未進入該處理範圍的流量，不會只因新增一條規則就立即消失。因此，畫面仍顯示舊圖片，不代表 REJECT 未生效；應以重新發出的請求及其連線記錄為準。
2. 先確認 Global Routing，再檢查規則順序
在 Home → Global Routing 確認目前的路由模式。測試本文的一般設定規則時，先確認使用 Config，並在 Config 中確認目前實際啟用的設定檔。若只把規則存進另一個檔案，卻沒有使用該檔案，現有連線的處理結果不會改變。
| 模式 | 處理方式 | 排查重點 |
|---|---|---|
Config | 依目前設定進行規則分流。 | 用來測試本文的規則順序與 REJECT 命中結果。 |
Proxy | 全程使用代理路由。 | 不可將此模式視為一般 Config 規則的等效測試環境。 |
Direct | 全程使用直連路由。 | 切換後可以連線，不代表代理伺服器一定有問題。 |
Scene | 依已設定的場景處理。 | 先確認目前的場景條件與路由設定，避免測試條件改變。 |
Settings → On Demand 用來管理依條件自動連線的行為，不是規則清單，也不會決定某個網域應採用 REJECT 或 DIRECT。測試期間若切換 Wi-Fi 或行動網路，請重新確認隧道連線狀態、Global Routing 與目前設定，勿將自動連線觸發和規則命中混為一談。
- 修改前先備份目前設定，並記下目前的 Global Routing 模式與測試目標網域。
- 在 Config 中編輯實際使用的設定檔；一次只調整一項條件或一條規則。
- 儲存後確認目前使用的仍是該檔案，關閉目標頁面並重新發出請求。
- 查看新請求的目標、命中規則與最終策略，再決定是否繼續修改。
3. DOMAIN-SUFFIX、IP-CIDR 與 FINAL 的寫法
規則通常依序由上往下比對，第一條符合的規則會決定處理策略。較精確的例外應放在較寬泛的規則之前，並將 FINAL 放在最後作為兜底。若先放入範圍寬泛的 REJECT，之後再加一條 DIRECT，通常無法挽回已符合前者的請求。
以下是便於閱讀的教學片段，網域與 192.0.2.10 均為範例。為避免依賴使用者自訂的策略名稱，兜底規則採用 DIRECT；這不代表日常設定都應使用直連。請勿以此片段覆蓋既有的完整設定。
[Rule]
DOMAIN,keep.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
IP-CIDR,192.0.2.10/32,REJECT,no-resolve
GEOIP,CN,DIRECT
FINAL,DIRECT網域比對範圍
- DOMAIN
- keep.example.com,DIRECT：只為完全相符的網域設定例外。
- DOMAIN-SUFFIX
- example.com,REJECT：涵蓋根網域及其子網域。
- 不會命中的相似名稱
- notexample.com 並非 example.com 的子網域。
先放精確例外，再放後綴規則；比對不是看字串中是否包含幾個相同字母。
IP 與兜底範圍
- IP-CIDR
- 192.0.2.10/32,REJECT,no-resolve：比對單一範例 IPv4 位址。
- GEOIP
- CN,DIRECT：依據 IP 地理位置資料庫判斷。
- FINAL
- DIRECT：處理未符合前面規則的請求。
no-resolve 表示不會為比對這條 IP 規則而主動觸發網域解析，不代表停用所有 DNS 查詢。
依照上述順序，keep.example.com 會先符合精確例外，img.example.com 則會符合後綴 REJECT。IP 規則是否會參與判斷，還取決於當時可取得的目標位址資訊；GEOIP 反映的是資料庫中的地理位置歸屬，不能保證服務所在地或內容性質。請勿將這些條件都視為相同的網域過濾方式。
4. 同網域內容與 HTTPS：REJECT 的限制
網域規則能判斷「是否拒絕這個目標網域」，卻無法判斷「應移除頁面中的哪一部分內容」。若主要功能與待封鎖內容共用同一個網域，直接對該網域套用 REJECT，可能連登入、圖片、付款轉址或其他相依請求也一併中斷。
| 目標情境 | 網域 REJECT 的結果 | 無法據此推斷 |
|---|---|---|
| 資源由獨立子網域提供 | 只要目標可辨識且符合規則，就能拒絕該子網域的請求。 | 無法保證頁面中的空白佔位也會一併消失。 |
| 同一網域下的不同 HTTPS 路徑 | 拒絕該網域會影響此網域的請求。 | 單靠網域規則無法區分 /content 與 /metrics。 |
| 多個網域共用同一個 IP | IP-CIDR 可能同時涵蓋多個不同服務。 | 不能將一個 IP 位址等同於一個網站。 |
| 請求使用 UDP 443 | 仍須查看實際目標與規則命中情況。 | 不能只憑連接埠判定流量類別或封鎖是否生效。 |
一般網域與 IP 規則不會因流量經過隧道，就自動取得 HTTPS 的完整路徑與內文。加密連線中的應用程式層內容，無法透過單一 DOMAIN-SUFFIX 條件逐段篩選。Shadowrocket 支援的連線協定與本機規則屬於不同層次；變更代理協定，不會讓網域規則突然具備辨識頁面元素的能力。
結論：無法區分目標時，優先縮小拒絕範圍
若同一網域同時承載必要功能與待封鎖請求，應撤除整個網域的 REJECT，先找出可獨立辨識的目標；若沒有獨立條件，保留必要功能會比持續增加範圍寬泛的 IP 拒絕規則更容易驗證與維護。
5. 誤封排查：從失敗請求回查，不要反覆切換連線
規則誤封常見的情況包括：主頁面能開啟，但登入一直停在等待畫面；文字已顯示，圖片卻載入失敗；或某項操作每次都在同一步驟出錯。這些現象只能作為線索，不能直接證明命中了 REJECT。DNS 失敗、遠端連線失敗與 App 本身的錯誤，也可能呈現類似狀況。
- 固定重現操作。記錄失敗時間、目標操作、目前網路與設定名稱。例如每次都重新開啟同一個登入頁面，不要同時測試多個 App。
- 檢查連線記錄。根據失敗時間搜尋目標網域或 IP，確認記錄是否確實顯示 REJECT，以及命中哪一條規則。若記錄不是 REJECT，請改查 DNS、連線建立或遠端回應。
- 撤回最小幅度的變更。暫時移除剛新增的一條規則，儲存設定後重做相同操作。不要一次刪除整段規則，否則無法確認是哪項變更造成影響。
- 為必要目標新增例外。若確認某個網域是必要依賴項目，可在範圍寬泛的拒絕規則之前新增精確的 DOMAIN 例外，並採用原設定中適合該目標的策略；不必一律改成 DIRECT。
- 還原並驗證。重新測試主要功能與原本要拒絕的目標。只有兩者結果都符合預期，才能確認新增例外沒有一併放行整個封鎖範圍。
測試新規則時，應重新建立目標連線；必要時中斷後重新連接隧道，並確認 On Demand 沒有改變預期狀態。若畫面上仍顯示快取內容，請先重新載入再判斷。向他人回報問題時，只提供已遮蔽敏感資訊的目標、規則與錯誤現象，並隱藏完整訂閱連結、token、密碼及其他憑證。
6. 常見問題：仍看得到內容，不代表規則失效
新增 REJECT 後，為什麼原本的圖片還在？
先重新載入頁面並觀察新連線。圖片可能來自 App 快取，也可能在新增規則前就已載入。只有新發出的目標請求仍成功，且未命中預期的 REJECT，才需要繼續檢查目前設定、網域條件與比對順序。
拒絕某個網域後，為什麼整個登入流程都失敗了？
先撤除該規則並重現一次，再對照失敗時的請求目標。驗證與業務資源可能共用網域；若只需保留某個獨立的必要子網域，可在範圍寬泛的 DOMAIN-SUFFIX 之前新增精確的 DOMAIN 例外，並重新測試登入流程。
將 REJECT 放在 FINAL 後面，為什麼沒有作用？
FINAL 是用來處理先前未命中規則的請求；放在它後面的普通規則，無法處理已由兜底規則接手的請求。請將具體比對規則放在 FINAL 之前，並維持精確例外、目標拒絕、其他分流、最終兜底的清楚順序。
可以把資源使用過的 IP 全部拒絕嗎？
先確認該位址是否也由其他必要服務共用。CDN 位址可能變動，一個 IP 也可能承載多個網域。若只想限制特定網域，優先使用可驗證的網域條件；不要用範圍寬泛的網段取代尚未確認的目標。
完成排查後，請保留簡短的變更紀錄：修改的規則、目的、重現操作與還原方式。日後發生異常時，先檢查最近的修改，再擴大排查範圍。如需確認 Home、Config 與 Settings 的基本操作，請參閱入門指南；規則術語可在術語表中查閱。