Shadowrocket（小火箭）的 REJECT 是请求处理策略，不是网页元素过滤器。本文适合已经有可用配置、准备添加本地屏蔽规则的用户：先区分匹配条件与策略，再按 Config 模式检查规则顺序，最后通过单条规则的启停比较判断误伤。示例全部使用示意域名与文档用途 IP 地址，需按实际请求替换，不是可直接使用的屏蔽清单。
REJECT 是什么：命中后拒绝连接
REJECT 的作用是拒绝命中该策略的请求，而不是为请求选择代理服务器。一条规则前半部分描述匹配条件，末尾指定处理策略。例如 DOMAIN,ads.example.com,REJECT 中，DOMAIN 是规则类型，ads.example.com 是匹配值，REJECT 才是请求命中后的动作。不要把 REJECT 填进服务器地址或端口字段。
规则只能处理进入相应分流流程的流量。在 Home → Global Routing 使用 Config，才是按当前配置检查本文规则的常规测试方式。Proxy 和 Direct 属于全局处理姿态，不能当作验证配置内 REJECT 的等价条件；Scene 则要结合所选场景的实际设置判断。若请求未进入 Shadowrocket 的处理路径，修改配置中的 REJECT 也不会影响它。
DIRECT：请求采用直接连接策略，并不表示拒绝连接。PROXY：请求交给对应代理策略；是否可用还取决于当前配置与服务器。REJECT：拒绝请求，不需要为这条拒绝规则准备代理出站。
规则怎么写：从精确域名开始
优先用 DOMAIN 精确匹配，再按需求扩大到 DOMAIN-SUFFIX 或 DOMAIN-KEYWORD。下面是配置文件 [Rule] 段中的语法示例。三条规则用于对照匹配范围，实际排查时先只启用需要的一条，避免范围叠加后无法分辨是哪条规则起作用。
[Rule]
DOMAIN,ads.example.com,REJECT
DOMAIN-SUFFIX,tracker.example.net,REJECT
DOMAIN-KEYWORD,telemetry,REJECT
FINAL,DIRECT域名条件与范围
- DOMAIN
- ads.example.com,REJECT：只匹配该完整域名。
- DOMAIN-SUFFIX
- tracker.example.net,REJECT：匹配该域名本身及其子域名。
- DOMAIN-KEYWORD
- telemetry,REJECT：匹配域名中含有该关键词的请求。
域名条件不填写 https://、页面路径或查询参数。
地址条件与兜底
- IP-CIDR
- 192.0.2.7/32,REJECT：按单个 IPv4 地址匹配。
- GEOIP
- CN,DIRECT：按 IP 地理数据库中的地区结果匹配。
- FINAL
- DIRECT：处理未命中此前规则的请求。
地址规则依赖可用的目标 IP 信息，不能替代精确域名规则。
域名规则匹配主机名，不匹配整个 URL。若目标地址是 https://ads.example.com/banner?id=1，可供此处域名规则判断的是 ads.example.com，不是 /banner 或 id=1。把整段 URL 写进 DOMAIN-SUFFIX 不会得到“只屏蔽这个页面”的效果。
示例里的 FINAL,DIRECT 只用于展示完整的规则收尾。它会让未命中的流量直接连接，不应拿来覆盖你原有的 FINAL 策略。把示例合并进已有配置时，只加入需要的拒绝规则，并保留原配置的兜底方式及有效策略名称。
匹配顺序怎么排：例外在前，宽泛条件在后
普通规则按自上而下的顺序判断，请求采用首条命中规则的策略。同一域名可能同时符合精确域名和后缀条件，最终并不自动选择“看起来更精确”的那一条。因此，允许访问的例外必须放在宽泛拒绝规则前面，FINAL 则放在普通规则末尾。
[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN-SUFFIX,example.com,REJECT
FINAL,DIRECT- 访问
login.example.com：先命中第一条，采用 DIRECT，不再继续命中后面的后缀拒绝规则。 - 访问
ads.example.com：不符合第一条，但符合第二条，采用 REJECT。 - 访问
example.com：域名本身也属于第二条的匹配范围，因此同样被拒绝。 - 访问
example.org：不符合前两条，最后按 FINAL,DIRECT 处理。
结论：先移动例外，再扩大屏蔽范围
如果登录域名需要保留，先把其允许规则放到后缀拒绝规则上方，再测试登录和业务页面。若把两条规则的位置互换，即使精确例外仍在配置中，也会因请求先命中宽泛规则而失去作用。
排查“规则写了却无效”时，应先查前面的命中条件。例如上方已有 DOMAIN-SUFFIX,example.com,DIRECT，下方再写 DOMAIN,ads.example.com,REJECT，这个请求仍会先直连。修正方法是调整顺序或收窄上方条件，而不是反复追加相同 REJECT 行。
如何添加与验证：一次只改一条规则
先复制当前配置，再在副本中修改并选用它。以下入口以 iPhone / iPad 的 Home、Config 界面词为参照，其他平台以实际菜单为准。操作应基于用户已有的配置和服务商；本文不提供、不销售、不推荐节点或订阅。
- 进入 Config，确认当前正在使用的配置文件，保留一份修改前的副本，以便恢复。
- 打开待修改配置的编辑入口，找到规则部分；若使用文本编辑，在既有
[Rule]段加入规则，不要重复创建相互分离的同名段。 - 先加入一条精确规则，例如
DOMAIN,ads.example.com,REJECT，放在可能匹配该域名的宽泛规则之前，并保持原 FINAL 不变。 - 保存并选用修改后的配置，回到 Home → Global Routing，确认使用 Config，再确认连接开关已开启。
- 关闭目标应用或页面的旧连接后重新发起请求；分别记录目标功能和应保留功能的表现。
- 临时删除或停用刚加的规则，再发起相同请求。如果功能随规则启停而改变，再继续判断规则范围是否合适。
已有连接和本地缓存可能让测试结果滞后。页面已经加载的图片不会因新增 REJECT 自动消失；应用也可能复用之前建立的连接。先新建请求，再比较启用与停用的差别。不要把缓存仍显示旧内容当成规则失效，也不要把某次网络超时直接归因于 REJECT。
屏蔽有什么边界：域名拒绝不等于内容过滤
REJECT 适合拦截可独立识别的请求目标，不适合按页面中的文字或元素精细过滤。如果广告、登录和正文使用同一域名，拒绝该域名可能同时破坏这些功能。HTTPS 请求中，不能仅凭 DOMAIN 类规则识别某个 URL 路径；本文的域名拒绝也不需要为此开启 HTTPS 解密。
- 同域资源：拒绝整个业务域名可能连同正文图片、账号验证或支付回调一起阻断，应优先寻找能够独立识别的目标。
- 关键词过宽：
DOMAIN-KEYWORD,ad,REJECT的范围远大于某个广告域名，普通业务域名只要包含这段字符也可能命中，不宜作为初始测试规则。 - 共享 IP：多个网站可能共用同一 CDN 地址。用 IP-CIDR 拒绝一个地址时，影响范围未必只包含原先观察到的网站。
- 动态地址：服务端地址变化后，手工记录的 IP 可能不再覆盖目标；反过来，旧地址也可能被其他业务使用。
- 匹配信息不足：当处理流程只有目标 IP、没有可用于匹配的域名信息时，域名规则未必命中，应核对实际请求记录，而不是不断扩大关键词。
结论：无法区分资源时，保留业务可用性
如果目标内容与必要业务共用域名，而且无法找到独立的请求目标，就不要继续扩大 DOMAIN-SUFFIX 或 IP-CIDR 的范围。撤回误伤规则，比用更多例外修补一个过宽条件更容易维护。
常见问题：误伤、更新覆盖与自动连接
多数问题应从当前配置、路由姿态和最近一次改动开始定位。先暂停扩大规则清单，保留可复现的单条测试条件，再按下面的顺序处理。应用界面中的连接状态只能说明隧道状态，不能单独证明某条 REJECT 已经命中。
加了 REJECT，为什么目标还是能打开？
先在 Home → Global Routing 确认 Config，再到 Config 确认选中的是修改后的文件。检查拒绝规则上方是否已有 DIRECT 或其他先命中的条件；最后关闭旧连接并新建请求，排除缓存和连接复用。
屏蔽后登录失败，应该加什么例外？
先撤回最近加入的拒绝规则并确认登录恢复，再核对登录流程实际使用的域名。若该域名与屏蔽目标不同，将精确允许规则放在宽泛拒绝规则前面；若两者共用域名，单靠域名规则无法可靠区分。
更新之后，本地添加的规则为什么不见了？
先区分更新的是 Home 中的服务器订阅，还是 Config 中的远程配置文件。服务器列表更新与规则文件更新不是同一件事；远程配置刷新可能替换本地编辑的内容。更新前保存副本，更新后核对规则段及其顺序，再选用需要的配置。
Settings → On Demand 能代替规则开关吗？
不能。On Demand 用于按所设条件触发连接，不负责指定某个域名是 DIRECT 还是 REJECT。测试时先确认隧道已连接，再核对 Global Routing 和当前配置；需要撤销某条屏蔽时，应修改对应规则。
维护规则时应保留修改原因和回退办法。每次只处理一个目标，记录实际域名、使用的规则类型以及必须保留的业务功能。配置来自远程来源时，还要在刷新后重新核对本地改动。这样可以把“拒绝范围是否正确”与“当前连接是否正常”分开判断，避免把全部网络问题都归到屏蔽规则上。