Shadowrocket 规则参考

配置文件结构与加载边界

Shadowrocket 的配置文件可以包含多个以方括号标记的段落。段名决定后续文本的解释方式，而不是文件中的视觉分组。[Rule] 下的域名规则与 [Host] 下的地址映射，虽然都可能出现同一个域名，作用却不同。开始修改前，应先确认当前启用的是哪份配置，再进入对应段落编辑。只把文件保存到 Config 列表，并不等于已经选中它。

先区分服务器信息、订阅与配置

服务器信息回答连接到哪里、采用什么协议、如何完成身份校验；订阅用于批量取得并更新这些条目；规则配置回答哪些请求采用哪种处理策略。这三者可能在同一工作流程里出现，却不能互相替代。已有服务器能连接，不代表规则文件已经生效；规则文件能够读取，也不代表其中引用的代理出口已经可用。遇到导入后没有预期结果，应先判断缺的是服务器条目，还是分流配置。

在 Config 中检查文件时，要同时记录文件名称、当前选择状态和来源。远程文件后续更新可能覆盖本地修改，因此第一次试验应保留原始副本。不要在尚未理解原配置的情况下，把整段内容替换成网络上的片段。本页示例只用于解释语法，不包含认证参数，也不构成可直接连接的完整配置。

四个段落分别负责什么

[General]
dns-server = system

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

[Host]
fixed.example.com = 192.0.2.10

上面的 192.0.2.10 是文档示例地址，不是可供使用的服务器。阅读这段文本时，应先看到段名，再看每行的分隔方式：General 与 Host 使用等号表达键值关系，Rule 通常使用英文逗号分隔规则类型、条件与策略。全角逗号、不可见空格以及从富文本复制来的标点，都会让看似相同的内容变成不同的输入。

编辑前建立最小检查清单

先记下 Global Routing 当前姿态，再确认 SERVER 中选择的服务器，最后确认 Config 中正在使用的文件。三处同时记录，才能避免把出口切换误判为规则变化。如果要比较修改前后，只改一个条件并保存，然后重新发起连接测试。不要同时更换服务器、调整 DNS、重排规则，否则结果变化后无法确定原因。

对配置文件的判断还应区分“能解析”和“符合目的”。前者只是说明语法被接受，后者需要真实请求验证。例如一条写在 FINAL 后面的域名规则可能语法正确，却不会处理已经被前面兜底规则接收的请求。反过来，文件中的注释可能清楚描述了用途，但注释本身不会改变匹配行为，应以实际生效的语句为准。

General、DNS 与规则输入

General 影响规则运行的环境。域名怎样解析、哪些目标由系统路径处理，会改变后续能够观察到的请求信息。因此，分析规则之前不能只看 Rule 段。相同的规则在不同解析条件下可能出现不同结果，尤其是依赖目标地址的 GEOIP、IP-CIDR 与 IP-CIDR6。先明确解析与路由是不同阶段，再决定应修改哪一处。

DNS 解析并不等于策略选择

DNS 将域名转换为地址，分流策略决定连接如何处理。一个域名成功解析，只能说明取得了某种解析结果，不能据此判断请求会走 PROXY 还是 DIRECT。域名规则也不必等到获得地址才有匹配依据；当客户端掌握目标域名时，可以直接按照 DOMAIN 或 DOMAIN-SUFFIX 判断。地址类规则则需要目标地址，二者的输入条件并不相同。

[General]
dns-server = system

[Rule]
DOMAIN,portal.example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
FINAL,PROXY

dns-server = system 表示这里采用系统提供的 DNS。它是一个便于理解的起点，不是适用于所有网络的固定答案。若现有配置已经指定其他解析方式，应先记录其用途，不要为了套用示例而直接覆盖。网络切换、系统 DNS 状态以及所访问服务的部署方式，都可能影响最终返回的地址。

no-resolve 的范围

地址规则末尾的 no-resolve 表示不要仅为了尝试该条地址规则而触发域名解析。它不等于关闭 DNS，也不表示整条连接以后不再解析。如果请求本来已经带有可用目标地址，仍可按该地址进行判断；如果只有域名且此时没有对应地址，这条规则不能凭空得到一个地址来匹配，后续规则仍可能继续处理请求。

