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

本文速览

阅读 .conf 时，先区分基础设置、路由规则、域名映射与请求改写，再检查当前启用的文件和 Global Routing。本文适合已经有自己的服务商与订阅、需要修改本地配置的用户；示例只解释语法，不包含可用连接参数，修改后应以应用内连接记录核对实际命中结果。

1. .conf 分段结构：段名决定内容的职责

Shadowrocket（小火箭）的 .conf 是文本配置文件。方括号包围的是段名，后面的内容属于该段，直到出现下一个段名。[General] 中常见的是键值设置，[Rule] 中则是一行一条的匹配规则；把正确的内容放进错误的段，也不能得到预期效果。

Home 主要处理连接与服务器选择，Config 用于管理配置文件，Settings 用于应用设置。已有订阅提供的服务器参数，与 .conf 中决定流量走向的规则不是同一件事。导入或更新服务器列表，不等于当前配置文件也随之切换。

4 个段

本文拆解 General、Rule、Host、URL Rewrite

3 个入口

Home、Config、Settings 各有职责

1 条兜底

示例将 FINAL 放在 Rule 最后

以下片段用于辨认结构，并非包含服务器信息的完整连接配置。example.com 是示例域名，192.0.2.10 属于文档示例地址；不要把它们当作实际业务参数保留在日常配置中。

[General]
dns-server = system

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

[Host]
example.com = 192.0.2.10

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

同一文件中有这些段，不代表每次请求都严格按文件的段落排列依次执行。段落是配置组织方式；解析、路由和改写有各自的处理条件。尤其不能把上面的排列理解为“先 Rule、后 Host、最后 URL Rewrite”的固定请求流水线。

2. General：基础行为与 DNS 设置

[General] 存放基础设置。阅读这一段时，逐项确认键名、等号右侧的值，以及值列表使用的分隔符。不要将其他配置格式中看似相近的字段直接粘贴进来；以 Shadowrocket 编辑界面可以识别、保存并实际使用的配置项为准。

[General]
dns-server = system

这里的 dns-server = system 表示使用系统 DNS。它不表示所有请求必然使用 DIRECT，也不能用来指定某个网站走 PROXY。DNS 负责域名解析，路由规则负责选择策略，两者会相互影响排查结果，但职责不同。

域名打不开、直接访问 IP 有响应：先核对解析结果和 DNS 设置，不要立即把整份 Rule 替换掉。
域名能解析、出站策略不符：检查 Global Routing 与命中的 Rule，而不是只更换 DNS。
切换网络后结果变化：系统 DNS 可能随当前网络改变，应记录测试时使用的是 Wi-Fi 还是蜂窝网络。
编辑已有文件：优先修改原有的同名设置，避免重复写入多个相同键后依赖不明确的覆盖结果。

修改 DNS 与修改路由应分开测试。一次同时改动多个 General 设置、Host 映射和 Rule，可能让页面恢复访问，却无法确认是哪一项起作用，也会增加以后恢复原状的难度。

3. Rule：从上到下匹配，FINAL 放在末尾

[Rule] 决定请求使用哪一个策略。规则按顺序匹配，先匹配到的规则决定处理方式；更精确的规则应放在更宽泛的规则之前。FINAL 不带域名或地址条件，用于接住前面没有匹配的流量，因此应放在这一段末尾。

关键字	示例语法	核对点
`DOMAIN-SUFFIX`	`DOMAIN-SUFFIX,example.com,PROXY`	匹配该域名及其子域名，不是任意字符串包含。
`IP-CIDR`	`IP-CIDR,192.0.2.0/24,DIRECT,no-resolve`	按 IPv4 网段匹配；no-resolve 避免为本条匹配主动发起域名解析。
`GEOIP`	`GEOIP,CN,DIRECT`	按 IP 地理数据库分类判断，不按网页语言判断。
`FINAL`	`FINAL,PROXY`	不再附加匹配条件，作为末尾兜底。

PROXY 与 DIRECT 是策略，不是协议名。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 等连接类型的参数应在对应服务器配置中核对，不能写成 FINAL,Trojan 来代替策略。若使用自定义策略名称，还要确认该名称确实存在并可用。

