小火箭配置文件结构详解:.conf 中 General、Rule、Host、URL Rewrite 段落作用

本文速览

Shadowrocket（小火箭）的 .conf 文件描述连接环境、规则匹配、静态域名映射与 URL 重写。本文适合已经拥有自己的连接配置、准备修改分流行为的用户：先识别四个段落，再用最小示例核对语法，最后在 Config 选中修改后的文件，并回到 Home 验证实际命中结果。连接参数与分流文件需要分别检查，保存文件不等于已经切换到该文件。

一、先区分文件与连接参数

Home、Config、Settings 管理不同层面的内容。Home 用于选择已有连接、查看连接状态与 Global Routing；Config 管理配置文件及其规则；Settings 提供应用设置，例如 Settings → On Demand 的按需连接条件。排查问题时，先确定要改变的是“何时连接”“连接到哪里”，还是“某个请求如何处理”。

常见的订阅更新主要维护连接条目，不能直接等同于更新当前 .conf 的 Rule 段落。配置文件的远程更新也可能覆盖本地改动，因此编辑前应保留本地副本。本文以用户已有自己的服务商与订阅为前提，只说明文件结构和验证方法。

段落	主要职责	不能代替的内容
`[General]`	设置 DNS、IPv6 等基础行为	具体域名的分流规则
`[Rule]`	按域名、IP 等条件选择策略	连接条目的认证参数
`[Host]`	为指定域名设置静态地址映射	服务器端的证书与站点配置
`[URL Rewrite]`	匹配 URL 并执行重定向等动作	将流量交给 PROXY 的分流规则

方括号中的段落名属于语法，需保留英文原文。常见写法按 General、Rule、Host、URL Rewrite 排列，便于阅读；这不是四个步骤依次执行的流水线。真正需要特别注意顺序的是 Rule 内部的规则，而不是把整份文件理解成“从第一段运行到最后一段”。

二、General：基础连接行为

General 常用“键 = 值”的形式。修改时保留半角标点，布尔值使用 true 或 false，不要把中文解释直接接到字段值后面。下面是用于理解字段的片段，不是要求所有用户覆盖原有设置的通用模板。

[General]
bypass-system = true
dns-server = system
ipv6 = false

General 字段

bypass-system: true：保留应用对系统相关流量的绕过处理。
dns-server: system：使用当前网络提供的系统 DNS。
ipv6: false：在配置层面关闭 IPv6 支持，不会替运营商修复网络。

先记录原值；一次只改一个字段，再对同一目标重复测试。

Rule 关键字

DOMAIN-SUFFIX: 按完整域名后缀及其子域名匹配。
IP-CIDR: 按 IPv4 地址网段匹配。
FINAL: 承接此前规则都未匹配的请求。

General 定义基础行为；Rule 决定请求采用的策略，二者不能互相替代。

dns-server = system 不保证当前网络的 DNS 一定可用；它只指定解析来源。出现域名无法访问而连接测试仍有响应的情况，应先检查解析结果，而不是只更换 Rule 的最终策略。连接测试能返回延迟，也不能证明目标网站的 DNS、TLS 与 HTTP 请求均正常。

ipv6 = false 也不是通用的网页修复开关。IPv4 与 IPv6 的可达性、代理出口能力和目标地址可能不同。若原文件已针对所在网络配置了 IPv6，应先保留原设置，在可复现的失败目标上逐项比较。

三、Rule：匹配条件与策略

Rule 的常见格式是“类型,匹配内容,策略”，各字段使用半角逗号分隔。规则通常自上而下匹配，命中后采用对应策略；FINAL 没有额外匹配内容，放在最后承接其余请求。下面的示例表示：指定域名走 PROXY，文档示例网段与 GEOIP 为 CN 的地址走 DIRECT，其余也走 DIRECT。

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

DOMAIN-SUFFIX,example.com,PROXY 匹配 example.com 及其子域名，不等于匹配所有包含这段字符的域名。
IP-CIDR 匹配地址网段。示例中的 192.0.2.0/24 是文档用途地址，不应当作可访问的业务网络。
no-resolve 表示不为了这一条 IP 规则额外发起域名解析；它并不是关闭整份配置的 DNS。
GEOIP,CN,DIRECT 根据目标 IP 的地理数据库分类匹配，不根据网页语言、域名后缀或用户当前位置判断。
FINAL,DIRECT 让未匹配流量直连；改成 FINAL,PROXY 会改变所有未匹配请求的去向。

更具体的例外通常放在较宽泛的规则前面。比如希望某个子域名走 DIRECT，而同一主域名的其他请求走 PROXY，应先写 DOMAIN,static.example.com,DIRECT，再写 DOMAIN-SUFFIX,example.com,PROXY。如果顺序反过来，子域名可能已经被上方的后缀规则接走。

四、Host：静态域名映射

Host 使用“域名 = 地址”的形式，适用于已知固定地址的映射需求。它与 Rule 分工不同：Host 回答“这个域名解析成什么地址”，Rule 回答“这个请求采用什么策略”。只修改其中一个，不应预期另一个自动同步改变。

[Host]
lab.example.com = 192.0.2.10

上面的域名与地址仅用于说明语法。192.0.2.10 属于文档示例地址，不是可用服务。实际填写时必须使用自己确认有效的目标地址，并确认目标服务器能够正确接收这个域名的请求。

