Shadowrocket
规则与配置参考

01 配置文件结构与生效范围

Shadowrocket 的连接信息与分流配置承担不同任务。前者说明如何连接用户已有的服务器，通常包含协议、地址、端口与认证字段；后者说明某个请求应当采用什么策略。导入 Subscribe 并不等于已经选好了规则文件，导入一份 .conf 也不等于获得了服务器。维护配置前，先分别确认 Home 中的 SERVER 列表与 Config 中当前使用的文件，避免把两个入口视为同一份数据。

先识别四个段落

配置文件以方括号段名划分作用范围。[General] 放置全局参数，[Rule] 放置有先后关系的匹配行，[Host] 放置主机名映射，[URL Rewrite] 放置 URL 重写表达式。段名不是说明性标题，而是解析器识别后续内容用途的标记。相同的一行文字放在不同段落，可能产生不同解释，也可能直接成为无效参数，因此复制片段时必须一起核对所属段落。

[General]
bypass-system = true

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

[Host]
example.com = 192.0.2.10

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

这份片段展示段落边界，不是建议直接启用的完整配置。example.com 与文档地址用于解释语法，实际请求仍取决于用户拥有的服务器、当前策略和网络条件。尤其是 [Host] 与 [URL Rewrite] 会改变解析或请求目标，初次建立基线时应先省略这两段的具体条目，等基本连接稳定后再逐项添加。

文件存在不等于规则生效

Config 中可以保存多份文件，但排查时需要辨认当前实际使用的是哪一份。保存编辑后，返回文件列表检查选择状态，再到 Home 核对 Global Routing。配置姿态 Config 才是检查规则分流的常用起点；代理姿态 Proxy 和直连姿态 Direct 用于不同的全局路由选择，不能仅因文件已经保存，就推断每个请求都按该文件逐行判断。

编辑前保留一份能工作的副本，并给工作副本起一个易于辨认的名称。名称表达用途即可，例如“域名规则测试”，不要把服务器密码、订阅令牌或个人账号写进文件名。若同时维护远程文件与本地副本，应确认当前编辑的对象，远程更新可能覆盖同一文件中的本地修改；重要的自定义内容应有独立记录，而不是依赖记忆重新补写。

把变更拆成可验证的小步

一次改动最好只涉及一个层次。需要调整某个域名的走向，就先只改对应 [Rule] 行，不同时修改 DNS、Host 和服务器认证字段。这样测试结果发生变化时，可以把原因收敛到刚才的规则。连续改动多个层次后再测试，即使结果恢复，也难以知道哪一处真正有效，后续更新配置时容易再次失去依据。

阅读文件时先找段名，再找 FINAL，随后查看兜底之前有哪些覆盖范围较大的规则。这个顺序比从第一行逐字阅读更容易建立全局认识。遇到不理解的参数应暂时保留原值，先查明它控制的是流量接管、名称解析还是请求匹配；不要根据字段名字猜测取值，更不要将其他配置格式中的相似字段直接搬入 .conf。

02 General：全局参数与 DNS 边界

[General] 中的参数影响整个配置的运行环境，不是对某个域名单独下判断。规则写法正确而实际行为不符合预期时，除了检查策略，也要检查全局设置是否改变了流量进入规则系统的方式。尤其要区分“系统流量如何被接管”“域名如何获得地址”“最终连接通过哪条路径”这三个问题，它们有联系，却不是同一个开关。

bypass-system 与 skip-proxy

bypass-system = true 用于让特定系统流量按相应机制绕过代理处理。它不等同于把 [Rule] 中所有 DIRECT 条目打开，也不能解释为整个设备都使用直连。判断某项流量是否参与规则匹配，应结合实际请求记录和当前接管条件，而不是仅凭这个参数的布尔值推断。

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

skip-proxy 表示需要绕过相应代理处理的地址范围。示例仅包含回环与一个常见私有网段，不能覆盖所有家庭和办公网络。若路由器、打印机或局域网服务位于其他地址段，应根据设备真实地址判断。把整个私有地址空间一次性全部加入，可能让原本需要通过受控路径访问的内部服务改变走向，因此应先明确设备所处网络。

