Shadowrocket 配置文件 .conf 结构详解:General、Rule、Host、URL Rewrite 各段作用

1. .conf 的段落结构与生效前提

Shadowrocket（小火箭）的 .conf 是按段组织的文本配置。方括号中的名称是段落标记，例如 [General]；标记之后、下一个段落之前的内容归属于该段。不同段采用不同语法：General 通常是键值，Rule 是逗号分隔的规则，Host 是名称与地址映射，URL Rewrite 则包含匹配表达式、替换目标及动作。

Home 负责连接条目的选择与连接状态，Config 负责规则配置文件，Settings 提供客户端设置。导入服务订阅并不等于已经启用某个 .conf；同样，选中 .conf 也不会自动获得可用的连接服务。本文只讨论配置结构，不涉及服务来源。

要验证 Rule 的分流结果，先在 Home 确认 Global Routing 使用 Config。Proxy 与 Direct 是不同的全局路由姿态，不能用来证明某条 Config 规则是否命中；使用 Scene 时，还要核对场景实际选择的路由配置。以下流程是排查顺序，不表示四个段在内部严格依次执行。

2. General：全局参数不是分流规则

[General] 存放全局参数，例如 DNS 相关设置。它的典型格式是 参数名 = 参数值，不能把 Rule 的逗号语法直接放进来。下面只展示使用系统 DNS 的写法，用于解释键值结构，不是要求所有网络环境采用同一 DNS 方案。

[General]
dns-server = system

dns-server 影响客户端的 DNS 处理，但不等于指定所有请求都走某个出站。DNS 解析回答“名称对应什么地址”，Rule 则决定“请求使用什么策略”，二者有关联，却不是同一个开关。应用缓存、加密 DNS 和连接是否携带域名信息，也会影响观察结果；不能仅凭网页能打开就判断 DNS 设置已经按预期生效。

• 先记录现有 dns-server 的完整值，再修改；不要在同一轮同时更换 DNS、规则与连接条目。
• 复制键名时保留英文拼写和半角符号，避免将 = 换成全角字符。
• 同一个键只保留一条明确设置，不依赖重复键的覆盖顺序来管理配置。
• 不认识的参数先保留原状；其他配置格式中的同名参数不一定能直接使用。

如果修改后出现大量域名解析失败，优先恢复刚才变动的 General 参数，再用同一网络、同一连接条目重新测试。此时先扩大 Rule 匹配范围通常不能修复 DNS 本身的问题，反而会增加排查变量。

3. Rule：首条命中决定策略，FINAL 放在末尾

[Rule] 中的规则按自上而下的顺序检查。常见结构是 类型,匹配条件,策略；FINAL 不需要匹配条件，用来处理尚未命中的请求。具体规则应放在宽泛规则之前，兜底规则放在末尾。

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

本例中的 example.com 与 192.0.2.0/24 是文档示例值。第一行让该域名及其子域名使用 PROXY；第二行让匹配示例地址段的请求使用 DIRECT。no-resolve 表示不为了这条 IP 规则主动触发域名解析，而不是关闭整个客户端的 DNS。

DOMAIN-SUFFIX,example.com,PROXY 不会匹配 notexample.com，也不是包含任意字符串就算命中。GEOIP,CN,DIRECT 则依赖目标 IP 和数据库分类，不是按网页语言、域名后缀或服务商注册地判断。若请求先命中上方域名规则，下方 GEOIP 就不再改变该请求的策略。

4. Host：名称映射不等于代理或重定向

[Host] 用于本地名称映射。下面把一个示例域名映射到文档保留地址，只展示语法。该地址不用于真实业务访问，不能把此示例作为网络可用性测试目标。

[Host]
lab.example.com = 192.0.2.10

Host 改变的是名称对应的地址，不是页面地址栏中的 URL，也不会自动把请求改成 DIRECT。请求采用什么策略，仍需结合当前路由姿态、Rule 和可用的域名或地址信息判断。若同时存在域名规则与地址规则，应通过新请求的记录确认结果，而不是假定映射后一定只按 IP 分流。

