Shadowrocket
规则与配置大全

01 / FILE STRUCTURE

配置文件结构与生效入口

配置文件与服务器信息分开管理

Shadowrocket 的服务器记录与配置文件承担不同任务。服务器记录保存连接目标、端口、协议和认证参数；配置文件说明请求如何匹配、采用哪种策略，以及怎样处理部分解析与请求行为。用户已有自己的订阅或服务器信息，是本手册的操作前提。导入服务器后能够选中它，并不表示某份规则已经启用；反过来，一份规则可以正常保存，也不表示其中的 PROXY 已经有可用的连接目标。

开始修改前，先到 Home 确认选中的服务器，再到 Config 确认当前使用的配置文件，最后检查 Global Routing。配置姿态 Config 才是查验文件内分流规则的常规入口。Proxy 与 Direct 用于改变全局路由姿态，不能用它们的测试结果直接判断某条域名规则是否写对。服务器、文件、全局姿态这三处应分别记录，避免改完一处后把另一处的状态误认为已经同步改变。

按分段标题读取文件

配置文件采用分段文本结构，方括号包围的标题标识后续内容所属的区域。[General] 放置全局参数；[Rule] 按行列出匹配条件与策略；[Host] 保存指定域名的静态映射；[URL Rewrite] 描述满足条件的 URL 处理方式。分段标题本身不是规则，也不参与请求匹配。把一条 DOMAIN-SUFFIX 写在 [General] 下，不会因为文本中出现了正确关键字就自动变成有效分流规则。

这份片段只表达两个路由意图：example.com 及其子域名使用 PROXY，其余交给 DIRECT。它没有包含服务器凭据，也不提供任何连接服务。示例域名只用于说明语法，不能据此期待某项业务能够访问。阅读完整文件时，先找所有分段标题，再在 [Rule] 中定位 FINAL；不要从第一行一直寻找某个域名而忽略它实际上位于哪个区域。

逗号、等号与注释各有用途

[General] 中常见写法是键、等号和值，例如 dns-server = system；[Rule] 中通常以英文逗号分隔类型、匹配内容和策略，例如 DOMAIN,example.com,DIRECT。两种格式不能互换。编辑时使用半角标点，避免输入法把逗号换成中文逗号。注释可单独以 # 开头，用于记录意图；不要依靠行尾中文备注解释某条规则，单独一行更便于检查字段边界与复制文本。

并非每份配置都需要四个分段。没有静态映射时，可以不写 [Host]；没有 URL 处理需求时，也不必添加 [URL Rewrite]。从最少参数开始，逐步增加有明确用途的内容，比把多个文件的段落全部拼接起来更容易验证。遇到重复分段或重复参数时，应整理成单一、明确的定义，不依赖重复项的覆盖行为；保留原文件副本后再进行这种结构性清理。

02 / GENERAL & DNS

General 参数与 DNS 设置

先确定网络边界，再设置绕过范围

[General] 中的参数会影响后续规则运行的环境。bypass-system = true 用于绕过系统相关流量，不等同于为所有 Apple 域名设置 DIRECT，也不应把它理解成一条替代 [Rule] 的通用规则。skip-proxy 用于指定跳过代理处理的地址范围；如果某个请求在进入规则评估前已经被绕过，修改后面的 PROXY 规则可能不会得到预期结果。排错时需要同时查看全局绕过设置与 [Rule]，而不是只移动规则行。

局域网设备通常需要根据实际地址规划选择绕过范围。192.168.0.0/16 与 10.0.0.0/8 是私有地址范围示例，不表示用户当前网络一定使用这些地址。应先查看设备的网络信息和目标服务地址，再决定是否保留相关范围。范围写得过大，可能把原本需要经过代理访问的内部目标一起排除；范围写得过小，则可能使打印、存储或其他本地访问进入并不合适的连接路径。

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

DNS 解析与路由策略不是同一件事

dns-server = system 表示使用系统 DNS 设置，是便于建立基线的写法。DNS 的任务是把域名解析为地址，路由规则的任务是决定请求采用哪个策略。一个域名能够解析，不代表选中的服务器能够连接该地址；一个请求命中 DIRECT，也不表示 DNS 查询必然采用用户想象中的路径。需要把解析结果、规则命中和最终连接这三个观察点分别检查，才能避免把连接超时全部归因于 DNS。