这里的绕过与 [Rule] 中的 DIRECT 不能简单视为重复。前者可能影响流量是否进入后续处理，后者是在规则层选择直连策略。若某条局域网规则始终没有请求记录，可以先检查是否已经被全局绕过；此时调整这条规则的位置，通常无法改变已经在更早阶段作出的处理决定。

DNS 结果与路由策略分别检查

dns-server = system 表示使用相应系统解析来源，适合建立便于理解的基础配置，但不代表它在所有网络中都能解析用户需要的名称。DNS 的职责是把主机名转换为地址，PROXY 或 DIRECT 的职责是决定连接路径。域名规则命中 PROXY，并不能单独证明名称解析来源符合预期；解析成功也不能单独证明目标端口可以建立连接。

配置其他解析服务器时，只使用自己清楚其用途、权限与可达性的地址。不要为了让某次测试通过而连续叠加多个来源，因为不同解析结果、缓存和网络切换会让问题变得难以复现。先记录系统解析的结果，再在保持路由规则不变的情况下比较其他设置，才能判断故障是否确实位于解析层。

地址规则可能引入解析动作

域名条件通常可以直接使用请求中的主机名判断；GEOIP 或 IP-CIDR 条件则需要目标地址信息。若请求起初只有域名，为判断某些地址规则可能需要解析。规则行带有适用的 no-resolve 选项时，含义是不要仅为了这条规则主动解析域名，而不是“整个连接过程都不再需要 DNS”。这一差别直接影响域名请求能否命中地址类规则。

已有地址信息的请求与尚未解析的域名请求，即使访问同一服务，也可能经历不同的匹配过程。维护者应在规则旁记录采用 no-resolve 的目的，例如减少规则判断阶段的额外解析，而不是把它作为每一条 IP 规则的固定装饰。若需要按最终地址决定策略，就应接受并验证相应的解析前提。

网络变化后的复核顺序

在 iPad 或 iPhone 从一个 Wi-Fi 切换到另一个网络后，先确认基础网络可用，再重新检查解析和局域网可达性。同一个私有地址在不同网络中可能指向不同设备，不能把上次可用的结果当作永久事实。On Demand 控制连接触发条件，也不替代 DNS 或 [Rule] 的配置检查；连接自动建立之后，仍要观察新请求的实际策略。

全局参数的维护原则是保持数量与用途相匹配。能用一条具体域名规则解决的问题，不必先调整全部解析路径；能通过修正一个私有网段解决的问题，也不必扩大整个绕过列表。保存前确认英文逗号、等号和地址前缀，保存后使用新请求复测，避免旧连接与缓存掩盖修改效果。

03 Rule：域名条件与匹配范围

[Rule] 的常见行结构是“规则类型、匹配内容、目标策略”。这里使用英文逗号分隔字段，域名位置不填写协议头、路径或端口。例如需要按 example.com 分流时，填写主机名即可，不应写成完整网页地址。域名规则处理的是请求的目标名称，而不是网页标题、页面正文或地址栏中的所有文字。

DOMAIN：限定完整主机名

DOMAIN,example.com,DIRECT 只匹配完整名称 example.com。它不会因为另一个名称含有相同文字，就自动覆盖那个名称，也不会自然扩展到 api.example.com。需要对某个接口或登录主机单独指定策略时，DOMAIN 的边界较清楚，通常适合放在覆盖范围较大的后缀规则前面。

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

在这组规则中，api.example.com 先命中第一行并使用 DIRECT；example.com 与其他符合后缀条件的子域名会继续到第二行使用 PROXY。若交换前两行，较宽的后缀条件会先命中，后面的精确例外便失去作用。规则系统不会自动把更精确的 DOMAIN 提升到前面，书写顺序就是实际判断顺序的重要组成部分。

