Shadowrocket 配置文件 .conf 结构解读:General、Rule、Host、URL Rewrite 各管什么

本文速览

修改 .conf 时，先按职责分段，再确认 Config 中实际启用的文件。General 放通用参数，Rule 决定连接策略，Host 定义静态名称映射，URL Rewrite 处理符合条件的 URL。本文适合已有服务器资料、需要阅读或维护配置的用户；示例只演示语法，不包含可用服务器，也不替代现有配置的备份。

1. 先看配置结构：段名不是执行步骤

Shadowrocket（小火箭）的 .conf 是文本配置文件。方括号包围的名称用于划分配置段，例如 [General]；后续各行一直归属这一段，直到出现下一个段名。不同段采用不同语法：通用参数和静态映射通常使用等号，Rule 则以逗号分隔关键字、匹配条件与策略。

下面只覆盖本文的四段，不代表完整配置只能有这四段。阅读已有文件时，应保留不熟悉的其他段，不要为了对齐示例而删除。文件中各段的排列也不是网络请求的时间顺序；不能把“Host 写在 Rule 后面”理解成一定先分流、再进行名称解析。

4 段

本文覆盖 General、Rule、Host、URL Rewrite

3 个逗号

IP-CIDR 示例含 no-resolve 时的字段分隔数量

1 条 FINAL

本文 Rule 示例末尾的最终策略

[General]
dns-server = system

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

[Host]
lab.example.test = 192.0.2.10

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

example.com、example.test 与 192.0.2.0/24 在这里用于文档演示。其中静态映射指向的地址不是供实际访问的服务器。不要将整份示例直接替换到日常配置；更合适的做法是在副本中逐段验证格式。

2. General：通用参数不等于分流规则

[General] 保存通用设置。本文只使用一项易于核对的参数：dns-server = system。等号左侧是参数名，右侧是取值；system 表示使用系统 DNS。不要把它写进 [Rule]，也不要把规则使用的逗号分隔格式套到这里。

[General]
dns-server = system

[General]：声明后续内容属于通用配置段。
dns-server：指定此处要设置的 DNS 参数。
system：使用当前系统提供的 DNS，而不是在示例中指定固定解析器地址。

DNS 解决的是名称解析问题，不能替代服务器连接，也不能单独决定一条连接走 PROXY 还是 DIRECT。例如，域名已得到 IP 地址，但服务器连接仍可能失败；反过来，服务器延迟测试有结果，也不代表当前 DNS 一定能解析目标域名。排查时应分别记录解析结果与连接结果。

3. Rule：自上而下匹配，FINAL 放在末尾

[Rule] 是分流规则段。在 Home → Global Routing 选择 Config 后，应按当前启用配置的规则核对匹配结果。Proxy 是统一代理姿态，Direct 是统一直连姿态；它们不能用来验证你刚修改的逐条分流规则。Scene 则需要先核对所选场景及其条件，不应默认它等同于 Config。

匹配条件

DOMAIN-SUFFIX: example.com,PROXY
IP-CIDR: 192.0.2.0/24,DIRECT,no-resolve
GEOIP: CN,DIRECT

三行分别按域名后缀、IP 网段与 IP 地理归属条件匹配。

策略与兜底

PROXY: 交给代理策略处理，仍须有可用的代理出站。
DIRECT: 直接连接目标，不经代理服务器转发。
FINAL: 前面未匹配时使用指定策略，例如 FINAL,PROXY。

REJECT 用于拒绝匹配的连接，不应误写成直连策略。

DOMAIN-SUFFIX,example.com,PROXY：匹配 example.com 及其子域名，例如 www.example.com。它不表示对任意包含这段文字的域名做模糊匹配。
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve：匹配指定 IPv4 网段。no-resolve 表示不为了判断这一条 IP 规则而主动触发域名解析；它不是关闭整个应用的 DNS。
GEOIP,CN,DIRECT：依据 IP 地理归属数据匹配 CN。这里判断的是 IP 数据，不是域名后缀或服务器资料中的地区标签。
FINAL,PROXY：将前面没有匹配到的连接交给 PROXY。它只有策略字段，没有域名或网段条件。

当一个连接符合前面的规则时，后面的规则不再用于为它重新选择策略。因此，更具体的例外应放在覆盖范围较大的规则之前，FINAL 应放在末尾。已经被前一条规则匹配的连接，不会因为你在文件底部又增加一条例外而改变结果。

结论：先核对模式，再调整顺序

规则看起来正确却没有预期效果时，先确认 Home → Global Routing 为 Config，再检查当前文件与第一条可能命中的规则；不要先反复追加相同域名规则。

4. Host：静态名称映射不是策略选择

[Host] 将指定主机名映射到指定地址，适用于已经明确知道目标地址的场景。它回答“这个名称应对应哪个地址”，不回答“这次连接应走哪个出站”。即使地址来自 Host，连接仍需结合当前路由姿态和相关规则判断处理方式。

[Host]
lab.example.test = 192.0.2.10

