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

1. 先区分配置文件、服务器与运行姿态

.conf 是文本配置文件，段名通常独占一行，后续条目归属于这个段，直到下一个段名出现。[General] 中常见的是键值参数，[Rule] 中则是一行一条的匹配规则。两种语法不能互换：把 dns-server = system 放进 [Rule]，并不会变成一条有效的域名规则。

Home 用于选择服务器、控制连接与查看 Global Routing；Config 用于管理和选择配置文件；Settings 用于应用设置。服务器条目回答“通过哪个出口连接”，配置文件回答“哪些请求采用哪种策略”。已有服务器订阅更新成功，也不代表 Config 中已经选中了预期的规则文件。

验证 [Rule] 时，在 Home → Global Routing 选择 Config。Proxy、Direct 是全局姿态，不能用它们判断某条配置规则是否命中；Scene 则按所选场景设置工作，排查时还需要核对场景采用的配置。先固定为 Config，能减少运行姿态变化带来的干扰。

2. [General]：先保留可解释的全局参数

[General] 使用 键 = 值 格式。下面的片段可放进测试配置：dns-server = system 使用系统提供的 DNS；bypass-system 与 skip-proxy 涉及系统及指定地址的绕过行为，不应把它们当成提高连接速度的通用开关。

[General]
dns-server = system
bypass-system = true
skip-proxy = 127.0.0.1, 192.168.0.0/16

127.0.0.1 是回环地址，192.168.0.0/16 是私有地址范围。示例只列出这两个范围，不代表它覆盖了全部本地网络。若局域网实际使用其他网段，应先确认网络地址和访问目标；不要照抄一个很大的绕过范围，再用后续规则补救。

不要在同一段里反复添加相同键来表达“追加”。不同参数对重复项的处理可能不同，整理时应保留一个明确的目标值。修改 DNS 前也应记录旧值；域名解析失败与代理握手失败是两类问题，换服务器并不能自动修正一个错误的 DNS 设置。

3. [Rule]：具体规则在前，FINAL 在后

在 Config 姿态下，规则按排列顺序检查，先匹配的条目决定策略。下面示例依次展示精确域名、域名后缀、地址段、地区匹配和兜底规则。example.com 与 example.org 仅用于说明语法；规则里没有任何服务器地址或订阅凭据。

[Rule]
DOMAIN,blocked.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
DOMAIN-SUFFIX,example.org,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

• DOMAIN 精确匹配指定域名，因此此处的 blocked.example.com 会先命中 REJECT，而不是后面的后缀规则。
• DOMAIN-SUFFIX,example.com,PROXY 匹配该域名及其子域名，不按网页 URL 的路径匹配。
• IP-CIDR 按目标 IP 所在地址段判断。附加的 no-resolve 表示不为这条 IP 规则主动触发域名解析，并不表示整个请求完全不需要 DNS。
• GEOIP,CN,DIRECT 依据目标 IP 的地区数据判断，不依据域名后缀或经营主体判断。
• FINAL,PROXY 处理前面没有匹配的请求，应保留在规则末尾。

PROXY、DIRECT、REJECT 是策略关键字，不是三种协议。PROXY 仍需有可用的代理出口；DIRECT 直接连接目标；REJECT 拒绝匹配请求。若自己的配置使用命名策略组，应确认规则引用的组名存在，不要把示例里的 PROXY 随意改成一个未定义名称。

4. [Host]：只建立域名与地址的映射

[Host] 的常见写法是 域名 = IP 地址，左侧不是完整 URL，右侧也不填写路径或端口。下面使用保留测试域名和文档示例地址说明格式，可复制到隔离的测试配置中阅读，但这些地址不代表可访问的真实服务。

[Host]
portal.example.test = 192.0.2.10
api.example.test = 192.0.2.20

