Shadowrocket
规则与配置参考

配置结构与 General

配置文件负责描述请求如何解析、匹配和处理，服务器信息负责提供实际的连接参数，两者不能互相替代。即使文件中写有 PROXY，也不代表已经具备可用服务器；反过来，已经导入服务器也不表示某份规则文件正在生效。开始修改前，先在 Config 确认当前使用的配置，再在 Home 确认连接对象，把“使用哪份规则”和“连接到哪里”分别记清。

四个区段分别处理什么

方括号标题用于划分区段。[General] 放通用选项，[Rule] 放按顺序检查的分流规则，[Host] 放名称到地址的静态映射，[URL Rewrite] 放符合条件的 URL 改写或重定向。它们并不是四套可以互相替代的规则：域名应该走哪个策略，通常在 Rule 中表达；域名应解析到哪个地址，则属于 Host 或 DNS 的问题。

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

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

[Host]
example.com = 192.0.2.10

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

这段文本只展示区段与语法，不是适合直接启用的成品配置。example.com 是说明用域名，192.0.2.10 是文档示例地址；Host 和 URL Rewrite 在这里用于说明格式，并不表示必须同时启用。练习时先保留 General 与少量 Rule，确认基本连接后，再单独添加需要验证的区段，避免示例之间相互影响。

通用选项要按用途理解

dns-server = system 表示使用系统 DNS 配置，适合作为核对当前网络行为的起点，但不能据此断言每一个远端请求都一定由本地同一解析器完成。服务器协议、连接方式和具体请求路径都会影响最终解析位置。遇到解析异常时，应同时查看请求记录中的域名与目标地址，而不是只根据这一行判断整个链路。

bypass-system = true 属于系统相关流量的绕过选项，不是“所有本地地址都直连”的同义写法，也不能替代明确的 IP 网段规则。它涉及系统流量处理边界，修改后可能影响观察到的请求范围。若目的只是让某个局域网网段使用 DIRECT，应先在 Rule 中表达该网段，再验证实际请求，不要顺手改变无关的 General 字段。

保存、生效与远程更新是三个动作

编辑器中保存成功，仅能说明内容已经写入，不能证明该文件已经被选中。修改后返回 Config，核对当前配置，再确认 Global Routing 使用 Config。对于远程维护的配置，还应区分本地修改与上游文件：重新更新可能覆盖本地内容。长期保留的自定义规则应有独立备份，并记录插入位置，不能把唯一副本留在可能被更新替换的文本里。

排查配置时，应先保存一份可恢复的原文，再只改一个字段。记录修改前的网络环境、Global Routing、测试域名以及预期策略；改动后用同一请求重新验证。若效果与预期相反，恢复该字段再复测，比连续加入多个不明选项更容易定位原因。尤其不要将不同来源的 General 内容全部拼在一起，重复键或互相牵制的设置会使结果难以解释。

Rule 与规则类型

Rule 的基本形式是“类型、匹配内容、策略”，字段之间使用英文逗号；FINAL 不需要匹配内容，所以通常只有类型与策略两个字段。规则关键字应保留英文原文，域名字段不要加入协议头、路径或查询参数。下面的示例都假设当前使用 Config，并且 PROXY 已有可用的连接对象，否则正确的匹配结果也不等于请求能够成功。

DOMAIN、DOMAIN-SUFFIX 与 DOMAIN-KEYWORD

DOMAIN 精确匹配一个主机名，适合只处理某个独立子域的情况。DOMAIN-SUFFIX 按域名后缀边界匹配，常用于根域及其子域；例如 example.com 的后缀规则也能覆盖 api.example.com，但不应把它理解为任意字符结尾相同的域名。DOMAIN-KEYWORD 按域名中的关键词匹配，范围通常更宽，需要额外检查可能被包含的其他主机名。

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

在这个顺序中，api.example.com 会先命中 DOMAIN，不会继续接受后面的 DIRECT。其他属于 example.com 的子域由第二行处理。第三行仅有机会处理前两行未命中的、域名中含 example 的请求。不要把这组示例当作通用建议；它刻意使用重叠条件，展示同一请求符合多条规则时为何必须关心排列顺序。

GEOIP 与 IP-CIDR

