2026-08-21 · 进阶配置 · 约 10 分钟

Shadowrocket 配置文件 .conf 怎么读:General、Rule、Host、URL Rewrite 分段详解

拆解 Shadowrocket .conf 配置文件的段落结构:[General] 管 DNS 与全局行为,[Rule] 写分流规则,[Host] 做本地映射,[URL Rewrite] 改写请求,附可直接对照的示例片段。

本文速览

本文适合已有连接配置、需要检查分流或维护 .conf 的用户。先区分 Home 的连接条目与 Config 的配置文件，再分别核对 General、Rule、Host 和 URL Rewrite；读完可判断一行设置属于哪个段落、为什么没有按预期生效，以及怎样在保留原配置的前提下逐项验证。

一、先区分 .conf、连接条目与当前运行状态

Shadowrocket（小火箭）的 .conf 用来组织配置行为，不等同于连接账号。Home 中已有的连接条目保存服务器地址、端口及认证等信息；Config 中的文件负责 DNS、规则、本地映射与请求改写等设置。仅拿到一段 Rule，不会自动得到可用的连接服务。

阅读前先确认正在使用哪份文件，以及 Home → Global Routing 的当前选择。选择 Config 时，才适合核对本文的 Rule 分流；Proxy 与 Direct 是不同的全局处理姿态，不能用它们的结果直接证明某条分流规则正确。Scene 用于场景化选择，排错时还要核对对应场景的设置，不能把它视为另一份固定规则。

4 个段落
本文核对 General、Rule、Host、URL Rewrite
3 个入口
Home 看连接，Config 看文件，Settings 看功能设置
1 项变更
每次只改一个设置，再重复相同请求

方括号声明分段，后面的行属于该段，直到下一个段名出现。General 常见写法是键值对，Rule 则通常按逗号分隔字段；不要把这两种格式互换。以下流程是人工排查顺序，不表示所有网络请求都严格按四个段落的书写顺序执行。

备份原文件 核对活动配置 修改单项设置 重建测试请求 检查匹配结果

二、General：先看 DNS，再看其他全局行为

[General] 中的键名决定全局选项的含义，不能只看等号右侧的值。排查域名打不开时，可以先找到 dns-server，再区分“域名解析失败”与“解析成功但连接失败”。前者需要核对解析路径，后者还可能涉及路由、目标端口或已有连接条目的认证设置。

[General]
dns-server = system

这里的 system 表示使用系统提供的 DNS 设置，不是名为 system 的服务器地址，也不代表请求必然直连。实际解析结果还会受当前网络、缓存及其他 DNS 相关选项影响。若原文件还有额外 DNS 设置，应保留上下文阅读，不要仅凭这一行判断整个解析过程。

  1. 在 Config 中打开当前使用的文件，记录 dns-server 原值，并保留可恢复副本。
  2. 使用同一个测试域名重现问题，记录当前网络为 Wi-Fi 还是蜂窝网络。
  3. 只调整一项 DNS 设置，保存并确认仍在使用修改后的文件，再重新建立请求。
  4. 若仍失败，分别查看是否得到目标 IP、是否命中预期 Rule，以及是否成功建立目标连接。

三、Rule：按匹配范围排列，最后保留 FINAL

[Rule] 负责把请求匹配到策略。规则通常自上而下判断，先匹配到的有效规则决定处理方式，所以具体规则应放在宽泛规则之前。下面是阅读用片段，其中 example.com 是示例域名，PROXY 依赖用户已有的有效连接设置，不构成可直接使用的完整配置。

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

域名与网段匹配

DOMAIN-SUFFIX
example.com,PROXY
IP-CIDR
192.168.0.0/16,DIRECT,no-resolve
no-resolve
不为了本条 IP 规则主动触发域名解析

先区分域名条件与 IP 条件，再判断规则是否可能命中。

区域与兜底匹配

GEOIP
CN,DIRECT
FINAL
PROXY
Global Routing
测试本文规则时选择 Config

区域判断依赖 IP 数据，FINAL 处理前面未匹配的请求。

DOMAIN-SUFFIX,example.com,PROXY 可匹配 example.com 及其子域名，例如 www.example.com，但不是对任意字符串做包含判断。若目标域名应使用特定策略，把这条规则放在 GEOIP 等较宽泛的判断之前，避免请求先被其他规则接走。

IP-CIDR 按地址段匹配；示例中的 192.168.0.0/16 表示对应私有地址范围。no-resolve 的作用局限于该条匹配的解析行为，不是关闭整个应用的 DNS。GEOIP,CN,DIRECT 则根据目标 IP 的区域数据判断，不能当成“所有中文网站直连”。

结论：规则无效时先检查 FINAL 的位置

先把 FINAL 保留在规则末尾，再确认目标规则位于它之前，并检查 Global Routing 是否为 Config；这三项核对完成后，再改写匹配条件，避免把运行姿态问题误判为语法问题。

