Shadowrocket 规则与配置参考

01 / CONFIG STRUCTURE

配置文件结构：先区分服务器资料与行为规则

Shadowrocket 中的服务器资料回答“通过哪一个服务器建立连接”，配置文件回答“某个请求应采用什么处理方式”。两者相关，但不是同一份资料。用户已有的订阅通常用于导入和更新服务器条目；一个包含分流规则的配置文件则需要在 Config 中核对并启用。看到 Home 中已有服务器，并不能据此判断自定义规则已经生效。阅读任何配置之前，先记录当前选择的服务器、当前启用的配置文件，以及 Global Routing 的状态，后续排查才能保持条件一致。

四个配置段分别负责什么

常见文本配置使用方括号标记段名。[General] 放置通用参数，例如 DNS 与系统流量相关设置；[Rule] 放置请求匹配条件及对应策略；[Host] 为指定域名写入地址映射；[URL Rewrite] 按表达式处理符合条件的 URL。段名不是装饰标题，某一行所处的段决定了它如何被解释。把域名规则粘贴到 General 下，即使整行拼写正确，也不能当作 Rule 中的规则使用。

[General]
bypass-system = true
dns-server = system

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
FINAL,PROXY

[Host]
localhost = 127.0.0.1

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

这份片段用于识别结构，不是要求整份套用的通用配置。General 中的两行分别展示一个布尔参数和一个 DNS 取值；Rule 中的三行展示域名、地址范围与最终策略；Host 中的 localhost 是本机回环名称示例；最后一行展示 HTTP 到 HTTPS 的重定向写法。示例域名不代表实际服务，复制前应先明确自己的目标。特别是 FINAL 的取值会影响所有未命中的请求，不能只因为示例采用 PROXY 就照搬。

标点、段落与可读性

规则字段使用半角逗号分隔，参数赋值使用半角等号，段名使用半角方括号。中文输入法产生的全角逗号、引号或空格可能导致内容不按预期解析。每条规则单独占一行，不要把网页排版造成的折行误当作新的规则。阅读时可按“关键字、匹配值、策略、可选参数”依次拆解，但不是所有关键字都有相同字段数；FINAL 就不包含匹配值，不能机械地补成三列。

配置段的排列也不应理解为一条固定处理流水线。文件中 General 写在 Rule 上面，不表示每个请求都先执行全部通用参数再逐行执行其他段；Host 与 URL Rewrite 也不是 Rule 的后续规则。真正需要按从上到下阅读的是 Rule 内部的匹配顺序。把配置结构和规则优先级分开理解，可以避免通过移动整个配置段来“提高规则优先级”的无效修改。

在 Config 中核对启用对象

进入 Config 后，先辨认目前选中的文件，再打开需要阅读或编辑的对象。修改副本前应给副本一个能说明用途的名称，并保留原文件。保存编辑与启用文件是两个检查点：保存只说明文字已写入，不一定说明当前连接已经使用这份文件。返回文件列表确认选择状态，再核对 Global Routing。界面项目的位置可能随应用调整，判断依据应是文件名、选中状态与实际请求结果，而不是某个固定的屏幕坐标。

如果目前还不能确认应用身份，可先按正版核验说明核对开发者 Shadow Launch Technology Limited、官方图标和应用 ID 932747118。Shadowrocket 是 Apple 平台付费客户端，唯一获取入口是 App Store；系统要求以 App Store 页面标注为准。确认基础环境之后，再使用本页的局部片段进行有目的的编辑，比同时更换服务器和配置更容易判断问题来源。

03 / DOMAIN MATCHING

域名规则：精确名称、后缀与关键词

当分流目标能用稳定的域名描述时，优先从域名规则考虑。与直接列出地址相比，域名条件更接近“某个站点或服务”的意图，也较少受服务器地址变化影响。但域名不是完整网址：协议、路径、查询参数和端口都不应直接粘贴到 DOMAIN 的匹配值中。例如浏览器地址栏中的完整 URL，需要先提取主机名，再判断是只匹配该名称，还是覆盖它下面的所有子域名。

DOMAIN：只匹配指定名称

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,account.example.com,DIRECT
FINAL,PROXY

第一行针对 api.example.com，第二行针对 account.example.com。DOMAIN 不表达“包含这个词”，也不自动覆盖其他子域名。如果实际请求是 images.api.example.com，不能因为它看起来属于同一个业务，就认定第一行应该命中。精确规则适合处理少量明确例外：例如大部分请求采用最终策略，仅某一个主机名需要 DIRECT。使用前应从实际请求中确认完整名称，避免把页面显示的品牌名称当成网络请求的主机名。