[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；www.example.com 则可以命中后面的 DOMAIN-SUFFIX，采用 PROXY。若把 DOMAIN-SUFFIX 移到前面，前一个精确例外就没有机会生效。测试时要访问完整目标主机名，不能只用同一网站的另一个子域名代替。

结论：先找命中行，再修改兜底

目标流量已经命中前面的 DOMAIN 或 DOMAIN-SUFFIX 时，修改 FINAL 不会改变它的策略；先在连接记录中定位匹配结果，再调整相应规则的位置或内容。

4. Host 与 URL Rewrite：映射地址不等于改写请求

[Host] 为指定域名设置地址映射；[URL Rewrite] 根据请求 URL 的匹配表达式执行改写或重定向。前者解决“这个名字对应哪个地址”，后者处理“符合条件的 URL 如何变化”。它们都不能替代 Rule 中的路由策略。

Host 映射

段名: [Host]
左侧: example.com
右侧: 192.0.2.10
写法: example.com = 192.0.2.10

示例地址仅供阅读语法，实际映射必须由用户确认。

URL Rewrite 重定向

段名: [URL Rewrite]
匹配表达式: ^http://example\.com/
目标地址: https://example.com/
动作: 302，临时重定向

表达式、目标地址与动作之间使用空格分隔。

Host 不会把浏览器地址栏中的域名变成 IP，也不会让目标服务器自动接受这个域名。对于 HTTPS，证书名称仍需与访问的主机名相符；将域名映射到一个不匹配的服务器，可能遇到证书错误或站点响应不符。应修正映射，不要把关闭证书校验当作常规解决方式。

URL Rewrite 示例中的 ^ 表示从开头匹配，\. 表示域名中的字面点号，302 表示让客户端转向目标 URL。这个例子只演示 HTTP URL 到 HTTPS 地址的重定向，并不保证保留任意路径和查询参数；若要保留它们，需要明确设计捕获组和替换表达式。

先用单个测试 URL 验证表达式，不要直接使用能匹配所有域名的宽泛写法。
HTTP 示例不要求解密 HTTPS 内容；若规则需要读取 HTTPS 的路径或内容，通常还涉及独立的 HTTPS 解密条件与信任设置。
添加 Host 后访问异常，先撤回该条映射；添加 URL Rewrite 后反复跳转，先检查目标 URL 是否再次触发同一规则。

5. Config 编辑流程：备份、保存、启用、验证

在 Config 中编辑文件前，先确认当前实际启用的是哪一份配置。文件存在于列表中、文本已经保存，以及配置被选中启用，是三个不同状态。仅修改一个未启用的文件，不会让当前连接立即采用新规则。

保留原稿编辑副本保存启用确认模式新建请求核对记录

保留原文件：在 Config 中确认原文件名称，通过文件操作保留副本或导出原稿。若文件来自远程配置地址，应先保留本地可恢复版本，避免后续更新覆盖手工修改。
进入编辑：从目标配置的文件操作进入文本编辑入口。保留段名，按需修改一段中的一项；不同应用界面布局下，入口可能位于文件操作菜单中，以当前页面显示为准。
检查语法并保存：Rule 字段之间使用英文逗号，General 与 Host 的键值使用等号，URL Rewrite 的字段使用空格。避免将中文逗号、全角方括号或说明文字误放到参数中。
选中配置：回到 Config 列表，确认编辑后的文件处于启用状态；再到 Home 检查当前服务器与连接状态。
核对 Global Routing：测试 Rule 时使用 Config。Proxy 与 Direct 是整体路由姿态，不能用它们的访问结果直接判断某一行 Rule 是否有效；使用 Scene 时，还要核对场景实际采用的配置与策略。
建立新连接：保存后重新发起测试请求，必要时断开再连接。已有连接和缓存可能保留旧状态，应使用新的连接记录比较目标域名、命中规则与最终策略。

Settings → On Demand 处理自动连接条件，不负责决定 Rule 的上下顺序。排查“改完又自动连上”时检查这一入口；排查“某域名走错策略”时则回到 Global Routing 与当前配置。把自动连接问题和分流问题分开，才能准确定位改动范围。

6. 常见问题：配置不生效、更新覆盖与回退

以下问题都应从当前文件、当前模式和新请求记录三处交叉核对。浏览器显示“能打开”只能说明一次访问成功，不能单独证明某条规则被执行，也不能证明它采用了预期服务器。

我已经保存 Rule，为什么还是走原来的策略？

先在 Config 确认选中的是刚编辑的文件，再检查 Home → Global Routing 是否为 Config。用新请求查看连接记录；如果已经命中前面的规则，应修改那一行或调整顺序，而不是继续在 FINAL 后面追加规则。

更新订阅后，手工写的 .conf 会一起更新吗？

服务器订阅更新与远程配置更新是不同操作。先确认更新的是 Home 中的服务器列表，还是 Config 中的远程文件。远程配置重新获取时可能替换本地内容，重要改动应保留副本，并在更新后逐项比较。

加了 Host 后报证书错误，该改哪里？

先撤回新增映射，使用新连接复测。确认映射地址确实服务于原主机名，并核对服务器证书。不要为了保留错误映射而关闭证书校验；Host 只能改变地址对应关系，不能改变证书覆盖的名称。

改坏以后怎样恢复，不影响已有订阅？

在 Config 重新选中备份文件，恢复测试前的 Global Routing，再重新建立连接验证。不要先删除 Home 中已有服务器或订阅。确认旧配置恢复正常后，在副本上一次只加入一项改动，逐步定位出错行。

最终检查顺序是：先确认文件启用，再确认路由姿态，然后读取命中结果，最后处理 DNS、Host 或改写条件。配置文件的价值在于让行为可以核对、修改可以回退，而不是将尽可能多的字段堆进同一份文件。