Host 映射改变的是地址解析结果，不会自动把请求变成 DIRECT。若需要让自己的测试域名直连，应另在 [Rule] 的适当位置添加对应策略。即使映射正确，HTTPS 连接仍需要证书与请求域名相符，Host 条目本身不会解决证书名称不匹配的问题。

1. 先确认服务实际监听地址与端口，例如自己的测试服务是否监听 443。
2. 只在 Host 左侧写域名，不写 https://，也不写 :443。
3. 在 Rule 中确认这个域名采用的策略，避免只检查解析结果。
4. 若目标地址已变更，更新或移除旧映射，再重新发起请求；已有连接与应用缓存可能影响立即复测的结果。

远端代理也可能参与目标域名解析，具体取决于出站方式和连接处理。因此，排查时应同时查看请求目标、所选策略和实际连接结果，不能仅凭本机的一次 DNS 查询就认定整条链路采用了同一个地址。

5. [URL Rewrite]：表达式、目标与动作分清楚

[URL Rewrite] 处理的是 URL，而不是选择代理出口。下面把示例域名的 HTTP 请求重定向到 HTTPS：匹配表达式、目标地址、302 动作以空格分开；$1 引用表达式中的第一个捕获组，保留主机名之后的内容。

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

例如输入 http://example.com/docs?a=1，规则目标为 https://example.com/docs?a=1。这里的反斜线把域名中的点当作字面字符，开头的 ^ 限定匹配起点。使用 302 意味着返回重定向，后续 HTTPS 请求仍要经过连接和分流处理。

• 先用单个、明确的域名测试，不直接写覆盖所有网站的宽泛表达式。
• 此例只匹配 HTTP，目标是 HTTPS，因此目标不会再次命中同一条规则。
• 若改写涉及路径，逐项核对斜杠、捕获组与查询参数，避免目标地址被拼接错误。
• 已有的 HTTPS 请求不会因添加此条规则就暴露完整路径；处理加密请求内容涉及另外的条件，本文示例不要求配置 MITM。

不要为了做域名分流而添加 URL Rewrite。只想让 example.com 使用 PROXY，应回到 [Rule] 写 DOMAIN-SUFFIX；只想固定自己的测试域名解析地址，应使用 [Host]。职责越单一，出错时越容易撤回。

6. 保存、启用与验证：一次只改一个段

编辑前先在 Config 保留当前可用配置的副本，并记下 Home 中选中的服务器和 Global Routing。服务器订阅与远程 .conf 配置是两种更新对象：前者通常更新服务器条目，后者更新配置正文。若直接编辑远程配置对应的内容，后续更新可能覆盖本地修改，因此应先建立独立的本地副本用于测试。

1. 建立基线：在 Home 选择已有的可用服务器，打开连接，使用 Connectivity Test 检查基本连接。此项测试不能替代具体网站或规则的验证。
2. 编辑副本：在 Config 打开准备测试的配置，找到对应段，只修改一个参数或一条规则，保存后返回配置列表。
3. 核对启用：在 Config 选中该文件，再到 Home → Global Routing 选择 Config；必要时重新连接，使新配置进入本次验证。
4. 重现请求：用相同域名、协议和路径发起新请求。修改 Host 或 URL Rewrite 后，尤其要避免用旧页面的缓存作为判断依据。
5. 对照结果：查看连接记录中的目标与策略；如果结果不符，先还原这一处修改，再比较前后差异。

例如，测试 DOMAIN-SUFFIX 时固定访问同一个子域名；测试 Host 时固定目标服务与端口；测试 URL Rewrite 时明确输入 http:// 而不是浏览器自动补全的 HTTPS 地址。把“请求根本没有发出”“请求命中错误策略”“出口连接失败”分开记录，比同时更换 DNS、规则和服务器更有诊断价值。

7. 常见问题：配置看似正确却没有生效

完整语法可继续查阅规则手册。实际配置中应保留能够解释用途的参数，把域名分流、地址映射与 URL 改写分开维护；每次修改都记录目标、预期策略和回退文件，便于后续更新时复查。