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

一、先区分 .conf、订阅与当前连接

.conf 是文本配置文件，方括号中的名称表示配置段。每个配置段有自己的语法：[General] 常用键值对，[Rule] 使用逗号分隔的规则，[Host] 保存名称映射，[URL Rewrite] 使用匹配表达式、目标地址和动作。不能把某段的写法直接复制到另一段。

在 Home 中导入订阅，主要是取得可用的连接条目；在 Config 中选用配置，则是决定流量如何处理。两者有关联，但不是同一个操作。用户已有自己的服务商与订阅时，应从你的服务商处获取订阅链接，并确认该链接提供的是连接信息还是完整配置。不要仅凭链接后缀判断内容。

要检验 [Rule] 的分流行为，应在 Home → Global Routing 选择 Config。Proxy 与 Direct 不是验证该段规则的等价环境；Scene 则还要检查当前场景采用的设置。只保存文件而不核对当前姿态，常会产生“修改规则完全没有变化”的错觉。

二、General：先读全局参数，再判断 DNS

[General] 管理全局行为，包括 DNS 等设置。阅读这一段时，先识别等号左侧的键，再看右侧的取值。字段名、英文标点和布尔值都应保持原样；不要把中文解释写到取值里，也不要用全角逗号替换半角逗号。

[General]
dns-server = system

这里的 dns-server = system 表示使用系统 DNS。它不意味着每条连接都直接出站，也不等于给所有请求指定代理。DNS 解决“名称怎样解析”的问题，Rule 解决“连接采用哪种策略”的问题；实际解析位置还可能受到规则选项、代理协议和其他 DNS 设置影响。

遇到“连接条目可用，但域名打不开”时，先查看日志中是解析失败，还是已经获得 IP 后连接失败。前者才优先检查 DNS；后者还要检查命中的策略、目标端口及服务端状态。HTTPS 常用端口为 443，但服务商连接端口不一定也是 443，两者不能混为一谈。

三、Rule：逐条匹配，FINAL 放在末尾

[Rule] 中的规则按从上到下的顺序匹配，命中后使用对应策略，不会为了寻找“更具体”的条件继续往下比较。因而例外项应放在宽泛规则之前，FINAL 负责其余流量，应位于最后。

[Rule]
DOMAIN,blocked.example.com,REJECT
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 都是说明用的示例，不代表线路资源。第一条拒绝指定主机；第二条让 example.com 及其子域名直接连接。由于精确拒绝规则在前，访问 blocked.example.com 不会被后面的后缀规则放行。

四、Host：改变名称解析，不改变 URL

[Host] 用于本地名称映射。下面的例子把 lab.example.com 映射到文档专用地址 192.0.2.10。该地址不是可访问的测试服务，使用时应替换为自己有权管理、且确实可达的目标地址。

[Host]
lab.example.com = 192.0.2.10

• 不写协议与路径：左侧是主机名，不是 https://lab.example.com/path。
• 不把端口当作 IP：右侧的 IP 映射不负责将目标端口改成其他端口。
• 不代替 Rule：映射后的连接仍须遵循当前的路由与策略处理。
• 不消除证书检查：HTTPS 访问仍会核对原请求主机名对应的证书。

如果把域名指向某台服务器后出现证书错误，不能仅因 IP 可达就认定 Host 配置正确。该服务器还必须正确处理原主机名及 TLS。应用自行解析名称或使用特定连接方式时，也不能假设所有请求都会受到同样的本地映射影响，应以实际连接记录为准。

五、URL Rewrite：匹配请求地址，执行指定动作

[URL Rewrite] 处理的是 URL 匹配与改写，不是“把域名交给哪个连接”的分流表。下面用一个 HTTP 到 HTTPS 的重定向演示三部分结构：正则表达式、目标地址、动作码。

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

^ 和 $ 分别限制匹配的起点与终点，\. 表示字面意义的点，(.*) 捕获后续内容，目标中的 $1 引用第一组捕获结果。302 表示重定向动作；不要把此处的动作码误写成 Rule 的 PROXY。

排查时先确认请求原本就是 HTTP，再检查是否有旧的重定向缓存。若浏览器因 HSTS 直接使用 HTTPS，HTTP 规则可能根本没有匹配机会。修改 Rule 的顺序不能解决这种现象，因为两段处理的对象不同。对无法确认行为的改写，应先停用该条并恢复原始访问路径。

六、编辑后怎样生效：保存、选用与重建连接

配置文件存在于 Config 列表中，不代表它已经被选用；文本保存成功，也不代表原有长连接会重新建立。建议先复制当前可工作的配置作为本地备份，再执行下面的单变量验证。不同平台菜单呈现可能不同，以下按 Home、Config、Settings 的页面职责说明。

1. 确认对象：在 Config 中找到当前选用的文件，记录名称，再打开其编辑入口。不要误改另一个尚未选用的文件。
2. 一次修改一处：先改一条规则或一个键值，保留原段名和英文标点。检查是否存在重复的 FINAL，或将规则写到了错误段落。
3. 保存并选用：保存编辑内容，回到 Config 确认该文件仍为当前配置。若出现语法提示，先修正，不能继续把它当作有效配置测试。
4. 核对姿态：回到 Home → Global Routing，选择 Config，并检查当前连接条目可用。
5. 建立新连接：在允许短暂断网的情况下重新连接，再让测试应用重新发起请求。必要时关闭旧页面或重启测试应用，排除连接复用。
6. 核对结果：用同一目标重复请求，查看命中的规则、策略及错误类型。不能只用“网页好像快了”判断配置生效。

远程配置与本地编辑要分开管理。重新下载远程文件可能覆盖本地改动，而更新 Home 中的连接订阅也不等于更新 Config 中的规则。长期维护自定义规则时，应保存独立副本，并记录每次修改的字段和预期结果。订阅更新后，还要确认配置引用的策略名称仍然存在。

七、常见问题：按现象定位配置段

维护 .conf 的关键是分清职责：General 决定全局参数，Rule 决定策略，Host 提供名称映射，URL Rewrite 处理符合条件的请求地址。每次只修改一个环节，并保留能恢复的副本，才能把配置变化与连接结果对应起来。