更改 DNS 前，先明确需要解决的问题：是域名没有解析结果、结果不符合预期，还是请求已解析但连接失败。若问题只在一个目标出现，应检查该目标与 [Host] 映射，不要立即替换整个文件的 DNS 设置。若多个域名都无法解析，再检查当前网络的系统 DNS 可用性。加密 DNS 地址、引导解析与连接路径之间还可能存在依赖关系，不能仅凭地址形式就判断设置适合当前网络。

规则是否触发解析，要看匹配条件

DOMAIN 类规则主要依据域名进行判断；IP-CIDR 与 GEOIP 需要能够用于判断的目标地址。请求本身以域名发起时，地址类规则可能涉及解析过程。给 IP-CIDR 增加 no-resolve 的含义，是避免为了该条地址规则额外进行域名解析，不是关闭整个客户端的 DNS。它适合明确的地址访问或避免特定地址规则引发解析的场景，但也可能使尚未得到地址的域名请求无法命中这条规则。

应用与系统可能缓存解析结果，网页连接也可能重复使用已经建立的会话。修改 DNS 后，直接刷新同一页面不一定是在观察一条新解析记录。验证时应重新发起连接，必要时重新连接 Shadowrocket，并留意日志对应的时间和目标。先保留一份 dns-server = system 的可用配置作为对照，每次只改一个与解析相关的参数，能区分新设置的效果与旧缓存造成的表面变化。

如果问题仅在切换 Wi-Fi 与蜂窝网络后出现，应分别保存两种网络下的现象。系统 DNS、本地地址范围和服务器可达性都可能随网络改变。此时不宜用扩大 skip-proxy 来掩盖错误，也不应反复追加重复 DNS 参数。先恢复可用基线、确认网络差异，再查阅疑难解答中的连接排查；确定需要长期修改后，才把参数写入日常使用的配置。

03 / DOMAIN MATCHING

DOMAIN 系列规则的范围

DOMAIN 只匹配指定域名

DOMAIN 用于精确域名匹配。DOMAIN,api.example.com,PROXY 针对 api.example.com，不会自动包含 example.com，也不会因为域名中含有相同文本就覆盖 otherexample.com。规则字段写主机名，不写协议、路径、端口或查询参数。把完整网页地址直接填入 DOMAIN 的匹配字段，会把 URL 与域名两个层次混淆；如果需求依赖路径，应先判断是否属于 URL 处理，而不是扩大域名规则。

精确规则适合给某个服务入口设置例外，例如整个 example.com 使用 PROXY，但 status.example.com 需要 DIRECT。这个例外必须放在较宽的 DOMAIN-SUFFIX 前面。若后缀规则已经先命中，后面的精确规则就没有机会参与判断。这里的优先级来自行的位置，不是来自 DOMAIN 比 DOMAIN-SUFFIX 看起来更具体；客户端不会自动替用户按精确程度重排文件。

DOMAIN-SUFFIX 匹配域名边界

DOMAIN-SUFFIX,example.com,PROXY 匹配 example.com 及其子域名，例如 www.example.com 与 a.b.example.com。后缀匹配依据域名层级边界，不等同于任意文本包含，因此不应把 otherexample.com 当作它的子域名。后缀字段通常不需要前置点号，也不需要写星号。将 *.example.com 作为普通后缀示例复制，容易把通配符思路带入不对应的规则语法。

[Rule]
# 精确例外在前
DOMAIN,status.example.com,DIRECT
# 主域名与子域名在后
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

同一个网页可能同时请求页面主域名、图片域名、认证域名与接口域名。只给地址栏中的域名加规则，并不意味着这些依赖都采用相同策略。先从连接记录识别实际请求的主机名，再决定应使用几条 DOMAIN，还是一个能够合理覆盖它们的 DOMAIN-SUFFIX。不要把多个不相关的目标压成一个很短的关键词，否则排查一个页面时可能改变其他应用的流量路径。

DOMAIN-KEYWORD 匹配文本包含

DOMAIN-KEYWORD,example,PROXY 依据域名中是否包含 example 文本进行判断，覆盖范围可能远大于 example.com。它可以匹配包含该文本的其他域名，不要求相同的注册域名边界。关键词适合边界明确、确实需要文本覆盖的场景；若本意只是覆盖一个主域名及其子域名，应优先使用 DOMAIN-SUFFIX。关键词越短，越需要检查意外命中的范围。

把规则意图写成可验证的条件

