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

先确认 .conf 的作用与生效入口

Shadowrocket（小火箭）的 .conf 是文本配置文件，使用方括号标记段名，每段只处理相应类别的设置。[General] 内通常是键值参数，[Rule] 内是按行排列的规则；不能把同一种行格式复制到所有段里。文件扩展名正确，也不代表其中每个参数都有效。

阅读前先到 Config 确认当前选中的配置，再到 Home → Global Routing 核对路由姿态。要验证文件中的分流规则，应使用 Config；处于 Proxy 或 Direct 时，不能拿观察到的出站结果直接判断 [Rule] 是否写对。使用 Scene 时，还应核对场景实际关联的设置。

连接资料与分流配置是两个层次。用户已有订阅的更新，主要涉及相应连接资料；不要据此认定本地 .conf 已同步修改。远程配置文件自身的更新也可能覆盖本地编辑，因此实验前应保留原文件，并在副本上逐项修改。

General：键值参数控制全局行为

[General] 使用 key = value 形式。先看键名，再看取值类型：有些接受布尔值，有些接受地址或列表。不要用中文标点替换等号和逗号，也不要把规则行放入此段。下面只展示两个独立设置，不代表任何网络都应采用这些取值。

[General]
dns-server = system
ipv6 = false

dns-server = system 表示使用系统 DNS；它不保证所有网络环境下解析都正常。ipv6 = false 是全局 IPv6 相关设置，不是域名分流规则，也不能代替对服务端 IPv6 连通性的检查。遇到问题时，应保留原值做对照，不要同时替换 DNS、调整 IPv6 和修改规则顺序。

Rule：先匹配先使用，FINAL 放在末尾

[Rule] 的核心不是规则数量，而是排列顺序。一般规则行由类型、匹配内容、策略组成；FINAL 不需要匹配内容。靠前的规则命中后，后面的规则不会再为同一请求重新选择策略。因此应把明确的例外放在宽泛条件之前。

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

示例中的 192.0.2.0/24 是文档用途地址段，不是可用服务地址。DIRECT 表示直连，PROXY 指向代理出站；如果使用自定义策略名称，必须确保当前配置确实定义了该名称。拼写相近不等于同一个策略，也不应把协议名直接当作已经存在的策略。

Host：改解析映射，不改请求地址

[Host] 用于指定域名的本地解析映射，常见形式是 域名 = IP。它处理的是“这个名字解析到哪个地址”，不是“流量经过哪条出站路径”。即使域名被映射到固定地址，请求仍需按实际生效的路由设置决定如何发送。

[Host]
lab.example.com = 192.0.2.10

• 键写域名：使用 lab.example.com，不要写成包含 https:// 或路径的完整 URL。
• 值写地址：此处的 192.0.2.10 仅作语法说明，实际使用必须换成自己有权使用且能够访问的地址。
• 不改变端口：若原请求访问 HTTPS 默认端口 443，Host 映射本身不会把它改为 8443。
• 不改变证书名称：HTTPS 仍需验证原域名对应的证书。映射到另一台服务器，不代表证书检查就能通过。

排查时要区分“域名解析不正确”和“目标地址无法连接”。若应用直接访问 IP，或者通过自己的解析机制获得地址，不能只凭一条 Host 映射就推断请求一定会使用它。修改后重新发起请求，必要时关闭原有连接再测试，避免把旧连接复用的结果误当成新配置的结果。

URL Rewrite：按正则匹配请求地址

[URL Rewrite] 处理可被应用识别的 HTTP 请求地址。以下示例使用正则表达式匹配一个明确的 HTTP URL，并以 302 返回重定向。三个部分之间用空白分隔：匹配表达式、目标地址、动作。它与 Rule 的逗号格式不同。

[URL Rewrite]
^http://example\.com/guide$ https://example.com/guide 302

1. ^ 限定字符串开头，避免匹配到地址中间的相似片段。
2. example\.com 中的反斜杠把点号限定为字面上的点；正则中的裸点号原本可以匹配其他字符。
3. /guide$ 限定路径结尾。带查询参数的 /guide?from=test 不符合这条完整表达式。
4. 302 表示重定向动作，客户端随后是否跟随重定向，需要结合发起请求的应用观察。

不要把这条示例理解成“任何 HTTPS 地址都能直接改写”。普通加密隧道只暴露连接所需的信息，并不天然提供完整的 HTTPS 路径。对 HTTPS 内容的匹配涉及 MITM、目标主机范围、证书信任及应用自身限制；本例从明文 HTTP 请求开始，不要求为它扩大解密范围。

把四段组合起来：一次只验证一种变化

这四段不是四个必须全部开启的功能。只需要域名分流时，可以先处理 General 与 Rule；没有固定解析需求就不必增加 Host，没有明确的地址改写需求就不必增加 URL Rewrite。较少的有效设置比大量来源不明的参数更便于判断问题。

1. 保留基线：在 Config 中保留原配置，记录 Home → Global Routing 当前的选择与原先可访问的测试目标。
2. 先改规则：仅增加一条具体域名规则，保存并选中修改后的配置，使用 Config 路由姿态测试。
3. 再测解析：确有固定地址需求时才加入 Host；记录目标域名、预期 IP 和端口，区分解析与连接失败。
4. 最后测改写：用明确的 HTTP 路径验证正则，不同时引入 HTTPS 解密设置，以免混合多个变量。
5. 保留观察记录：结合应用内可用的请求记录，核对域名、命中规则和实际策略；失败时只撤销刚才那一项，再重复同一请求。

Settings → On Demand 控制按需连接行为，不负责修复规则语法。若手动断开后又自动连接，应检查这里的触发设置；不要因此认定 .conf 没有保存。测试期间保持连接方式一致，才能比较同一规则修改前后的结果。

常见问题：保存成功为什么仍与预期不同