本文适合已经使用 Shadowrocket、希望调整现有配置的用户。先区分规则条件与 REJECT 策略，再用教学域名验证匹配顺序，最后按连接记录定位误伤。操作以用户已有自己的服务商与订阅为前提；示例只用于说明语法，不是可直接替换日常配置的完整方案。
1. REJECT 是处理结果，不是内容识别器
Shadowrocket（小火箭）是 Apple 平台的付费客户端，唯一获取入口是 App Store，开发者为 Shadow Launch Technology Limited，应用 ID 为 932747118，采用一次性买断。以 iPhone / iPad 为主，其他设备兼容性与系统要求以 App Store 页面标注为准。客户端买断 ≠ 线路套餐；本文讨论的是本地配置的匹配与处理，不涉及连接服务的提供。
在一条 DOMAIN-SUFFIX,example.com,REJECT 规则中，DOMAIN-SUFFIX 是匹配类型，example.com 是条件，REJECT 才是命中后的策略。它拒绝符合条件的请求，不会继续尝试下方规则，也不会把被拒绝的请求自动改为代理重试。
这条流程只描述进入 Shadowrocket 处理范围的新请求。已经建立的连接、应用缓存中的内容，以及没有进入该处理范围的流量，不能仅凭添加一条规则就立即消失。因此，页面仍显示旧图片并不能证明 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 失败、远端连接失败和应用自身错误也可能出现类似表现。
- 固定复现动作。记录失败时间、目标操作、当前网络与配置名称。例如每次重新进入同一个登录页面，而不是同时测试多个应用。
- 检查连接记录。围绕失败时间查找目标域名或 IP，核对是否确实显示 REJECT，以及命中的是哪条规则。若记录并非 REJECT，应转查 DNS、连接建立或远端响应。
- 撤回最小改动。暂时移除刚添加的一条规则，保存配置后重新发起同一动作。不要一次删除整个规则段，否则无法确认是哪项改动起作用。
- 按必要目标加例外。若确认某个域名属于必要依赖，可在宽泛拒绝规则之前添加精确 DOMAIN 例外，并使用原配置中该目标适合的策略；不是一律改成 DIRECT。
- 恢复并验证。重新测试主功能和原本要拒绝的目标。只有两者结果都符合预期，才能说明例外没有把整个屏蔽范围一起放开。
测试新规则时应重新建立目标连接；必要时断开再连接隧道，并确认 On Demand 没有改变预期状态。对仍在屏幕上的缓存内容，先重新载入再判断。向他人反馈问题时，只提供脱敏后的目标、规则与错误现象，隐藏订阅完整链接、token、密码及其他凭据。
6. 常见问题：看见内容不等于规则失效
加了 REJECT，为什么原来的图片还在？
先重新载入页面并观察新连接。图片可能来自应用缓存，也可能在添加规则前已经加载。只有新的目标请求仍成功、且没有命中预期 REJECT 时，才继续检查当前配置、域名条件与匹配顺序。
拒绝一个域名后，为什么整个登录都失败了？
先撤回该规则复现一次，再对照失败时的请求目标。认证与业务资源可能共用域名；若只需要保留一个独立的必要子域名，在宽泛 DOMAIN-SUFFIX 之前加精确 DOMAIN 例外，并重新测试登录流程。
把 REJECT 放在 FINAL 后面，为什么没有变化？
FINAL 是此前未命中请求的兜底，放在它后面的普通规则无法处理已经被兜底的请求。把具体匹配放在 FINAL 前面，保持精确例外、目标拒绝、其他分流、最终兜底的清晰顺序。
能不能把资源使用过的 IP 全部拒绝？
先确认该地址是否被其他必要服务共享。CDN 地址可能变化，一个 IP 也可能承载多个域名。若只想限制某个域名，优先采用可验证的域名条件；不要用宽泛网段替代尚未查清的目标。
完成排查后，保留一份简短变更记录：修改的规则、目的、复现动作与恢复方法。后续出现异常时，先回看最近修改，再扩大检查范围。需要核对 Home、Config 与 Settings 的基础操作，可阅读入门指南；规则术语可在术语表中对照。