Shadowrocket配置文件语法详解：规则与分流进阶实战

一、先弄清 .conf 配置文件的组成

Shadowrocket 的 Config 用于管理配置文件及其规则。它与 Subscribe 订阅不是同一类内容：订阅主要用于取得和更新服务器记录，配置文件则可以定义规则，以及与规则处理相关的设置。导入了服务器，不代表已经选择了预期的 Config；选择了 Config，也不代表其中每条规则都符合自己的分流需求。

.conf 通常按段落组织。方括号中的段名标记后续内容的用途，具体可识别的字段与语法可能随应用版本和配置来源而不同。阅读文件时先看段名，再看等号或逗号分隔的字段；不要把其他格式的配置整段粘贴进 Shadowrocket，也不要仅通过更改文件扩展名来转换格式。

不同配置文件可以省略不需要的段，也可能引用远程规则。遇到无法识别的字段时，先在副本中逐段检查，保留原始文件以便恢复。若配置由自己已有的服务商提供，涉及服务器地址、认证信息或令牌的行应按凭据保管，不要公开粘贴到论坛或在线检查工具。

二、规则如何匹配，顺序为什么重要

在 [Rule] 中，每条规则通常表达匹配类型、匹配内容与处理策略。对常见的规则列表，应按文件中的排列顺序检查：前面的规则先参与判断，匹配后便会影响该请求所采用的策略。若宽泛规则排在更具体的规则前面，后面的例外规则可能无法按预期生效。规则列表末尾常用 FINAL 提供兜底策略。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN,www.example.net,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

上面只展示规则行的阅读方式，域名与网段均为文档示例。实际策略名称必须能在当前配置中对应到可用策略；如果策略名写错，即使匹配条件正确，结果也可能不符合预期。

• DOMAIN-SUFFIX：按域名后缀匹配，例如示例中的 example.com 及其子域名。把针对单个主机的例外规则放在宽泛后缀规则之前，便于先处理例外。
• DOMAIN：用于指定域名匹配。检查时要分清单个域名与后缀匹配，避免为了一个主机扩大到整个域名范围。
• IP-CIDR：按 IP 网段匹配；no-resolve 是规则参数，不是策略名。示例中的 192.0.2.0/24 仅用于说明写法。
• GEOIP：按目标 IP 所属地区信息匹配，不是依据网页语言、域名文字或设备地区来判断。
• FINAL：作为前面规则均未命中时的兜底项。FINAL,PROXY 与 FINAL,DIRECT 会得到不同结果，应明确选择并核对。

三、在 Shadowrocket 中安全地修改并验证

实际界面会随版本和配置来源有所差异。以下步骤强调操作顺序：先确认当前生效文件，再复制备份，修改一项后验证一次。若文件是远程托管或由自己的服务商维护，应先确认本地编辑是否会被后续更新覆盖。

1. 确认当前配置

   打开 Config，找到正在使用的配置文件并核对名称。不要只凭 Home 中已选中服务器，就推断当前正在使用哪份规则配置。

2. 保存备份副本

   在 Config 中复制或导出原配置；若当前界面没有对应操作，先保留原始 .conf 文件。记录修改前的规则行与测试域名，确保可以恢复。

3. 只改一条规则

   进入当前配置的编辑界面，先定位 [Rule]，再调整一条测试规则的顺序或策略。检查逗号、域名拼写、CIDR 前缀和策略名称，不要顺手改动无关段落。

4. 保存并重新选择

   保存后回到 Config，确认编辑后的文件仍是当前使用的配置。若应用提示语法或导入错误，先停止继续修改，回到备份检查报错附近的段名和字段。

5. 查看连接日志

   回到 Home，在 Global Routing 中确认选择 Config，再开启连接并访问一个明确的测试域名。查看 Shadowrocket 的请求记录或日志，核对请求匹配的规则与处理策略；不同版本的日志入口和字段呈现可能不同。

如果日志显示请求没有命中预期规则，检查域名是否被实际请求、规则是否排在更早的匹配项之后，以及该请求是否使用了缓存连接。若规则命中但访问仍失败，再分别检查策略可用性、网络状态与服务器侧情况。一次测试只改变一个条件，并记录测试前后的结果。

四、远程 RULE-SET 与版本差异怎么处理

RULE-SET 用于引用远程规则集时，配置行通常需要提供规则集地址和目标策略。下面仅展示结构示意，URL 与策略均为占位内容，不应当作真实规则服务使用：

[Rule]
RULE-SET,https://rules.example.com/sample.list,PROXY
FINAL,DIRECT

远程规则集的具体格式、可接受的地址形式及更新行为，应以 Shadowrocket 当前版本对该配置的解析结果为准。规则集本身也必须包含应用能够识别的规则行；一个可以在浏览器打开的 URL，并不自动意味着其响应内容符合规则集格式。若远程资源返回错误页面、空内容或登录页面，客户端可能无法按预期加载规则。

• 检查地址：确认 URL 完整、可访问且没有复制时遗失查询参数。不要把带有私人令牌的地址公开分享。
• 检查响应内容：向规则维护方确认返回的是规则文本，而不是登录页面、说明网页或错误提示。
• 检查策略：确认 PROXY 等策略在当前配置中可用；策略未定义时，仅有规则集地址并不能决定流量如何处理。
• 检查更新结果：更新后重新查看配置识别结果和请求日志。若更新失败，先确认本地规则是否仍在生效，不要直接删除唯一可用的配置。

不同版本可能在配置导入、字段识别、远程内容更新和日志展示上有所变化。不能仅凭其他人的截图推断当前界面相同；也不要把某个版本中的未知字段解释为必然有效。出现行为差异时，保留原文件、记录 Shadowrocket 的实际提示，并逐项移除或调整最近新增的配置内容来缩小范围。

五、MitM 解密的适用范围与安全边界

MitM（中间人）解密不是普通分流规则的必要组成部分。它会改变特定域名 HTTPS 流量的处理方式，通常涉及在设备上安装并信任相应 CA 证书。证书一旦被信任，其签发能力就具有安全影响；配置不当可能暴露敏感请求内容，或造成应用连接异常。

• 只有在确有调试或检查需要、并且理解证书用途时，才考虑启用相关功能。
• 将作用域限制在自己控制或明确获准检查的域名，不要用宽泛匹配覆盖无关站点。
• 不要在日志、截图、公开配置或他人设备中暴露证书私钥、口令及敏感请求内容。
• 测试结束后检查 Shadowrocket 中的 MitM 配置，并在 iOS Settings → General → About → Certificate Trust Settings 核对相关证书信任状态；不再需要时按证书来源的说明撤销信任或移除证书。
• 遇到证书警告或应用连接失败时，不要通过扩大解密范围或忽略证书错误来掩盖问题。

MitM 的配置键、证书安装流程和界面名称可能随应用与系统版本变化。本文不提供可直接套用的证书参数；请以当前 Shadowrocket 界面提示和证书实际用途为准。普通域名分流测试优先使用 [Rule] 与日志验证，不需要为了确认策略命中而启用 HTTPS 解密。

六、常见问题