DOMAIN-SUFFIX：按域名边界覆盖后缀

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

DOMAIN-SUFFIX,example.com 会覆盖 example.com 及其子域名，例如 www.example.com。它按域名边界理解后缀，不是任意字符串结尾比较，因此不要把 notexample.com 当成这个后缀的正常覆盖对象。上例先为 private.example.com 写精确例外，再写宽泛后缀；如果交换这两行，后缀规则会先匹配该例外名称，精确规则便失去预期作用。规则的覆盖关系比行数多少更值得关注。

写后缀时通常不需要添加星号。把 *.example.com 当作 DOMAIN-SUFFIX 的标准值，会混淆通配符表达式与后缀匹配两种机制。也不要因为需要覆盖图片域名就把范围扩大到很短的公共后缀。范围越宽，误包含其他服务的概率越大。合理的起点是业务真实使用的注册域名，然后根据请求记录补充独立域名，而不是猜测所有请求都共享同一后缀。

DOMAIN-KEYWORD：范围更宽，也更容易误匹配

[Rule]
DOMAIN-KEYWORD,example,PROXY
FINAL,DIRECT

DOMAIN-KEYWORD 用于匹配域名中包含的关键词。这里的 example 不是一个完整域名，也没有 DOMAIN-SUFFIX 那样的域名边界含义，因此可能命中本来没有关系的名称。只有当你明确需要这种较宽的条件，并能检查其影响范围时才使用。若目标只是 example.com 及其子域名，后缀规则通常更符合意图。规则越短不代表越准确，关键词更少也不代表维护成本更低。

页面域名不等于全部请求域名

一个页面可能分别向登录、图片、接口和静态资源域名发起请求。主页能打开但登录失败，不一定说明同一条规则忽好忽坏，也可能是另一组请求采用了不同策略。应在操作发生时查看请求记录，识别真正失败的名称，再决定是否新增规则。第三方资源域名可能同时被多个业务使用，不能只因它出现在某个页面中，就认定所有访问该域名的请求都应跟随这个页面的策略。

若请求记录中只有 IP，没有可用于匹配的域名信息，域名规则就可能不是正确的检查入口。这时应继续看地址规则、DNS 与请求产生方式，而不是堆叠更多类似域名。针对国际化名称或格式特殊的名称，也应以实际记录中的形式为准。完成修改后同时测试目标名称和一个相近但不应命中的名称，才能验证规则既覆盖了需要的范围，也没有把边界以外的对象一起包含。

05 / POLICY

Global Routing 与 PROXY、DIRECT、REJECT

Global Routing 的 Config、Proxy、Direct 是模式选择，Rule 中的 PROXY、DIRECT、REJECT 是规则的处理策略。两组词看起来接近，但处在不同层次。排查规则是否生效时，先看 Global Routing；如果当前不是按配置处理请求的 Config，就不能仅凭修改 Rule 推断连接结果会随之改变。尤其在临时切到 Proxy 或 Direct 测试之后，应记得恢复原来的模式，再验证自定义分流。

PROXY：采用代理路径，不代表远端必定成功

规则策略 PROXY 表达通过当前代理选择建立连接的意图。它不是服务器地址，也不会补齐服务器所需的认证和协议参数。若用户已有服务器资料中的地址、端口、凭据或相关设置错误，规则正确命中 PROXY 也可能连接失败。因此需要分别证明两件事：请求选择了预期策略，以及该策略所用的连接路径可用。把这两个检查混成一个“规则没生效”，会把排查方向带到错误的位置。

Home 中的服务器选择也应纳入记录。使用同一份配置但换了服务器，结果可能不同；这并不意味着 Rule 的语法发生变化。对于自定义策略或分组，应核对其名称和实际指向，不要把未定义的名称写入示例。本文统一使用三个内置策略，避免让配置片段依赖额外的分组定义。需要进一步检查 Trojan 参数时，可查阅Trojan 参数说明，不要通过修改域名规则修正协议参数。

DIRECT：采用当前网络的直接连接

DIRECT 不表示停止 Shadowrocket，也不表示关闭系统中的 VPN 配置。它是在当前处理流程中选择直接连接目标。目标是否可达仍取决于当前网络、解析结果和服务自身状态。对局域网目标使用 DIRECT 常常符合访问意图，但还需要设备处于相应网络中；若设备不在同一网络，或局域网服务没有监听对应地址，DIRECT 规则本身不能建立原本不存在的网络连通性。