添加域名规则前，用一句话描述它的范围，例如“只有 status.example.com 直连”，然后把这句话与实际字段对照。若描述包含“所有子域名”，应检查是不是后缀规则；若描述包含“路径为某一目录”，说明域名规则不足以表达需求。对国际化域名，应核对请求记录中实际出现的主机名形式，避免显示名称与配置文本不一致。不要依赖网页标题或应用名称来猜测域名。

验证时分别访问需要命中的目标与一个不应命中的目标，形成正反两组测试。记录主机名、命中的规则和策略，而不只记录页面是否打开。页面成功可能是 DIRECT 也能完成访问，并不能证明 PROXY 规则生效；页面失败也可能由服务器或目标服务引起。修改后若发现不相关请求被带入 PROXY，先缩小关键词范围，再检查行顺序，不要在文件末尾继续叠加同类规则。

04 / ADDRESS & REQUEST

GEOIP、IP-CIDR 与 USER-AGENT

IP-CIDR 按地址与前缀匹配

IP-CIDR 用于 IPv4 地址范围，例如 IP-CIDR,192.168.0.0/16,DIRECT。斜杠后的数字是前缀长度，不是端口，也不是要匹配的地址数量；前缀越长，范围越小。一个单独的 IPv4 地址可以用 /32 表示。修改网段规则时，应把目标实际地址与网段边界一起核对，不能仅凭地址开头相似就认为目标在范围内。写错前缀可能把本来无关的大量请求归入同一策略。

局域网范围的处理要与 [General] 中的 skip-proxy 一起理解。若某范围已经被全局绕过，在 [Rule] 中再写相同范围的 DIRECT，可能只是重复表达，并不能用来证明规则引擎命中了该行。若需要研究某条规则的行为，应先明确请求是否进入规则判断。日常配置可以保留必要的保护性直连，但注释中应说明它的用途，不要把重复条目当作提高优先级的方法。

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

IP-CIDR6 与 no-resolve 的边界

IP-CIDR6 用于 IPv6 地址范围，不能把 IPv6 文本直接放进 IP-CIDR 并期待按同样方式处理。fc00::/7 是本地 IPv6 范围示例，不代表所有 IPv6 请求都应 DIRECT。目标域名可能同时得到 IPv4 与 IPv6 结果，因此只观察其中一种地址会遗漏实际连接路径。出现“同一个域名有时命中、有时不命中”时，应先检查请求使用了哪种地址，再决定是否补充相应规则。

no-resolve 是地址规则的附加参数，用来避免为匹配该行主动解析域名。对于明确以地址发起的请求，已有地址可以直接参与判断；对于尚未有地址可供匹配的域名请求，它可能使该行无法据此命中。这不是语法错误，而是使用条件不同。不要为了缩短解析过程给所有地址规则机械追加 no-resolve，也不要把它看作一种强制直连或强制使用远端 DNS 的策略。

GEOIP 不等同于域名归属

GEOIP,CN,DIRECT 根据目标 IP 的地区分类进行判断，不是根据域名后缀、网页语言或服务品牌判断。一个域名可能解析到不同地区的地址，地址库分类也不能代表实时网络质量。若业务需要稳定的特定域名策略，应先用 DOMAIN 或 DOMAIN-SUFFIX 明确表达，再把 GEOIP 放在较后位置处理剩余流量。否则地址变化可能让同一服务在不同网络下采用不同策略。

USER-AGENT 依赖可见的请求字段

USER-AGENT 匹配可见 HTTP 请求中的 User-Agent 内容，不是按应用显示名称识别进程。示例 USER-AGENT,ExampleClient*,DIRECT 表达一个前缀匹配意图，但只有能够读取该请求字段时才有判断依据。普通加密连接中的 HTTP 请求头通常不可直接看到；不能因为应用确实发送了这个字段，就认定客户端一定能够拿它做规则匹配。它不适合作为所有应用分流的通用替代方案。

[Rule]
USER-AGENT,ExampleClient*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

为了让 USER-AGENT 生效而启用请求解密，会引入额外的信任与兼容性要求，不属于初次分流的必要步骤。若需求能通过域名规则表达，先采用域名规则。地址规则与请求特征规则都应有清楚的验证前提：可供判断的地址是否存在、请求字段是否可见、前面的规则是否已经命中。排查时逐项回答这些问题，比把规则从文件底部拖到顶部更有依据。

05 / POLICY & PRIORITY

PROXY、DIRECT、REJECT 与匹配顺序

策略说明命中后如何处理

