Shadowrocket 配置文件 .conf 结构:[General]、[Rule]、[Host]、[URL Rewrite] 逐段读懂

本文速览

适合已经在 Shadowrocket（小火箭）中配置好自有连接服务、准备阅读或修改 .conf 的用户。先辨认四个配置段的职责，再逐项检查参数、规则顺序、域名映射与地址改写，最后在 Config 中选用文件并验证结果。文中的 example.com 与测试地址只用于解释语法，不是可用的连接服务。

一、先分清 .conf、连接信息与运行姿态

.conf 是文本配置文件，方括号中的名称是段标题，不是文件夹。一个段从标题开始，到下一个段标题之前结束；空行主要用于阅读。把规则写到错误的段内，即使每个英文单词都拼对，也不等于应用会按规则解析。

Home 管理用户已有的连接条目，Config 管理配置文件，Settings 管理应用设置。订阅导入的连接信息与当前选用的 .conf 不能简单画等号：更新连接列表，不代表已经切换配置文件；保存配置文件，也不代表 Global Routing 已改为 Config。

4 个段

本文拆解 General、Rule、Host、URL Rewrite

2 处确认

Config 当前文件与 Home → Global Routing

1 条命中

Rule 按顺序采用首条匹配规则

Global Routing 中的 Config 表示按当前配置分流；Proxy 与 Direct 用于整体改变路由处理方式；Scene 用于场景化选择。排查本文的 Rule 示例时，先明确选择 Config，避免把姿态差异误认为文件没有保存。

二、[General]：全局参数使用键值语法

[General] 内通常使用 键 = 值，与 Rule 的逗号分隔语法不同。这里的参数决定全局处理方式，例如 DNS 服务器配置。不要把一整段网络参数当成通用优化清单直接覆盖：当前网络、已有 DNS 设置与规则对解析的需求，都可能影响结果。

[General]
dns-server = system

这个片段仅演示使用系统 DNS 的写法，并不保证适合所有网络。DNS 解析成功与连接成功是两个阶段：拿到目标地址之后，仍需经过路由选择、连接建立与应用层交互。网页打不开时，只替换 DNS 而不检查后续阶段，容易掩盖真正的问题。

General 阅读方式

段标题: [General]
参数键: dns-server
示例值: system

先确认参数含义，再修改等号右侧的值。

Rule 阅读方式

段标题: [Rule]
匹配条件: DOMAIN,example.com
处理策略: PROXY

规则依次写类型、匹配值与策略，不使用等号。

检查文本时同时留意标点：段标题使用半角方括号，参数使用半角等号，规则使用半角逗号。中文逗号、全角空格或从富文本复制来的引号，可能让肉眼相似的内容变成不同字符串。

三、[Rule]：先写具体条件，最后设置 FINAL

[Rule] 决定流量采用哪种策略。规则从上向下匹配，首条命中后就采用该条策略，不会继续寻找更“精确”的后续规则。因此，顺序是配置的一部分；把 FINAL 放在前面，会使它后面的规则失去兜底之前的匹配机会。

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

关键字	本例匹配对象	结果与注意事项
`DOMAIN`	`api.example.com` 完整域名	先命中 DIRECT，不再采用下一条 PROXY。
`DOMAIN-SUFFIX`	`example.com` 及其子域名	其余匹配域名使用 PROXY。
`IP-CIDR`	`192.0.2.0/24` 地址段	使用 DIRECT；此地址段专用于文档示例。
`GEOIP`	地址数据库归类为 CN 的目标 IP	按 IP 归类，不按网页语言或域名后缀判断。
`FINAL`	前面均未命中的流量	本例选择 DIRECT 兜底。

no-resolve 表示不为命中这条 IP 规则而主动进行域名解析，并不是关闭整个应用的 DNS。若请求本身已有目标 IP，仍可按地址范围判断。示例中的 GEOIP 没有附加该选项，阅读时不要把一条规则的选项扩展理解成整个 Rule 段的设置。

PROXY 是策略，不会自动生成服务器信息。它需要用户已有的可用连接条目；DIRECT 表示直接连接，也不保证当前网络一定能访问目标。验证时应同时检查命中策略与实际连接结果。

四、[Host]：指定解析地址，不指定代理策略

[Host] 用于本地域名映射。它回答“这个名字对应哪个地址”，而不是“这个请求走哪条线路”。下面把一个示例域名映射到文档测试地址；该地址不是提供网页服务的公共服务器，不能用访问失败来判断语法是否有效。

[Host]
lab.example.com = 192.0.2.10

