Shadowrocket
规则与配置手册

Global Routing 与规则生效条件

规则只有在请求进入对应的处理路径时才有意义。开始编辑之前，应先确认 Shadowrocket 当前已经选中可用服务器、连接开关处于预期状态，并且 Config 中启用的是准备修改的配置。文件保存在列表里，不代表正在使用；文本编辑器里出现了新内容，也不代表运行中的连接已经按新内容重新建立。把“文件存在”“文件被选中”“请求使用新配置”分开检查，可以避免把生效问题误判为语法错误。

区分 Config、Proxy 与 Direct

Global Routing 的配置、代理、直连分别对应 Config、Proxy、Direct。Config 按当前配置中的规则决定请求策略，是查阅本页大部分示例的前提。Proxy 用于让通常经过代理处理的请求采用代理路径，Direct 用于采用直接连接路径；两者适合做路径对照，但不应理解为仍在逐条测试自定义 Rule。系统绕过项、局域网例外与既有连接也可能影响观察结果，因此切换姿态后仍需重新发起请求。

把服务器、订阅与规则分开理解

服务器信息描述连接到哪里以及采用什么协议和认证参数；订阅是批量维护服务器信息的一种输入方式；规则则决定哪些请求采用哪种策略。更新服务器订阅不等于同步修改 Rule，导入一份配置文件也不意味着其中涉及的服务器已经存在。本文始终以用户已有自己的订阅或服务器信息为前提。客户端一次性买断 ≠ 线路套餐，购买应用与具备可用的连接条件是两件事，本站不提供、不销售、不推荐节点或订阅。

Shadowrocket 是 Apple 平台上的付费闭源商业应用，主要在 iPhone 与 iPad 上使用，唯一获取入口为 App Store。核对获取方式请参阅App Store 正版购买与安装说明，系统要求与购买适用性以 App Store 页面标注为准。本文的配置示例解释客户端行为，不替代商店信息，也不保证任何用户已有服务器的可用性。先建立基础连接，再调整分流，能让故障范围保持清晰。

建立可重复的观察条件

第一次测试建议只选择一个明确的目标域名，记录当前 Global Routing、选中服务器、配置名称与网络类型。先在已有可用配置下访问，确认目标本身能响应，再更改一条规则。不要同时更新订阅、切换网络、修改 DNS 并重排规则；当多个变量一起变化时，即使命中结果改变，也无法判断是哪项设置起作用。操作记录可以保存在本地笔记中，分享时去掉服务器地址、认证参数和完整订阅链接。

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

上例是局部规则片段：对精确域名 example.com 使用 PROXY，其余未命中的请求使用 DIRECT。它不是普遍适用的分流方案，也不会自动准备代理服务器。若目标页面还请求其他域名，那些请求可能落到 FINAL，出现一部分内容成功、一部分失败的现象。这不是规则随机生效，而是页面包含多个独立连接。验证时应逐个核对实际请求的目标，不能只根据地址栏中的主域名下结论。

.conf 配置文件结构与编辑流程

配置文件按方括号段名组织内容。General 放全局参数，Rule 放按顺序检查的匹配规则，Host 放域名到地址的本地映射，URL Rewrite 放符合条件的 URL 改写或拒绝处理。段名不是供阅读的装饰标题，而是解析器识别后续行用途的标记。相同文字放在错误段内，不会自动按原本意图执行。编辑前先辨认当前位置，尤其不要把域名映射写进 Rule，或把普通说明文字直接放进参数段。

先读骨架，再看局部示例

[General]
bypass-system = true

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

[Host]
test.example.com = 192.0.2.10

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

这里的 example.com、example.net 与 test.example.com 用于说明语法；192.0.2.10 是文档示例地址，不应期待访问成功。URL Rewrite 示例把指定的 HTTP 地址重定向到 HTTPS，是否适合实际目标仍取决于该站点支持情况。整段代码展示的是各段如何排列，不是建议整体替换现有配置。实际调整时只复制所需行，并明确每一行会改变哪些请求，保留当前文件中已确认有效的其他设置。

在 Config 中辨认当前文件

