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

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

按段拆解 Shadowrocket 的 .conf 配置文件:[General] 放全局参数,[Rule] 决定流量走向,[Host] 做本地映射,[URL Rewrite] 改写请求地址。每段都配有示例片段和常见写错的地方。

本文速览

.conf 是配置文本，不是服务器订阅的另一种名称。本文适合已经拥有自己的订阅、准备阅读或修改 Config 的用户；操作路径以 iPhone / iPad 界面为例，Mac、Windows、安卓、Linux 用户可按所在版本核对相应设置入口。读完可区分全局参数、分流规则、本地映射和请求改写，并按备份、单项修改、重新连接、核对记录的顺序验证。

1. 先分清 Config、服务器与 Global Routing

Shadowrocket（小火箭）的 Home 用于查看和选择已有服务器，Config 用于管理配置文件。服务器条目保存连接所需的地址、端口、协议与认证信息；本文的四个段落则描述解析、分流和改写行为。只导入包含这四段的 .conf，不会凭空产生可用服务器，也不会替代用户已有的订阅。

编辑之前先看 Home → Global Routing。Proxy、Direct、Config、Scene 不是四种服务器协议，而是不同的路由姿态。要验证本文的 [Rule]，先使用 Config；处于 Proxy 或 Direct 时，不能拿全局连接的结果证明某条规则已经命中。

姿态检查重点与本文的关系
Proxy全局代理路由不能据此判断 [Rule] 的分流结果。
Direct全局直连路由服务器可用与否不是此姿态下的直接验证目标。
Config当前启用的配置文件用于验证本文的规则顺序与策略。
Scene场景条件及其关联设置先核对场景实际采用的路由与配置，不把它等同于固定的 Config。
备份配置选择文件修改单项重新连接核对记录

这条流程表示编辑与验证顺序，不是网络处理管线。实际连接中的 DNS 解析、域名匹配与 IP 匹配可能互相影响；[URL Rewrite] 也不是所有流量都必经的一站。Settings → On Demand 管理按条件连接的行为，同样不能替代 Config 中的分流规则。

2. .conf 的分段语法与安全编辑顺序

段名独占一行，并用英文方括号括起。参数通常使用英文等号，规则字段通常使用英文逗号；不要把中文输入法的逗号、括号混入语法。下面是结构示例，省略未使用的段不等于配置损坏。它仅演示文本布局，不包含服务器凭据。

[General]
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

[Host]
lab.example.com = 192.0.2.10

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302
  1. 进入 Config，保留当前可工作的文件副本；若文件来自远程配置，同时记录原地址和本地修改内容。
  2. 打开待修改文件的编辑入口，确认当前编辑对象与准备启用的文件一致。不同平台的编辑按钮位置可能不同。
  3. 每次只改一类内容，例如只调整一条 DOMAIN-SUFFIX，不同时更换 DNS、增加映射和改写规则。
  4. 保存后确认该文件已启用，回到 Home 检查 Global Routing 为 Config，再重新建立连接并发起新的测试请求。

注释宜单独占一行，例如以 # 开头说明规则用途。不要把说明文字直接接到参数值后面，除非已经确认该位置支持行尾注释。文件扩展名也应保持为 .conf，避免文本编辑器额外追加 .txt。

3. [General]：全局参数与 DNS 解析

[General] 放置适用于配置的全局参数。下面的 dns-server = system 表示使用系统 DNS 设置，不是设置一个名为 system 的服务器。它不保证当前网络的解析结果一定可用；若连接失败，需要分清是解析失败、路由错误，还是目标服务没有响应。

[General]
dns-server = system

不要看到他人的参数列表就整段复制。IPv6、DNS 与绕过设置会改变不同层面的行为；例如修改 DNS 不能修正错误的服务器认证信息，关闭某类地址解析也不能解释所有超时。先保留现有可工作的参数，再围绕明确现象调整一项。

[General] 检查项

段名
[General]
参数
dns-server = system
验证对象
新请求的域名解析结果与错误记录

先确认解析是否成功，再判断连接走向。

[Rule] 检查项

段名
[Rule]
匹配项
DOMAIN-SUFFIX,example.com,PROXY
兜底项
FINAL,DIRECT

规则决定策略，不负责提供服务器认证信息。

检查时应发起新连接。已经建立的长连接可能继续使用原来的连接状态，浏览器和系统也可能保留 DNS 缓存。只刷新一次页面，既不能证明新的 DNS 设置生效，也不能据此断言保存失败。

4. [Rule]：从上到下匹配，FINAL 放在最后

[Rule] 按顺序匹配，前面的规则命中后，后面的规则通常不再参与该连接的策略选择。因此更具体的例外应放在宽泛规则前面。下面先让一个精确域名直连，再让同一域名后缀下的其他请求使用 PROXY。

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