GEOIP 根据目标 IP 的地址数据库归属进行匹配，例如 GEOIP,CN,DIRECT。它判断的不是网页语言、网站注册地或用户所在地。一个域名可能返回不同地址，数据库也有覆盖与更新边界，因此观察到同一网站在不同网络下采用不同策略时，应先比较实际目标 IP，而不是直接认定规则失效。

IP-CIDR 表示 IPv4 地址与前缀长度。192.168.0.0/16 覆盖对应地址范围，并非只匹配 192.168.0.0 这个单独地址；单一 IPv4 地址可用 /32 表达。IP-CIDR6 用于 IPv6。涉及 IP 条件时，已有目标地址可以直接用于判断；对于只有域名的请求，是否为匹配而进行额外解析，则应结合规则选项与实际记录核对。

[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

no-resolve 用于避免仅为该 IP 规则主动触发域名解析，不表示忽略已经可见的目标 IP，也不保证域名请求一定命中这条网段规则。若局域网服务通过主机名访问，可能还需要明确的 DOMAIN 规则。添加网段前也要核对是否与远端资源地址重叠；地址范围写得越大，误纳入请求的可能性越高。

USER-AGENT 与 FINAL 的边界

USER-AGENT 用于匹配可读取的请求 User-Agent。它不是对应用身份的可靠认证，也不能据此认定所有加密请求都能识别出应用名称。请求是否包含该字段、字段是否可见、内容是否改变，都会影响结果。若目标是稳定处理一组主机，优先核对域名条件；不要仅因为某条 USER-AGENT 规则没有命中，就扩大到未经确认的流量范围。

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

FINAL 是此前规则未命中时的兜底，通常放在 Rule 末尾。它不是错误处理规则，不会在前面命中的服务器连接失败后自动接管。将 FINAL 提前，相当于让其后的普通规则失去被检查的机会。检查长配置时，应先定位 FINAL，再确认希望执行的规则都在它之前，这往往比从第一行开始逐字阅读更快。

Host 与解析边界

Host 解决的是“名称对应哪个地址”，Rule 解决的是“请求采用哪个策略”。在 Host 中指定一个地址，不等于指定 DIRECT，也不等于已经绕过服务器或网络限制。判断一条映射是否符合目的，至少要分开核对三个事实：实际请求的主机名、映射后的地址，以及最终命中的策略。只看到地址变化，还不足以说明整条连接已经正确。

静态映射的最小写法

[Host]
example.com = 192.0.2.10
api.example.com = 192.0.2.20

左侧是主机名，右侧是地址。示例地址用于文档说明，不对应可用的业务服务。使用真实映射前，应从自己管理的网络或已有服务资料中确认地址，不能根据一次查询结果就假定它长期有效。这里按具体名称逐项列出，也有助于避免把精确名称映射误解成覆盖整个域的分流规则；需要处理哪些主机，就分别检查哪些主机的解析结果。

映射只改地址信息，不会把网页原本的主机名自动改成另一个名称。对于 HTTPS，证书验证与服务端的主机识别仍然重要。即使目标地址可以建立连接，若该地址没有为原主机名提供正确服务，也可能出现证书不匹配、返回错误站点或连接被终止。遇到这类情况，应先恢复映射确认差异，不要通过降低验证要求来掩盖地址错误。

Host 不等于固定整个网站

一个页面经常会调用多个主机：入口文档、图片、接口、登录和静态文件可能并不共用同一名称。只映射入口主机，不能推导其他资源也使用了相同地址。若页面主体能打开但内容缺失，应从请求记录查出失败资源实际访问的主机，再判断是否与映射有关。不要为了补齐页面而盲目扩大映射，更不要把所有子域指向同一个未经确认的地址。

静态地址还会改变原本由 DNS 实现的负载选择。原解析结果可能随网络、地区或服务状态变化，固定到某一个地址后，这些变化不会自动反映到本地映射中。短期排错时，映射可以帮助验证某个解析结果是否有问题；长期保留则需要明确的维护依据。对于不受自己控制、地址会变化的服务，静态映射通常不应被当作永久修复。

DNS、缓存与请求路径分别检查

修改 Host 后立即刷新旧页面，观察到的可能仍是复用连接，而不是全新建立的请求。应用、系统和网络链路中也可能存在缓存。验证时先记录修改前的地址，再关闭相关页面或结束旧请求，重新发起同一个主机的访问，然后检查新记录。若记录没有变化，需要确认当前配置是否生效、请求是否经过预期路径，而不是不断重复保存同一行。

有些连接会由远端处理域名解析，某些应用也可能自行进行解析或直接使用 IP。于是“在 Host 写了主机名”与“每条连接都使用该映射”并不是同一结论。应根据实际连接类型观察名称与地址在哪个环节可见。对于直接访问 IP 的请求，原本就没有相应的域名查找过程，继续添加域名映射通常不会改变它的目标。

一次完整的 Host 实验应只改一个主机，明确预期地址，并保留恢复记录。若移除映射后故障消失，说明映射至少参与了问题，但仍需区分地址失效、证书不匹配与访问路径不通。记录清楚原因后再决定保留或删除，避免把临时诊断项留在长期配置中，数周后再遇到地址变化时难以追溯。

URL Rewrite

URL Rewrite 按 URL 表达式处理符合条件的请求，常见用途是把一个明确的 HTTP 地址重定向到 HTTPS。它不是 DOMAIN 规则的另一种拼法，也不能代替 PROXY、DIRECT 或 REJECT 的策略选择。配置之前应先说明目的：是改变访问地址，还是只改变连接路径；如果只是希望某个域名走不同策略，通常应该修改 Rule，而不是添加重定向。

先从范围明确的重定向开始

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

这条示例由匹配表达式、目标 URL 和状态码组成。开头的 ^ 限定从字符串起始匹配，结尾的 $ 限定到字符串结束；\. 表示域名中的实际句点，避免把普通正则句点当成任意字符。示例只匹配指定主机的 HTTP 根路径，使用 302 进行重定向，并不涵盖该主机的所有路径或查询参数。

选择这样窄的表达式，是为了让测试结果容易解释。若表达式只写到域名而不限制后续内容，可能会覆盖更多路径；若又把目标固定成根路径，还可能丢失原请求中的业务路径与查询信息。需要保留哪些部分，应先分别列出根路径、子路径、查询参数三种请求，再设计并验证表达式，而不是从很宽的匹配条件开始试错。

请求可见性决定适用范围

HTTP URL 与加密连接中的完整 URL 不是同一种可见条件。不能因为能看到目标域名，就认为也能读取 HTTPS 请求的路径、查询或 User-Agent。对于加密流量，是否具备处理相关内容的条件，需要另行核对。本文的示例从明确的 HTTP 请求开始，不要求为了让一条改写生效而调整证书信任或扩大解密范围。

浏览器也可能先依据既有安全策略把 HTTP 升级为 HTTPS，使实际发出的请求与地址栏最初输入的内容不同。此时没有看到预期的 302，并不能单独证明表达式写错；应先确认是否真的发出了匹配的 HTTP 请求。访问工具、浏览器历史和站点自身跳转都会影响观察，测试记录必须包含最初请求以及随后出现的请求链。

重定向之后是一次新的请求

收到重定向后，客户端通常会向目标 URL 发起新的请求，新请求需要再次解析地址并接受规则处理。原请求命中过哪条分流规则，不应被理解为目标请求必然沿用完全相同的处理结果。若重定向目标换了主机名，尤其要检查新主机是否被另一条 DOMAIN 或 DOMAIN-SUFFIX 规则覆盖，以及它的解析和连接是否正常。

循环通常来自相互冲突的条件，例如本地规则把地址导向 HTTPS，而服务端又把同一入口送回原来的 HTTP 地址。表现可能是不断跳转、加载失败或浏览器报重定向次数过多。遇到这种现象，应先停用新增的改写规则，确认原站行为，再检查每一步返回的目标。不要仅仅增加另一条更宽的改写去覆盖症状，否则循环来源会更难辨认。

涉及登录、表单或带临时凭据的 URL 时，应格外谨慎。查询参数可能包含敏感内容，测试记录对外分享前应先删除；请求方法与重定向状态码的交互也不能仅凭地址变化推断。最初验证应选择自己可控制、没有登录状态的普通页面，确认表达式只处理预期请求后，再评估是否适合实际场景。

策略与 Global Routing

策略说明匹配后如何处理请求，Global Routing 说明当前使用哪种整体路由姿态。排查时应先看 Global Routing，再看规则中的策略字段；否则即使逐字检查了 Rule，也可能一直在验证一份当前没有按预期参与处理的配置。中文说明可称配置、代理、直连，对应界面词分别是 Config、Proxy、Direct。

PROXY、DIRECT、REJECT

PROXY 表示使用代理处理路径，需要已有且可用的连接对象。它不是具体服务器地址，也不自动补齐认证信息。DIRECT 表示直接连接目标，但“直接”并不保证目标可达，当前网络的路由、DNS 与目标服务状态仍然有效。REJECT 表示拒绝对应请求，适合明确需要阻止的目标，不能把它误认为失败后再尝试其他路径。

[Rule]
DOMAIN,api.example.com,PROXY
DOMAIN,printer.example.com,DIRECT
DOMAIN,blocked.example.com,REJECT
FINAL,PROXY

示例中的名称用于解释三种动作。api.example.com 命中后使用 PROXY；即使连接失败，也不会因为失败而自动尝试下一行 DIRECT。printer.example.com 则直接连接，是否成功仍取决于其解析地址及当前网络是否能到达。blocked.example.com 被明确拒绝后出现失败，是策略预期结果，不应再归类为服务器故障。

三种整体姿态如何用于对照

在 Proxy 下可以访问，而在 Config 下失败，说明应继续查看 Config 下实际命中了什么策略，但不能立即断言某个规则关键字存在错误。两种姿态可能使请求采用不同的解析位置、目标地址或连接路径。可靠的对照需要同时记录主机、实际地址与处理策略，确认差异从哪一步开始，而不是只记住页面最后是否打开。

在 Direct 下失败、Proxy 下成功，也不表示应把整个配置都改成 PROXY。局域网设备、只对当前网络开放的服务和其他特定资源，仍可能需要 DIRECT。Global Routing 的临时切换适合缩小问题范围，长期策略则应在理解资源需求后写入 Rule。完成对照后应恢复原姿态，避免之后继续以错误模式判断新规则。

策略名称与实际连接能力分开核对

部分配置会引用自定义策略名称。阅读这类文件时，不能把任何看起来像英文标签的值都当成内置策略；应确认该名称在当前配置中是否有相应定义、指向什么连接对象，以及对象是否仍存在。对于只需要学习基础分流的用户，先用 PROXY、DIRECT、REJECT 理清流程，比同时引入复杂选择关系更容易核对。

连接对象失效时，规则仍可能正常命中。比如认证信息已经变化、服务器地址暂时不可达或服务端不支持当前参数，都会导致“选对了策略但连接失败”。此时继续调整 DOMAIN 的匹配范围并不能修复服务器。先使用已有服务资料核对地址、端口与认证，再做 Connectivity Test，并把它与实际业务请求的结果分别记录。

同样，连通性测试成功只证明测试涉及的那部分路径获得了响应，不保证所有目标、协议和业务动作都成功。网页请求、长连接和其他传输方式可能有不同条件。若只有某个业务失败，应先定位该业务使用的主机与请求类型，而不是因为一次测试成功就完全排除服务器端或目标端问题。

已有订阅中的服务器与本地规则也是两类维护对象。更新订阅可能改变可选连接对象，不等于修复本地规则顺序；编辑 Rule 也不会更新已过期的服务器参数。关于更新动作的区别，可继续阅读订阅更新与失败原因，避免把服务器资料变化与配置文件变化混在一起。

匹配顺序与优先级

Rule 的核心顺序是从上到下检查，首条命中决定策略。所谓“更具体的规则优先”是配置编写建议，不是自动发生的排序机制。DOMAIN 不会仅因为更精确就越过前面的 DOMAIN-SUFFIX；IP-CIDR 也不会自动让位于后面的域名条件。要实现预期优先级，就必须在文本中把例外放到覆盖它的宽泛条件之前。

用同一请求逐行推演

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

以 api.example.com 为例，第一行已经精确命中，因此后面的域名后缀、关键词、地址归属和 FINAL 都不再决定该请求的策略。以 www.example.com 为例，第一行不匹配，第二行后缀命中后采用 DIRECT。只有前两行都未命中，第三行关键词才有机会生效。逐行推演时，应把“条件是否满足”和“匹配后动作是什么”写成两列，避免凭关键词直觉跳行。

如果把第二行移到第一行之前，api.example.com 就会被后缀规则先接住，原先的精确例外失去作用。这不是 DOMAIN 的匹配能力变化，而是检查顺序变化。理解这一点后，遇到“新增规则完全没有效果”，首先应向上查找是否已有覆盖该请求的规则，而不是在文件末尾反复添加同样条件。

宽规则与窄规则如何安排

常见写法是先放明确例外，再放域名集合或较宽条件，之后放需要的 IP 规则，末尾保留 FINAL。但这只是便于维护的组织方式，不是所有场景必须照搬的固定顺序。如果某段受控网段必须优先直连，它就可能需要位于相关宽泛条件之前；关键是先说明需求，再对照具体请求判断重叠，而不是机械套用一种排列。

同一目标可能同时满足域名条件与 IP 条件。例如名称属于指定域名后缀，解析地址又落在某个 GEOIP 范围。哪一条最终生效，取决于实际可用信息以及前后顺序。为 IP 规则增加 no-resolve 后，还应考虑仅有域名时是否会执行额外解析；不能把文本里的先后关系与请求当时尚不可用的信息混为一谈。

FINAL 不是第二次机会

FINAL 只处理前面尚未匹配的请求。某条规则已经选择 PROXY，随后服务器连接失败，并不等于“未匹配”，因此不会回到 Rule 中接着寻找 DIRECT 或 FINAL。需要备用连接能力时，应检查相应连接或策略设置的实际支持方式，而不是通过重复添加 FINAL 期待错误恢复。Rule 负责选择，连接失败属于选择之后的阶段。

排查时也要区分“没有命中预期规则”与“命中了预期规则但执行失败”。前者应检查主机、类型、顺序和当前配置；后者应检查连接对象、解析地址与目标服务。将这两类结果混在一起，会导致一边修改分流范围，一边偶然改变请求路径，最终虽然某次成功，却无法解释真正原因。

维护长规则时，可以为每个例外记下它覆盖的宽规则以及保留原因。删除重复内容之前，应比较完整字段而不只比较域名；同一域名配不同策略、同一网段带不同选项，都不一定是无意义重复。整理后再用预先选定的代表请求测试，至少包含一个精确例外、一个普通子域以及一个应落入 FINAL 的目标。

常见写法与变更流程

下面按需求拆分配置片段。每段都只展示一个主要意图，不是把所有片段合并后即可适用于任何网络。使用前应替换为自己需要处理的目标，保留已有服务器信息，并确认当前文件中的其他规则是否会提前命中。若已有配置包含 FINAL，应在原有末尾规则之前安排需要的例外，而不是再附加一套相互重叠的结尾。

同一域中的精确例外

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

需求是让一个指定接口使用 PROXY，而同域其他主机使用 DIRECT。先精确、后宽泛，是这里的关键。测试时分别访问 api.example.com 与另一个确认存在的子域，检查它们是否得到不同策略。不要只验证接口成功就认为例外正确，因为整体 Proxy 姿态同样可能让接口成功，却无法证明后缀规则正在参与处理。

如果接口发生跳转，或页面还调用其他域名，需要继续查看后续请求。第一跳命中了精确例外，只能证明这一跳的处理正确。对于需要多个独立主机协作的业务，应依据实际记录逐项整理，不能把一个可见入口等同于完整资源集合。范围扩大前，也应确认新增主机确实属于所需业务。

局域网网段与主机名分别处理

[Rule]
DOMAIN,printer.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

这里分别表达主机名与地址范围的直连意图。主机名使用示例名称，实际应填写自己受控环境中的名称。使用 no-resolve 的网段规则，不能作为所有域名都一定会被解析后匹配的保证，因此明确的局域网名称可以单独表达。测试前还要确认当前确实连接到能访问设备的网络，DIRECT 不会替用户建立通往另一处局域网的路由。

如果同一个地址范围也在其他受控网络中使用，网段规则可能覆盖到不同用途的目标。特别是多个网络存在私有地址重叠时，不能仅凭地址“看起来像内网”就决定处理路径。应先列出需要访问的设备、实际网络与目标地址，尽量缩小到真正必要的范围；单个设备可考虑更具体的前缀，而不是一开始就覆盖大段地址。

按地址归属分流与末尾兜底

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

这段表达一个精确例外、一个地址归属条件和一个兜底。它并不等于按网站内容或语言分类。对使用分布式地址的服务，解析到不同 IP 可能改变 GEOIP 判断结果；测试应包含实际地址，而不是只记录网址。如果需求本来针对一组确定域名，用明确的域名规则往往更容易解释，但仍应根据自己的资源与网络条件决定。

FINAL 选择 PROXY 也有明确前提：用户已有可用服务器，并且愿意让未覆盖请求走该路径。如果实际维护目标相反，可以选择不同的兜底策略，但必须意识到它会影响大量此前未明确列出的请求。调整 FINAL 属于影响范围较大的变更，不能只用一个页面的成功与否来评估，应连同日常使用的代表资源一起验证。

保留、编辑、验证、回退

1. 保存当前配置原文，记录所选文件、Global Routing 与连接对象。
2. 写明一个可验证需求，例如“指定主机从 DIRECT 改为 PROXY”。
3. 搜索已有规则，找到最早可能覆盖该主机的条件，确定插入位置。
4. 只改一处并保存，确认当前配置仍是这份文件。
5. 建立新请求，核对命中规则、目标地址、策略与实际结果。
6. 结果不符时恢复原文，再用相同目标复测，保留差异记录。

回退文件不要与正在自动更新的来源混用。尤其在订阅或远程配置更新后，应重新确认自定义规则仍在预期位置，以及规则引用的连接对象是否发生变化。更新完成只能说明拉取动作结束，不能替代功能验证。修改较多时，分批保留可用状态，比一次覆盖整份配置更容易找到引入问题的那一步。

验证与故障定位

验证的目标不是只看到连接开关处于开启状态，而是确认一个具体请求采用了预期配置、命中预期条件，并通过对应路径得到结果。建议固定一个测试目标，按“服务器、Global Routing、DNS、规则、目标服务”的顺序检查。每完成一步，都记录能确认的事实与尚不能排除的因素；不要在同一轮测试中同时更新订阅、换服务器和改 DNS。

从连接对象到实际请求

先核对用户已有服务器的地址、端口、认证与协议参数，再使用 Connectivity Test 获取基础连通性线索。若测试失败，先确认当前网络与服务资料，不必立即重排 Rule。若测试有响应，再发起实际业务请求，观察是否只有某个主机失败。基础测试与业务请求不同，前者有响应不能证明后者所需的所有路径与参数都正确。

随后检查 Global Routing。若当前是 Proxy 或 Direct，先记录状态，再切到 Config 验证规则。若在 Config 下结果异常，查看实际请求的主机名与目标地址，确认它与预设测试对象一致。页面可能重定向，也可能调用独立接口；错误发生的主机未必就是地址栏中的主机，不能只围绕入口域名反复添加规则。

用记录区分三类失败

第一类是规则未按预期命中：当前配置可能不对、匹配内容可能写错，或上方规则已经提前接管。第二类是策略正确但连接失败：应检查服务器可达性、地址与目标服务。第三类是解析环节异常：需要比较域名是否得到地址、地址是否符合预期，以及 Host 是否覆盖了结果。把三类分开后，修改范围通常可以明显缩小。

记录中若出现 REJECT，先回到配置找到对应条件，判断它是否本来就要阻止该目标。记录显示 DIRECT 但目标是仅能通过已有远端路径访问的资源，应核对策略意图；显示 PROXY 但服务器认证失败，则优先处理已有服务资料。错误文字只能提供定位线索，不能跳过实际命中规则与连接对象的核对。

On Demand 与规则分流分开验证

On Demand 负责按条件触发连接或断开，Rule 负责连接工作时的请求处理。自动连接没有触发时，不应先判断域名规则错误；应检查当前网络是否满足 On Demand 条件，以及连接是否真的建立。反过来，连接已经建立，也不能说明所有请求都采用 PROXY，因为 Config 仍可能把部分请求交给 DIRECT 或 REJECT。

验证自动行为时，先手动建立连接并确认同一配置能够正确处理请求，再单独测试网络切换后的触发情况。记录切换前后网络、连接状态与请求时间，不要同时调整触发条件与 Rule。具体场景可参阅On Demand 的 Wi-Fi、蜂窝网络与域名条件；后台连接取舍可参阅后台耗电与常驻连接说明。

常见核对问题

分享排查记录前，应删除订阅完整地址、认证信息、个人网络名称以及其他敏感内容。通常只需保留脱敏后的主机、规则类型、策略与错误阶段，便能解释问题。完成排错后，恢复临时切换的 Global Routing，删除不再需要的 Host 或改写测试项，并再次保存一份已验证配置。以后出现相似故障时，先对照这份基线，再逐项复测。