这一区别对排错很重要：加入 no-resolve 后，某个域名不再命中地址规则，并不一定是地址段写错，而可能是匹配时没有可用地址。不要为了强行命中而删除所有 no-resolve。应先确认目标是域名请求还是直接地址请求，再判断是否需要解析，最后比较解析开销与分流目的。

缓存、网络切换与观察时间

浏览器、应用、系统和客户端可能在不同位置保留解析或连接状态。更改 DNS 后立即刷新页面，有时仍会复用已有连接，看不到新设置的效果。测试时应重新发起请求，必要时关闭对应应用的现有会话，再按应用可用的方式清理相关缓存。一次刷新没有变化，不足以证明配置没有加载；同样，一次偶然成功也不足以证明问题已经解决。

切换无线网络与蜂窝网络后，要重新核对基础网络是否可用。若系统本身无法访问已知可达的目标，继续调整 Rule 往往不能解决底层连接问题。可以先使用 Direct 姿态做有限对照，再回到 Config 验证规则。对照结束后应恢复原姿态，避免随后把全局直连状态误当作规则分流结果。

不要把绕过范围当作普通 Rule

General 中某些设置影响哪些流量进入后续处理路径，它们与 Rule 内的 DIRECT 不是同一层含义。扩大绕过范围可能让请求根本不经过预期规则，因此不能简单地用“最后有 FINAL”推断所有流量都会被兜底。调整此类设置前，要检查现有文件说明与应用内选项，不确定用途时保留原值比批量删除更容易维持可复现性。

涉及 IPv6 的问题，还应检查域名是否同时返回不同地址族。只为 IPv4 编写地址规则，不意味着 IPv6 请求也被覆盖。优先使用能准确表达业务边界的域名规则，再按确有必要的地址范围补充。不要把停用某种地址族作为第一步；先通过记录确认实际目标地址，才能知道问题在解析、匹配还是连接路径。

DOMAIN 系列的匹配范围

域名规则通常比不断变化的目标地址更适合表达站点分流意图，但前提是客户端在匹配时能够取得目标域名。DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD 的差异主要在覆盖范围，而不是哪一种更“强”。选择规则时，应先写清希望覆盖的集合，再使用最窄且足够的条件，避免为了省一行而引入难以发现的误匹配。

DOMAIN：限定一个完整域名

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

DOMAIN 用于完整域名匹配。第一条只表达对 login.example.com 的处理，不会自动包含 example.com 或 cdn.login.example.com。适合把登录入口、接口域名等独立出来处理。规则条件中填写域名，不要附加协议头、端口或路径；把整个网页地址放进去，不会使这条域名规则变成路径规则。

如果希望只改变某一个接口请求，但同一域名下其他路径保持原状，DOMAIN 本身不能表达这种粒度。需要先判断是否真的需要路径级处理，不能仅靠在域名后面加斜杠实现。域名规则选择的是连接策略，也不会因为条件写成登录域名，就自动解决登录过程涉及的其他依赖域名。

DOMAIN-SUFFIX：包含根域名与子域名

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

DOMAIN-SUFFIX 用于域名后缀边界匹配。这里的 example.com 覆盖根域名及其子域名，例如 www.example.com 与 a.b.example.com，不是任意位置出现同样字符就算命中。notexample.com 不属于这个域名边界，example.com.other.test 也不是它的子域名。

示例中，portal 的精确例外在前，因此先按 DIRECT 处理；其余属于 example.com 的域名才由后缀规则交给 PROXY。如果把后缀规则放在第一行，portal 的例外就失去生效机会。由此可见，精确规则并没有自动获得更高优先级，是否先被检查仍由排列位置决定。

DOMAIN-KEYWORD：字符范围更宽

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

DOMAIN-KEYWORD 用于域名中的关键词匹配。它可能覆盖 example.com，也可能覆盖 myexample.test。如果真正意图是处理某一个域名及其子域名，使用关键词通常比后缀规则更宽，会让名称恰好包含同一字符的其他站点被一并处理。关键词短到只有几个常见字母时，误匹配尤其难以追踪。

因此，建议先用 DOMAIN 表达单点例外，再用 DOMAIN-SUFFIX 表达清楚的域名集合。只有确实需要跨多个无共同后缀的域名按名称片段归类，且已经检查潜在覆盖范围时，才考虑 DOMAIN-KEYWORD。不要用关键词代替维护域名清单，否则后续很难说明某次请求为什么被归类。

域名条件的边界与缺失