规则类型决定检查什么，策略决定命中后怎样处理。PROXY 将请求交给代理路径，简单配置中通常使用当前选中的服务器；若文件包含策略组或其他关联设置，还需检查实际选中的成员。DIRECT 表示直接连接目标，不经过代理服务器转发，但流量仍然受当前网络、DNS 与目标服务状态影响。REJECT 表示拒绝匹配的请求，不应把它当作连接失败时自动切换的备用策略。

配置中的 PROXY、DIRECT、REJECT 是策略关键字；Home 中的服务器选择与 Global Routing 的 Proxy、Direct 是界面状态。两者大小写与使用位置不同，不能混写成一个概念。把某条规则改成 PROXY 不会自动修正服务器密码、端口或协议参数。若所有命中 PROXY 的请求都失败，应优先检查代理路径，而不是把每条规则逐一换成 DIRECT 后认定问题已经解决。

Global Routing 三种姿态

这张表用于建立测试姿态，不表示任何情况下所有流量都能忽略系统绕过与其他全局设置。诊断时可以短暂使用 Proxy 或 Direct 比较连接路径，但验证完成后应恢复 Config，再对照当前文件检查规则命中。否则“改了文件没有变化”可能只是仍停留在全局代理或全局直连姿态。记录测试结果时，把姿态与目标一起写下，便于区分同一目标在不同路由条件下的表现。

先命中即停止，不自动回退

[Rule] 自上而下检查，第一条满足条件的规则决定策略。更具体的规则应放在更通用的规则前面；这是一种编排原则，而不是客户端会自动执行的排序算法。若前面的 DOMAIN-KEYWORD 已经匹配某域名，后面的 DOMAIN 即使更精确，也不能覆盖它。相同匹配条件重复出现时，后面的条目通常只是不可达的重复项，应整理，而不是期待后写的内容自动替代前写的内容。

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

在这份示例中，status.example.com 在第一行命中，后续后缀规则不再参与；blocked.example.com 命中 REJECT；其他 example.com 子域名使用 PROXY；余下请求再检查 GEOIP，最后由 FINAL 收尾。请求命中 PROXY 后连接失败，不会因此继续向下寻找 DIRECT。规则判断与连接执行是先后两个阶段，连接结果不能反过来改变已经完成的首条匹配。

FINAL 必须体现明确的默认意图

FINAL 不需要匹配字段，写法是 FINAL,PROXY 或 FINAL,DIRECT。它处理前面没有命中的请求，应放在 [Rule] 的最后。写在 FINAL 后面的规则没有机会处理这些剩余请求。选择默认策略前，先问“没有专门列出的目标应走哪里”，再据此设置；不要因为复制的文件使用了某个默认策略就原样保留。两个 FINAL 也不能形成主备线路，第二个不是故障切换机制。

加入 REJECT 时，范围应尽量具体并单独测试。一个页面的统计、图片、认证与业务接口可能共享域名，粗放拒绝后可能出现页面打开但功能异常。应先判断是否确实需要拒绝、是否可用精确域名表达，再观察依赖请求。恢复时删除或停用自己添加的拒绝规则，并重新发起会话；不要通过追加更晚的 DIRECT 来抵消已经在前面命中的 REJECT。

06 / HOST & URL REWRITE

Host 映射与 URL Rewrite 的边界

Host 改变地址映射，不直接决定策略

[Host] 用于指定域名与地址的静态映射，例如 lab.example.com = 192.168.1.20。它回答“这个域名应得到哪个地址”，而不是“请求应该代理还是直连”。使用这种映射后，仍然需要检查 [Rule] 对域名或目标地址的处理。示例适合说明用户自己管理的本地服务；只有确认该地址确实对应预期目标时才应采用，不要把示例地址直接用于真实网站的访问。

[Host]
lab.example.com = 192.168.1.20

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

静态映射会固定解析结果，因此目标地址变化时需要更新对应的映射记录。若原服务通过多个地址分配负载，把它固定为一个地址可能使访问绕过正常分配过程。修改前先保留原始解析情况，确认域名、地址与使用目的都一致。只在一台设备上成功，不表示该映射适合其他网络；例如本地地址离开对应 Wi-Fi 后可能无法访问，此时应检查网络范围，而不是不断重试同一映射。

映射不会替代证书与业务身份

通过域名访问 HTTPS 服务时，连接目标地址与证书对应的域名是两个不同条件。[Host] 改变地址，不会把服务证书变成适用于任意域名的证书，也不会修复服务端名称配置。出现证书错误时，应确认服务本身为该域名提供正确证书，不能把静态映射当作绕过验证的办法。回退映射后重新建立连接，有助于区分原始服务问题与自己加入的地址固定行为。