进入 Config 后，先查看当前被选中的配置，再打开对应文件进行检查。不同界面状态可能提供查看、编辑或其他操作，具体入口以应用实际显示为准。不要仅凭文件名称相似就判断是同一份内容；从远程来源保存的文件、本地副本与曾经导入的旧文件可能同时存在。建议给工作副本使用容易辨认的名称，记录其用途，并在修改后返回列表确认选中项没有改变，再开始验证请求。

完整替换与局部补充的风险不同。完整替换可能同时改变 DNS、绕过设置、规则与改写行为，适合在已经读懂整份配置时使用；局部补充只增加明确需要的条目，更便于排查。即便选择局部补充，也要找到现有的相应段落，而不是在末尾不断追加相同段名。重复段的合并与覆盖行为不应作为维护手段依赖，保持每段职责集中、内容顺序明确，能减少编辑器与运行结果之间的歧义。

保存时检查字符与段落边界

Rule 中的逗号应使用英文半角字符，参数赋值使用等号，方括号应成对出现。中文输入法可能把逗号、空格或引号替换成外观相近的字符；从富文本复制时也可能带入不可见字符。遇到一行看起来正确却无法解释的情况，可在纯文本环境中重新输入该行的段名、分隔符与关键字，再保存测试。规则中的域名只写主机部分，不要附带路径、查询参数或用于浏览器显示的完整地址。

较长配置应按用途排列并保留简短注释。可以在独立行用井号说明一组规则的意图，例如写明某个精确例外为何必须位于后缀规则之前；不要依赖复杂行尾注释来解释关键参数，以免复制时混入内容。注释应记录决策理由，而不是重复关键字的字面含义。过一段时间回看时，“测试某目标的直接连接”比“DIRECT 规则”更能帮助判断该行是否仍然必要。

修改后先检查能否正常保存与选中，再重新发起连接测试。保存成功只能说明文件被写入，并不证明每条规则都会命中；某条内容即便语法成立，也可能一直被更早的规则遮住。建议保留修改前的副本，按一次一项的方式增加规则，验证通过后再继续。需要按段理解更多编辑细节，可阅读General、Rule、Host 与 URL Rewrite 分段说明，并与本页的优先级章节交叉核对。

General、DNS 与系统绕过的边界

General 中的参数影响整体处理环境，而不是像 Rule 一样逐项决定某个域名的策略。因此，一条请求没有出现在预期规则记录中时，不能只在 Rule 里不断添加更宽泛的匹配。应先确认请求是否进入客户端处理、系统绕过设置是否参与、目标信息是否可见，以及域名到 IP 的解析是否成功。把这些前置条件查清后，再决定是否需要增加规则，通常比直接替换全部配置更容易定位问题。

bypass-system 的含义与限制

[General]
bypass-system = true

bypass-system 用于控制是否绕过系统相关的部分流量。它不是“所有本地地址直接连接”的同义词，也不是让某个网站访问成功的通用开关。系统相关请求的处理可能早于普通规则观察，因此启用该参数后，不应期望所有流量都能在 Rule 中找到对应命中记录。若现有配置使用这一设置，应先理解保留它的理由；不要为了让记录看起来完整就直接关闭，更不要把它当作改变所有应用行为的保证。

排查绕过设置时，先区分目标是公网服务、局域网设备还是系统组件。公网域名的匹配通常可以通过精确 DOMAIN 规则观察，而局域网设备可能受地址范围、网络环境和系统行为共同影响。先记录访问地址与当前 Wi-Fi 或蜂窝网络，再做一次有限改动。若只是一个局域网目标存在问题，应围绕该目标验证，不要用调整整体系统绕过的方式掩盖地址、端口或局域网隔离问题。

解析结果与连接策略不是同一件事

域名规则判断目标名称，IP 规则判断目标地址；二者之间常有解析过程。DNS 成功返回地址，并不表示该地址可达；选中 PROXY，也不表示解析过程必然与该代理采用完全相同的路径。阅读配置时应分别确认 DNS 相关设置、是否已有缓存，以及请求记录中实际使用的目标。只看到一个解析地址变化，就认定域名规则没有生效，会把解析层与路由层混为一谈。

