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

1. .conf 文件结构：段名决定每一行的解释方式

Shadowrocket（小火箭）的 .conf 是文本配置文件。方括号中的名称是配置段标题，例如 [General]。标题之后的内容属于该段，直到遇到下一个段标题。同样一行文字放在不同段中，不会自动得到相同含义；编辑前应先确认所在位置。

[General] 主要容纳全局参数，[Rule] 描述流量匹配与策略，[Host] 提供本地域名映射，[URL Rewrite] 描述 URL 改写。四者不是依次执行的四条分流规则。尤其不能把配置段在文件中的排列，理解为一次网络请求必然经过的处理顺序。

下面是一份用于阅读结构的示例。example.com 是示例域名；192.0.2.10 属于文档示例地址，不是实际服务地址。不要把这份内容直接替换进正在使用的配置。以 # 开头的独立注释行用于说明，不参与规则匹配。

[General]
dns-server = system

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

[Host]
lab.example.com = 192.0.2.10

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

复制配置时使用半角方括号、逗号和等号。不要把中文说明直接接在规则末尾。为了保留可核对的修改记录，可以在目标行前新增独立注释，说明修改目的，而不是同时重排所有段落。

2. General：全局参数与 DNS 入口

[General] 常用 键 = 值 的形式表达设置。示例中的 dns-server = system 表示使用系统提供的 DNS 服务器。它不是一条分流规则，也不表示所有请求都会采用 DIRECT。域名如何获得地址，与连接最终选择哪种策略，是需要分别检查的事情。

DNS 查询通常涉及 53 端口，但不能仅凭日志中的一个端口判断整个解析链路。加密 DNS 与普通 DNS 的传输方式不同；如果原配置已经包含明确的 DNS 设置，应先记录原值，再按需求修改，不要为排查一个域名而批量替换全部解析参数。

文件里的参数与 Settings 中的开关也不是同一种表达方式。例如 Settings → On Demand 处理连接触发条件，不负责把某个域名改成 DIRECT。排查期间应记录 On Demand 的原状态，避免手动断开后再次触发连接，却误以为刚才修改的配置没有保存。

3. Rule：匹配对象、顺序与 FINAL

[Rule] 中的规则按顺序检查，命中后使用该条指定的策略。因此，精确例外通常需要放在更宽的匹配条件之前。把一条例外规则追加到 FINAL 后面，不能指望它覆盖前面的兜底结果。

DIRECT 表示直连，PROXY 表示使用代理策略，REJECT 表示拒绝。PROXY 本身不包含服务器地址、凭据或连接服务。本文以用户已有自己的服务商与订阅为前提；使用示例前，仍需确认 Home 中已有可用的连接条目。

no-resolve 用于避免仅为匹配这条 IP 规则而主动进行域名解析。它不等于禁用所有 DNS，也不会使域名自动获得地址。GEOIP 则依赖 IP 数据库，不是根据网页语言、域名后缀或用户所在位置判断。

Global Routing 中的 Proxy、Direct、Config、Scene 是不同的路由姿态。Config 用于按配置规则分流；Scene 还需要核对对应场景的设置。记录当前姿态，是复现规则问题的必要步骤。

4. Host：本地域名映射不等于分流策略

[Host] 可以用 域名 = IP 地址 建立本地映射。例如下面一行把 lab.example.com 对应到文档示例地址。它解决的是域名与地址的对应关系，并没有同时指定这个请求使用 DIRECT 还是 PROXY。

[Host]
lab.example.com = 192.0.2.10

• 左侧填写域名，不填写 https://、路径或查询参数。
• 右侧的地址必须来自用户自己管理或获准使用的环境；示例地址不能用于实际连通性验证。
• 服务端口不在这行中表达。HTTPS 默认使用 443 端口，其他端口应由请求 URL 或应用连接设置指定。
• 访问 HTTPS 时仍会校验域名与证书。映射到另一个 IP 不会自动使证书匹配。

如果修改 Host 后仍连接到旧地址，先关闭原网页，再发起新请求。浏览器缓存、应用缓存与已建立的连接都可能影响观察结果。应在请求记录中核对目标域名和地址，而不是只根据页面有没有变化判断。

部分应用使用自己的解析方式，或者直接连接预置 IP，因此未必按预期使用这条映射。此时需要先确认应用实际请求的是域名还是 IP。不要通过不断添加更宽泛的 Rule 来补救一个尚未确认的解析问题。

5. URL Rewrite：按 URL 模式改写，而不是按域名分流

[URL Rewrite] 与 [Rule] 的字段结构不同。下面的示例包含匹配表达式、目标 URL 和 302。它描述 HTTP 重定向：匹配指定旧地址时，让客户端转向新地址。它不是 PROXY 策略，也不用于配置服务器连接参数。

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

1. ^ 限定字符串开头，避免把其他位置包含相似文本的 URL 一并匹配。
2. \. 表示域名中的字面句点；正则中的裸句点具有更宽的匹配含义。
3. /old$ 限定路径与结尾，因此带额外查询参数的 URL 不会被这条精确表达式匹配。
4. https://example.com/new 是重定向目标；后续访问仍需正常解析、分流与建立连接。
5. 302 表示临时重定向。测试时应核对重定向链，而不只查看地址栏最后显示的内容。

本例刻意匹配明文 HTTP URL。HTTPS 的路径和查询参数处于加密请求中，不能把这条示例直接理解为可以改写任意 HTTPS 页面。需要读取 HTTPS 请求内容的改写涉及额外的 MITM 条件与信任设置，不能仅通过添加一行 URL Rewrite 实现。本文不把启用这些条件作为入门编辑步骤。

为避免重定向循环，目标 URL 不应再次命中同一条规则。首次测试应选择单个、可控的地址，保留精确匹配边界；确认结果后再评估是否需要扩大范围。不要从匹配所有域名的正则开始。

6. Config 页导入与编辑：一次只验证一项变化

Home 主要用于连接与路由姿态，Config 用于管理配置文件，Settings 用于应用设置。已有连接条目或订阅，并不意味着某份 .conf 已经被选中；导入一份文件，也不等于它已经作为当前配置使用。完成编辑后，应回到 Config 核对选中状态。

1. 保留原件。在编辑前保存当前可用的配置副本，记录文件名、Global Routing 姿态以及本次要修改的具体行。
2. 准备输入。从自己持有的 .conf 文件导入，或使用自己信任的配置 URL。远程文本可能改变 DNS、分流和改写行为，导入前应阅读内容。
3. 打开 Config。通过添加入口选择对应的文件或 URL 导入方式。导入后核对文件名，并查看内容是否包含预期的段标题。
4. 进入编辑。使用该配置的操作入口打开文本编辑，按段修改一个参数或一条规则，然后保存。编辑入口的具体呈现以当前界面为准。
5. 确认选用。在 Config 中选中保存后的文件，再到 Home → Global Routing 核对 Config。测试前按需重新建立连接。
6. 复现请求。重新访问同一目标，检查请求记录中的匹配规则、策略和目标地址。失败时先恢复刚改动的那一项，再重复测试。

远程配置更新与连接条目订阅更新是两个不同的操作。前者可能替换 .conf 的内容，后者主要更新已有订阅中的连接条目。若把个性化修改直接写入会被远程更新覆盖的文件，下次更新后可能丢失。保留独立副本，并在更新前后比较关键段落。

判断配置是否有效，需要同时核对“保存的文件”“当前选中的文件”“Global Routing 姿态”和“新发起的请求”。只看到保存成功，不能证明请求已按新规则处理。

7. 配置编辑常见问题