PROXY 与 DIRECT 是策略关键字，不是协议名。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 描述的是服务器连接方式，不能随意填入规则末尾充当策略。若使用自定义策略名称，必须确认它确实在配置中有对应定义，拼写也完全一致。

结论：先验证一个精确域名，再扩大范围

在副本中为自己管理的测试域名添加一条 DOMAIN 规则，放在 FINAL 前，重新连接后核对新请求的匹配记录；确认结果正确，再改成 DOMAIN-SUFFIX。这样能把“语法不对”与“范围过宽”分开排查。

5. [Host]：域名映射不等于路由策略

[Host] 用于配置本地域名映射。左侧写域名，右侧写要使用的地址；不要把浏览器地址栏里的协议、端口和路径一起粘进去。映射改变的是目标地址解析，不会自动把该连接变成 DIRECT，也不会替目标站点修复证书。

[Host]
lab.example.com = 192.0.2.10
api.example.com = 192.0.2.20
写法或现象问题处理
https://lab.example.com/path把 URL 当成域名键。左侧只保留 lab.example.com。
192.0.2.10:443把端口附加到 IP 映射值。映射只填地址；HTTPS 的 443 端口属于连接目标信息。
映射后出现证书错误该地址上的服务未必持有对应域名的有效证书。核对服务端证书与域名，不通过忽略证书错误来掩盖映射问题。
仍然经过代理地址映射并未指定 DIRECT。回到 [Rule] 核对该域名或目标地址命中的策略。

例如，自己管理的测试域名指向内部服务器后，还需确保当前网络或所选代理能够到达该地址。若该服务只能从本地网络访问，应单独检查对应的直连规则。映射正确、地址可达、端口开放和证书有效是四项独立条件，不能只验证其中一项。

6. [URL Rewrite]：正则匹配与重定向

[URL Rewrite] 面向请求地址，不是服务器订阅更新工具。以下规则只匹配 example.com 的明文 HTTP 地址，将路径保留后返回到 HTTPS 地址的 302 重定向。它改变的是请求地址处理方式，不是在 [Rule] 中选择 PROXY 或 DIRECT。

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302
  1. ^ 限定从地址开头匹配，$ 限定到结尾，减少意外覆盖其他地址的机会。
  2. example\.com 中的点被转义，表示字面量的点；未转义的点在正则中通常表示任意单个字符。
  3. (.*) 捕获斜杠后的内容，替换地址中的 $1 引用这一组内容。
  4. 302 是重定向状态码，不是端口号；不要把它改成服务器使用的 443。

测试地址应是自己控制的服务，例如检查一条带路径和查询参数的 HTTP 请求，观察重定向的 Location 是否保留预期内容。浏览器的 HTTPS 自动升级或 HSTS 可能使请求根本没有以 HTTP 发出，因此“浏览器最终打开 HTTPS”不能单独证明该规则生效。

常见错误包括匹配范围过宽、替换目标再次命中原规则，以及把规则写进 [Rule] 段。若发生反复跳转，先停用新增改写，恢复原始请求，再收窄正则；不要同时增加多条重定向去补救同一个循环。

7. 保存后不生效：按文件、姿态、匹配条件排查

排查要先确认“正在使用哪份文件”，再确认“请求是否进入所测条件”。服务器订阅更新与远程配置更新不是同一件事：前者主要影响已有服务器条目，后者可能替换配置文本。对远程配置做过本地修改时，更新前应保留副本，避免把覆盖后的结果误认为编辑器没有保存。

保存了规则，为什么所有网站还是走同一种策略？

先到 Config 确认刚保存的文件已启用，再到 Home → Global Routing 选择 Config。随后检查 FINAL 是否位于末尾，关闭旧的测试连接后发起新请求，并查看实际匹配记录。

加了 [Host]，为什么网页仍打不开？

先把映射值与自己服务器的真实地址逐字核对，再检查该网络能否到达目标地址及端口。如果是 HTTPS 的 443 端口，还要核对站点证书；文中的 192.0.2.10 仅供语法演示，不能作为实际服务地址。

订阅更新后，为什么没有出现新规则？

回到 Home 核对服务器列表，再到 Config 查看规则文件。服务器订阅更新不等于配置文件更新；需要修改 [Rule] 时，应编辑正在启用的配置，而不是把规则粘贴进服务器地址字段。

改完配置后，断开连接又自动连上了？

到 Settings → On Demand 核对当前条件。进行手动对照测试时，可先暂停相关自动连接条件，完成验证后恢复原设置；On Demand 控制连接触发，不会替你调整 [Rule] 顺序。

若仍无法定位，恢复备份配置并保持同一服务器、同一网络、同一测试目标不变。备份可用而修改版失败时，再逐项加入差异；两份都失败时，优先检查服务器连接和目标服务，而不是继续扩大规则范围。向他人提供诊断材料前，应移除订阅地址中的令牌、认证信息与其他个人数据。

下载 Shadowrocket