Shadowrocket配置文件.conf语法详解：从规则到MitM的进阶实战

先认识 .conf：按区段管理不同设置

Shadowrocket 的配置文件是纯文本，通常使用 .conf 扩展名。文件由方括号标记的区段组成，例如 [General]、[Rule] 和 [MITM]。区段名决定后续内容的用途；把一行放进错误的区段，即使字符看起来正确，也可能无法按预期生效。

编辑前先在 Config 中确认当前实际启用的配置，并保存一份未经修改的副本。若文件由用户自己的服务商提供，先确认哪些内容会在更新时被覆盖。订阅服务器资料与 .conf 配置文件承担的职责不同，不要把订阅地址粘贴到配置正文，也不要将整份原文件直接替换成本文的局部示例。

常见区段可以按用途理解：[General] 放通用行为与 DNS 等设置；[Proxy] 描述代理服务器；[Proxy Group] 组织策略组；[Rule] 决定流量匹配结果；[Host] 可定义主机映射；[URL Rewrite] 保存 URL 重写规则；[MITM] 声明需要进行 HTTPS 解密处理的主机名。不是每份文件都必须包含所有区段。

配置语法对空格、逗号、区段名称和行内容都有要求。编辑时保留英文区段名、规则关键字与策略标识，不要把 DOMAIN-SUFFIX、FINAL 或 MITM 翻译成中文。若需要导入自己的服务器或订阅，可先按入门指南完成基础设置，再回来单独维护配置规则。

规则优先级：具体规则在前，FINAL 兜底

在 [Rule] 中，规则通常按文件顺序匹配。一个请求命中前面的规则后，后面针对同一请求的规则通常不再决定其去向。因此，越具体、越希望优先处理的条件，越应放在宽泛条件之前；FINAL 应位于需要兜底的规则之后。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN-SUFFIX,example.com,DIRECT
RULE-SET,https://rules.example.net/custom.list,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

这段内容仅演示排列方式。example.com、example.net 都是示例域名，不提供实际规则服务。此处先用 DOMAIN 精确指定一个主机，再用 DOMAIN-SUFFIX 处理更宽的域名范围；远程 RULE-SET 与 GEOIP 的位置则应按实际分流意图安排。若把宽泛的域名规则或较早命中的规则放在精确规则之前，后者可能失去匹配机会。

• DOMAIN,api.example.com,PROXY：匹配指定主机名，交给 PROXY 策略。
• DOMAIN-SUFFIX,example.com,DIRECT：匹配该后缀及相应子域名，使用直连；不要误把它理解为只匹配一个完整主机名。
• RULE-SET,...,PROXY：按远程规则集中的匹配项执行后面的策略；文件地址、规则格式和策略名称必须与自己的配置相符。
• FINAL,PROXY：前面的规则都未命中时交给代理策略，不会自动判断某网站是否应该直连。

远程规则集依赖网络读取与内容解析。检查时先确认 URL 拼写、网络可达性以及规则集是否为预期的纯文本格式，再确认末尾策略名称在配置中确实存在。更新规则集成功不等于每条规则都符合预期；遇到异常时，在 Data 的连接记录中查找目标域名和处理结果，并与配置中的规则逐项对照。具体记录栏目以当前界面为准。

URL Rewrite：限定主机后再验证规则

[URL Rewrite] 用于按 URL 模式执行重定向或拒绝等处理。它与 [Rule] 的流量分流不是同一层设置：前者处理符合条件的 URL，后者选择连接路径。书写时要检查正则表达式中的转义符、目标地址和状态标记，并将匹配范围限制在明确需要测试的主机上。

[URL Rewrite]
^https?://www\.example\.com/old$ https://www.example.com/new 302
^https?://ads\.example\.com/ - reject

第一行示范将特定路径临时重定向到另一个地址；第二行示范对指定主机的匹配请求执行拒绝。示例只用于说明写法，不表示这些域名存在可用服务。修改前，先确认当前版本接受的 URL Rewrite 格式与标记；不同类型的规则不可仅凭示例猜测状态码或目标格式。