DOMAIN-SUFFIX：覆盖域名及其子域名

DOMAIN-SUFFIX,example.com,PROXY 用于覆盖 example.com 及其子域名，例如 a.example.com 与 b.a.example.com。这里的后缀依据域名标签边界理解，不应把 notexample.com 当作同一个域。常见误写是加上星号，以为必须写成通配表达式；对这种规则类型，直接填写域名后缀即可，不需要把它改造成正则表达式。

后缀规则适合一个域名体系整体采用同一策略的情况，但一个网站的完整功能可能依赖其他独立域名。登录、图片、文件和统计请求不一定都在同一后缀下，因此“主页能打开、附件不能加载”不必然说明这条后缀规则无效。应观察失败资源的实际主机名，再决定是否需要另一条独立规则。

DOMAIN-KEYWORD：按名称中的片段判断

DOMAIN-KEYWORD,example,DIRECT 匹配域名中含有 example 字符片段的请求，其范围比单一后缀更难凭直觉控制。它可能覆盖属于不同组织的主机名，也可能漏掉名称完全不同的关联资源。除非明确需要这种宽泛条件，否则优先使用完整域名或后缀条件，减少后续出现难以解释的误命中。

从请求记录提取条件

添加规则前先确定实际请求主机，不要从页面名称猜测。一个应用可能连接多个后台服务，地址栏显示的域名也可能只是入口。对失败动作执行一次可复现操作，查找同一时段的目标名称，再决定采用 DOMAIN 还是 DOMAIN-SUFFIX。若记录只显示目标地址，就暂时不能凭空补出一个确定的域名条件。

需要匹配国际化域名时，注意可见名称与网络中使用的编码形式可能不同；以客户端记录中实际参与判断的主机名为核对依据。复制地址时还要清除尾部路径、查询参数和意外空白。域名规则不是 URL Rewrite，路径条件写入 DOMAIN 字段不会自动获得路径匹配能力。

维护多个域名规则时，应把“业务目的”和“语法范围”分开记录。例如目的可能是让某个自有测试服务使用指定路径，但实际条件应写出具体主机。只写“工作网站”之类注释，几个月后很难解释为何使用宽泛关键字。保留命中证据与选择原因，通常比不断增加重叠条目更有助于长期维护。

04 IP、GEOIP 与 USER-AGENT 条件

域名条件以名称为依据，地址条件以连接目标的 IP 为依据。两者描述的对象不同，不能假设某个域名永远对应固定地址，也不能假设同一地址只服务一个域名。内容分发、负载均衡和网络位置都可能改变解析结果。因此只有在目标确实以地址范围管理时，才适合把 IP 规则作为主要判断方式。

IP-CIDR：理解地址与前缀长度

IP-CIDR,192.168.0.0/16,DIRECT 表示匹配一个 IPv4 地址段。斜线后的数字是网络前缀长度，不是端口，也不是地址数量。前缀越长，覆盖范围通常越小；单个 IPv4 地址可用 /32 表达。编辑前应确认目标属于哪个网段，不能只因为地址开头相似，就随意扩大为一个更宽的范围。

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

192.0.2.10 与 2001:db8::/32 是文档示例，不是待连接的真实服务。IP-CIDR6 对应 IPv6 地址条件，不能把 IPv6 地址直接塞进 IPv4 规则并期待自动转换。若服务同时返回两类地址，只检查 IPv4 规则可能遗漏实际使用的 IPv6 连接；应先看记录中的目标地址族，再判断需要哪种规则。

局域网规则与实际拓扑

家庭与办公网络常见私有地址，但具体分配由网络管理方式决定。打印机访问失败时，先确认设备真实地址、子网和网络隔离设置。若设备处于另一个隔离网络，即使规则选择 DIRECT，也不会自动获得跨网段路由或访问权限。规则只能选择已有路径，不能替路由器创建缺失的网络连接。