URL Rewrite 用正则表达式描述目标

[URL Rewrite] 使用 URL 匹配表达式与相应处理动作。下面的示例把特定路径重定向到另一个路径，302 表示临时重定向响应。它不是代理策略，也不会把 PROXY 自动改成 DIRECT。规则里的 example.com 是文本示例，不是外部服务入口。使用前应确认动作适用于当前请求环境，并从一个具体路径开始验证，避免写成覆盖整个域名全部路径的宽泛表达式。

[URL Rewrite]
^http://example\.com/legacy$ http://example.com/current 302

表达式中的 ^ 限定起点，$ 限定终点，域名里的点号通过反斜杠写成 \.，防止被正则表达式解释为任意字符。这个例子只匹配以 /legacy 结尾且没有额外查询参数的完整地址；/legacy/ 或带查询参数的请求不属于同一个条件。若需要保留路径或参数，应先理解捕获组与替换关系再扩展，不要随意用 .* 把所有内容吞入匹配范围。

HTTPS 的可见性限制必须先确认

普通 HTTPS 连接不会直接暴露完整 HTTP URL 路径。对这类请求应用路径级重写，通常涉及额外的请求解密条件与证书信任配置；仅在文件中加入 [URL Rewrite] 并不意味着路径已经可见。部分应用还会采取额外的证书检查，启用相关功能可能影响兼容性。没有明确需求时，保留默认连接行为；域名分流不需要为了路径重写而同时增加解密设置。

重定向还会生成新的访问目标，新请求需要重新评估其路由与业务条件。如果目标又被另一条重写规则改回原路径，就可能形成循环。验证时记录原 URL、命中的表达式、返回位置与最终目标，不能只看浏览器最后显示的页面。先停用其他重写规则做单条测试，再逐项恢复，是区分规则相互影响与目标服务自身跳转的方法。遇到持续跳转，应先回退重写，不要扩大正则范围。

07 / EDITING WORKFLOW

配置修改流程与常见规则写法

复制当前文件，建立最小变更

修改前保留当前可用配置，使用能够辨认用途的名称区分原文件与测试文件。先写清要改变的目标、匹配范围和预期策略，再到 Config 打开对应文件进行编辑。保存后确认测试文件已成为当前使用的配置，Global Routing 设为 Config，然后重新发起目标请求。不要同时更换服务器、DNS、默认策略与多条规则，否则结果变化时无法确定是哪一项修改造成的。

用户已有的服务器订阅与远程配置可能有不同更新入口。更新服务器列表，不应被理解为必然更新了本地规则；重新获取远程配置，则可能覆盖对该文件做过的本地修改。编辑远程内容前先弄清保存与更新方式，将自己的规则意图保留在副本或独立记录中。不能只依赖文件名记住哪些内容是自己新增的，最好用独立注释说明每一组规则对应的用途。

默认直连，只代理指定域名

如果需求是让已明确列出的域名使用代理，其余直连，可采用以下结构。DOMAIN-SUFFIX 覆盖示例主域名及子域名，FINAL,DIRECT 明确处理剩余请求。增加新目标时，先判断它是否已在现有后缀范围内；若已经覆盖，不必重复追加相同策略。业务依赖使用其他域名时，应根据真实连接记录补充，而不是猜测一个更宽的关键词覆盖所有可能目标。

[General]
dns-server = system

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

默认代理，给具体目标设置直连例外

另一类需求是将未专门列出的请求交给代理，同时保留局域网或特定域名的直连例外。这个结构必须先确认当前服务器可用，因为 FINAL,PROXY 会使剩余请求依赖该连接路径。地址例外与域名例外应分别写清，不要为了一个内部域名直接把所有私有地址之外的范围都扩大。若日常配置已经包含全局绕过，先对照相关参数，再判断是否需要重复的网段规则。

[Rule]
DOMAIN,lab.example.com,DIRECT
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
FINAL,PROXY

这两种结构都不是固定推荐方案，而是不同默认意图的表达。它们不能直接混合成两个 FINAL；合并时必须先决定最终默认策略，然后把所需的具体规则放在它前面。若只想改变一个域名，不应顺便修改整个配置的默认策略。验证例外时，检查该目标是否命中具体条目，再检查另一个未列出的目标是否采用 FINAL，形成两组相互补充的结果。

合并文件先处理冲突，再处理长度

