Shadowrocket（小火箭）的 REJECT 是连接分流策略，不是网页内容过滤器。本文适合已经能够正常连接、准备编辑规则的用户：先确认 Global Routing 使用 Config，再按域名或 IP 添加最小范围的规则，通过请求记录验证命中结果，最后区分规则遗漏、缓存和同域名内容这几类限制。
REJECT 拒绝的是连接，不是页面中的某个元素
应用访问网络时，Shadowrocket 对进入其处理路径的连接执行规则匹配。命中 REJECT 后，不再按照 DIRECT 或 PROXY 为这条请求建立到目标的正常出站连接。这里的“连接建立前”指目标出站阶段，并不表示应用尚未发出请求，也不表示匹配前一定没有发生 DNS 查询。
应用如何表现取决于自身的错误处理：图片可能加载失败，独立的统计请求可能结束，也可能出现重试或超时提示。REJECT 不会替应用生成一个正常页面，更不会自动把网页中的空白区域收起来。因此，“某个请求被拒绝”和“整个页面看起来没有变化”可以同时发生。
DIRECT：直接连接目标地址，仍然允许该请求访问网络。PROXY：通过所选代理策略出站，不等于拦截请求。REJECT：拒绝匹配到的请求，不承担内容替换或页面排版工作。
这些策略与所用代理协议不是同一个层级。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 描述代理传输或隧道方式；把代理协议换一种，并不会让 REJECT 获得识别 HTTPS 页面内部内容的能力。
域名与 IP 规则分别能识别什么
当匹配阶段能够取得目标域名时，可以使用 DOMAIN 或 DOMAIN-SUFFIX。前者匹配一个完整主机名，后者匹配指定域名及其子域名。若要拒绝的只是一个独立请求端点，应优先从完整主机名开始，而不是直接扩大到整个主域名。
域名匹配范围
- DOMAIN
- metrics.example.com,REJECT
- DOMAIN-SUFFIX
- example.com,REJECT
- 匹配依据
- 目标主机名，不是 URL 路径
example.com 及其子域名仅用于说明语法，不代表可直接使用的屏蔽清单。
IP 匹配范围
- IP-CIDR
- 192.0.2.10/32,REJECT,no-resolve
- GEOIP
- CN,DIRECT
- 匹配依据
- 目标 IP、网段或 IP 地理归属库
192.0.2.10 是文档示例地址；GEOIP 示例说明直接放行姿态，并非屏蔽建议。
/32 表示一个 IPv4 地址，而不是一段模糊范围。no-resolve 用于避免仅为这条 IP 规则额外发起域名解析；不要把它理解为“所有请求都不再使用 DNS”。如果应用直接访问 IP，且没有可用的域名关联信息，单独一条域名规则未必能够命中。
IP 规则也有边界。多个域名可能共享同一个 CDN 地址，同一个域名也可能随地区、网络或时间返回不同地址。把某次解析得到的 IP 全部拒绝，既可能遗漏之后的新地址，也可能影响共用该地址的其他服务。GEOIP 依据地址归属库作判断，同样不等于识别网站的实际内容或经营主体。
范围扩大前先核对依赖。登录、验证码、图片和正文可能使用同一主域名的不同子域名。把一条 DOMAIN 直接改为 DOMAIN-SUFFIX，可能从阻止一个端点变成阻止整组必要请求。
规则按顺序匹配，REJECT 没有额外优先权
在 Config 分流下，规则按从上到下的顺序检查，命中后使用该条策略。REJECT 不会因为具有拒绝含义就自动压过前面的 DIRECT 或 PROXY。较具体的例外应放在较宽的规则之前，FINAL 则放在规则段最后，处理尚未命中的连接。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY在这段仅用于解释顺序的示例中，login.example.com 先命中 DIRECT，metrics.example.com 先命中 REJECT，其他属于 example.com 的请求再匹配 PROXY。若把 DOMAIN-SUFFIX 移到最上面，前两个主机名都会先被它接走，后面的细分规则就失去作用。
| 配置情况 | 结果 | 修正方法 |
|---|---|---|
| 宽泛放行在 REJECT 前 | 目标先命中放行 | 把精确 REJECT 放到相关宽泛规则之前 |
| REJECT 放在 FINAL 后 | 请求已由 FINAL 接管 | 将 FINAL 保持在规则段末尾 |
| 同一主机名有多条策略 | 先命中的规则生效 | 检查完整规则顺序，而非只搜索 REJECT |
判断：先找实际命中的规则，再扩大屏蔽范围
如果请求记录显示 DIRECT 或 PROXY，应先修正前置规则或当前分流姿态；继续增加相似的 REJECT 条目，无法解决同一个请求已经提前命中的问题。
确认 Config 生效，再做一次最小验证
规则文件存在于 Config 中，并不代表当前请求一定按该文件处理。先检查 Home 的 Global Routing。Proxy 和 Direct 是整体出站姿态；验证规则时应明确选择 Config。Scene 是场景化的路由姿态，不能仅凭看到 Scene 就认定它等同于当前配置的规则结果。
- 保存副本。在 Config 中确认当前使用的配置，编辑前保留可恢复副本。不要直接覆盖一套尚未理解的完整规则。
- 只加一条精确规则。使用请求记录中实际出现的主机名，按
DOMAIN,主机名,REJECT的结构填写；这里的“主机名”说明字段位置，不是可直接粘贴的规则。 - 检查生效状态。保存修改并确认使用的是刚编辑的配置，在 Home 将 Global Routing 设为 Config，同时确认连接开关已开启。
- 触发新请求。退出目标页面后重新进入，必要时结束目标应用再打开。不要仅观察已经加载完毕的图片或旧标签页。
- 核对记录。在请求记录中查找目标主机名或 IP，检查实际命中的规则与策略。只有新请求显示 REJECT，才能证明这次测试确实进入拒绝分支。
- 恢复验证。暂时移除刚添加的规则，再以同样方式触发请求。比较移除前后的连接结果和功能变化，确认影响来自这条规则。
Settings → On Demand 用来控制按条件自动连接，不是 REJECT 的开关。若测试过程中隧道被断开，后续请求可能不再经过同一处理路径；应先确认连接状态，再解释“规则失效”。对于保活连接，修改规则也不应被视为已经断开所有既有会话，验证时需要产生新的连接。
记录的是验证条件，不是速度结论。建议保留目标主机名、Global Routing 姿态、命中策略、是否重新启动应用这四项。没有这些条件，仅凭“页面还能打开”不能判断 REJECT 是否生效。
HTTPS、缓存与同域名内容构成哪些限制
域名或 IP 规则处理的是连接目标。假设正常内容位于 https://example.com/article，另一类内容位于 https://example.com/promo，两者主机名相同。单靠 DOMAIN 或 DOMAIN-SUFFIX 无法按这两个路径区分；拒绝该主机名可能同时阻止正常文章。
端口只能提供传输用途的线索。正常网页与其他 HTTPS 请求都可能使用 443，不能靠拒绝整个端口实现精细筛选。即使能够获得目标域名，也不等于能够读取加密连接中的 URL 路径、请求正文或返回内容；REJECT 本身不负责解密。
- 内容已缓存：应用直接显示磁盘或内存中的数据，没有新的网络请求可供拒绝。重新进入页面也可能继续使用缓存。
- 内容随主响应返回：正常正文与其他内容由同一个请求一起返回，连接级拒绝无法只保留其中一部分。
- 页面结构仍在：远程图片请求虽然失败，网页预留的容器、标题或按钮仍可能存在。
- 请求切换端点：应用遇到失败后可能访问另一个域名，原规则只负责已匹配的目标，不自动推断新端点用途。
- 请求未进入处理路径：连接未开启或存在排除路径时，不能靠增加规则补救，应先核对流量是否经过当前配置。
URL Rewrite 属于另一类请求改写机制，不应把其能力归给 REJECT。某项内容不能被连接规则单独分离时，应保留必要功能并缩小目标范围，而不是通过不断扩大网段来尝试删除页面元素。
常见现象与恢复步骤
加了 REJECT，页面为什么还在显示？
先在 Home 确认 Global Routing 为 Config，再重新触发请求并检查记录。若新请求已显示 REJECT，而旧图片仍在，检查应用缓存；若完全没有新记录，不能用现有页面判断规则结果。
为什么屏蔽后登录也失败了？
先撤销最近添加的 DOMAIN-SUFFIX 或 IP-CIDR 规则，重新打开应用验证登录。若恢复正常，找出登录与目标内容是否共用域名或地址；能区分时改用精确 DOMAIN，不能区分时保留登录所需连接。
更新订阅后，刚写的规则怎么没效果了？
回到 Config 核对当前启用的文件及 Rule 段是否仍有本地修改。更新服务器订阅与替换远程配置不是同一个操作；若更新过程替换了整份配置，本地规则可能被覆盖，应从副本恢复并重新检查顺序。
可以直接复制一大批 IP 来屏蔽吗？
先不要批量加入。记录一个实际目标，验证它是否共享 CDN 地址、是否还会返回其他地址，再决定是否使用 IP-CIDR。每次只改一组相关规则，保留恢复副本，避免无法定位是哪一条导致功能异常。
本文以用户已有自己的服务商与订阅为前提，订阅从你的服务商处获取。服务商提供的连接参数解决接入问题，REJECT 解决当前配置下的匹配与拒绝问题，两者不能相互替代。完成验证后，保留精确、可解释且可以回退的规则，比持续增加无法确认用途的条目更便于维护。