2026-09-14 · 进阶配置 · 约 8 分钟

Shadowrocket 配置文件 .conf 结构详解：General、Rule、Host、URL Rewrite 各段写法

拆解 .conf 配置文件的各个段落，说明 General、Rule、Host、URL Rewrite 的作用与书写格式，附示例片段。

本文速览

Shadowrocket（小火箭）的 .conf 文件按段组织设置，不是把订阅地址写进去就能完成分流。本文适合已有自己的服务商与订阅、准备在 Config 中检查配置的用户。先分清各段职责，再看完整规则、域名映射与重定向示例，最后按单项修改、重新连接、核对请求记录的顺序验证。

1. .conf 的段名、键值与生效条件

配置文件是文本。方括号中的名称标识一个段，例如 [General]；下一段出现之前的内容都属于当前段。段名中的空格需要保留，[URL Rewrite] 不能随意改成另一个拼写。键值设置通常使用 键 = 值，规则则使用逗号分隔字段，两种写法不能混用。

Home 管理连接与服务器选择，Config 管理配置文件。导入或保存文本不等于已经启用它：应在 Config 确认当前选中的文件，再到 Home → Global Routing 选择 Config。Proxy 是全局代理姿态，Direct 是全局直连姿态；Scene 则按已设置的场景选择路由方式。检查规则顺序时先固定为 Config，避免场景切换影响判断。

保存配置 选中配置 启用 Config 重新连接 核对请求

下面只展示可独立阅读的基础结构。它将未匹配流量交给 DIRECT，适合观察文件是否能正常解析，不是适用于所有网络的成品方案。example.com 是文档示例域名，不代表本站提供的服务。

[General]
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,DIRECT
  • 使用普通文本编辑，标点采用英文半角字符；不要将说明文字直接拼在规则后面。
  • 一条规则占一行。需要备注时可另起一行，以 # 开头。
  • 先保留原文件副本，再编辑测试副本；不要同时改 DNS、规则和重写。
  • 实际文件可以有更多段，本文四段并不是全部能力清单。

2. General：配置基础行为，不承担规则排序

[General] 放置全局基础设置。以 dns-server = system 为例，它表示使用系统 DNS 设置；并不保证系统所选解析器在所有网络中都可达。将这一行改成另一种解析方式之前，先记录当前 Wi-Fi 或蜂窝网络、目标域名以及失败现象。

DNS 负责把域名解析成地址，Rule 负责选择流量策略。这两件事有关联，但不是同一个开关。解析失败时，添加 DOMAIN-SUFFIX 规则不会自动修好解析器；同样，DNS 返回了地址，也不表示目标端口或代理路径一定可用。

General 基础检查

段名
[General]
设置项
dns-server
示例值
system
书写形式
dns-server = system

先确认原有解析方式，再决定是否修改。

应用内生效检查

文件位置
Config
路由入口
Home → Global Routing
验证姿态
Config
自动连接入口
Settings → On Demand

On Demand 控制按条件连接，不代替 Rule 的匹配逻辑。

编辑文本时，不要凭名称猜测设置项。未确认支持的键可能被忽略或导致解析问题。需要扩展 General 时，以应用内配置编辑界面中对应项及其说明为依据，并保留修改前的值。On Demand 的自动连接行为也应单独核对，避免在排查时被自动重连打断。

3. Rule：从上到下匹配，FINAL 放在最后

[Rule] 中每一行描述匹配条件与执行策略。规则按排列顺序判断，命中后采用该条指定的策略。因此具体域名规则通常放在宽泛规则之前，FINAL 放在最后。若把兜底放在前面，后面的条件就失去预期的匹配机会。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY
关键字示例中的含义检查重点
DOMAIN-SUFFIX匹配 example.com 及其子域名。只写域名，不加协议、端口或路径。
IP-CIDR匹配 192.0.2.0/24 地址范围。这是文档保留网段，不是可用服务器地址。
GEOIP按 IP 地理数据库判断 CN。结果依赖 IP 地理数据库，不能仅凭域名后缀判断。
FINAL为前面未命中的请求选择 PROXY。没有匹配值字段，写成 FINAL,PROXY。

no-resolve 用于避免为了匹配该 IP 规则而主动执行域名解析。它不是“关闭所有 DNS”：请求本身或其他规则仍可能需要解析。若请求当前只有域名、没有可用于判断的 IP，该条带 no-resolve 的 IP 规则可能不会命中，应结合实际记录核对。

PROXY 表示代理策略，DIRECT 表示直连策略；它们不是协议名称。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 描述连接协议，连接参数仍来自用户自己的服务。把策略写成 PROXY 不会凭空创建可用连接，测试前必须确认 Home 中已有可用服务器。

判断规则问题：先确认请求命中了哪一行

目标域名走向不符合预期时，先在请求记录中核对域名、命中规则与策略，再移动那一条具体规则。不要先更换全部 General 设置，否则无法判断是哪项修改起了作用。

4. Host：固定域名映射，不等于选择出站策略

[Host] 用于指定域名与地址的映射。最直接的写法是 域名 = IP 地址。它改变的是目标域名对应的地址，不替代 Rule 中的 DIRECT 或 PROXY，也不能把不可达地址变成可达地址。