对带 no-resolve 的地址规则，应再次检查请求是否已经有目标地址。若请求仍以域名形式进入判断，该选项可能使这条地址条件无法通过额外解析获得所需信息。此时应根据目的选择保留 no-resolve、补充具体域名规则，或验证允许解析后的行为，而不是盲目把同一网段复制成多条规则。

GEOIP：依据地址数据库分类

GEOIP,CN,DIRECT 按目标 IP 的地理归属分类结果判断，CN 是地区代码。它判断的不是网页语言、用户所在位置、网站注册地，也不是内容服务面向的地区。一个中文页面可能使用不同地区的地址，一个国际化服务也可能解析到本地分发地址，所以 GEOIP 不应被当作业务身份识别条件。

数据库分类有边界与变动，不能把一次命中视为永久结论。需要稳定处理某个明确服务时，可以把具体域名例外放在 GEOIP 之前；需要对剩余地址按大范围条件分类时，再使用 GEOIP。若分类结果与预期不同，应记录目标 IP 和当时解析结果，再检查数据库与规则顺序，不要直接认定服务器协议出了问题。

USER-AGENT：可见请求信息的限制

USER-AGENT 按请求中的 User-Agent 信息匹配，例如 USER-AGENT,ExampleClient*,DIRECT 表达一个前缀模式。它不是按应用显示名称识别所有连接，也不是系统级应用标识。只有在客户端能获得相应请求信息、请求确实携带该字段且符合支持的匹配方式时，这个条件才有判断基础。

加密连接中的 HTTP 字段通常不能仅从外层连接直接读取，因此不要把 USER-AGENT 作为所有 HTTPS 请求都能可靠命中的条件。也不应为让这一条规则命中而扩大证书信任或解密范围。本手册的基础配置不依赖此类操作；能使用明确域名达到目的时，先采用更容易验证的域名条件。

组合这些类型时，先问“此时真正可见的是什么”：主机名、IPv4、IPv6，还是可读取的请求字段。规则需要的数据不存在时，语法正确也不保证命中。把信息可见性与匹配语法分开检查，能够避免反复调整同一条无从判断的规则。

05 PROXY、DIRECT、REJECT 与匹配顺序

规则前半部分描述“什么请求”，末尾策略描述“如何处理”。PROXY、DIRECT 与 REJECT 是本页使用的基础策略关键字，书写时保留英文原文。PROXY 使用当前适用的代理路径，DIRECT 直接建立连接，REJECT 拒绝匹配请求。它们不是延迟等级，也不会依据访问结果自动互换。

策略不能替代服务器配置

PROXY 需要可用的用户服务器信息与相应选择状态。规则命中了 PROXY，但认证、端口或协议参数有误，连接仍可能失败。DIRECT 同样依赖基础网络能到达目标；它不表示请求必定成功。REJECT 是主动拒绝，适合明确不希望发出的请求，但对关键接口使用后，可能影响登录、同步或内容加载，应先确认依赖关系。

先命中的规则先决定策略

在通常的 [Rule] 顺序匹配中，请求从上到下接受判断，第一条符合条件的规则决定策略。后面的规则不会因为更精确而自动覆盖前面的结果。所谓“优先级”，首先来自位置，而不是规则名称看起来更专业或字段更长。编辑规则时，应把特定例外放在宽泛条件之前，让读者可以沿着文件顺序解释每次判断。

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

api.example.com 使用 DIRECT；blocked.example.com 被 REJECT；其余符合 example.com 后缀的名称使用 PROXY。前面这些域名条件均不符合时，才继续查看私有网段与 GEOIP。即使某个 example.com 的解析地址属于 CN，它也已经在更早的后缀规则中决定策略，不会再被后面的 GEOIP 改成 DIRECT。

FINAL 是兜底，不是补丁

FINAL 没有域名或地址条件，常见格式为 FINAL,PROXY 或 FINAL,DIRECT，放在用于兜底的位置。把 FINAL 提前，会使后面的普通匹配行失去处理机会。维护时应保留一个含义明确的最终策略，并解释为什么选择它，而不是同时留下多个不同方向的 FINAL，期待它们相互补充。

