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

本文速览

本文适合已在 Shadowrocket 中使用自己的订阅、准备检查本地配置文件的用户。先分清连接资料与 .conf 的职责，再读懂四类段名、规则顺序和改写格式，最后用一次只改一项的方式验证结果。示例只解释语法，不作为可直接替换现有环境的完整配置。

1. .conf 管什么：先区分配置文件与连接资料

Shadowrocket（小火箭）的 .conf 是文本配置文件，方括号中的段名决定后续内容由哪一类功能读取。[General] 常见的是参数赋值，[Rule] 是按顺序排列的规则，[Host] 是本地域名映射，[URL Rewrite] 则描述 URL 匹配与处理方式。不同段的语法不能互换。

Home 中已有的连接资料与 Config 中选中的配置文件不是同一件事。订阅更新通常用于同步连接条目；编辑本地 .conf 则用于调整请求处理行为。更新了订阅，不等于当前生效的规则文件也已更换；反过来，导入 .conf 也不等于已经具备可用的连接资料。

4 个段名

本文检查 General、Rule、Host、URL Rewrite

1 个兜底

FINAL 放在规则末尾处理未匹配请求

2 类资料

Home 连接条目与 Config 配置文件分别核对

开始编辑前，在 Config 确认当前选中的文件，并保留原文件副本。回到 Home 检查 Global Routing：验证 [Rule] 时使用 Config。Proxy 与 Direct 会改变全局分流方式，Scene 则还涉及场景设置；这些状态不能与 Config 下逐条匹配规则的测试结果混为一谈。

在 Config 中确认选中的文件，而不是仅确认文件已经导入。
打开该文件的编辑入口，核对段名使用半角方括号。
在 Home 确认已有连接条目，再将 Global Routing 设为 Config。
保存修改后，重新建立测试连接，避免沿用修改前的长连接。

2. [General]：读取全局参数，不在这里写分流规则

[General] 使用 键 = 值 的形式。参数的作用范围取决于各个键的定义，并不是“放在最上面就能覆盖所有段”。例如 DNS 参数涉及解析行为，绕过参数涉及部分流量是否进入处理流程，都不能用来代替 [Rule] 中的域名规则。

[General]
dns-server = system
skip-proxy = 127.0.0.1, localhost

这里的 dns-server = system 表示使用系统 DNS 设置，不是指定某台固定服务器。127.0.0.1 是本机回环地址；把它列入 skip-proxy 的目的与让某个公网网站走 DIRECT 不同。此片段只展示两种参数写法，不构成通用网络优化方案。

一行只写一个参数赋值，不把 DOMAIN-SUFFIX 规则粘到参数值后面。
列表分隔符使用半角逗号，避免中文逗号导致整项内容被错误读取。
修改 DNS 前记录原值；若新设置导致域名解析失败，先恢复原值再排查规则。
只保留来源明确、知道作用的参数，不用大量重复键尝试叠加效果。

Settings → On Demand 管理的是按条件建立或断开连接的行为，不是 [General] 的同义入口。排查配置时若连接自动恢复，应同时检查 On Demand 的触发条件；不要把自动重连误认为 .conf 没有保存。

3. [Rule]：从上往下匹配，FINAL 负责最后兜底

[Rule] 中的规则按顺序判断，通常由类型、匹配值、策略组成。对于能够完成匹配判断的请求，先命中的规则决定策略；不是“更长的域名自动优先”，也不是“最后一行覆盖前面的所有规则”。具体例外应放在宽泛规则之前。

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

在上面的示例中，api.example.com 先匹配 DOMAIN，使用 PROXY；www.example.com 则可匹配后面的 DOMAIN-SUFFIX，使用 DIRECT。若把后缀规则移到精确域名规则前面，前者会先命中，原本为 API 设置的例外就失去作用。

关键字	匹配依据	检查重点
`DOMAIN`	完整域名	不写协议、端口和路径
`DOMAIN-SUFFIX`	域名及其子域名	更具体的例外放在它前面
`IP-CIDR`	IPv4 地址段	核对地址、掩码和解析条件
`GEOIP`	目标 IP 的地理归属数据库	不是按网站显示语言判断
`FINAL`	前面没有匹配的请求	放在最后，不填写域名

no-resolve 是 IP 规则的附加选项，表示不为这条 IP 规则额外发起域名解析。它不代表关闭整个应用的 DNS，也不代表一个域名请求必然会命中该网段。判断时需结合请求是否已经具备目标 IP。

结论：规则不生效，先核对模式和先命中的行

先将 Home → Global Routing 设为 Config，再检查目标规则前面有没有更宽的规则。确认请求匹配到了哪一行后，再决定是否修改策略；不要先改连接协议或 DNS。

PROXY 与 DIRECT 是策略含义，不是协议名称。PROXY 所使用的连接还需在现有环境中可用；把 FINAL 改成 PROXY 不会自动创建连接条目。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 等连接类型，与 DOMAIN-SUFFIX、IP-CIDR 等匹配类型分属不同层次。