[Host]
lab.example.com = 192.0.2.10

该片段仅说明语法，192.0.2.10 是文档保留地址，不能直接用来验证联网。在自己的测试环境中，应填入明确受控的域名与实际可达地址，并核对服务监听端口。Host 一行只做名称映射，不要写成 192.0.2.10:443；HTTP 常用 TCP 80，HTTPS 常用 TCP 443，端口由 URL 或应用连接参数决定。

  • 域名填写 lab.example.com，不要填写 https://lab.example.com/path。
  • 使用 HTTPS 时，服务端证书仍须匹配请求域名。固定 IP 不会绕过证书校验。
  • 测试前关闭旧连接并重新发起请求，避免复用连接或缓存掩盖改动。
  • 移除测试映射后再次检查，确认没有把临时地址长期留在正式配置中。

出现“地址已经变化，但页面仍打不开”时，应分别检查地址可达性、端口服务、证书与路由策略。Host 是定位解析问题的工具之一，不适合把互联网上随意找到的地址写进长期配置。

5. URL Rewrite：匹配 URL，再指定重定向动作

[URL Rewrite] 处理 URL 匹配与重写。下面的示例使用正则表达式匹配一个 HTTP 地址，再用 302 返回重定向目标。它不创建 DNS 映射，也不是把某个域名指定到 PROXY 的另一种写法。

[URL Rewrite]
^http://example\.com/(.*)$ https://example.com/$1 302
  1. ^ 约束 URL 的开头，$ 约束结尾，避免只匹配到地址中间的一段。
  2. example\.com 中的点号被转义，表示字面上的点，而不是正则中的任意字符。
  3. (.*) 捕获斜杠之后的内容；目标中的 $1 引用第一个捕获组。
  4. 302 表示重定向动作。浏览器收到后再向目标地址发起请求，并非两端流量直接互换。

这个表达式只匹配 http://example.com/ 开头的地址，不匹配 https://example.com/，也不匹配带显式端口的 http://example.com:80/。这些边界应在测试前写清。不要为了“全都匹配”随意放宽域名部分，否则可能改写不相关请求。

遇到循环跳转时，先移除新加的重写规则，再观察原站响应。只让 HTTP 跳转到 HTTPS 的单向规则，仍可能与服务端自己的跳转逻辑相互影响；需要分别记录初始 URL、返回状态和跳转目标，而不是仅看最终页面是否打开。

6. 分段验证：把解析、路由与重写分开检查

四个段分别解决基础行为、分流、名称映射和 URL 处理问题。它们不是四步固定执行流水线；不同请求是否需要解析、是否能看到 URL、是否命中域名规则，都影响实际处理。以下数字只描述本文示例结构，不代表应用全部支持范围。

4 段
本文拆解：General / Rule / Host / URL Rewrite
4 类
规则示例：DOMAIN-SUFFIX / IP-CIDR / GEOIP / FINAL
80 / 443
HTTP / HTTPS 常用 TCP 端口
  1. 在 Config 保留原文件副本，确认测试文件已被选中。到 Home → Global Routing 固定使用 Config。
  2. 先只测试 General 与 Rule。使用自己已知可访问的目标，记录时间、网络类型和所选服务器。
  3. 停止并重新连接，再产生一条新请求。区分解析错误、连接超时、TLS 错误与 HTTP 状态码。
  4. 需要 Host 时只添加一个受控域名映射，比较修改前后的目标地址。
  5. 最后单独测试 URL Rewrite，观察重定向目标。失败时撤销最近的一项修改，而不是覆盖全部配置。

服务器延迟测试有结果，只能说明对应测试过程取得了响应，不能证明目标网站的 DNS、TCP 443、TLS 与 HTTP 请求全部正常。收到 HTTP 403 则表示请求已经得到服务器响应，应检查服务端访问条件，不能直接归因于 .conf 语法。

7. 常见问题：文件保存了，为什么结果没有变化？

我改了 Rule，网站还是全部走代理？

先查看 Home → Global Routing 是否为 Proxy。改为 Config 后，回到 Config 确认选中的是刚修改的文件，重新连接并发起新请求，再核对命中规则；不要只凭网页打开速度判断策略。

FINAL 能不能写在文件第一条？

应放在 Rule 段最后。把具体域名和地址规则移到它之前，例如先写 DOMAIN-SUFFIX,example.com,DIRECT，再写 FINAL,PROXY，才能让该域名有机会命中直连规则。

更新订阅以后，自己改的配置会保留吗？

先区分 Home 中的服务器订阅与 Config 中的远程配置。前者通常更新服务器条目，后者重新获取配置文本时可能覆盖本地改动。需要长期保留的编辑应放入独立本地副本，并在更新后确认当前选中文件。

Host 改成一个 IP，HTTPS 为什么报错？

核对该 IP 上是否运行目标域名的 HTTPS 服务，以及证书是否覆盖该域名。先撤销 Host 映射比较结果；不要以关闭证书校验代替修正域名、地址或服务端配置。

保存配置后的最终检查可以归纳为三项：当前文件正确、Global Routing 姿态正确、新请求命中预期规则。确认这三项后，再处理 DNS、目标服务与重写边界，能减少把连接故障误判为文件格式错误的情况。

App Store 正版核验 →