静态映射不会随目标站点的地址迁移而自动更新，站点更换地址后可能出现持续连接失败。
多个域名共享一个 IP 并不代表可以互换；HTTPS 仍需要域名、证书与服务器站点配置相匹配。
网页通常还请求图片、脚本与 API 域名；只映射主页面域名，不代表所有资源都改用了同一个地址。
撤销测试映射后，重新建立相关连接，避免把旧连接仍在使用的结果误认为新配置无效。

遇到证书错误时，不要通过关闭校验来掩盖错误映射。应先删除新增 Host 行，恢复原有解析，再确认目标域名的证书与服务器地址。对于频繁变化的公共站点，长期硬编码地址通常会增加维护成本。

五、URL Rewrite：重写与分流分开看

URL Rewrite 根据 URL 的匹配表达式执行指定动作，并不接受 DOMAIN-SUFFIX 那样的 Rule 语法。以下片段用正则表达式匹配一个 HTTP 地址，再返回 302 重定向到 HTTPS 地址；它展示结构，不是可直接部署的业务规则。

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

这里的 ^ 限定从 URL 开头匹配，\. 表示字面上的句点，末尾的 302 是重定向状态码。这个简单示例将匹配请求重定向到固定地址，并未保留原请求的路径与查询参数；不要把它用于需要保留参数的登录、支付或 API 请求。

检查项目	Rule	URL Rewrite
匹配对象	域名、目标 IP 等条件	可被处理的请求 URL
示例结果	采用 DIRECT 或 PROXY	返回 302，转到另一 URL
常见错误	宽泛规则提前命中	正则过宽、路径丢失或循环重定向

HTTPS 的完整路径与查询参数位于加密请求内，普通分流并不能读取这些内容。需要检查 HTTPS 请求内容的重写场景涉及单独的 HTTPS 解密配置、证书信任与域名范围管理，不能靠添加一行 URL Rewrite 自动完成。仅验证分流时，无需为了这段示例额外配置 HTTPS 解密。

六、保存后在 Config 生效

编辑完成后，需要同时核对“文件保存成功”和“当前正在使用这个文件”。在列表中能看到文件，只说明它存在；Home 的 Global Routing 若仍是 Proxy 或 Direct，也不能用访问结果证明 Rule 已经按预期执行。以下流程适合对已有文件进行小范围修改。

保留原文件

进入 Config，记录当前选中的文件，并先保留一份本地副本。若文件来自远程更新，测试修改使用独立副本，避免下一次更新覆盖。
编辑副本

在 Config 打开副本的编辑界面，仅修改一个目标段落。检查方括号、半角逗号、等号及策略名称，保存后重新打开核对内容。
选中配置

回到 Config 文件列表，选中修改后的文件，确认选中标记对应副本，而不是原文件或名称相近的另一份远程文件。
切换姿态

进入 Home → Global Routing → Config，核对 Home 中当前选择的连接条目。必要时重新连接，让后续请求使用新配置。
验证请求

先用 Home → Connectivity Test 检查连接，再重新访问同一目标，在连接记录中核对域名、命中规则与策略；失败时恢复原文件复测。

Config

Proxy

让由应用处理且未被绕过的流量采用代理，而不是按 Rule 中的常规分流结果逐条选择。系统绕过等基础行为仍需单独考虑。

适合：临时对照连接可用性，区分代理故障与分流错误。

Direct

采用直连姿态。此时目标能打开，只能说明当前直连路径可用，不能证明 PROXY 条目或指定的代理规则正常。

适合：比较同一目标的直连结果，辅助定位故障范围。

如果当前使用 Scene，应先检查该 Scene 实际关联的配置与策略，不要仅凭文件名称推断生效范围。为了减少变量，首次核验本文规则时可先使用明确的 Config 姿态。On Demand 则管理自动连接条件，不负责决定某个域名命中哪条 Rule。

七、常见问题与回退检查

改了 FINAL，网站还是走原来的路径？

先检查 Home → Global Routing 是否为 Config，再核对 Config 中选中的文件。FINAL 只接收前面尚未匹配的请求；如果已有 DOMAIN-SUFFIX 或 GEOIP 命中，修改 FINAL 不会改变该请求。重新建立连接后再看记录。

保存时提示格式不正确，先查哪里？

优先检查段落名是否带完整方括号、Rule 是否使用半角逗号、General 与 Host 是否使用等号。将本次新增片段暂时移除，确认旧内容可保存，再逐行加回；不要一次混入多个来源的大段配置。

为什么更新后手写规则不见了？

先区分更新的是 Home 中的订阅条目，还是 Config 中的远程文件。远程文件更新可能替换文件正文。回到保留的本地副本恢复规则，再逐项合并需要的新内容，避免把连接条目更新误当作规则备份。

有延迟但网页打不开，要重写整个文件吗？

不需要立即重写。先撤销本次新增的 Host 与 URL Rewrite，再核对 DNS 解析、实际命中策略和目标连接结果。Connectivity Test 返回延迟只覆盖测试对应的链路，不能代替真实网页访问；可结合疑难手册继续排查。

一次可靠的修改记录至少包含原文件名称、修改字段、测试域名、Global Routing 姿态与实际结果。保留这五项，下一次出现异常时就能直接回退和复现，而不是同时改 DNS、规则和连接条目后失去判断依据。需要补充概念时，可查看术语手册；遇到连接故障时，可按连接问题排查继续检查。