同一域名可以返回多个 IPv4 或 IPv6 地址，地址也可能随网络和时间改变。如果规则只覆盖某个 IPv4 地址，下一次解析选择 IPv6 时就可能走不同策略。此时优先检查是否应该使用域名规则表达需求，而不是继续把每次看到的地址追加进列表。只有确实要控制一个稳定网段或明确地址时，才使用 IP-CIDR 或 IP-CIDR6。规则的匹配对象应与实际需求保持一致，维护起来才不会依赖偶然的解析结果。

no-resolve 是规则选项，不是 DNS 开关

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,fc00::/7,DIRECT,no-resolve
FINAL,PROXY

no-resolve 通常用于 IP 类规则，表示不要仅为了检查这一条规则而额外触发域名解析。它不表示整个客户端停止 DNS，也不保证之后的连接不需要解析。如果当前已经有可用于匹配的目标 IP，规则仍可能命中；如果只有域名且没有适用地址，这条规则可能无法据此作出判断，请求继续向后检查。将它理解为“禁止任何解析”或“让所有域名自动按地址匹配”，都会得到错误预期。

若某个目标只有在删除 no-resolve 后才改变行为，应检查变化是否来自新增的解析动作，而不是简单判定选项好坏。记录解析前后获取到的地址、命中的规则和最终策略，再决定保留哪种行为。尤其在同时存在域名规则与 GEOIP 规则时，早期域名规则可能已经结束匹配，后面的解析选项根本没有参与。验证选项必须先确认执行路径确实到达该条规则。

处理 DNS 问题时，先用一个已知可访问的目标作对照，再检查问题是否只影响单个域名、是否只在某种网络发生，以及是否伴随 IPv6 路径变化。每次只调整一个明确参数，测试后保留结果。不要随意把网上的整段 General 覆盖到当前文件中；其中的解析、绕过与其他全局选项可能互相影响。若需要先恢复基本连接，可返回FAQ 的连接排查说明，按解析与连接两个层次分开核对。

DOMAIN、后缀、关键字与 USER-AGENT

域名规则应根据需要控制的范围选择，而不是一律使用最宽泛的写法。DOMAIN 适合精确主机名，DOMAIN-SUFFIX 适合一个域名及其子域，DOMAIN-KEYWORD 适合在域名中查找指定字符串。三者都不是完整 URL 匹配：路径、查询参数、页面标题与浏览器里显示的文字，不属于这些规则的匹配范围。先确定目标主机，再选择最小的覆盖范围，可以减少误匹配和难以解释的访问变化。

精确匹配与后缀匹配

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

DOMAIN,api.example.com,DIRECT 只表达对这个主机名的精确判断，不自动包含 www.example.com，也不包含 api.example.com 下的其他子域。DOMAIN-SUFFIX,example.com,PROXY 则用于 example.com 及其子域。上例中，api.example.com 因为先命中精确规则而使用 DIRECT，其他属于 example.com 范围的主机再由后缀规则处理。若把后缀规则移到前面，精确例外就没有机会执行，这也是规则顺序的重要性。

后缀匹配具有域名边界含义，不应当作任意字符串搜索。需要覆盖 example.com 时，使用该域名作为后缀，而不是在开头添加浏览器地址里的协议部分，也不用在末尾附上斜杠。不要把 DOMAIN-SUFFIX,example.com 理解为匹配所有包含“example.com”字符的任意名称；如果需求确实是字符串包含关系，应明确使用 DOMAIN-KEYWORD，并额外检查范围是否过宽。

关键字规则应先评估误命中

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

DOMAIN-KEYWORD,example,PROXY 会检查域名是否包含 example 字符串，其覆盖面比 example.com 的后缀规则更广。它可能同时覆盖不同后缀、不同所有者的域名，因此不适合仅为了少写几行就替代一组已知精确域名。若需求是某个站点的完整功能，先从实际请求记录提取必要主机，逐一确认用途，再决定是否用后缀合并。过宽规则带来的问题往往不是语法报错，而是无关请求被悄悄改变策略。

USER-AGENT 的可见性限制

[Rule]
USER-AGENT,ExampleClient*,PROXY
FINAL,DIRECT