从自己保存的多份配置整理规则时，先按类型与匹配范围找重叠项。完全相同的条件却指定不同策略，需要决定哪一个代表当前意图；精确域名与后缀重叠时，需要保留正确的例外顺序；关键词与后缀重叠时，需要检查关键词是否过宽。规则数量多不表示覆盖更准确，重复与不可达条目只会增加查阅成本。整理后仍应保持单一、明确的 FINAL。

把完整文件分成局部例外、服务域名、地址范围和默认策略四组，是便于人工查阅的组织方法，不是必须使用的固定顺序。每组之间可用注释说明意图，但实际优先级仍由行号决定。若某个地址例外必须压过一个广泛域名条件，就应根据真实需求调整位置。每完成一组整理，使用同一目标重新测试并记录结果，避免一次重排后无法找回原有行为。

导入入口与服务器字段的操作细节不在本页重复展开。需要重新整理已有记录时，可先查阅订阅导入方法；需要理解协议字段时，查阅协议与参数说明。不要用调整规则来弥补认证或传输参数错误，这些错误发生在另一层。

08 / VERIFICATION

规则命中验证与故障排查

一次测试记录四项事实

验证一条规则时，至少记录目标主机名或地址、当前 Global Routing、命中的规则或策略、最终连接结果。页面是否打开只是最后一项，不能代替前面的路由证据。在当前连接或日志记录中查看目标与策略时，应以应用实际显示的内容为准；不同请求可能对应多个域名与多条连接。先选一个能反复发起的明确目标，再追踪对应的新记录，避免把后台请求当成正在测试的目标。

Connectivity Test 用于检查连接状态，但不能证明某个网页的每个依赖都采用预期规则。测试服务器可达后，仍要发起真实目标请求并查看命中情况。规则修改后，已建立连接可能继续存在，浏览器也可能使用缓存内容；必要时重新连接并建立新会话。比较修改前后时，应保持网络、服务器和目标一致，只改变待验证的规则，以免观察结果受到其他条件变化影响。

配置没有变化，先查生效链

如果编辑后完全没有变化，按文件、姿态、顺序三个层次排查。先确认保存的是当前使用文件，而不是同名副本；再确认 Global Routing 为 Config；最后从 [Rule] 顶部逐行检查有没有更早的条件已经覆盖目标。尤其留意宽泛关键词、较大的网段与提前出现的 FINAL。不要因为刚加的行语法正确，就跳过前面的规则；首条匹配决定的是整个有序列表的结果。

命中正确，不等于连接必然成功

如果记录已经显示预期策略，问题应转向执行路径。PROXY 失败时，检查 Home 中选中的服务器是否仍有效，认证字段、端口、传输条件是否与已有信息一致；DIRECT 失败时，检查当前网络是否能直接连接目标；REJECT 则应核对拒绝是否本来就是意图。不要把明确的连接失败继续当作规则优先级问题。必要时使用 Proxy 与 Direct 做短暂对照，再恢复 Config 重测。

只有部分功能失败时，把页面主请求与后续接口分开看。登录、文件上传、图片加载与持续连接可能使用不同域名或不同连接方式，单个页面成功并不能代表所有依赖成功。先检查是否有 REJECT 命中关键接口，再检查依赖是否落入不符合预期的 FINAL。若只有某类传输失败，应回到服务器与协议能力检查，不宜通过扩大域名匹配范围来替代传输层诊断。

用最小配置定位，再恢复完整文件

最小配置保留必要的 [General]、一条目标规则与一个 FINAL，暂时移除自己加入的 Host、重写与宽泛关键词。它用于判断基础匹配是否符合预期，不是让用户永久丢弃原配置。如果最小文件工作正常，逐组恢复原有内容，直到出现差异；如果仍失败，先检查目标名称、解析结果与服务器路径。每轮只恢复一组，才能把问题定位到具体条件，而不是只能知道完整文件有问题。

回退时同时恢复配置内容和测试姿态，并重新发起连接。对问题做记录可包含目标、网络类型、规则片段与报错描述，但应删去订阅链接中的认证参数、服务器密码与其他私密字段。将真实凭据直接复制到排查记录，会把原本局部的连接问题变成信息暴露问题。只保留能够解释结构的示例文本，即可讨论规则顺序、分段位置与字段数量。

首次连接与 VPN 配置授权问题请返回快速上手；购买、恢复与系统要求请查阅已购恢复说明，系统要求以 App Store 页面标注为准；更集中的现象对照见疑难解答。本页用于解释配置机制，不把应用购买、服务器连接与规则匹配混成同一个故障入口。