网页往往同时请求主站、静态资源、身份校验、接口等多个域名。主站命中了预期规则，不代表页面内的所有资源都使用同一策略。遇到页面框架正常但图片或登录失败，应按实际失败请求的域名检查，而不是继续为主域名重复添加规则。对第三方依赖的处理也应依据记录，不应猜测后批量扩大范围。

直接访问地址的连接可能没有可用域名，此时域名规则没有匹配条件。加密流量中能够获得哪些域名信息也取决于具体连接情况，不应假设所有请求都能恢复出原始名称。若记录只显示地址，应转到地址规则检查，而不是把该地址伪装成 DOMAIN 条件。术语含义可配合名词解释查阅。

GEOIP、IP-CIDR 与 USER-AGENT

当目标以地址形式出现，或者分流目的确实依赖地址归属时，可以使用地址类规则。它们与域名规则并列参与匹配，不会自动排到域名规则之后。USER-AGENT 则依据可见的请求头信息，输入条件又不同。将这些类型放在同一个列表时，需要分别理解每种条件从哪里来，否则容易把缺少输入信息误判为语法问题。

IP-CIDR 与 IP-CIDR6

[Rule]
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR,198.51.100.8/32,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXY

IP-CIDR 描述 IPv4 地址范围。斜杠后的数字是网络前缀长度，不是端口，也不是优先级。/32 对应单个 IPv4 地址，/24 对应一个更大的地址块。IP-CIDR6 用来表达 IPv6 范围，其中单个地址可用 /128 表示。示例中的地址均为文档用途，不能当作实际服务目标验证连通性。

前缀越短，覆盖范围通常越大。不要为了“确保包含目标”而随意扩大网络段，因为这可能把与目标无关的连接一并改道。编写前先确认实际地址，再确认网络边界。若地址来自某次域名解析，还要考虑该域名之后是否会返回其他地址；一次解析结果并不能代表服务长期使用的全部地址范围。

GEOIP：依据地址数据库判断

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

GEOIP 依据地址数据库中的地区归类匹配。示例表示先处理明确的域名例外，再让归入 CN 的目标地址使用 DIRECT，其余交由 FINAL。地区归类不等于域名注册地区、内容语言或服务所属机构，也不是连接速度结论。数据库与实际网络分配存在时间差，跨地区部署和地址变动也会让直觉判断与数据库结果不同。

当某个重要目标不能仅靠地区归类稳定处理时，可在 GEOIP 前面增加更明确的域名或地址例外，并写明原因。不要在没有观察结果的情况下频繁切换整个地区策略。若使用 GEOIP,CN,DIRECT,no-resolve，还需要考虑前章所述的解析限制：没有可用地址时，这条规则可能无法完成预期判断。

USER-AGENT 的适用边界

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

USER-AGENT 检查能够被客户端读取的 User-Agent 请求头。示例用通配形式表示以 ExampleClient 开头的值，仅说明规则结构，不对应某个实际应用。它不是按系统应用名称分流的通用机制，也不能从加密连接里自动得到任意请求头。应用显示名称、进程名称与 User-Agent 可能完全不同，不能互相替代填写。

对于 HTTPS，普通连接处理通常不能直接读取被加密的 HTTP 请求头，所以不要把 USER-AGENT 当作覆盖所有应用流量的依据。本页示例不要求为此增加证书或扩大解密范围。若不能确认头部可见，优先采用可验证的域名或地址规则；若目标本来就没有该请求头，这类规则同样没有匹配输入。

先选表达方式，再处理例外

维护业务域名时优先考虑域名条件；维护固定地址范围时考虑 IP-CIDR；按地址数据库归类时使用 GEOIP；只有确认请求头可读且确实需要按头部区分时再考虑 USER-AGENT。多种类型不是越多越完整，同一目标堆叠多条条件只会增加理解成本，尤其是在不同条件对应不同策略时。

验证地址规则时，要同时记录地址族、实际目标地址和命中规则。某个域名在一次测试中使用 IPv4，另一次使用 IPv6，可能自然落入不同规则。对照测试应尽量保持网络与目标一致；若需要增加 IPv6 例外，也应基于确认的范围，而不是把所有 IPv6 请求统一处理来掩盖局部配置问题。

策略、Global Routing 与优先级