REJECT：明确拒绝匹配请求

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

第一行拒绝指定名称，第二行使其他符合后缀的请求采用 PROXY，最后处理剩余流量。REJECT 适合明确不希望连接的目标，不应拿来代替一个尚未想清楚的最终策略。若被拒绝的名称同时承担登录、验证或内容加载功能，页面可能出现局部异常。修改前应理解该名称的用途，修改后检查页面关键操作，而不是只看主页是否能显示。

拒绝策略也不等同于某种页面清理承诺。网页中看到的内容与网络请求并非一一对应，单个域名还可能承担多个功能。为了阻断某一资源而使用过宽的后缀或关键词规则，容易同时影响正常请求。应从精确目标起步，通过请求记录确认条件，再考虑是否需要扩大范围。若出现新问题，先撤回刚添加的拒绝规则，避免继续叠加例外掩盖原有错误。

FINAL：为未匹配请求指定去向

FINAL 是不带匹配值的最终规则，常见写法是 FINAL,PROXY 或 FINAL,DIRECT。它与全局模式不是同一个概念：FINAL 仍属于 Config 下的规则配置，仅处理前面没有匹配的请求。选择哪一种策略取决于预期默认行为，不能把某个值当作所有人的正确答案。采用 PROXY 时，应确认用户已有的服务器可用；采用 DIRECT 时，应接受未列出的目标会按直接连接处理这一结果。

如果三个模式下的现象不同，记录差异而不是直接下结论。Direct 可用而 Proxy 失败，可能需要检查服务器路径；Proxy 可用而 Config 失败，可能需要检查命中策略及其他配置项；三者都失败，也可能是目标或当前网络问题。具体判断仍需要连接记录配合，不能把模式切换结果当作能够排除所有其他原因的单一证据。

07 / HOST AND URL REWRITE

Host 与 URL Rewrite：映射地址和改写网址分别处理

Host 处理名称与地址的对应关系，URL Rewrite 处理符合表达式的网址，两者都不等同于选择 PROXY 或 DIRECT。访问失败时，应先说明需要改变的到底是什么：是同一个域名应解析到另一个地址，还是旧网址需要跳转到新网址，抑或只是希望连接经过另一条路径。前两种需求才可能涉及本章，第三种应回到 Rule。为了分流而修改 Host，往往会引入额外的地址和证书问题。

Host 的最小示例与作用边界

[Host]
localhost = 127.0.0.1

左侧是名称，右侧是地址；localhost 与 127.0.0.1 表示本机回环示例。这里的“本机”指发起连接的设备自身，不是路由器，也不是所选代理服务器。不要把这个地址用于需要访问远端服务器的业务。写入一个映射只提供地址信息，不会让该地址自动运行所需服务。若目标端口没有监听、网络不可达或服务配置不符，名称能够对应到地址也仍然可能连接失败。

为真实域名固定地址之前，需要确认这个地址由谁维护、是否稳定，以及是否允许这样访问。很多服务根据地区和负载动态返回地址，固定其中一个结果可能破坏原本的调度。映射还可能掩盖正常 DNS 的变化，让后续排查误以为解析服务一直返回旧地址。因此 Host 适合明确、可控的映射需求，不适合把一次临时解析结果无限期保存下来。

Host 不会替代 TLS 验证

HTTPS 连接还涉及请求域名与证书等条件。把域名映射到某个地址，不等于该地址能提供与此域名相符的服务，也不会自动修复证书名称不匹配。遇到 TLS 错误，应核对目标名称、地址和服务端配置，不应把关闭校验当作常规修正。测试结束后若不再需要映射，应及时移除，并在重新发起连接时核对实际地址，避免旧配置影响其他诊断。

URL Rewrite 的三个组成部分

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

这行依次包含匹配表达式、替换目标和重定向状态码。开头的 ^ 表示从字符串起始位置匹配，example 后面的反斜杠用于把点号按普通字符处理；如果省略，正则表达式中的点号通常表示任意字符，会扩大匹配范围。末尾的斜杠也属于条件的一部分。这里使用 302 展示临时重定向，不应由此推断它会修复所有 HTTP 访问，或自动保留原网址的路径和查询参数。

示例的替换目标是固定网址，未显式保留被匹配网址的其余部分。如果真实需求包含路径或查询参数，应先规划捕获范围和替换方式，再用少量可控目标测试。不能仅因为起始域名相同，就把登录回调、接口请求与普通页面都重定向到站点首页。过宽改写可能破坏请求语义，甚至使页面出现循环跳转。改写后的目标若又符合另一条改写条件，还需要检查相互作用。