映射的是域名到地址，不是把整个 URL 放在等号左边；不要写成带有 https:// 或路径的形式。
Host 不负责端口转换。访问 https://lab.example.com/ 时，常规 HTTPS 默认端口仍为 443；常规 HTTP 默认端口为 80。
HTTPS 仍需验证证书。把域名指向另一台服务器，不会让那台服务器的证书自动匹配原域名。
映射后仍需结合 Rule 判断路由。要让该域名采用 DIRECT，可在 Rule 中明确写 DOMAIN,lab.example.com,DIRECT，并放在可能覆盖它的宽泛规则之前。

应用自身的解析缓存、复用中的连接，以及应用使用自有加密 DNS 的情况，都可能使一次测试不体现预期变化。改动后先关闭旧页面，再重新发起请求；必要时重新建立 Shadowrocket 连接。不要连续追加多个 Host 项来弥补尚未查明的缓存问题。

五、[URL Rewrite]：改变请求地址，不代替 Rule

[URL Rewrite] 通过正则表达式匹配 URL，再按动作处理。以下演示把示例域名的 HTTP 请求重定向到 HTTPS，末尾的 302 是重定向状态码，不是端口号，也不是代理策略名称。

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

^ 把匹配限制在 URL 开头；\. 表示域名中的实际句点，避免把任意字符当成句点。
(.*) 捕获斜杠后的内容，目标地址中的 $1 引用第一组捕获结果。
按此表达式，http://example.com/docs 对应的重定向目标是 https://example.com/docs。
重定向后产生的新请求仍需按路由配置处理。把地址改成 HTTPS，不等于把策略改成 PROXY。

浏览器可能因 HSTS 或已缓存的重定向直接使用 HTTPS，导致示例 HTTP 规则没有匹配机会。测试时应区分“客户端没有发出 HTTP 请求”与“改写表达式错误”，不要只凭地址栏最终显示 HTTPS 就判定规则已经执行。

六、在 Config 页保存、选用并验证

修改文件的最后一步不是退出编辑器，而是确认保存的是哪份文件、当前选用的是哪份文件，以及连接是否已重新加载。下面以已经存在的本地配置为起点；编辑时仅更改一个段，测试通过后再进行下一项。

保留原文件

进入 Config，先导出或复制待修改文件。记录它的文件名，避免把同名远程配置与本地副本混淆。
编辑文本

在 Config 点按目标文件，进入 Edit Plain Text。按对应段标题修改内容，检查半角标点，并保存编辑结果。
选用配置

回到 Config，点按这份文件并选择 Use Config，确认当前选用标记对应修改后的文件，而不是只停留在编辑页面。
确认姿态

进入 Home → Global Routing → Config。检查 Home 中选中的连接条目；若自动连接影响测试，再到 Settings → On Demand 核对触发设置。
重新验证

需要时先断开再重新连接，重新发起目标请求并检查请求记录。用原本可正常访问的目标作对照，不把 Connectivity Test 的单次结果当成全部规则验证。

分开验证：路由命中与内容处理

检查 Rule

保持 Global Routing 为 Config。
分别测试精确域名与同后缀的其他域名。
核对请求记录中的目标、命中规则与策略。

检查 Host 与改写

确认请求确实使用了预期解析方式。
检查目标地址、协议和重定向响应。
排除旧连接、缓存与 HSTS 的影响。

先确认文件已被加载，再确认请求经过对应处理；一次只调整一个变量。

七、配置修改后的常见问题

文件保存了，为什么仍然全走同一策略？

先检查 Home → Global Routing 是否选择 Config，再回 Config 确认当前文件。随后检查 Rule 顶部是否存在范围过大的规则，或 FINAL 是否提前出现。保存文本、选用文件、选择姿态是三个不同动作。

Host 已改成新地址，为什么 HTTPS 报错？

核对新服务器是否监听 443，以及它提供的证书是否覆盖原域名。Host 只改变解析结果，不改变 URL 中的主机名，也不会绕过证书验证。恢复原映射再测试，可判断问题是否由这次地址变更引起。

更新订阅后，Rule 会自动变成新的内容吗？

不能据此推断。Home 的连接订阅更新与 Config 的远程文件更新应分别检查。前者主要更新连接条目，后者才涉及配置文本；使用本地副本时，还要确认当前选中的仍是该副本。

只想让几个网站走 PROXY，需要改四个段吗？

通常只需在 Rule 中加入目标域名的 PROXY 规则，并按需求以 FINAL,DIRECT 兜底。General、Host 和 URL Rewrite 不必为了凑齐结构而添加。前提是已有可用连接条目，并在 Home → Global Routing 选择 Config。

配置文件的检查顺序可以固定为：先确认段标题和语法，再检查规则顺序，最后检查运行姿态与真实请求。需要继续定位连接问题时，可阅读故障排查；不确定关键字含义时，可对照术语手册。这样能把文本错误、路由选择和网络可达性分开处理。