两种兜底方向都有明确适用前提。FINAL,DIRECT 表示未被特殊指定的流量走直连；FINAL,PROXY 表示未被特殊指定的流量走代理路径。选择时要考虑已有服务器能力、业务范围与故障影响，不应把某一种称为普遍正确。更改兜底前先测试常用服务，并确认哪些流量会从原路径转移。

区分路由姿态与规则策略

Global Routing 中的 Config、Proxy、Direct 是界面姿态，规则中的 PROXY、DIRECT 是配置关键字。两者文字相关，但不应混用成同一个配置字段。检查规则时先回到 Config；临时使用 Proxy 或 Direct 做对照后，应明确是否恢复，避免下一次测试仍处于全局姿态，却误以为某条规则发生变化。

测试 REJECT 时尤其要控制范围。先使用自己可识别的单个测试主机，确认命中记录，再讨论扩大为后缀。不要用宽泛关键字一次拒绝大量请求后，以“页面似乎更快”作为判断依据。关键资源可能在稍后的同步、付款确认或会话刷新中才被使用，短时间外观正常不能说明依赖关系已经完整验证。

06 Host 与 URL Rewrite：映射和重写

[Host] 与 [URL Rewrite] 都可能改变访问结果，但两者处理的层次不同。Host 关心名称对应什么地址，URL Rewrite 关心匹配到的 URL 如何改写或重定向；[Rule] 则关心请求使用什么策略。把三个层次分开理解，才能判断为什么页面目标变化、证书报错或某条分流条件没有按预期出现。

Host：固定主机名的解析结果

example.com = 192.0.2.10 表示为该名称指定地址。它不等于把访问域名变成这个数字地址，也不会自动改变 HTTP Host、TLS 使用的服务名称或远端证书。服务器仍需能正确处理原来的名称。若只把一个可达 IP 填进去，而对端不为该域名提供服务，可能得到错误页面或证书不匹配提示。

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

示例中的两个映射相互独立，不能假设根域条目自然覆盖所有子域。需要固定多个名称时，应分别确认它们的目标与使用目的。映射地址应来自自己可管理、可验证的环境；对经常变化的公共服务长期固定旧地址，可能使原本正常的负载分配与故障迁移失效。

Host 常用于自有测试环境或明确的名称解析修正，不适合拿来试探未知地址。排查前先删除或停用工作副本中的相关映射，与系统解析结果做对照。如果恢复常规解析后连接正常，就继续检查映射目标是否过期、端口是否开放以及证书名称是否正确，而不是直接增加更多代理规则。

URL Rewrite：用有限范围表达目标变化

URL Rewrite 的常见表达包含匹配模式、替换目标和处理方式。下面展示把 example.com 的 HTTP 地址重定向到对应 HTTPS 地址的语法。它只作为格式说明；实际部署前，应确认目标服务支持 HTTPS，且重定向不会与服务器已有逻辑相互冲突。使用真实业务地址时，应先在工作副本中以单个入口测试。

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

匹配部分的点号写成 \.，是为了把它限制为字面上的点。若直接写 example.com，正则表达式中的点可能代表任意字符，扩大命中范围。开头的 ^ 限定从字符串起始位置匹配，域名后面的斜线也有助于约束主机边界。重写规则应尽可能表达精确目标，而不是用过宽表达式覆盖所有请求。

重写不是对加密内容的通用修改能力

客户端是否能读取完整 URL，取决于请求形态与可见信息。HTTPS 的路径通常位于加密层内，不能假定写入 URL Rewrite 后就能匹配任何 HTTPS 路径。外层可见的连接目标与完整 HTTP 请求并不相同。若仅需要改变连接策略，应回到 [Rule] 使用域名或地址条件，不必引入请求内容处理。

本页不以扩大证书信任或解密范围作为基础配置步骤。对需要额外请求可见性的功能，应先理解其权限边界和适用对象，再按应用内说明判断。不要为了修复一个普通连接失败而添加不明来源的证书，也不要把服务认证失败误判成 URL Rewrite 的能力不足。