• 端口不由该行指定：访问 https://lab.example.com/ 默认使用 443；访问 http://lab.example.com/ 默认使用 80。Host 映射不把 443 改成其他端口。
• 证书仍需匹配名称：HTTPS 连接仍会校验证书中的域名。将名称指向另一台服务器，不会让不匹配的证书自动有效。
• 缓存会干扰验证：已有连接或应用内部缓存可能继续使用旧结果。保存后应关闭旧页面连接，再发起新请求。
• 并非所有解析都经过此映射：应用自行完成解析或直接使用 IP 时，可能无法观察到预期的 Host 效果。

因此，适合先在自己控制的测试域名上验证 Host，再决定是否保留。若只需要调整出站策略，应修改 Rule；若需要把某个网页地址换成另一个地址，则应检查 URL Rewrite，而不是不断增加 Host 条目。

5. URL Rewrite：先匹配 URL，再执行指定动作

[URL Rewrite] 处理的是可见且符合条件的 URL。下面是一个 HTTP 到 HTTPS 的 302 重定向示例：第一部分是正则表达式，第二部分是替换地址，最后的 302 是动作。此处故意使用明文 HTTP 作为输入，便于区分 URL 匹配与 HTTPS 加密内容的边界。

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302

1. ^ 限定从 URL 起始位置匹配，避免只在中间出现相同文本时触发。
2. example\.com 中的反斜杠让点号表示字面意义的点；未转义的 . 在正则表达式中含义更宽。
3. (.*) 捕获域名后斜杠之后的内容，$1 在替换目标中引用第一组捕获结果。
4. 302 表示返回重定向；应用是否跟随跳转，还取决于它自己的 HTTP 行为。

例如输入 http://example.com/docs?a=1，按这条规则构造的目标是 https://example.com/docs?a=1。这并不保证目标站点提供对应页面，也不保证重定向后的 HTTPS 连接成功。规则只改变请求处理方式，服务器的证书、路径和访问权限仍然需要独立满足。

URL Rewrite 也不是按域名分流的替代写法。需要让整个域名走某个策略时，优先使用 Rule；需要阻止某类请求时，应先明确是域名级阻止还是 URL 级处理，避免把不同层级的语法混在同一段中。

6. 修改后如何生效：保存、选中与新连接验证

“文件保存成功”和“正在使用这个文件”是两件事。尤其在 Config 中保留了多个本地文件或远程配置时，编辑副本后容易仍然运行旧配置。远程配置后续更新也可能覆盖本地修改，因此应先创建可识别的本地备份，再做实验。

1. 记录基线：记下 Home 当前选择的连接条目、Global Routing 姿态，以及 Config 当前选中的文件。
2. 备份并单项编辑：在 Config 保留原文件副本，只修改一个段中的一项；先用规则行前的 # 注释停用实验内容，不直接删除整段。
3. 保存并核对启用项：返回 Config，确认选中的是修改后的文件，不只是打开过它的编辑页面。
4. 使用 Config 验证：回到 Home，将 Global Routing 核对为 Config，并确认所选连接条目本身可用。
5. 发起新连接：关闭旧页面或旧会话后再访问；必要时手动断开并重新连接，使测试不依赖原有连接。
6. 记录结果并回退：核对目标域名、目标地址、命中规则和实际策略。若结果异常，恢复刚才那一项并重复同一测试。

还要区分两种“更新”：Home 中服务订阅的更新主要改变连接条目；Config 中远程配置的更新可能改变 General、Rule 等文本内容。不要把两者都称为“刷新配置”后就认为效果相同。更新前先确认操作对象，更新后检查实际内容与选中状态。

Settings → On Demand 管理的是自动连接条件，不是 Rule 的匹配条件。若手动断开后又自动连接，应先检查 On Demand 与系统 VPN 设置，不能据此推断 .conf 没有保存；反过来，自动连接成功也不证明新规则已经命中。

7. 常见问题：文件能导入，结果为什么仍不符合预期？

判断 .conf 是否正确，不能只看文件能否导入。段名与字段决定语法是否可读，当前选中项与路由姿态决定是否参与处理，新请求的实际记录才用于验证行为。按这个顺序检查，通常能把“写错了”“没启用”和“请求没有满足条件”区分开。