Shadowrocket 配置文件结构详解：[General] [Rule] [Host] [URL Rewrite] 各段作用

先理解 .conf 的分段与处理顺序

Shadowrocket（小火箭）的 .conf 文件不是一串从第一行执行到最后一行的脚本，而是由多个方括号段名划分的声明式配置。段名决定后续行交给哪个处理模块，例如 [General] 保存通用参数，[Rule] 保存分流规则。空行通常只用于阅读，行首注释用于说明，不参与匹配。

读取配置时，先确认段名拼写，再确认每一行使用的分隔符，最后检查同一段内部是否存在顺序依赖。段名缺少右方括号、逗号写成中文标点、策略名拼错，都可能使某一行失效。编辑后应回到 Config 重新选中配置，并通过实际域名请求验证，而不是只看文件能否被导入。

四个核心段并非全部作用于同一阶段。[Host] 影响特定域名如何得到地址，[Rule] 决定请求采用哪种策略，[URL Rewrite] 针对可识别的 URL 做跳转或拒绝处理。把这些功能混写到一个段中，即使单行看起来正确，也不会产生预期效果。

[General]：DNS、bypass 与基础行为

[General] 是配置的通用参数区。这里的项目会影响 DNS 解析、系统绕过行为、局域网地址处理及其他基础选项。它不是分流规则清单，因此不能把 DOMAIN-SUFFIX 或 FINAL 放在这里。不同来源的配置可能包含不同项目，核对时应以 Shadowrocket 当前界面能够导入和导出的字段为准。

dns-server 指定配置使用的 DNS 解析入口。写成 system 表示采用系统可用的解析设置；写入明确地址时，应先确认该地址在当前网络中可达。DNS 负责把域名转换为地址，但它本身不决定最终使用 PROXY 还是 DIRECT，策略仍由 Global Routing 与 [Rule] 共同决定。

[General]
bypass-system = true
dns-server = system
ipv6 = false
skip-proxy = 127.0.0.1, localhost, *.local, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

bypass-system 用于控制是否采用系统相关的绕过处理；skip-proxy 则明确列出不应交给代理处理的主机或地址范围。上例包含回环地址、.local 名称与三个常见私有地址段，适合解释语法，不代表所有网络都应照抄。企业内网、家庭存储设备或打印设备可能使用不同网段，修改前应先查看设备当前获得的局域网地址。

ipv6 = false 是明确关闭该配置中的 IPv6 行为的写法示例，但不应把它当作通用修复项。如果当前接入网络、已有服务配置与目标站点均正常支持 IPv6，关闭后反而可能改变解析结果。排查时一次只调整一个项目，并记录调整前后的 DNS 结果和访问现象。

[Rule]：自上而下匹配与 FINAL 兜底

[Rule] 是最容易受顺序影响的段落。Shadowrocket 在 Global Routing 设为 Config 时，按照配置中的排列从上到下检查请求；命中第一条适用规则后，就采用该行末尾的策略，不再继续寻找“更具体”的后续规则。因此，具体域名通常放在宽泛后缀或地域规则之前。

常见规则由英文逗号分隔。DOMAIN 匹配完整域名，DOMAIN-SUFFIX 匹配域名后缀，IP-CIDR 匹配地址范围，GEOIP 按地址所属地域匹配，FINAL 处理此前均未命中的请求。策略通常写为 PROXY、DIRECT 或 REJECT。

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

上例第一行优先让 api.example.com 使用 DIRECT。如果把第二行放到第一行之前，完整域名会先被 DOMAIN-SUFFIX,example.com 命中，后面的例外规则没有机会执行。no-resolve 用于避免该条 IP 规则为了匹配而额外触发域名解析，适合本身只需要检查目标地址的规则。

Global Routing 会改变规则是否参与决策。Config 使用当前配置的规则；Proxy 强制采用代理策略；Direct 直接连接；Scene 按已设置的场景条件决定姿态。测试单条规则时，应先确认没有停留在 Proxy 或 Direct，否则修改 [Rule] 后看不到预期差异。

1. 在 Home 确认已经选中需要测试的服务器配置。
2. 将 Global Routing 切换到 Config。
3. 在 Config 确认目标 .conf 处于选中状态。
4. 把待验证的具体规则放到宽泛规则之前。
5. 重新发起请求，检查命中的策略是否符合预期。
6. 最后确认 FINAL 位于规则段末尾。

[Host]：固定域名映射，不等同于分流规则

[Host] 用于把指定域名映射到明确地址，可以理解为配置内部的域名解析覆盖。它解决“这个域名应得到哪个地址”的问题，不负责决定请求走 PROXY、DIRECT 还是 REJECT。最终策略仍需要由 [Rule] 处理。