规则条件回答“是否匹配”，策略回答“匹配后如何处理”。PROXY、DIRECT 与 REJECT 是本页示例使用的三种基本策略。它们与 Home 中的 Global Routing 不是同一层：Global Routing 决定采用配置分流还是全局姿态，Rule 里的策略则在配置分流过程中对单条连接给出处理结果。排错时必须先看外层姿态，再看内层规则。

三种策略的实际含义

PROXY 的前提是已有可用的服务器信息以及有效出口选择。若出口认证失败，命中 PROXY 的规则依然可能正确，只是后续连接无法完成。DIRECT 不代表请求必然成功，也不代表请求脱离所有系统网络条件。REJECT 是明确拒绝，适用于确有意图的阻断条件；不要将大范围关键词直接设为 REJECT 后，再把资源缺失当作服务器故障。

Global Routing 的三种姿态

配置姿态对应 Config，按当前配置进行分流；代理姿态对应 Proxy，用于全局代理处理；直连姿态对应 Direct，用于全局直接连接。核对规则时应回到 Config。若一直处于 Proxy 或 Direct，单纯调整 Rule 并不能证明该规则是否按预期工作。姿态对照应作为诊断步骤，而不是长期替代正确规则。

本页讨论的是进入客户端处理路径后的分流。系统层面的网络处理与 General 中的绕过范围仍可能影响实际覆盖面，因此不要把“全局”理解为所有系统流量都必定走相同路径。测试对象应是可以观察到的具体请求，不能只看状态栏是否出现连接标识就推断每个目标都采用了预期策略。

自上而下，首次匹配结束

[Rule]
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

Rule 列表通常按自上而下的顺序检查，首次命中后使用对应策略，不会继续寻找“更精确”的规则。上例把单域名例外放在后缀规则前，把明确地址范围放在地区规则前，最后才兜底。这里的排列体现的是作者意图，而不是引擎替作者计算了精确度排名。相同目标若被两条规则覆盖，前面的那条先产生结果。

FINAL 不是普通带条件规则

FINAL,PROXY 只有类型与策略，用于处理前面未匹配的请求，不需要再填写域名。将它放在中间，会让之后的规则失去处理其余请求的机会。维护时应确认只有预期的末尾兜底，不要因合并文件产生多个 FINAL。末尾使用 PROXY 还是 DIRECT 是配置目的的选择，应根据已有网络与访问需求决定，而不是认为其中一种天然正确。

重排规则前，可用纸面推演确定优先级：选一个具体域名，从第一行向下判断，到首个命中处停止。再对一个不在清单内的目标重复推演，确认其进入 FINAL。若推演结果与实际记录不同，应检查当前文件、姿态和可用输入信息，而不是先假设匹配引擎会自动按照关键词长度或域名层级排序。

Host 与 URL Rewrite 的区别

Host 与 URL Rewrite 都可能改变访问结果，但处理对象完全不同。Host 指定域名到地址的映射，URL Rewrite 按 URL 表达式执行对应处理；二者都不等同于 Rule 中的策略选择。看到某个请求访问了意外地址或跳到了另一个 URL 时，应分别检查解析映射、重写结果与分流规则，不能只在 Rule 中寻找原因。

Host：指定解析映射

[Host]
fixed.example.com = 192.0.2.10
service.example.com = 198.51.100.20

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

这里两条 Host 记录演示把完整域名映射到指定地址，地址仍是文档示例值。第一条 Rule 另行决定 fixed.example.com 使用 DIRECT，说明“映射到哪里”和“如何连接”需要分别表达。不要因为填写了 Host，就认为该域名一定走直连；也不要认为 DOMAIN 指向 PROXY 就会自动纠正错误的地址映射。

固定映射会减少对正常 DNS 返回结果的依赖，也会失去服务动态调整地址的灵活性。若服务使用动态部署或多个地区的接入点，长期固定某次解析得到的地址可能逐渐失效。只有已经确认用途并能持续维护时才适合使用。出现部分网络可达、部分网络失败的情况，应将 Host 作为单独变量移除对照，而不是直接替换所有 DNS。

Host 不会修改证书身份

把域名映射到某个地址，并不会使该地址上的服务自动拥有正确的站点配置或有效证书。HTTPS 仍会校验访问域名对应的身份，服务端也可能根据请求中的名称选择不同站点。映射后出现证书错误，应检查目标地址是否确实服务于该域名，不应通过忽略身份校验来掩盖地址填写错误。