USER-AGENT 根据能够获取到的 User-Agent 内容匹配，上例中的 ExampleClient 是解释通配模式的示例值。它不是按应用名称选择流量，也不会自动识别设备上的所有应用。加密请求中的 HTTP 头通常不能仅凭普通连接信息直接读取，因此这类规则的适用性受请求类型及可见信息限制。不要因为某应用的网页请求曾经命中，就推断该应用的所有连接都会按同样方式处理，更不要为追求命中而随意扩大解密范围。

验证域名规则时，应同时查看重定向后的目标与页面依赖域名。打开一个页面可能先访问主域，再跳转到登录域，随后请求图片、接口与静态资源；这些连接分别判断。若只有登录失败，优先检查登录流程中的实际主机，而不是反复修改首页规则。如果请求记录只显示 IP，也应先检查域名信息是否可获取，而不是把没有名称的请求强行解释成某条 DOMAIN 规则失效。

建议以精确规则建立可验证的最小集合，再根据实际观察合并成后缀规则。新增一项后至少检查目标访问与一个无关对照目标，确认既解决预期请求，也没有扩大影响。删除旧规则前记录原来的命中位置，避免把依赖它的例外一并移除。对于经常变化的业务域名，维护原则仍是依据当前实际请求，而不是根据名称相似性猜测关联；名称看起来相近，不代表应该使用同一种策略。

IP-CIDR、IP-CIDR6 与 GEOIP

IP 类规则用于判断目标地址，不负责判断一个网站由谁运营，也不保证地址对应的服务性质。IP-CIDR 处理 IPv4 网段，IP-CIDR6 处理 IPv6 网段，GEOIP 根据地址数据库进行地区归类。它们适合表达明确的地址范围或作为域名规则之后的补充条件。若需求本来就是“某个域名采用某种策略”，通常先写域名规则更直接；将当前解析到的一两个 IP 当作网站的永久地址，会使规则很快失去覆盖。

读懂 CIDR 中的前缀长度

[Rule]
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR6,2001:db8::10/128,DIRECT,no-resolve
FINAL,PROXY

IPv4 的 /32 表示单个地址，/16 表示按前十六位确定的地址范围；IPv6 的 /128 表示单个地址。前缀越短，覆盖的地址通常越多。示例中的 192.0.2.10 与 2001:db8::10 属于文档示例范围，不能当成可用目标。实际填写时应确认地址与前缀共同表达的范围，不要只看前半段像不像目标地址。一个错误的宽网段可能影响大量完全无关的连接，而且不会因为覆盖太大而自动提示。

写局域网规则时，也应先确认正在使用的实际网段。192.168.0.0/16 只是常见私有地址范围的一部分，不代表所有局域网地址；IPv6 的本地范围也有不同用途。若设备访问失败，除了客户端策略，还要检查 Wi-Fi 是否允许设备互访、目标服务端口是否开放，以及目标是否只监听某个接口。DIRECT 只选择直接连接路径，不能替代局域网授权，也不能让原本不存在的服务开始响应。

GEOIP 是地址归类，不是域名标签

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

GEOIP,CN,DIRECT 表示把数据库归类为 CN 的目标地址交给 DIRECT。它不等于按域名后缀判断，也不等于按页面语言判断。一个域名可能使用分布在多个地区的服务地址，数据库也可能存在更新延迟，因此不能根据组织所在地推断每次连接都会命中同一 GEOIP 条件。若某个业务必须固定策略，应在 GEOIP 前写明确域名规则，避免依赖地址归类的间接结果。

GEOIP 与解析的关系需要结合当前请求信息判断。当目标只有域名时，地址判断可能需要可用的解析结果；当应用直接连接 IP 时，则可能已有匹配对象。给 IP 类规则增加 no-resolve 后，行为可能不同，因为该条规则不再为了自身判断额外触发解析。应同时记录目标名称、目标地址与命中规则，不能只看最终策略就判断 GEOIP 数据库是否正确。前面的域名规则已经命中时，GEOIP 根本不会参与。

为 IPv4 与 IPv6 分别设计验证