• 优先从精确主机和单一路径开始，不要一上来使用覆盖大量网站的通配表达式。
• 分别测试匹配路径与不匹配路径，确认规则不会误伤同站点的登录、支付或其他必需资源。
• 测试时重新发起请求，并在 Data 查看相关连接记录；已有网页连接可能继续复用旧结果。
• 如果没有变化，先确认当前生效的是编辑过的配置，再检查正则表达式、规则顺序和目标协议头。

URL Rewrite 也可能改变页面跳转结果，因此不要用它来隐藏配置问题。若一个站点因此无法正常加载，先移除刚添加的单条规则并重新加载页面。只有在“移除后恢复、加入后稳定复现”的对照结果明确时，才继续调整匹配条件。

MitM：理解证书信任边界

MitM 是 HTTPS 解密检查功能，启用后，Shadowrocket 可在用户授权并信任相关证书的前提下检查指定主机的加密流量。它与普通分流规则不同，也不是打开一个开关就能读取所有 HTTPS 内容。证书信任会扩大设备对该证书的信任范围，因此只应在理解用途、明确授权且有权检查的设备和主机上进行测试。

[MITM]
hostname = api.example.com

上面是主机名范围的配置示意。将 api.example.com 换成自己有权管理或测试的主机，并从小范围开始；不要使用过宽的通配符覆盖无关站点。Shadowrocket 的 MitM 证书与启用入口应在应用内按当前界面完成，证书安装和信任则按 iOS/iPadOS 系统提示操作。配置文件中的主机声明不能代替证书生成、安装或系统信任步骤。

1. 备份原配置

   在 Config 记录当前启用文件，并另存未修改副本。确认自己有权检查目标主机；不要在不知情或未经授权的设备上启用解密检查。

2. 限定主机名

   在 [MITM] 中只填写必要的测试主机。先使用单个明确主机，避免把整个域名空间或与测试无关的服务纳入范围。

3. 生成并信任证书

   按 Shadowrocket 当前的 MitM 设置流程生成证书，再按系统显示的步骤安装和启用信任。菜单名称可能随应用或系统版本变化，应以设备实际界面为准。

4. 验证后及时关闭

   仅访问自己的测试接口，检查请求是否按预期出现；完成后关闭不再需要的 MitM 设置，并在系统证书信任设置中撤销不再使用的证书信任。

证书私钥和配置文件都应视为敏感资料，不要通过公开渠道发送，也不要将含有证书材料的文件交给不可信对象。若某应用启用了证书固定或其他安全校验，MitM 可能无法解密其连接；这类限制不应通过关闭安全校验或扩大拦截范围来绕过。遇到证书警告时，先核对系统时间、证书状态、主机名范围及测试权限。

应用配置并逐项核验

编辑 .conf 后，不要立刻把所有变化归因于网络或服务器。先确认文件保存成功且当前选中的是该配置，再用一个明确目标发起新连接。建议每轮只改一个区段或一条规则；若同时更换策略、URL Rewrite 与 MitM，结果即使改变，也很难知道是哪项产生影响。

1. 保存副本

   保留原始文件和修改版，给文件名加入容易识别的说明。不要在未确认更新行为前覆盖服务商维护的原配置。

2. 检查区段

   核对方括号区段名、逗号分隔、策略名称及行尾内容。确认 FINAL 位于需要兜底的规则之后。

3. 启用配置

   进入 Config 选择修改后的文件，再回到 Home 核对 Global Routing 处于 Config。若选择 Proxy 或 Direct，配置中的分流规则不会按 Config 的方式决定同一请求路径。

4. 发起新请求

   访问一个能明确对应到单条规则的测试目标，记录时间、网络类型和预期策略。新开页面再测，减少复用旧连接造成的干扰。

5. 查看处理记录

   在 Data 检查目标域名和实际处理结果；URL Rewrite 与 MitM 的测试也要分别验证。一次成功不代表所有规则、所有主机都正确。

配置文件可以让规则更清晰、便于备份和复核，但不会自动验证每一项设置是否适合当前网络。遇到无法解析的配置、订阅更新冲突或服务器资料问题时，可查看服务器管理说明；排查时只提供脱敏后的相关片段，不要公开订阅链接、认证信息或证书私钥。