4. [Host]：固定解析地址，不直接选择出站策略

[Host] 用于本地域名映射。下面将一个测试域名指向文档示例地址：左侧写域名，右侧写 IP 地址。这里的 192.0.2.10 属于文档示例地址范围，不应被理解成可访问的业务服务器。

[Host]
demo.example.test = 192.0.2.10

Host 的作用是影响可适用的解析结果，不是写下域名就自动直连。请求最终使用 DIRECT 还是 PROXY，仍需结合 Global Routing、规则以及实际出站路径判断；若域名交给远端解析，也不能假定本地映射一定决定最终目标地址。

Host 映射检查

段名: [Host]
左侧: demo.example.test
右侧: 192.0.2.10
处理对象: 域名到地址的本地映射

不在域名后附加路径，也不把端口拼到 IP 地址中。

Rule 策略检查

段名: [Rule]
匹配类型: DOMAIN
匹配值: demo.example.test
策略示例: DIRECT

选择 DIRECT 只决定直连姿态，不会替目标提供可用地址。

Host 映射也不会改变 HTTPS 证书需要匹配域名的要求。即便解析到了指定 IP，若目标服务器没有为该域名提供正确证书，仍可能出现证书错误。此时应检查服务器域名配置，而不是把证书错误归结为规则优先级。

5. [URL Rewrite]：正则、目标地址与状态码分别核对

[URL Rewrite] 常见的重定向写法是“匹配表达式、目标 URL、重定向状态码”，各项用空白分隔。它处理的是 URL，不是简单的域名匹配；正则表达式中的点号、括号与边界符号都有语法含义。

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

这条规则匹配以 http://example.com/ 开头的地址，把捕获到的后续部分放入目标地址的 $1。例如输入 http://example.com/docs?a=1 时，预期重定向目标为 https://example.com/docs?a=1。这是语法示例，不是要求访问外部测试页面。

^ 锚定开头，避免把不相关 URL 中的一段文字当成目标。
\. 匹配字面点号；直接写 . 会匹配任意单个字符。
(.*) 建立捕获组，$1 引用第一组内容。
302 表示临时重定向；调试时仍要留意浏览器已有缓存。

能否处理 HTTPS URL 取决于加密流量是否在合法授权范围内被解密，以及相关配置是否完整。仅添加 URL Rewrite 规则，不会自动获得 HTTPS 的路径或内容。本文使用 HTTP 输入展示格式，不要求添加 HTTPS 解密配置或信任证书。

6. 保存后怎样验证：按职责拆开测试

配置文件里的段落顺序，不等于请求处理的完整执行顺序。不能把四个段从上到下读成固定流水线。验证时应先确认选中文件与全局模式，再分别检查解析、规则命中和 URL 行为；每轮只变更一个因素。

备份原文件核对选中项修改单项重建连接检查结果

建立基线：保留一份能正常使用的配置，记录测试域名、网络类型以及 Global Routing 状态。
检查语法：核对方括号、等号、半角逗号与拼写，确认规则没有落到错误段落。
验证规则：在 Config 模式下新建目标请求，结合应用提供的连接记录检查目标、策略和命中情况；有记录时以记录为依据，不只凭页面打开速度判断。
验证映射：使用自己控制且有正确服务配置的域名，确认实际目标地址；不要用本文文档地址测试连通性。
验证改写：使用自己控制的 HTTP 测试入口，检查目标地址与跳转次数，避免旧缓存掩盖配置变化。
异常回退：恢复原配置并重建连接。若恢复后正常，再单独加入刚才修改的那一项。

远程配置与本地文件还要分开管理。若编辑的是会被远程更新覆盖的文件，应先保存独立副本，并确认实际选中的是副本。订阅更新与远程配置更新各自检查，不能仅凭 Home 的连接条目发生变化就判定本地规则已被替换。

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

把 FINAL 放第一行，后面的规则还会起作用吗？

FINAL 应放到规则末尾。它负责接住前面未匹配的请求，提前放置会让后续规则失去预期作用。将精确例外移到宽泛规则前，再把 FINAL 留在最后重新测试。

改了 Host，为什么网站还是没有直连？

Host 不选择出站策略。先检查 Home → Global Routing，再检查 [Rule] 中该域名命中的策略；同时核对解析是否由本地处理，避免把远端解析结果当成本地映射失效。

订阅刚更新，为什么 Config 里的规则没变？

连接订阅与配置文件不是同一类资料。回到 Config 检查选中文件及其来源；需要更新远程配置时操作对应文件，不要反复更新 Home 中的连接订阅。

保存后没变化，是不是要删除原文件？

先不要删除。确认修改的是已选中的文件，保存后重新建立连接，再用新请求测试。若连接被自动恢复，检查 Settings → On Demand 的条件，并保持前后测试条件一致。

完整排查记录至少包含：选中的配置文件、Global Routing 状态、修改的段名与具体行、测试目标以及观察到的结果。分享记录前移除订阅地址、令牌与连接凭据；通常保留相关规则和已脱敏的目标信息就足以讨论匹配逻辑。