Shadowrocket 规则怎么添加？5步完成导入、启用与命中排查
简答：Shadowrocket 添加规则的最短路径是：先备份当前配置，再在 Config 中导入或编辑规则，返回 Home → Global Routing 选择 Config，重新发起请求并检查策略结果。如果当前选择的是 Proxy 或 Direct，不能据此判断自定义规则是否生效。不同版本的按钮名称和日志字段可能不同，请以设备实际界面为准。
定义：Shadowrocket 规则是由匹配条件和处理策略组成的路由条目，用来决定某个域名或 IP 请求走 PROXY、DIRECT、REJECT 或其他策略。
先做这一步：分清节点、订阅、配置和规则
Shadowrocket 的节点、订阅、配置文件和规则不是同一个东西。App Store 页面将它描述为支持按域名、域名后缀、关键词、CIDR IP 段或 GeoIP 配置规则，并支持从 URL 或 iCloud Drive 导入规则文件；这只能说明应用具备相关功能，不代表导入任何订阅后都会自动获得适合自己的分流规则。可先查看App Store 中的应用说明。
| 对象 | 主要作用 | 是否直接决定分流 | 常见入口 |
|---|---|---|---|
| 服务器或节点 | 保存地址、端口、协议和认证参数 | 否 | Home 或 SERVER |
| 订阅 | 批量获取或更新服务器条目 | 通常不单独决定分流 | 添加入口中的 Subscribe |
| 配置文件 | 保存 General、Rule 等配置内容 | 是 | Config |
| 规则 | 匹配域名、IP 或其他条件并选择策略 | 是 | 配置文件的 [Rule] 区域或 Add Rule |
| Global Routing | 选择 Config、Proxy、Direct 等总体路由模式 | 决定规则是否参与当前请求 | Home → Global Routing |
因此，订阅导入成功只说明服务器条目被读取；它不等于当前配置已经选中，也不等于自定义规则已经启用。
Shadowrocket 规则添加方式怎么选？三种路径对比
| 方式 | 适合谁 | 优点 | 风险或限制 |
|---|---|---|---|
| 手动添加单条规则 | 只想处理一个域名或网段 | 改动小，容易验证和回滚 | 规则多时维护成本较高 |
| 导入远程配置 | 已有配置 URL 或完整配置文件 | 可一次导入多段配置 | 远程内容更新后可能改变规则、DNS 或重写设置 |
| 导入规则文件或规则集 | 希望集中维护较多规则 | 便于批量更新 | 需确认来源、格式和更新行为，可能覆盖本地改动 |
如果只是解决一个域名走直连或代理，优先用手动添加并只改一条；如果需要完整的配置文件，先复制一份测试副本，再导入远程内容。本文不确认任何远程规则地址的归属或安全性，使用前应查看文件内容和更新方式。
公开使用教程中可以看到 Config、Use Config、Add Rule 等操作路径，但这些页面的官方身份未在本次检索中独立核实，不能将其称为官方说明；具体按钮名称和位置应以当前应用界面为准。可参考公开的 Shadowrocket 使用教程。
5步添加并启用 Shadowrocket 规则
- 备份当前配置。先记下当前选中的配置文件、服务器和 Global Routing 模式；如果应用提供复制、导出或分享配置的功能，先保留副本。不要直接覆盖唯一可用配置。
- 打开 Config，确认目标文件。进入 Config，确认准备修改的是当前实际使用的配置，而不是仅存在列表中的旧文件。若是导入远程配置，先查看内容，确认存在
[Rule]区域或规则编辑入口。 - 添加一条规则。可以在规则编辑入口选择 Add Rule，也可以在配置文本的
[Rule]区域新增一行。常见格式是“规则类型、匹配值、策略”，例如：
[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.net,PROXY
FINAL,DIRECT以上域名和地址仅用于语法演示，不代表真实服务。保存后先不要一次加入多条复杂规则，否则出现问题时难以判断是哪一条导致的。
- 在 Home 中选择 Config。返回 Home，打开 Global Routing，选择 Config。Proxy 主要用于对照测试选定服务器，Direct 用于对照当前网络；二者都不能证明自定义规则已经按预期参与匹配。
- 重新发起请求并验证。关闭目标网页或应用后重新打开，产生一条新的请求。查看连接记录、策略结果或目标域名；如果当前版本不展示“命中规则”字段，就用同一目标在 Config、Proxy、Direct 三种模式下做对照，并记录实际访问结果。
完整的最小闭环是：备份配置 → 改一条规则 → 保存 → 选中配置 → Global Routing 设为 Config → 重新请求 → 查看结果 → 异常时恢复备份。
常见规则类型和写法
| 类型 | 含义 | 示例 | 注意事项 |
|---|---|---|---|
| DOMAIN | 匹配一个精确域名 | DOMAIN,example.com,DIRECT | 通常不应据此推断其子域名也会匹配 |
| DOMAIN-SUFFIX | 匹配域名后缀及相关子域名 | DOMAIN-SUFFIX,example.net,PROXY | 适合覆盖一个根域名及其子域名 |
| DOMAIN-KEYWORD | 匹配域名中包含的关键词 | DOMAIN-KEYWORD,example,REJECT | 匹配范围可能较宽，存在误匹配可能 |
| IP-CIDR | 匹配 IPv4 地址段 | IP-CIDR,192.0.2.0/24,DIRECT | 实际效果可能受 DNS 解析和当前配置影响 |
| GEOIP | 按目标 IP 的地理数据库结果匹配 | GEOIP,CN,DIRECT | 依赖应用使用的地理数据库，不等同于按网页语言判断 |
| FINAL | 前面没有规则命中时的兜底策略 | FINAL,PROXY | 应放在需要优先匹配的规则之后 |
策略和规则类型要分开理解：DOMAIN、IP-CIDR 等描述“匹配什么”；PROXY、DIRECT、REJECT 描述“匹配后怎么处理”。PROXY 不是服务器地址，也不包含账号、密码或订阅服务。
示例中的 no-resolve、IP-CIDR 解析流程和具体匹配行为可能受应用版本及配置影响。没有实际测试记录时，不应把示例推断为所有版本的绝对行为。
规则顺序为什么会导致“不生效”
按公开资料中对配置规则的说明，规则通常从上到下检查，先命中的规则会决定后续策略。因此，具体例外应放在宽泛规则前面，FINAL 应作为兜底放在后面。当前版本若采用不同的匹配实现，应以应用实际结果和日志为准。
[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT在这个语法示例中，api.example.com 先匹配第一条，其他符合后缀条件的请求再匹配第二条，未匹配前两条的请求才进入 FINAL。如果把 FINAL 或过宽的 DOMAIN-KEYWORD 放在前面，后面的例外规则可能没有机会执行。
判断顺序时重点检查三项：第一，规则是否真的写入当前配置；第二，前面是否已经存在更宽泛的匹配；第三，当前 Global Routing 是否为 Config。不要只看到连接开关处于开启状态，就认定所有请求都会使用自定义规则。
没有显示命中规则时，怎样验证实际走向
- 固定测试条件。使用同一台 iPhone、同一网络、同一目标域名，只改一个变量。
- 先测 Config。确认当前配置被选中，Global Routing 为 Config，然后重新打开目标页面或发起应用请求。
- 做 Proxy 对照。暂时选择 Proxy，观察同一目标是否出现不同结果。若 Proxy 能访问而 Config 失败，优先检查配置、规则顺序和策略，不要马上重导所有节点。
- 做 Direct 对照。选择 Direct 观察本地网络下的结果。Direct 只能作为网络对照，不代表代理服务器状态。
- 检查可见记录。若当前版本提供连接日志、请求记录、策略或目标地址字段，记录这些信息；若没有命中规则字段，就至少记录目标域名、Config/Proxy/Direct 模式和访问结果。
延迟有返回不等于网页能加载，DNS 解析成功也不等于规则策略、代理连接和页面请求都正常。排查时应分别记录 DNS、匹配模式、代理连接和网页加载结果。
远程配置更新后规则变化：备份、对比、回滚
远程配置或规则集可能在更新后改变规则顺序、策略、DNS、重写或其他配置内容。本文没有核实任何具体远程配置的自动更新机制，因此只给出通用且可回滚的做法：
- 更新前复制当前配置，保留原文件或导出内容。
- 记录更新前的规则数量、关键规则和 Global Routing 模式。
- 更新后先查看配置文本或规则列表，比较关键段落是否变化。
- 只用一个目标域名做复测，不要同时修改节点、DNS 和规则。
- 如果出现连接异常，先切回备份配置；仍异常时再对比服务器、网络和当前模式。
如果应用提供自动更新开关，可以在测试阶段暂时关闭，避免刚修复的本地规则被远程内容覆盖；完成确认后再按自己的需要恢复。具体开关名称和位置可能随版本变化。
规则不生效、导入为空或连接失败怎么分流
| 现象 | 先检查 | 可回滚的下一步 |
|---|---|---|
| 添加后没有变化 | 当前文件是否选中，Global Routing 是否为 Config | 重新选中配置并发起新请求 |
| 精确域名能匹配，子域名不匹配 | 是否使用了 DOMAIN | 备份后测试 DOMAIN-SUFFIX |
| 自定义规则似乎被跳过 | 前面是否有宽泛规则或 FINAL | 只调整一条规则的位置并复测 |
| 远程配置导入为空 | 地址是否完整、内容是否可读取、格式是否被识别 | 恢复原配置，改用本地测试文件 |
| Proxy 能用但 Config 不能用 | 当前配置、规则策略和规则顺序 | 暂时保留备份，不要删除原节点 |
| 更新后自定义规则消失 | 是否被远程配置覆盖 | 恢复更新前副本，再比较更新前后内容 |
如果问题涉及订阅链接、服务器认证或节点可用性，规则本身未必是唯一原因。应把“规则是否命中”和“代理服务器能否连接”分开测试。
常见问题
Shadowrocket 添加规则后为什么没有生效？
先确认修改后的配置文件已被选中，再在 Home → Global Routing 中选择 Config。随后关闭旧页面并重新发起请求。如果当前是 Proxy 或 Direct，测试结果不能直接证明自定义规则正确。
Shadowrocket 的规则应该添加在哪里？
通常是在当前配置文件的 [Rule] 区域添加，或者通过配置编辑界面的 Add Rule 操作添加。不同版本的入口名称可能不同，不能仅凭其他版本截图判断当前路径。
DOMAIN 和 DOMAIN-SUFFIX 怎么选？
DOMAIN 用于精确域名匹配；需要覆盖根域名及其子域名时，再考虑 DOMAIN-SUFFIX。两者的实际表现仍应结合当前版本和一次新请求验证。
FINAL 为什么会让后面的规则不生效？
FINAL 是没有匹配到前面规则时的兜底项。如果它位于自定义规则前面，后续规则可能没有匹配机会，因此通常应放在需要优先处理的规则之后。
导入订阅后会自动添加分流规则吗？
不一定。订阅主要用于获取或更新服务器条目，分流规则通常由当前配置文件或规则文件决定。导入后仍要检查配置是否选中、Global Routing 是否为 Config，以及规则内容是否存在。
当前版本看不到“命中规则”怎么办？
可以使用同一设备、同一网络和同一目标，在 Config、Proxy、Direct 之间做对照，记录目标域名、访问结果和连接状态。若仍无法区分，再恢复备份配置，避免继续叠加修改。
修改规则后连接失败怎么恢复？
先撤销最近添加的规则；如果问题仍在，重新选择修改前保存的配置副本，并恢复原来的 Global Routing 模式。不要在没有备份的情况下连续删除节点或覆盖配置。
常见问题
Shadowrocket 添加规则后为什么没有生效？
确认修改后的配置已选中，并在 Home → Global Routing 中选择 Config；然后重新发起请求。若当前是 Proxy 或 Direct，不能用该结果判断自定义规则。
Shadowrocket 规则应该添加在哪里？
通常添加到当前配置文件的 [Rule] 区域，也可以使用配置编辑界面的 Add Rule。不同版本的入口可能不同，以设备当前界面为准。
DOMAIN 和 DOMAIN-SUFFIX 怎么选？
DOMAIN 用于精确域名；需要覆盖根域名及其子域名时再考虑 DOMAIN-SUFFIX，实际结果应通过一次新请求验证。
FINAL 为什么会导致后面的规则不生效？
FINAL 是兜底规则。若它或其他宽泛规则放在自定义规则前面，后面的具体规则可能没有匹配机会。
导入订阅后会自动添加分流规则吗？
不一定。订阅主要更新服务器条目，分流规则通常由当前配置文件或规则文件决定，还要检查配置是否选中及 Global Routing 是否为 Config。
当前版本看不到命中规则怎么办？
用同一设备、网络和目标，在 Config、Proxy、Direct 三种模式下做对照，记录目标域名、连接状态和访问结果；无法判断时恢复备份配置。
相关阅读
参考资料
- Apple App Store：Shadowrocket 应用说明与功能介绍
- Shadowrocket 使用教程：配置、规则与订阅操作路径（公开资料，官方身份未独立核实）（shadowrocket.gitbook.io）