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

一、.conf 是什么，怎样确认正在使用的文件？

.conf 是配置文本，不等同于 Home 里的服务器列表。Shadowrocket（小火箭）可以通过配置文件管理规则与相关参数，但已有订阅更新成功，并不代表当前启用的规则文件也随之改变。先进入 Config 查看当前选中的配置，再到 Home → Global Routing 核对模式，才能判断文件里的规则是否参与分流。

1. 进入 Config，找到当前选中的文件，记录文件名；若准备编辑，先保留一份原文件副本。
2. 打开该文件的编辑界面，按方括号段落名识别内容，不要只搜索某个域名就直接改动。
3. 返回 Home → Global Routing，需要测试文件规则时选择 Config；Proxy 与 Direct 不按该文件的逐条规则选择路径。
4. 保存后再次确认启用的是修改后的文件，再用同一个目标复测；若连接仍沿用旧状态，断开后重新连接再观察。

段落名决定后续内容如何被解释。[General] 后通常是 key = value 形式的参数，[Rule] 后是逗号分隔的规则；直到遇到下一个段落名才切换语义。不要把一行 DOMAIN-SUFFIX 插进 [Host]，也不要把段落标题写成全角方括号。

[General]
dns-server = system

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

[Host]
lab.example.com = 192.0.2.10

二、[General] 与 [Host] 分别控制什么？

[General] 管理基础行为，[Host] 指定域名到地址的静态映射。遇到解析问题时，先在 Config 的当前文件里检查这两个段落。它们不是分流规则：把域名写进 [Host] 不代表请求一定走 DIRECT，把 DNS 参数改掉也不会自动把 Global Routing 切到 Config。

dns-server = system 表示使用系统 DNS，不是给所有请求指定出站策略。如果你现有文件使用其他 DNS 设置，应先记录原值，再比较修改前后的解析结果。域名解析得到地址后，请求仍可能受到规则、所选服务器以及远端解析行为等因素影响，不能只凭“DNS 有响应”判断网页一定可访问。

[Host] 不负责修改 HTTPS 的身份校验。例如把 lab.example.com 指向自己管理的测试地址后，浏览器仍使用原域名访问，服务端证书需要适用于该域名。即便地址映射正确，证书错误、目标端口未监听或服务未配置相应站点，也会导致失败；不要用忽略证书错误来掩盖映射问题。

• 只对单个域名异常：检查 [Host] 是否残留旧映射，再检查针对该域名的规则。
• 许多域名同时无法解析：检查 [General] 的 DNS 参数，并与修改前的文件对照。
• 域名能解析但连接超时：继续检查路径与服务端口；HTTPS 常见端口为 443，解析成功不代表该端口可达。

三、[Rule] 如何从上往下匹配？

[Rule] 按排列顺序检查，先命中的有效规则决定策略。进入 Home → Global Routing → Config 后，再检查当前文件中规则的先后位置。下面的流程只描述规则分流的判断过程，不表示 DNS、Host 与 URL Rewrite 在内部总是按同一条固定流水线执行。

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

精确例外必须先于宽泛匹配。在此示例中，api.example.com 先命中 DOMAIN，采用 DIRECT；其他匹配 example.com 后缀的请求采用 PROXY。若把前两条互换，精确域名也会先命中后缀规则。这里的 PROXY 表示代理策略，不会凭空建立服务器参数，仍需在 Home 确认可用的服务器选择。

no-resolve 不等于关闭全部 DNS。它约束的是相应 IP 规则的解析行为。对于尚未获得目标 IP 的域名请求，不应假设这条带有 no-resolve 的规则一定能匹配；对于直接以 IP 访问的请求，则可依据已有地址判断。排查时要区分访问域名与直接访问 IP 两种测试条件。

四、[URL Rewrite] 与域名分流有什么区别？

[URL Rewrite] 处理 URL 匹配与改写，不负责选择代理路径。需要把某个请求地址重定向到另一个地址时才检查这一段；只想让某个域名走 PROXY，应修改 [Rule]。下面是仅针对文档示例域名的 HTTP 重定向语法，不是供日常访问使用的规则。

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302

• ^ 与 $ 限定匹配范围；example\.com 中的反斜杠用于把点号当作普通字符匹配。
• (.*) 捕获后续内容，目标地址中的 $1 引用这一组捕获结果。
• 302 表示以临时重定向方式引导后续请求，不是代理服务器端口。
• 目标只匹配 http://，因此不会把已经使用 https:// 的目标再次匹配到同一条规则。

HTTPS 的完整路径并不会仅因连接经过 VPN 就自动可见。如果改写需要读取加密后的 URL 路径或内容，通常涉及 MITM 的相应设置、主机范围与证书信任；仅写入一条 URL Rewrite 并不够。本例使用 HTTP 入口解释语法，不要求你为阅读配置而扩大证书信任范围。

改写测试要检查跳转链，而不只是看最终页面能否打开。浏览器可能缓存旧重定向，应用也可能直接使用 HTTPS，导致看似“规则没生效”。先确认原始请求确实符合正则，再检查是否发生预期的 302。不要把“页面最后打开了”直接当成这条改写已经命中的证据。

五、修改文件后，怎样逐步验证？

一次只修改一个变量，才能把现象与配置对应起来。测试前记录当前文件、Global Routing 模式与所选服务器。若用户已有的订阅刚更新过服务器列表，也应先固定测试选择，避免把服务器变化误认为规则变化。

1. 建立基线：保留可工作的原文件，记录同一目标在修改前是正常打开、超时、解析失败还是证书错误。
2. 确认模式：在 Home → Global Routing 选择 Config。若使用 Scene，先核对场景条件实际选中的模式，不要直接假设正在走该文件规则。
3. 修改一处：例如只新增一条精确 DOMAIN 规则；保存并确认该文件仍被启用，再重新发起请求。
4. 排除旧连接：已有长连接可能继续使用原路径。结束原请求，必要时重新连接，再访问相同目标。
5. 对照回退：若异常在修改后出现，恢复原文件并重测。恢复后仍异常，就继续检查服务器、网络与目标服务，而不是反复添加更多规则。

Connectivity Test 只能作为连通性线索，不能替代业务请求验证。在 Home 执行测试后，仍要打开出问题的具体域名。测试成功说明测试目标在相应条件下可达，不代表所有域名的 DNS、Host 映射、规则和 URL Rewrite 都正确。

On Demand 解决连接触发，不解决单个请求的规则选择。若连接会随网络条件自动变化，可到 Settings → On Demand 检查触发设置；若开关已打开但域名走错路径，应回到 Global Routing 与 Config 检查。两类问题不要通过同一个开关反复尝试。

• 原文件正常、新文件异常：优先对比刚修改的段落与规则顺序。
• DIRECT 正常、PROXY 异常：检查所选服务器及其到目标的可达性，不要直接判定 DNS 配置错误。
• 仅指定域名异常：检查精确规则、静态映射与该域名的改写条件。
• 配置文件来自远程更新：保留本地副本，更新后检查手动修改是否被替换。

六、配置文件常见问题