同一服务可能同时公布 IPv4 与 IPv6 地址，而应用和系统会根据网络条件选择其中一种。只写 IP-CIDR 不会自然覆盖相应的 IPv6 目标；只测试一次成功，也不能证明另一个地址族具有相同行为。排查“换网络后策略变了”时，应查看实际连接使用的地址族，再检查是否存在对应的 IP-CIDR6 条目。不要把关闭某种地址族当作所有问题的固定解决办法，先确认故障究竟发生在规则覆盖还是网络路径。

还要留意共享地址与动态解析。多个域名可能共用同一个地址，针对该地址写规则会同时影响它们；一个域名也可能经常更换地址，旧规则因此不再命中。如果只是要控制单个站点，用域名条件通常更容易表达边界。只有明确接受共享地址的影响范围，或者目标确实以 IP 形式访问时，才把地址规则作为主要依据。维护时记录网段来源与用途，避免长期保留已经失去解释依据的条目。

推荐的检查顺序是：先确认实际目标地址，再计算规则覆盖范围，再检查 no-resolve 与前置规则，最后观察连接结果。若命中正确但访问失败，应继续排查目标可达性、端口与所选路径，而不是盲目扩大网段。IP 规则解决的是分类问题，不是连通性本身。需要恢复到稳定状态时，撤回最近新增的地址规则，并用原有域名规则进行对照，比一次性清空所有配置更便于确认原因。

PROXY、DIRECT、REJECT 与匹配优先级

Rule 通常按从上到下的顺序检查，一旦命中并得到相应策略，就不再继续寻找后面的普通匹配规则。规则关键字的“精确程度”不会自动赋予它更高优先级：写在后面的 DOMAIN 不会因为比 DOMAIN-SUFFIX 更精确，就越过已经命中的前一行。维护时应先摆放明确例外，再放较大范围，最后放 FINAL。所谓优先级，首先是文件中的排列顺序，而不是域名长度、关键字名称或编辑时间。

三种策略分别做什么

PROXY 把匹配请求交给代理路径，通常需要当前选中的有效服务器或配置中明确引用的相应策略。DIRECT 使用直接连接路径，仍取决于本地网络和目标本身是否可达。REJECT 用于拒绝匹配请求，不会把请求转给另一条备用线路，也不负责将网页替换为其他内容。三者是处理结果，不是服务质量等级；把失败请求改成 PROXY 或 DIRECT，只是改变路径，不能自动修复认证、目标服务或协议参数问题。

用一个例外解释顺序

[Rule]
DOMAIN,login.example.com,DIRECT
DOMAIN,metrics.example.com,REJECT
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY

上例先处理登录主机与 metrics 主机，再处理其余 example.com 范围，之后才检查 GEOIP，最后由 FINAL 兜底。若把 DOMAIN-SUFFIX 移到最前面，两个精确主机都会先命中后缀规则，DIRECT 与 REJECT 就失去作用。阅读长配置时应从目标请求向前查找所有可能覆盖它的条件，而不是只搜索自己刚加入的那一行。看到规则存在，只能证明文本中有该行，不能证明执行路径会到达它。

FINAL 的位置决定兜底范围

FINAL 不包含域名或地址条件，写法是 FINAL,策略。它用于处理此前没有命中的请求，因此通常放在 Rule 末尾。如果在中间放置 FINAL，后面的普通规则就可能无法执行；如果重复放多个 FINAL，后面的兜底也不能按想象发挥作用。选择 FINAL,PROXY 还是 FINAL,DIRECT，应依据当前使用需求与可用路径，而不是认为其中一个是唯一正确答案。示例中的选择只为说明结构，不能替代对实际业务的判断。

REJECT 更需要控制边界。某个看起来像统计用途的域名，也可能承担配置、登录状态或其他必要请求；只凭名称猜测就拒绝，可能造成页面部分加载或应用间歇失败。新增拒绝规则前，先确认命中对象与影响范围，并准备恢复方法。验证时不仅检查目标请求是否被拒绝，还要检查正常功能是否受到影响。若功能异常，应先撤回最近的 REJECT 条目再观察，不要用更多例外掩盖最初的误判。

区分策略名与策略实际去向