四、Host：改变名称解析，不替代连接策略

[Host] 用于显式指定域名映射。它回答“这个名称对应哪个地址”，而 Rule 回答“这个请求采用什么策略”，两者不能互相替代。添加映射不会自动创建 DIRECT 规则，也不会自动提供服务端程序、可达路由或有效证书。

[Host]
demo.example.com = 192.0.2.10

这里的 192.0.2.10 是文档示例地址，不是可用的测试服务。实际操作时，只对用户有权管理或已明确获知地址的目标设置映射。不要为了让网页“看起来能打开”而随意固定公共站点的 IP，地址变动与分布式部署都可能使固定映射失效。

五、URL Rewrite：先限定匹配范围，再验证重定向

[URL Rewrite] 用于按模式匹配请求 URL 并执行对应动作，不负责给域名分配 IP。下面以 HTTP 的临时重定向说明“匹配表达式、替换目标、动作”三个部分；这是语法阅读示例，不要求将其加入日常使用的配置。

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

表达式开头的 ^ 与结尾的 $ 限定整个匹配范围，\. 表示域名里的字面句点。这条示例仅匹配 http://example.com/old，不会自动覆盖 HTTPS、其他子域名或带查询参数的地址。末尾 302 表示临时重定向，客户端随后是否继续访问取决于请求方的处理方式。

  1. 先写出一个应命中的完整 URL，再写一个不应命中的 URL，例如 http://example.com/older。
  2. 把规则限定在明确的域名与路径，避免使用范围过大的表达式影响登录、支付或接口请求。
  3. 检查替换目标是否再次满足原表达式；若满足，可能产生循环重定向。
  4. 验证时观察重定向状态与目标地址，而不只是看页面是否最终显示。

六、导入与更新：保留连接来源和文件来源的区别

更新连接订阅与更新 .conf 是两件事。本文以用户已有自己的服务商与订阅为前提：订阅可维护 Home 中的连接条目，配置文件则维护 Config 中的规则和其他行为。订阅更新成功，不代表已经换用了新的 Rule；远程配置更新，也可能覆盖此前直接在文件内做的本地修改。

  1. 导入前：在 Home 记录当前选中的条目，在 Config 保留现有文件副本，并记录 Home → Global Routing 的选择。
  2. 核对内容：先检查文本是否确实包含 [General]、[Rule] 等配置段落，不要仅凭文件扩展名判断。
  3. 使用文件：在 Config 中确认导入后的文件已被选中使用；仅保存文件而未切换活动配置，测试的仍可能是旧规则。
  4. 更新之后：检查自定义 Rule、Host 与 URL Rewrite 是否仍保留，再对同一组目标重新发起请求。

自动连接行为还要单独检查 Settings → On Demand。On Demand 决定特定条件下是否触发连接，不替代 Rule 的目标匹配；若手动断开后又恢复连接，应先核对触发条件，而不是反复删除 FINAL。为隔离变量，可先记录原设置，临时停用按需触发，再进行手动连接测试，完成后恢复。

分享配置前应检查所有行，而不只是 Rule。订阅地址中的 token、连接认证信息，以及证书私钥都不应出现在公开片段中。本站不提供、不销售、不推荐节点或订阅；文中的域名、地址与规则只用于说明格式和排查方法。

七、常见问题：按现象定位到对应段落

为什么修改了 Rule，访问方式还是没变？

先到 Config 确认使用的是刚修改的文件，再到 Home → Global Routing 确认选择 Config。随后检查是否有更靠前的规则已经命中，并关闭旧连接后重新发起请求；已建立的连接不会仅因编辑了规则就必然重新匹配。

加了 Host，为什么 HTTPS 反而报错？

先检查映射的 IP 是否正确，以及该服务器是否提供原域名对应的 HTTPS 服务。Host 只改变名称映射，不会修改证书。恢复原映射并重建请求进行对照，不要用忽略证书错误代替定位原因。

远程配置更新后，自定义规则去哪了？

先比较更新后的文件与备份，确认本地修改是否被远程内容覆盖。把需要维护的规则保存在独立副本中，再核对顺序与策略后使用；不要在没有备份时反复更新同一份手工修改过的远程文件。

是不是把四个段落复制进去就能连接？

不是。本文片段没有提供服务器地址、账号与认证参数，也没有建立可用服务。先使用用户已有且有效的连接配置，再测试分流；如果目标无法连接，应分别检查 DNS、连接条目与规则，不能只靠增加段落解决。

最终验收应固定测试对象和网络条件：同一域名、同一请求路径、同一 Wi-Fi 或蜂窝环境，每次只改一项。能说明“使用哪份配置、命中哪条规则、解析到什么地址、连接在哪一步失败”，才便于继续定位，而不是用反复导入整份文件代替检查。

App Store 正版核对