重定向循环与重复条件

当一条规则把地址 A 改为 B，而另一条规则或服务器又把 B 改回 A，就可能出现重定向循环。浏览器反复跳转或提示跳转过多时，应逐条停用重写规则，记录每一次 Location 变化。单纯更换 PROXY 与 DIRECT 可能改变可达性，但无法修复逻辑上互相指回的目标关系。

组合维护时，先验证常规 DNS 与路由，再启用 Host，最后单独启用重写。若三个层次同时修改，很难判断最终地址来自解析、重定向还是页面自身请求。给每项变化写出用途和撤销方式，测试结束后移除临时映射，避免日后将遗留测试条目误认为长期业务要求。

07 常见规则组合与配置维护

可维护的配置不是规则越多越好，而是每个请求的处理结果都能从少量条件中解释出来。开始组合前先写清默认方向：是大部分请求直连、仅指定域名使用代理，还是大部分请求使用代理、仅保留明确直连例外。这个决定体现在 FINAL，随后再把具体例外按范围由小到大放在前面。

组合一：直连兜底，指定域名使用 PROXY

下面的配置适合说明“只对确定名称使用代理路径”的结构。api.example.com 是精确直连例外，其他符合 example.com 后缀的请求使用 PROXY，其余请求由 FINAL,DIRECT 处理。这里的关键不是示例域名本身，而是例外、域名集合、局域网与兜底之间的先后关系。

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

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

如果目标服务实际使用其他独立域名，这份示例不会自动识别它们。新增条件应来自请求证据，不应把服务名称作为关键字后一次覆盖所有相似名称。应用需要多个请求共同完成时，应验证完整动作，包括打开、登录、读取与提交，而不是仅确认入口页面能显示。

组合二：代理兜底，保留明确的直连范围

另一种结构让未被例外覆盖的请求使用 PROXY。它要求用户已有服务器能够处理相应流量，并且清楚哪些请求仍需使用本地路径。示例保留一个域名例外、一个私有网段，再根据地址分类使用 GEOIP；是否保留 GEOIP，应依据实际需求，而不是因为常见配置中经常出现它。

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

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

两份配置是不同的维护方向，不应直接首尾拼接。拼接后，第一份里的 FINAL 会先结束判断，第二份中多数条目便不再有机会生效。合并配置时应先删除各片段原有的兜底行，整理具体规则与重复条件，最后只留下一个符合整体目标的 FINAL，并逐项验证合并后的行为。

订阅与配置文件分开更新

Subscribe 更新通常围绕已有服务器列表，配置文件更新则可能改变规则、参数或策略引用。更新其中之一不代表另一部分已经同步正确。列表中的名称变化后，如果自定义配置引用了具体名称，就应检查引用是否仍存在；本页使用基础 PROXY 关键字，是为了让规则语义不依赖某个教学示例中的服务器名称。

订阅地址可能带有访问令牌，应把它视为敏感信息。需要分享排错材料时，只保留必要的规则与目标类型，移除完整订阅地址、服务器认证字段和个人标识。有关分享链接与订阅地址的区别，可继续阅读节点链接格式说明；它们的导入与更新机制不同，不能仅凭都能复制为文本就视为同一种对象。

保存、切换与回退

在 Config 中编辑或导入后，先检查文件能否正常打开，再确认当前选择对象。保存并返回 Home，核对 Global Routing 为 Config，然后生成新请求进行测试。需要重新建立连接时，应先结束可能受影响的操作，再按应用当前界面完成连接切换；正在进行的长连接可能继续沿用原先建立时的路径。

回退依据应是一个已验证的工作副本，而不是一句“把刚才的内容删掉”。每次记录修改目的、涉及的段落、测试对象与观察结果。若远程配置更新覆盖本地改动，先恢复工作副本验证基础连接，再决定重新合并哪些条目，不要在故障状态下连续导入多个来源不明的配置。