lab.example.test 是完整主机名。这里没有声明对子域名使用通配映射。
= 分隔主机名与地址，不要改成 Rule 使用的逗号。
192.0.2.10 是文档示例地址。实际使用必须换成你已核实的目标地址。

静态地址可能随目标服务调整而失效，尤其是采用动态调度的服务。出现故障时，先在配置副本中移除这条映射并重新发起连接，对比是否恢复，而不是继续叠加更多 Host 项。

5. URL Rewrite：改写 URL，不负责选择代理

[URL Rewrite] 用于对符合条件的 URL 执行改写动作。它与 Rule 的区别在于：Rule 选择连接策略，URL Rewrite 处理请求 URL。不能把一条域名分流规则原样放入这一段，也不能用重写规则代替代理服务器参数。

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

字段	示例	含义
匹配表达式	`^http://example\.com/`	匹配以指定 HTTP 地址开头的 URL；点号前的反斜线用于匹配字面点号。
目标 URL	`https://example.com/`	本例使用固定目标地址，不演示路径捕获与回填。
动作	`302`	返回临时重定向，让客户端按目标 URL 发起后续请求。

这一行刻意只匹配明文 HTTP。若原始 URL 带有路径或查询参数，本例也不会自动保留它们，因为目标字段没有引用捕获组。需要保留路径时，应先确定正则捕获范围，再逐项验证结果，避免登录回调或查询参数在重定向后丢失。

不要把本例直接扩展成“所有 HTTPS 地址都能按路径重写”。HTTPS 内部 URL 的可见性涉及 MITM 等额外条件，并受应用行为和证书机制影响。本文不要求开启 MITM，也不涉及证书安装；只用于说明这一段的字段结构。

先用一个明确的测试 URL 检查是否匹配，不要从覆盖全部域名的表达式开始。
目标 URL 不应再次落入同一重定向条件，避免形成循环。
浏览器可能自动升级 HTTP 或使用缓存；未观察到重定向时，要先确认实际发出的请求地址。

6. 在 Config 生效：保存文件、选中文件、重建连接

编辑完成不等于当前连接已经使用新配置。Config 中可能同时存在多个本地文件和远程配置，必须核对实际选中的那一份。文件名称相似时，可先给测试副本使用便于识别的名称，保留原文件作为回退依据。

备份原文件修改副本保存并选中核对模式重新验证

进入 Config，记录当前启用的文件名，并保留原文件副本。打开待修改文件的编辑界面后，确认段名与准备调整的行。
一次只修改一个段中的少量内容。保存并返回 Config，确认编辑结果确实保留，再选中准备测试的配置。
回到 Home → Global Routing，选择 Config。若使用 Scene，先检查场景选择结果，再决定是否暂时改为 Config 做隔离验证。
确认 Home 中已有可用的服务器选择。PROXY 只是策略名称，不能凭空生成服务器地址、端口或认证资料。
在允许短暂中断网络时关闭再打开连接开关，随后重新发起目标请求。已有长连接可能继续复用，不能只观察修改前已经打开的页面。
结合请求记录核对目标域名、目标 IP 和策略结果。若行为不符，恢复原配置后重复同一测试，判断差异是否由本次修改引起。

还要区分服务器订阅与 .conf 配置：前者通常用于维护服务器资料，后者用于维护规则和通用设置。更新服务器订阅，不等于已经切换 Config 中启用的文件；重新获取远程配置，也可能覆盖你直接写在该文件中的修改。长期维护前，应明确哪一份是远程来源、哪一份是自己的本地副本。

结论：用可回退的单项变更验证配置

每次记录“改了哪一行、启用了哪个文件、测试了哪个请求”。只有同一请求在修改前后产生可解释的差异，才把这项变更保留到日常配置中。

7. 常见问题：按症状定位到配置段

改了 Rule，为什么所有网站还是走同一种方式？

先到 Home → Global Routing 核对是否为 Config，再到 Config 确认启用文件。如果仍然相同，检查 Rule 顶部是否有范围过大的规则，以及 FINAL 是否过早出现。用新发起的请求验证，不要只刷新原有长连接。

在 Host 写了地址，为什么 HTTPS 仍然报错？

检查该地址是否确实承载目标主机名的服务，并核对证书是否适用于这个域名。Host 仅改变名称映射。先在副本中移除该行作对照，不要通过放宽证书校验来掩盖地址填写错误。

URL Rewrite 保存成功，却没有看到跳转？

核对真实请求是否以示例中的 HTTP 地址开头，再检查正则中的反斜线、空格分隔和末尾动作。若浏览器在发出请求前已经升级为 HTTPS，这条只匹配 HTTP 的规则就不符合条件。

更新后手动修改的规则不见了，应该检查哪里？

先在 Config 确认当前选中的文件，再检查是否重新获取了远程配置。对照事先保留的本地副本，只迁移确认需要的改动。不要把服务器订阅更新与配置文件更新视为同一个操作。

继续调整前，可对照规则参考核对关键字，或在设置说明中区分路由姿态与其他功能。Settings → On Demand 管理按需连接条件，它不替代 Config 文件选择，也不改变 Rule 每一行的书写格式。