Shadowrocket（小火箭）的 REJECT 是拒绝连接的策略，不是删除页面元素的工具。先在 Config 选用含有目标规则的配置，再到 Home → Global Routing 选择 Config。本文适合已经持有自己的服务商资料与订阅、准备调整本地规则的用户：从域名匹配入手，区分 URL 可见性、规则顺序和缓存影响，并用小范围验证降低误拦风险。
1. REJECT 在哪里生效：匹配请求，而不是修改页面
应用发起网络请求后，只有进入 Shadowrocket 接管范围的流量，才有机会接受当前配置中的规则判断。规则以可获取的域名、目标 IP 或 URL 等信息作为条件；命中某条使用 REJECT 的规则后，该连接会被拒绝，而不是继续交给 DIRECT 或代理策略处理。应用可能显示加载失败、重试提示，也可能自行换用其他地址。
这个过程不理解页面布局，也不会识别一段图片或文字“是不是广告”。如果目标内容由单独域名加载，拒绝该域名的连接可能阻止内容出现；如果内容已经包含在主页面响应中，REJECT 无法只删除其中一部分。空白占位、加载图标和应用自身显示的提示，也不属于连接规则能直接清理的对象。
先判断“要阻止的内容是否有独立网络请求”，再选择匹配条件。页面仍有占位，不等于请求没有被拒绝；页面暂时没有显示内容，也不等于规则已经命中。
2. DOMAIN-SUFFIX 写法：先从独立域名做小范围屏蔽
DOMAIN-SUFFIX 匹配指定域名及其子域名。下面的 ads.example.com 只是说明语法的示例地址，不是可用的屏蔽清单。它会覆盖 ads.example.com 和 img.ads.example.com，但不会覆盖 notads.example.com。不要为了匹配一个子域名，直接把整个主域名设为 REJECT。
[Rule]
DOMAIN-SUFFIX,ads.example.com,REJECT
FINAL,DIRECT上述片段适合解释“目标域名拒绝、其余直接连接”的逻辑。它不是适合所有网络需求的完整配置；如果现有配置的 FINAL 指向其他策略，应保留原有兜底意图，不要机械替换成 DIRECT。已有配置中包含 [Rule] 时，把规则加入该区域即可，不要重复创建同名区域。
- 在 Config 中备份当前配置，确认正在编辑的文件就是准备启用的文件。
- 把目标域名的 REJECT 规则放在可能提前命中的宽泛放行规则之前，并保持 FINAL 在规则末尾。
- 保存并选用配置，回到 Home → Global Routing，选择 Config。
- 确认连接已开启，重新发起目标请求；同时检查登录、图片和正文等正常功能是否受影响。
在通常的顺序匹配中，前面已经命中的规则会决定策略。比如先写 DOMAIN-SUFFIX,example.com,DIRECT，再写针对 ads.example.com 的 REJECT，后者就可能没有执行机会。应先安排具体条件，再安排较宽泛的条件；FINAL 用于前面规则均未匹配时的最终处理。
3. Global Routing 与匹配条件：不要把连接触发当成屏蔽规则
排查规则不生效时，先检查 Home → Global Routing。Proxy、Direct、Config、Scene 是不同的路由姿态，不能只凭连接开关已打开就认为配置规则正在使用。本文的验证基线是 Config：让选用配置中的规则参与分流。Scene 应另行核对其场景设置，不作为这份最小测试的前提。
最小域名测试
- 配置入口
- Config → 选用测试配置
- 路由入口
- Home → Global Routing → Config
- 目标规则
- DOMAIN-SUFFIX,ads.example.com,REJECT
- 兜底示例
- FINAL,DIRECT
示例仅解释语法；测试时使用已确认的真实目标域名。
连接与匹配边界
- 自动连接入口
- Settings → On Demand
- On Demand 作用
- 按条件触发连接，不替代 REJECT 规则
- IP-CIDR 条件
- 按目标 IP 所属网段匹配
- GEOIP 条件
- 按目标 IP 的地理归属数据匹配
先确认连接和 Config，再核对请求究竟提供了什么匹配信息。
域名规则需要能够获得请求对应的域名信息。应用直接访问 IP、使用不同的解析路径，或请求的可观察信息受限时，不能假设域名条件一定会匹配。IP-CIDR 可以表达网段条件，GEOIP 可以表达地理归属条件，但它们都不能判断某个 IP 上的内容用途；共享服务器或内容分发地址尤其容易产生误拦。
Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 是连接协议名称，不是“识别页面内容”的规则条件。对于已命中 REJECT 的请求，更换协议并不会让被拒绝的请求变成放行。应先检查命中的规则和策略，再判断是否存在另一个连接问题。
4. URL-REGEX 写法：路径匹配取决于 URL 是否可见
URL-REGEX 使用正则表达式匹配 URL，可以比域名规则更细地描述路径。下面只匹配示例主机下以 /banner/ 开头的路径；^ 限定 URL 开头，\. 表示字面量的点，https? 表示 HTTP 或 HTTPS。正则能描述条件，不代表客户端在所有连接中都能看到完整 URL。
URL-REGEX,^https?://ads\.example\.com/banner/,REJECT| 条件 | 需要的信息 | 主要边界 |
|---|---|---|
DOMAIN-SUFFIX |
目标域名 | 不能区分同域名下的不同路径。 |
URL-REGEX |
可供匹配的 URL | HTTPS 加密路径通常不能直接读取。 |
IP-CIDR |
目标 IP 与网段 | 同一 IP 上的多个服务可能一起受影响。 |
HTTPS 会加密 HTTP 请求内容，包括路径和查询参数。即使连接使用常见的 443 端口，能够知道主机名也不等于能够读取 /banner/。要对 HTTPS 路径进行匹配，通常需要相应流量能被 MITM 处理，并满足目标主机范围、证书信任和应用兼容等条件。不能把一条 URL-REGEX 当作无需其他设置就可读取加密路径的规则。
部分应用使用证书固定或其他校验机制，可能拒绝被 MITM 处理的连接。此时应停止该范围的处理并恢复原设置，不应把应用报错简单归因于正则写错。明文 HTTP 在客户端支持的处理路径中可提供 URL 信息，但是否匹配仍应以实际请求和日志为准。
结论：域名独立时先用域名规则
确认目标由独立域名加载后，先测试一条 DOMAIN-SUFFIX 规则；只有确实需要区分同域路径、且能验证 URL 可见性时，再考虑 URL-REGEX。
5. 能拦与拦不住：同域内容、缓存和应用内嵌请求
REJECT 最适合处理可以明确识别、且拒绝后不会破坏必要功能的独立连接。所谓“应用内嵌请求”并不天然绕过规则：只要进入接管范围并满足匹配条件，它同样可能被拒绝。难点在于这些请求可能共用主业务域名、改变地址、使用已有长连接，或根本没有重新访问网络。
- 独立资源域名：拒绝该域名可以阻止新连接，但应检查它是否同时承担验证码、图片或登录功能。
- 同域名不同路径：DOMAIN-SUFFIX 会影响整个域名，无法只区分某个页面区域；URL-REGEX 又受 URL 可见性约束。
- 同一响应中的内容：正文和附加内容在同一响应里返回时，拒绝连接会一起阻断，不能只留下正文。
- 本地缓存与内置素材：应用无需新连接即可显示的内容，不会因为新增 REJECT 规则而自动消失。
- 备用地址与重复请求：一个地址被拒绝后，应用可能请求另一个地址；应观察后续请求，而不是不断扩大主域名屏蔽范围。
- 现存连接：新规则不应被视为对所有已建立连接的即时清理命令。验证时应让目标应用重新发起连接。
例如，若登录接口与待屏蔽资源都在 api.example.com，对该域名使用 REJECT 可能同时造成登录失败。若多个域名共享同一个 IP，改用网段拒绝也未必更精确。规则粒度应由请求结构决定，不能用更大的屏蔽范围弥补证据不足。
6. 验证与回退：每次只改一项
有效验证应同时检查“目标请求是否被拒绝”和“必要功能是否仍能使用”。Connectivity Test 用于诊断所选连接的可达性，不是 REJECT 命中测试。测试结果正常，不能证明某条屏蔽规则生效；结果异常，也不能直接证明目标域名被拒绝。
- 记录基线：保留原配置，记录目标内容出现的位置、已确认的请求域名，以及登录等正常功能。
- 单条修改：只增加一条具体域名规则，不同时更换协议、兜底策略和 DNS 设置。
- 确认状态：核对 Config 选用的文件、Home → Global Routing → Config，以及连接开关状态。
- 重新请求：重新加载目标页面或重新打开目标应用，排除已有连接和缓存带来的干扰。
- 核对证据：在可用的请求记录或日志中检查目标域名、命中规则与最终策略，不仅观察页面外观。
- 对照回退：移除该规则或恢复备份，再重复相同步骤。必要功能受影响时，先恢复可用状态。
写了 REJECT，为什么内容还在？
先到 Home → Global Routing 确认 Config，再检查 Config 中选用的文件。随后重新发起请求；若没有新的目标请求记录，应先考虑缓存、内置素材或现存连接，而不是继续添加宽泛规则。
一屏蔽就不能登录，怎么恢复？
在 Config 移除刚添加的 REJECT 规则或恢复备份，保存并重新选用。检查目标域名是否与登录接口共用；未经验证，不要改成拒绝整个主域名或共享 IP 网段。
URL-REGEX 写对了，HTTPS 路径仍然匹配不到？
先确认请求实际 URL 与表达式一致，再确认该流量是否具备完整 URL 的可见性。只看得到域名时，路径规则没有足够信息；不要仅凭 443 端口或连接成功推断 MITM 已生效。
更新配置后，自加的规则怎么没了？
区分服务器资料订阅与远程配置更新。前者主要更新服务器资料，后者可能替换配置内容。修改前保留独立备份，更新后重新核对 Config 中的规则、顺序和选用状态，不要只检查 Home 的服务器列表。
如果需要进一步理解分流条件，可查看技术参考；首次连接与路由模式操作可查看入门指南的 Global Routing 说明。本站不提供、不销售、不推荐节点或订阅；客户端购买与用户已有的线路服务是两件独立事项。