客户端一次性买断 ≠ 线路套餐。Shadowrocket 的购买与用户已有连接服务分别管理；本站不提供、不销售、不推荐节点或订阅。需要核对应用获取入口与开发者信息时，请查看App Store 正版核验说明。客户端只在 Apple 平台发行，系统要求以 App Store 页面标注为准。

08 规则验证与故障定位流程

故障排查首先要把“没有连接”“连接建立但请求失败”“请求成功但走向不对”分开。这三类问题需要不同证据。Home 显示连接状态，只说明客户端处于相应工作状态，不保证每个目标都可达；Connectivity Test 提供测试结果，也不能单独证明某个业务请求命中了预期规则。

第一步：建立可重复的测试对象

选定一个明确动作，例如打开自己已知的测试页面，记录目标主机名、当前网络和失败现象。一次只执行这一项操作，减少后台请求干扰。若问题只在登录或上传时出现，就测试那一步，而不是反复刷新首页。不同阶段可能使用不同目标，首页成功不能替代后续接口的验证。

随后记录当前文件、Global Routing、服务器选择与最近一次修改。若问题出现在切换网络之后，应在原网络与新网络分别复测。不要在尚未保存证据时连续重装或重置全部设置，因为这会消除能解释故障的状态，使问题从“某一条规则变化”变成更大范围的重新配置。

第二步：确认配置是否参与判断

检查 Config 中实际选中的文件，确认编辑结果已经保存，再检查 Home 的 Global Routing。若仍处于 Proxy 或 Direct，用它们的结果只能帮助比较全局路径，不能据此宣告 [Rule] 中某条条件失效。回到 Config 后生成一次新请求，观察目标、命中条件和策略是否与文件顺序一致。

Global Routing: Config
Config: 当前工作副本
Target: api.example.com
Expected Rule: DOMAIN,api.example.com,DIRECT
Expected Policy: DIRECT

这是一份记录格式，不是客户端运行日志。实际结果应以本次测试为准，不要把预期值抄成观察值。若记录中看不到目标请求，应检查测试是否复用了已有连接、目标是否被其他全局条件提前绕过，以及观察时间是否对应刚才的操作。

第三步：按症状缩小范围

命中错误规则时，先找第一条能够匹配的前置条件。常见原因包括 DOMAIN-KEYWORD 范围过大、后缀规则位于精确例外之前，以及 FINAL 出现在文件中段。修正顺序后重新发起请求，不要继续往末尾追加重复规则，因为已经被前面条件处理的请求不会因此重新判断。

命中策略正确但连接失败时，把注意力转向该路径需要的条件。PROXY 检查用户已有服务器的地址、端口、协议与认证信息；DIRECT 检查基础网络与目标可达性；REJECT 则先确认拒绝是否出于维护者本意。若认证失败，增加域名规则通常没有帮助；若目标已被拒绝，更换 DNS 也不会让它自动改用其他策略。

第四步：区分缓存、旧连接与配置错误

域名解析结果和已有连接都可能暂时延续之前的状态。修改规则后，优先用可控的新请求验证；必要时按应用提供的操作重新建立连接，再检查结果。不要把每一次缓存变化都解释为配置随机生效。记录“修改前、保存后、新请求后”的观察，可以更清楚地区分编辑问题与连接生命周期。

如果只有特定应用失败，检查它是否使用独立域名、不同地址族或特殊传输方式。一个测试页面的成功不能证明所有协议路径都可用，延迟数字也不等于完整业务体验。关于如何理解测试结果与服务器选择，可阅读延迟测试与节点判断方法，继续以自己已有的列表为测试范围。

第五步：形成能复查的结论

排查结束后保留最小有效改动，并恢复测试期间临时切换的 Global Routing。结论应说明哪一个条件导致问题、修改了哪一行、如何验证，以及如何回退。尚不能确定时，保存经过脱敏的配置片段与实际现象，继续查阅常见问答；需要重走首次授权和导入流程时，返回快速上手教程。