同样，Host 并不是网页重定向工具。访问栏中的域名一般不会仅因为地址映射就变成另一名称。若想解释为什么浏览器跳转到了新页面，应检查服务端响应或 URL Rewrite，而不是把地址变化与可见 URL 变化混为一谈。保留这种分层思路，才能避免用错误机制解决表面相似的问题。

URL Rewrite：先理解表达式与动作

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

示例将匹配到的 HTTP URL 重定向到对应 HTTPS URL。左侧是正则表达式，^ 限定起点，域名里的点用反斜杠转义，(.*) 捕获后续内容；中间是替换目标，$1 引用第一组捕获；末尾 302 表示临时重定向。它不是把目标域名交给 PROXY 的语法，也不等于为服务器配置了 HTTPS。

编写表达式时，应限定协议与域名边界。未转义的点表示任意字符，缺少起点或结束边界可能扩大匹配范围。测试至少包含根路径、带查询参数的路径和不应命中的相似域名，确认捕获内容没有被截断或重复拼接。不要把含有私人查询参数的真实 URL 贴进共享笔记，示例统一使用 example.com。

可见范围与重定向循环

URL Rewrite 需要能够识别相应 URL 信息。普通加密连接不代表完整路径天然可读，不能假设对 HTTP 的示例会自动覆盖所有 HTTPS 内容。本章不要求扩大解密范围。若规则始终不触发，先检查输入 URL 是否可见，再检查表达式；直接把正则扩大到所有域名只会增加风险，并不能补齐缺失的信息。

若目标地址又被另一条规则改回原地址，就可能形成重定向循环。浏览器记录通常会表现为反复跳转而不是单次超时。排查时暂时停用新增 Rewrite，确认原始请求恢复，再逐条加入对照。Host、Rewrite 与 Rule 应分开测试，每一步只改一种机制，保留原始 URL、最终 URL 和命中结果供比较。

规则组合、合并与配置维护

一份便于维护的配置，不在于规则数量多，而在于每一层条件都有清楚的用途。常见组织方式是：明确的单点例外在前，业务域名集合随后，确有需要的地址与地区条件再后，末尾统一兜底。这里的“常见”不是固定标准；如果配置目的不同，可以调整层级，但应能解释任意一条具体请求为什么得到当前结果。

从最小可验证片段开始

[Rule]
# 单点例外先于域名集合
DOMAIN,portal.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY

# 只处理已经可用的目标地址
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve

# 地区判断之后统一兜底
GEOIP,CN,DIRECT
FINAL,PROXY

这段示例只表达规则层的组织方法，不包含服务器与认证信息。首先检查 portal 是否进入 DIRECT，再检查同一后缀下的其他域名是否进入 PROXY，最后检查无关域名是否按地址归类或进入 FINAL。文档地址不能作为实际测试服务器，应使用自己已经掌握且有权访问的测试目标替换相应条件。

增加 REJECT 时，应采用同样的最小原则。可以先限定一个确认不影响主要功能的完整域名，并在真实记录中验证请求确实属于预期对象。不要为了减少请求数量就直接拒绝整片业务域名。某个看起来只提供静态资源的域名，也可能承担身份校验或页面初始化功能，误拒绝通常表现为局部异常而不是全部断网。

合并前先解决重叠与终止条件

把两份文件简单首尾拼接，容易产生重复段落、互相冲突的策略，以及位于中部的 FINAL。合并时先整理成一个明确的 Rule 列表，再检查每条规则的位置。重复的相同条件若策略一致，通常只是增加维护负担；若策略不同，后面的那条可能长期没有机会命中，却会让读者误以为两种处理都在生效。

不能只用文本去重判断冲突。DOMAIN 与 DOMAIN-SUFFIX 虽然内容不同，也可能覆盖同一个目标；IP-CIDR 与 GEOIP 也可能在地址层重叠。应选择几个代表目标逐条推演，确认例外仍然位于宽条件之前。合并完成后只保留一个预期兜底，并重新核对所有策略名称确实能够在当前配置环境中解析。

远程更新与本地修改的边界

已有订阅的更新主要涉及服务器条目，远程配置更新则可能涉及 Rule、General 等文本，两者不能视为同一件事。若更新后行为改变，应先确认更新的是哪种内容。服务器列表发生变化可能影响出口选择，规则文本变化则可能改变匹配路径。把更新前后的文件分别保存，通常比凭记忆回想更容易发现真正差异。