本页使用 PROXY、DIRECT、REJECT 这些基础策略关键字，便于直接理解。若现有配置还使用自定义策略名称，应确认对应定义确实存在，并检查其最终指向的服务器或选择方式。名称看起来像某个地区或用途，并不能证明其实际去向。服务器被删除、订阅更新后项目变化，或者当前选项与预期不同，都可能让同一条规则得到不同连接结果。先核对策略引用，再检查服务器，不要只按显示名称推断。

调整顺序时建议按“精确例外、后缀范围、地址补充、最终兜底”组织，再用至少三个目标验证：一个应命中例外，一个应命中大范围，一个应落入 FINAL。这样能同时发现例外被遮挡和兜底提前的问题。如果需要比较两份配置，不必先比较行数，应比较相同目标在两份文件里遇到的第一条有效规则。规则更长不代表更准确；保持每一条都有明确目的，才便于长期维护与回退。

Host 与 URL Rewrite 的职责边界

Host 改变域名解析所用的地址映射，Rule 决定请求采用的策略，URL Rewrite 处理符合条件的 URL。三者位于不同层次，不应互相替代。把域名映射到某个地址，不等于让它走 DIRECT；把 HTTP 地址重定向到 HTTPS，也不等于让目标走 PROXY。排查时需要沿着“目标名称、解析地址、规则策略、请求处理”逐层检查，避免某一层发生变化后，错误地去修改另一层的配置。

Host 映射只解决名称到地址

[Host]
test.example.com = 192.0.2.10

[Rule]
DOMAIN,test.example.com,DIRECT
FINAL,PROXY

示例将 test.example.com 映射到文档地址，并单独用 DOMAIN 规则选择 DIRECT。两行各自承担不同职责，不能省去其中一行后仍期待完全相同的行为。实际使用中，应把地址替换为自己明确管理或获知的有效目标，并确认该服务能够接受这个域名。Host 不是让任意域名指向任意地址后都能正常访问的工具；服务器是否监听、站点如何识别域名、证书是否匹配，仍由目标服务决定。

HTTPS 尤其需要留意证书与主机名关系。即便解析地址已经按预期改变，客户端仍会按请求中的域名进行相关验证，映射本身不会让证书自动适配。出现证书错误时，不应通过关闭验证来掩盖问题，而应核对目标地址是否正确、服务是否提供对应域名，以及是否存在网络认证页面等干扰。如果直接访问 IP 能返回内容，也不能据此断定使用原域名的 HTTPS 请求一定成功。

URL Rewrite 先确认可观察对象

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

上例使用正则表达式匹配以 http://example.com/ 开头的 URL，再以 302 方式重定向到 HTTPS。开头的插入符限定起点，域名中的点使用反斜杠转义，避免被正则解释成任意字符。目标站点必须实际支持 HTTPS，否则重定向只是把请求带到另一个仍无法使用的地址。该示例的目标是展示语法，不代表所有站点都应这样改写，也不表达对加密流量内部路径的普遍可见性。

URL Rewrite 的输入取决于客户端能够获取的请求信息。普通加密连接中，完整路径和请求头并不会天然暴露给所有规则。不要把能匹配明文 HTTP 的示例直接套到任意 HTTPS 请求，并据此判断配置无效。涉及更深入的请求处理时，需要理解额外条件与安全影响；本手册不要求为基础分流启用这些能力。仅仅希望某个域名改变连接路径时，使用 Rule 中的域名条件通常更合适。

正则范围与重定向循环

正则表达式比域名后缀匹配更灵活，也更容易写得过宽。没有起点限制、没有转义的点、跨域名边界的通配，都可能让不相关 URL 被处理。建议先限定协议和明确主机，再考虑路径范围；每次扩展都用一个应匹配与一个不应匹配的请求对照。若不确定表达式含义，先停留在精确示例，不要把未知的长表达式加入现有配置，更不要只根据复制来源的说明推断其实际覆盖面。

重定向后还可能被站点再次重定向。若本地规则把一个地址改到目标地址，而站点又把它送回原处，就会形成循环，表现为页面反复跳转或浏览器报告重定向过多。此时应临时移除相关改写，观察原始站点行为，再判断是否需要缩小规则或直接取消。不要通过不断增加新重定向去压住旧循环；先画清每一步的来源与目标，才能判断问题在哪一跳出现。