HTTPS 的可见性限制

完整 HTTPS 路径与请求内容通常处于加密连接中，不能假定只添加 URL Rewrite 就能对所有加密请求生效。本章不要求配置 HTTPS 解密，也不把证书安装作为规则分流的前提。若你的目的只是按域名决定去向，应使用域名规则，不必为获得完整 URL 而增加其他设置。判断功能是否适用，应以当前实际可见的请求信息和应用支持的处理条件为准。

这两个配置段的测试都应包含撤销步骤。先保存原值，再添加单条映射或改写，确认目标行为，最后撤销并复测，观察现象能否随改动稳定变化。若撤销后问题仍在，应考虑缓存、已有连接或目标服务变化，而不是继续叠加条目。想从完整文件角度复查四段关系，可阅读配置文件结构解读；本章的原则是把影响范围限制在能够解释和验证的范围内。

08 / CHANGE AND VERIFY

配置修改与故障定位：建立可重复的验证过程

配置正确与访问成功是两个相关但不同的结论。正确的规则可能选择了一条暂时不可用的路径；一次成功访问也可能来自缓存或已有连接，未必证明新规则参与了判断。可靠的验证需要固定测试条件、保存原始配置、一次只修改一个因素，并记录新请求的结果。本章把前面各类规则整理成一个可回退的过程，适合用于单个域名异常、修改后无变化或配置更新后行为改变等情况。

第一步：记录基线，不先改配置

先记录当前网络类型、Global Routing、启用文件和所选服务器，再描述问题发生在哪个具体操作。不要只写“不能用”，而应区分主页打不开、图片不显示、登录失败、接口请求失败或局域网设备无法访问。确定一个可重复触发的动作，尽量固定同一个目标。若问题本来就间歇出现，需要先多次观察基线，否则修改后的偶然成功很容易被误判为修正有效。

第二步：保存副本，缩小改动范围

在 Config 中保留原文件，再编辑副本。先查看相关段是否已有同类规则、是否出现重复条件、是否存在提前的 FINAL。对于单个域名问题，可以先添加一条范围最窄的 DOMAIN 例外，而不是立即增加宽泛关键词。若要调整 DNS，先不要移动 Rule；若要调整 Host，先不要更换服务器。这样在结果变化时，才能把变化与某一个明确的改动建立联系。

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

这份局部示例用于验证精确例外：api.example.com 采用 PROXY，其余符合后缀的名称采用 DIRECT，其他请求采用最终策略。逐行解释之后，再把自己的目标与预期策略对应进去。不要直接用示例域名测试真实连通性，也不要把整个片段追加到已有 FINAL 后方。若现有文件结构复杂，先在副本中做最小复现，确定逻辑成立后再合并回需要长期维护的配置。

第三步：保存、启用，再发起新请求

完成编辑后检查保存结果，返回 Config 核对启用对象，再将 Global Routing 设为 Config。重新发起目标操作，必要时断开后重新连接，以减少已有连接复用对观察的影响。重新连接不意味着所有应用缓存都会消失，因此还需结合请求记录判断是否产生了新的网络请求。测试中不要把“页面显示未变化”直接等同于“规则未变化”，页面可能根本没有重新请求相关资源。

第四步：先查命中，再查连接

请求采用的策略不符合预期时，回到 Rule 顶部检查覆盖关系、实际主机名、地址族与 Global Routing。策略符合预期但仍失败时，再检查所选服务器、协议资料、DNS 与目标响应。若仅某个网络失败，应比较网络条件；若仅某个服务器失败，应比较服务器连接结果。不要在策略已经正确时继续增加重复规则，因为重复项不能修复认证错误、不可达地址或目标服务异常。

第五步：回归相邻目标，并保留回退记录

目标恢复后，还要检查同一后缀下的其他请求、一个不属于该范围的目标，以及可能受影响的局域网访问。修改最终策略时，回归范围应更广，因为所有未命中请求的去向都可能改变。记录应包含改了哪一行、为何修改、怎样验证以及如何恢复，不需要保存完整的敏感请求内容。长期配置的价值在于后来仍能理解，而不是只在修改当天看起来可用。

若仍无法定位，可按开关已打开却无法连接的排查顺序继续检查，或在疑难解答中查找对应分类。需要重新核对导入和连接流程时，回到快速上手教程；涉及购买与设备兼容性时，查阅App Store 正版说明，系统要求与是否通用购买均以 App Store 页面标注为准。不要把重新购买客户端当作解决规则问题的步骤。