Shadowrocket 配置文件结构详解:General、Rule、Host、URL Rewrite 各段写什么

先区分 .conf、订阅与当前连接

.conf 是配置文本，方括号标题标识段落，标题下的内容属于该段。[General] 主要使用键值对，[Rule] 使用逗号分隔的规则行；不能把同一种写法套用到全部段落。以 # 开头的独立行可作为注释，建议把说明单独写一行，避免注释混入参数值。

Home 主要用于连接、选择服务器与查看 Global Routing；Config 用于管理和选择配置文件；Settings 用于应用设置。已有订阅通常用于维护服务器列表，不能把服务器条目已更新理解成当前规则文件也已替换。配置文件也可能引用远程资源，检查时需要进一步确认其更新来源。

在 Config 编辑前，先保留原文件副本，记录 Home 当前选中的服务器与 Global Routing 状态。文件能够保存，不等于已经选中使用；选中配置，也不等于所有流量一定按其中的分流规则处理。排查时应把“文件内容”“当前配置”“路由姿态”分开核对。

[General]：全局参数使用键值对

[General] 设置影响配置整体行为的参数。以下片段以系统 DNS、关闭 IPv6 及系统流量绕行为例，展示 键 = 值 格式。这是语法示范，不是所有网络都适合直接采用的参数组合。

[General]
# 使用系统提供的 DNS
dns-server = system

# 是否启用 IPv6
ipv6 = false

# 允许系统相关流量绕过
bypass-system = true

• dns-server = system：使用系统提供的 DNS。切换 Wi-Fi 后，系统可用的解析环境可能变化，不能据此认定两张网络的解析结果必然一致。
• ipv6 = false：控制此配置的 IPv6 行为，不等于关闭路由器或整台设备的 IPv6。若连接依赖 IPv6，应先核实服务端地址与当前网络，再决定是否修改。
• bypass-system = true：涉及系统流量的绕行处理，并不是为某个网站指定 DIRECT 的规则；网站分流仍应到 [Rule] 检查。

同一个键不要重复写入多个相互冲突的值。合并两份配置时，先对照已有键，再决定保留哪一个，而不是整段追加。DNS 相关故障也要区分“服务器域名无法解析”和“目标网站域名无法解析”：二者影响的是不同的连接环节。

[Rule]：逐行匹配，具体条件放前面

[Rule] 决定请求匹配哪个目标策略。常见结构为 规则类型,匹配值,策略；FINAL 没有匹配值，直接写目标策略。规则按顺序检查，前面已经命中的请求不会继续依靠后面的宽泛条件重新分配。

[Rule]
# 匹配 example.com 及其子域名
DOMAIN-SUFFIX,example.com,PROXY

# 文档示例网段，不是实际服务地址
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve

# 按目标 IP 的地区数据库结果匹配
GEOIP,CN,DIRECT

# 未命中前面规则时使用
FINAL,PROXY

PROXY 表示代理策略，仍需要可用的代理出口；DIRECT 表示直接连接。若使用自建策略组，规则末尾必须引用实际存在的名称，拼写、空格与大小写均应核对。把不存在的组名写入规则，并不能自动创建对应出口。

要验证此段，在 Home → Global Routing 选择 Config，并确认 Config 中使用的是刚编辑的文件。Proxy 是全局代理姿态，Direct 是全局直连姿态；Scene 按已配置的场景处理，不能简单视为 Config 的另一个名称。希望验证逐条规则时，应先排除全局姿态或场景切换的干扰。

[Host]：修改域名映射，不等于修改出口

[Host] 用于指定域名对应的地址。下面将一个完整主机名映射到文档保留地址，结构为 主机名 = IP 地址。这里的地址没有部署网站，复制后请求失败属于预期结果，不能拿它判断实际服务器是否可用。

[Host]
# 仅作格式说明
portal.example.com = 192.0.2.10
api.example.com = 198.51.100.20

Host 映射既不是 HTTP 重定向，也不是 DOMAIN-SUFFIX 规则。浏览器地址栏仍可保留原域名，HTTPS 证书也仍须与请求域名匹配。若把域名指向没有该域名证书的服务器，即使网络连接成功，也可能出现证书错误；不要通过忽略证书错误来掩盖映射问题。

验证时，使用完整主机名发起一次新请求；已有连接可能继续复用旧连接，不能只看网页是否仍然打开。若移除映射后恢复正常，先核对目标地址、服务监听与证书，而不是继续添加更宽泛的直连规则。远端代理是否再次解析域名也与连接方式有关，不要把本地映射理解为强制控制所有远端解析。

[URL Rewrite]：匹配 URL 后执行重写动作

[URL Rewrite] 处理 URL 匹配与动作，不使用 [Rule] 的逗号格式。下面示例把一个 HTTP 地址临时重定向到 HTTPS，动作中的 302 是重定向状态码，不是服务器端口。

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

1. ^ 表示从 URL 开头匹配，防止匹配范围意外落到地址中间。
2. example\.com 中的反斜杠使点号表示普通字符，而不是正则表达式里的任意字符。
3. (.*) 捕获域名之后的内容，目标中的 $1 引用这部分内容。
4. url 302 指定 URL 重定向动作；改写后产生的新请求仍需要正常解析、分流与建立连接。

重写不负责补齐服务器能力。目标站点必须实际支持 HTTPS，证书也必须有效。如果目标地址再次跳回原地址，可能形成重定向循环。测试应先使用一条精确域名规则，不要一开始就对所有 HTTP 地址应用宽泛正则。

保存后的验证顺序与常见问题

四段可以同时存在于一个文件，但不应理解成机械执行的四步流水线。General 影响全局行为，Rule 负责策略匹配，Host 影响域名映射，URL Rewrite 处理可见的请求 URL。故障定位应围绕实际现象拆分，而不是认为“最后一段覆盖前面所有设置”。

1. 在 Config 保存副本并选择该文件，确认没有误选另一个同名配置。
2. 回到 Home，确认服务器可用，再把 Global Routing 设为 Config 以验证规则分流。
3. 发起一个新的目标请求，记录目标域名、预期策略、实际连接结果与错误提示；必要时查看相关请求记录。
4. 撤销刚才的单项修改后再测试一次。只有修改与回退能够稳定改变结果，才继续合并下一项配置。

配置文件应只保留能够说明用途、能够验证结果的设置。合并远程规则前，检查其匹配范围、目标策略以及更新是否会覆盖本地内容。需要继续核对语法时，可查看规则参考；首次连接步骤见使用教程。