下面使用文档保留地址演示格式。192.0.2.0/24 与 2001:db8::/32 专门用于文档示例，不应当被当作真实业务地址。实际配置应填写用户自己管理或确认可用的目标地址。

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.20
ipv6.example.com = 2001:db8::10

Host 映射最常见的检查错误是域名层级不一致。例如只写 example.com，不应默认认为 api.example.com 一定获得相同映射。需要覆盖子域名时，应逐项确认当前配置支持的匹配写法，并通过实际解析结果验证，不要依靠视觉上相似的域名推断。

[URL Rewrite]：跳转、拒绝与 HTTPS 可见性

[URL Rewrite] 根据 URL 匹配表达式改变请求结果。常见用途包括返回 302 跳转，或使用 reject 阻止符合条件的请求。它处理的是 URL，而 [Rule] 主要根据域名、地址或地域选择策略，两者不能互相替代。

表达式中的点号需要转义，路径边界也应尽量写清楚。过于宽泛的表达式可能同时命中页面、接口与静态资源，表现为网页结构缺失或应用请求失败。开始编写时应先限定到一个测试域名和一条路径，确认结果后再扩大范围。

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302
^http://api\.example\.com/private - reject

第一行把精确的旧地址跳转到新地址，末尾的 302 是临时跳转状态。第二行使用连字符占据替换目标的位置，并以 reject 作为处理动作。字段之间使用空格，正则内部不应加入中文标点。

HTTPS 请求的路径位于加密内容中，仅凭域名连接不一定能检查完整 URL。需要查看或改写 HTTPS 路径时，必须在 Shadowrocket 中完成用户明确授权的证书与解密范围设置，并只对自己确认的测试域名启用。未配置相应范围时，HTTP 示例有效而 HTTPS 示例无效，属于加密可见性差异，不一定是正则写错。

• 先用完整起始符 ^ 与结束符 $ 限定精确测试地址。
• 域名中的英文句点写成 \.，避免匹配任意字符。
• 先测试单条规则，排除前面已有表达式提前命中的情况。
• 出现页面资源缺失时，暂时停用最近增加的改写行再复测。
• HTTPS 只对已确认且已授权的域名范围进行检查。

最小完整配置与导入后的核对步骤

把四段组合起来时，建议先建立一份只包含少量测试行的最小配置。最小配置的价值不是覆盖全部需求，而是让每个现象都能对应到一行：DNS 由 General 控制，地址覆盖由 Host 控制，分流由 Rule 控制，URL 动作由 URL Rewrite 控制。

[General]
bypass-system = true
dns-server = system
skip-proxy = 127.0.0.1, localhost, *.local, 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

[Host]
test.example.com = 192.0.2.10

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

[URL Rewrite]
^http://example\.com/old$ http://example.com/new 302

导入后进入 Config，确认该配置处于选中状态，再回到 Home 将 Global Routing 设为 Config。如果用户使用自己已有服务商提供的配置订阅，更新后应重新检查本地修改是否仍然存在；远端更新可能以新内容替换旧内容。需要测试 URL 形式时，可使用明显的示例地址 https://example.com/sub?token=xxxx 理解字段位置，不应把示例值当成可用服务。

1. 保留原始 .conf 副本，并给测试文件使用容易辨认的名称。
2. 检查所有段名是否使用英文方括号，段名后不要附加多余字符。
3. 检查 Rule 行是否使用英文逗号，策略是否位于行末。
4. 确认具体规则在宽泛规则之前，FINAL 位于最后。
5. 确认 Host 中的地址格式正确，域名没有协议前缀和路径。
6. 确认 URL Rewrite 中的正则、替换目标与动作字段数量完整。
7. 进入 Home 检查 Global Routing，随后分别测试解析、分流和改写。

如果配置无法正常工作，不要同时改动多个段。先暂时保留 [General] 与一条 FINAL，确认基础连接；随后加入一条 DOMAIN 测试规则，再加入 Host 映射，最后测试 URL Rewrite。分阶段恢复可以快速确定错误属于解析、匹配还是改写。

配置检查的最终判断标准

配置正确不能只用“连接开关已打开”判断。完整验证至少包含四项：域名是否得到预期地址、Global Routing 是否处于预期姿态、请求是否命中正确策略、URL Rewrite 是否只影响目标路径。每一项都应能对应到明确段落和具体配置行。

Shadowrocket 是 Apple 平台的闭源商业应用，以 iPhone 与 iPad 使用为主，Mac、Apple TV 与 Apple Vision 的兼容性及系统要求以 App Store 页面标注为准。正版获取入口为 App Store，开发者名称为 Shadow Launch Technology Limited，应用 ID 为 932747118，采用一次性买断。客户端购买与用户已有的服务配置属于不同事项。