维护 Host 与 URL Rewrite 时，最好分开测试：先恢复正常解析和不改写状态，确认基础连接，再只启用一条映射，最后再验证一条改写。移除 Host 后要重新发起请求并考虑已有缓存，停用改写后也应避免复用浏览器已有跳转结果。每次都记录实际目标与第一条命中规则，才能确认变化来自哪一层。对规则分流没有必要的映射或改写，应保持精简，减少隐藏依赖与后续排查成本。

配置验证、常见误判与回退流程

验证配置应按“文件、命中、连接、业务”四层进行。文件层检查选中项与语法；命中层检查请求是否匹配预期规则；连接层检查所选路径能否建立通信；业务层检查登录、接口和页面内容是否完整。前一层成功不代表后一层必然成功。例如 DOMAIN 已按预期命中 PROXY，但服务器认证失败，问题仍在连接层；页面主文档可访问而接口失败，则需要继续检查其他请求，不能只看浏览器是否打开页面。

用最小测试集确认规则

准备一个应命中精确例外的域名、一个应命中后缀范围的域名，以及一个应落入 FINAL 的对照域名。保存配置后确认 Global Routing 为 Config，重新发起目标请求，再查看应用提供的连接或请求记录。界面显示的具体字段以实际情况为准，重点记录可获取的目标、策略、服务器与错误信息。若记录没有展示全部细节，应承认观察限制，而不是把缺失字段当作规则没有执行的证据。

测试尽量使用新建连接。已经建立的长连接、页面缓存和应用后台会话可能继续沿用原先状态，使刚修改的规则看起来没有作用。可以先停止相关应用中的活动请求，再按需要重新建立连接，保持其他设置不变。不要因为一次结果未变化就立即重排全部规则；先确认确实发出了新请求，并检查目标是否经历重定向。可重复的测试条件比频繁切换开关更有助于判断。

按症状缩小范围

如果所有目标都失败，先检查连接开关、系统 VPN 配置状态、当前服务器与基本网络，不要从单个域名规则开始排查。Connectivity Test 可以辅助了解所测连接情况，但一次测试成功不等于所有业务、所有协议或所有目标都成功。首次连接的操作步骤可参阅默认服务器选择与 Connectivity Test 验证。如果只有一个站点异常，再沿着它的实际请求与规则命中继续查找。

如果只有某条规则似乎失效，先检查上方是否存在更宽的 DOMAIN-SUFFIX、DOMAIN-KEYWORD、地址规则或提前出现的 FINAL。随后检查关键字、半角逗号、目标名称与策略引用。若命中正确却结果不符，应把“规则选择正确”和“连接能够成功”分开处理。不要为修复连接失败而不断增加同义规则；多条规则指向同一个失败路径，只会使配置更复杂，不会改变根因。

回退应能恢复到明确状态

开始修改前保留当前可用文件的副本，并记录当前选中服务器与 Global Routing。发现异常后，先撤回最近一项修改；如果修改范围太大，就切回已确认可用的配置，再按相同目标测试。回退后仍失败，说明问题可能不只来自规则，例如网络条件已经变化、服务器信息不再有效或目标服务本身异常。此时应继续按连接层排查，而不是认定备份文件也被改变。

从远程来源更新配置前，要先确认本地修改是否会被覆盖。把自己的精确例外与修改理由单独记录，更新后逐项核对，而不是假定新文件一定保留旧内容。更新订阅与更新配置也应分开执行，分别验证服务器列表和规则结果。涉及导入入口时，可查阅Subscribe、Add Server、扫码与剪贴板导入说明，避免把连接信息导入问题误当成 Rule 解析问题。

最后整理一份可分享的最小问题描述：设备上的当前网络类型、Global Routing 姿态、出问题的公开目标、预期策略、实际观察以及相关的少量规则。删去密码、完整订阅链接、认证字段和个人访问记录；不需要公开整份配置才能解释顺序问题。仍有疑问时可按FAQ逐项对照，尚未完成基础流程则返回教程。一份可靠配置的标准，是每条规则目的清晰、结果可验证、出现问题时能准确回退。