长期使用时，建议把经过验证的本地修改保存在独立副本中，并记录来源、目的与恢复方式。更新远程内容前查看是否会覆盖该文件，不要假定所有本地添加都能自动保留。关于导入入口与订阅更新的区别，可参阅Subscribe、Add Server、扫码与剪贴板导入说明。

注释应记录原因与撤销条件

有效注释不只是把规则念一遍，而是写清为什么需要例外、如何验证，以及何时可以撤销。例如记录“该接口需与主站使用相同出口，测试时核对登录与后续接口”，比仅写“接口规则”更有帮助。注释中不要保存订阅认证信息、完整私人链接或服务器密码；配置文本在求助时应先脱敏。

每次改动保留简短记录：变更条件、原先结果、预期结果、实际结果。若新增规则没有改善目标问题，应撤销后再尝试其他变量，不要让无效修补长期留在列表里。规则维护的目标是让未来能够重复解释当前行为，而不是让文件累积越来越多无法追溯的例外。

命中验证与连接排错

规则问题与连接问题常常同时表现为页面打不开，但处理路径不同。规则排查首先确认请求是否进入预期策略，连接排查则检查该策略对应的网络路径是否可用。应把“当前连接状态”“命中条件”“出口连接结果”分开记录。VPN 开关已打开，只说明配置连接已启动，不足以证明服务器、DNS 和目标服务都正常。

建立可以重复的测试条件

开始前记录网络类型、Global Routing 姿态、当前配置名称、选中的服务器，以及一个明确的测试目标。先用已有配置验证基础连接，再进入 Config 检查目标规则。每次测试尽量重新发起连接，避免应用复用旧会话。不要同时打开多个相似页面比较体感速度，应优先寻找实际请求是否命中预期策略的证据。

Connectivity Test 可以帮助观察已有服务器的连通情况，但结果只针对测试条件，不代表所有域名、所有协议请求都能成功。一个服务器通过测试后，目标站点仍可能因为 DNS、分流、服务端限制或地址族不同而失败。因此服务器测试通过是一个检查点，不是跳过规则验证的依据。

没有命中预期规则时怎么查

1. 确认 Global Routing 为 Config，并且 Config 中选中的确实是刚编辑的文件。
2. 检查请求实际使用的域名或地址，不要用浏览器地址栏代替全部资源请求。
3. 从列表顶部向下查找更早命中的宽条件、重复条件或提前出现的 FINAL。
4. 核对英文逗号、段名、策略名称与 no-resolve 对输入条件的影响。

如果记录中只看到地址，先判断域名是否确实不可用，再检查 IP-CIDR 或 GEOIP。若命中了一个意外的 DOMAIN-KEYWORD，应考虑缩小关键词覆盖范围。若规则根本没有参与处理，还应回查 General 的绕过设置。不要一开始就删除整份配置，因为这会丢失能够解释问题的原始条件。

已命中正确策略但仍失败

PROXY 路径失败时，可以在保持规则不变的前提下，使用自己已有的其他有效出口作对照；如果更换后恢复，问题更可能在原出口或其到目标的路径。DIRECT 路径失败时，先检查同一网络下系统访问情况。对照时记录每一次只改变了什么，避免把网络波动与配置修改混为一谈。

局部资源失败与配置回退

登录、图片、视频或接口失败时，先查对应请求，不要假设它们与主页面共享域名和连接。也应检查 REJECT 是否阻断了依赖项，以及不同域名是否被安排到相互不兼容的出口路径。若新增配置后才出现问题，先恢复基线确认关联，再逐条恢复修改，比继续追加补丁更容易定位。

需要整理问题记录时，只保留配置片段、脱敏后的目标名称、命中规则和错误现象。删除认证参数、私人订阅地址与敏感请求内容。协议参数不匹配的问题可继续查阅VMess 与 VLESS 字段区别，常见连接现象可转到常见问题按分类核对，不要将认证故障当成规则关键字故障。

验证完成后恢复平时使用的 Global Routing 姿态，保存已经确认有效的配置，并撤销临时 Host、Rewrite 或测试规则。若需要重新建立完整上手流程，返回使用说明依次核对导入、出口选择、VPN 配置授权与连接验证。系统要求、设备兼容性和应用获取信息，以 App Store 页面标注为准。