Shadowrocket 规则手册
配置结构与匹配顺序

配置文件与订阅不是同一种对象

配置文件描述请求如何处理，订阅主要用于导入和维护用户已有的服务器条目。两者可以共同参与一次连接，却不能互相替代。订阅更新成功，只能说明相关内容已被读取，不能证明当前规则正确；配置文件能够保存，也不能证明其中引用的代理已经可用。排查之前先分别确认这两个对象，避免把服务器参数问题写成规则例外。

在 Config 中核对当前选用的配置，再进入相应编辑入口。需要试验时先复制文件，给副本使用容易辨认的名称，并保留原文件。只修改副本而没有选用副本，连接结果通常不会体现修改。反过来，如果编辑的是正在使用的文件，保存后也应按应用提示重新载入；验证时重新发起请求，不要继续依赖修改前已经建立的连接。

方括号确定设置的作用范围

Shadowrocket 的常见文本配置使用章节标题组织内容。[General] 放通用设置，[Rule] 放分流规则，[Host] 放主机名映射，[URL Rewrite] 放请求地址重写规则。章节不是给阅读者看的装饰：相同一行文字处于不同章节，解释方式就可能不同。复制片段时必须连同章节位置一起检查，不能只凭文件里出现了关键字就认为设置已经生效。

[General]
dns-server = system

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

这段示例只展示结构。第一条规则精确处理根域名，第二条处理同一后缀的其他域名，最后处理剩余请求。dns-server = system 表示使用系统 DNS 设置，并不承诺所有环境下的解析结果一致。不要因为示例能被保存，就推断已经完成服务器选择、连接授权或全部网络设置；这些条件仍需在应用内独立核对。

修改配置时保留可追溯的最小差异

读取长文件时，先找章节标题，再找当前要解决的问题对应的段落。重复的章节、重复的兜底规则以及散落在文件末尾的临时条目，都会增加判断成本。推荐把同一类本地例外放在连续位置，并在独立注释行解释目的。注释应说明为什么需要这条规则，而不是重复规则本身；不要把真实订阅地址或认证参数写入准备分享的注释。

导入配置之前也应先读内容，而不是根据文件名判断适用性。重点查看最终策略、DNS 设置、主机映射与重写部分，再确认是否引用了当前环境不存在的策略名称。一个配置即使包含很多规则，也可能只适用于它原来的服务器组织方式。遇到不认识的选项，先保留原值并在应用内核对支持情况，不要把其他格式的设置名直接拼进当前文件。

自动更新的内容与手工维护的内容要分开管理。若配置来源更新时会覆盖本地编辑，修改可能在下次更新后消失。先确认更新对象是订阅还是整个配置，再决定把本地例外放在哪里。不能确定覆盖范围时，保留独立副本并记录差异，比连续修改同一份远程内容更容易恢复，也更容易判断一次故障究竟来自更新还是本地操作。

下文的代码块有的包含章节标题，有的只有规则行。只有规则行的片段应放入已有的 [Rule]，不必为每段示例新建一个同名章节。需要从购买与首次打开重新确认环境时，转到App Store 正版核验页；本手册不把获取客户端与配置流量混在同一套操作里。

先核对 Config、Proxy、Direct

需要按配置文件分流时，Global Routing 应选择 Config。Proxy 与 Direct 是不同的全局处理姿态，不是给配置规则追加的两条普通规则。如果当前处于 Proxy，就不能通过修改一条域名规则来证明 Config 中的分流已经正确；如果处于 Direct，看到目标能够访问，也不能说明代理服务器已经接受了这次请求。模式必须放在排查顺序的前面。

表格说明的是三种姿态的主要用途，不意味着配置中的所有其他设置都会被完整替换。DNS、已有连接以及应用本身的网络行为，仍可能影响观察。切换模式是一种对照方法，而不是证明某一环节绝对正常的检测器。做测试时记录当前模式与选用配置，完成后恢复预期设置，否则后续调整可能一直建立在错误前提上。

模式、规则与服务器形成三层判断

可以把一次排查分成三层：先看是否进入配置分流，再看请求命中哪条规则，最后看策略所依赖的连接资源是否可用。规则选择 PROXY，表达的是处理方向，不会补齐服务器地址、端口或认证信息。已有订阅中没有可用条目时，再精细的域名规则也不能代替连接参数。应先检查用户自己的服务器信息，再讨论是否需要增加例外。

界面上的 Proxy 与规则里的 PROXY 不要混读。前者是 Global Routing 的一个选项，后者是配置文本中的策略关键字。它们都涉及代理路径，但处于不同层级。同样，界面的 Direct 与规则里的 DIRECT 也需要按上下文区分。编辑文本时保留大写关键字，可以减少阅读时把模式名称当成规则参数的机会。

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

这段规则的预期是：在 Config 参与处理的前提下，匹配指定域名后缀的请求使用 PROXY，其他请求使用 DIRECT。验证它时要同时检查一次应命中的请求和一次不应命中的请求。只检查目标站点能够打开，无法区分是规则正确、全局模式覆盖了预期，还是目标本来就能直接连接。

用对照测试缩小范围，而不是反复切换

如果 Proxy 下能够连接而 Config 下失败，优先检查 Config 使用的文件、策略引用以及匹配顺序。这个现象说明两种处理方式存在差异，但不能立即断定域名规则写错；某个主机映射、解析设置或更早的拒绝规则也可能造成差异。若两种姿态都失败，应先确认服务器参数与基础网络，不要继续扩大规则列表。

如果 Direct 下成功而 Proxy 下失败，应该沿代理路径检查，不要立即把整个目标后缀改成 DIRECT。临时改直连可以用于对照，但它同时改变了请求路径，可能只是在绕开原问题。应记录失败发生在连接建立、名称解析还是后续访问阶段，再决定修改哪一层。每次只改变一个条件，得到的结果才有明确解释。

切换之后重新打开目标或重新发起操作，必要时结束原有连接后再测。长连接可能继续沿用建立时的处理方式；缓存页面也可能让人误以为刚发生了新的网络访问。测试应选择明确会产生请求的操作，并结合应用内实际可见的连接记录判断。详细操作路径见教程中的 Global Routing 说明。

DOMAIN：只匹配指定主机名

DOMAIN 用于精确匹配域名。写入 example.com 时，匹配的是这个主机名本身，不会自然扩展到所有子域名。因此，目标只涉及一个明确主机时，精确规则通常更容易验证；需要同时处理根域名与子域名时，再考虑后缀规则。不要在精确域名参数里添加协议前缀、路径或页面查询参数，它们不是域名的一部分。

DOMAIN,example.com,DIRECT
DOMAIN,www.example.com,PROXY
DOMAIN,api.example.com,PROXY

这三行分别处理三个完整名称。第二行不会匹配第一行，也不会自动覆盖第三行。一个网站可能把页面、登录、图片与接口分布在不同主机上，浏览器地址栏只显示其中一部分。出现首页正常而登录失败时，先查看实际失败请求的主机名，再决定是否补充规则；不要仅凭地址栏里的根域名推断整套服务都已命中。

DOMAIN-SUFFIX：匹配域名边界上的后缀

DOMAIN-SUFFIX,example.com,PROXY 表达的是后缀匹配，通常覆盖根域名及其子域名，例如 www.example.com。它不是任意字符包含测试，notexample.com 不能因为字面尾部相似就被当成同一个域名后缀。阅读规则时要看域名标签的边界，而不是把后缀规则理解成对整条网址做搜索。

常见错误是把 *.example.com 当成后缀规则的必要写法。这里直接写 example.com 即可表达该后缀，不需要额外添加通配符。规则参数里也不写末尾斜杠。复制目标地址时，应先从完整网址提取主机名，去掉协议、端口、路径与查询部分，再判断要用精确规则还是后缀规则。

DOMAIN-KEYWORD：范围更宽，需检查误命中

DOMAIN-KEYWORD 检查域名中是否包含指定字符串。它不以完整域名标签为边界，因此影响范围通常比后缀规则更难直观看清。除非确实需要跨多个域名按共同字符串处理，否则优先使用可列举的精确名称或明确后缀。关键字越短，越容易把无关请求一起匹配，后续维护时也更难解释为什么某个主机进入了代理路径。

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

在这个顺序里，精确主机先使用 DIRECT；同一后缀下的其他请求再使用 PROXY；包含关键字但没有被前两行处理的域名，才可能进入 REJECT。示例用于展示三种范围的差异，不是建议用一个宽泛关键字拒绝全部相关名称。若把第三行提前，原本希望保留的例外就可能失去机会。

域名规则依赖客户端能够取得可用于匹配的域名信息。请求如果直接连接一个地址，不能预期它必然反推出原始主机名。反过来，一个域名解析出多个地址，也不意味着需要为每个地址手写规则。优先按真实请求形态选匹配方式：能够稳定识别主机名时用域名规则，明确需要处理网络地址范围时再使用地址规则。

新增一条域名规则后，至少核对根域名、一个子域名以及一个相似但无关的域名应如何处理。这里的核对可以先做纸面推演，不必把所有示例当成真实可访问服务。规则基本语法的逐条解释见DOMAIN、DOMAIN-SUFFIX 与其他规则类型详解；后文继续说明地址规则与域名规则发生交叉时的判断方式。

IP-CIDR 与 IP-CIDR6 描述地址范围

IP-CIDR 用于 IPv4 地址段，IP-CIDR6 用于 IPv6 地址段。斜杠后的数字是前缀长度，不是端口，也不是通配符数量。单个 IPv4 地址可用 /32 表示，单个 IPv6 地址可用 /128 表示。扩大网段会同时扩大影响对象，不能因为某个地址连接失败，就把相邻的大段地址全部划进同一策略。

IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
IP-CIDR,192.0.2.0/24,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve

这里使用文档示例地址，不代表真实服务端。第一行是一个精确地址例外，第二行是较宽的地址段，先后顺序决定例外是否能生效。IPv6 示例说明另一种地址族的语法，不能替代 IPv4 规则。如果真实目标可能返回两类地址，应分别理解它们的处理结果，而不是只检查一个地址族就认定整次访问都符合预期。

no-resolve 控制为规则匹配额外解析的行为

地址规则面对域名请求时，可能需要先得到地址才能判断。no-resolve 的用途是避免仅为这条规则的匹配主动触发域名解析；当已有可用地址信息时，仍应按实际处理过程判断结果。它不表示整个客户端停止 DNS，也不保证请求永远不会经过其他解析路径。把这个参数理解成通用的解析故障修复开关，会使排查偏离问题本身。

需要按域名稳定分流的服务，通常先用域名规则表达意图；需要明确处理某个网络范围时，才使用地址规则。原因是同一地址可能承载多个主机，而同一主机也可能随网络、解析器和时间返回不同地址。把一次解析结果固定成长期规则，可能遗漏后续地址变化，也可能让共用地址上的其他服务受到影响。

GEOIP 是地址归类，不是网站身份识别

GEOIP,CN,DIRECT 表示按地址数据库中的地区归类选择策略。它判断的是地址归属信息，不是经营主体或页面内容。服务使用分布式基础设施时，域名身份与接入地址归类可能不同。数据库也存在更新与分类边界，因此不能把一次地区匹配当成对服务实际部署位置的永久结论。

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

示例先给明确域名指定路径，再让地址归类处理其他请求，最后交给兜底。这样的顺序使意图清楚的域名规则优先于较宽的地址判断。如果 GEOIP 被移到前面，一个解析到相关地址范围的域名可能先被处理，后面的域名规则就不再有机会。关键不是某种类型天然更高级，而是哪条规则先满足条件。

USER-AGENT 受请求可见性限制

USER-AGENT 依据可观察到的请求头特征匹配，可用于具有相应请求信息的场景，但不能当成对所有应用可靠识别身份的方法。不同应用可能使用相同标识，同一应用也可能在不同请求里使用不同标识。尤其对加密流量，普通网络转发并不意味着可以读取其中的 HTTP 请求头；看不到匹配字段时，规则不会凭应用名称推测内容。

USER-AGENT,ExampleClient*,DIRECT

这一行仅说明该类型的写法与通配符形式，不表示设备上存在这个程序。不要为了让示例命中而改变设备的安全设置，也不要用 USER-AGENT 代替可以明确表达的域名规则。若怀疑它没有生效，先确认实际请求中是否存在可见且符合预期的字段，再检查顺序；字段本来不可观察时，增加更多相似规则通常没有帮助。

地址、地区与请求特征规则都需要结合实际可见信息解释。记录里只有一个目标地址时，先确认它是直接请求地址、解析结果还是代理服务器地址，三者不是同一个对象。把连接到服务器的外层路径误当成目标站点地址，会导致整段分流判断错误。无法确认时，回到最小域名规则做对照，再逐步加入地址条件。

规则回答“匹配什么”，策略回答“如何处理”

一条常见域名规则由类型、匹配内容与策略组成。DOMAIN-SUFFIX,example.com,PROXY 中，前两项确定条件，最后一项确定命中后的处理方式。改变最后一项不会改变匹配范围；把 PROXY 改成 DIRECT 后，仍然是同一批域名被选中，只是路径发生变化。理解这层分工，可以避免把策略问题误修成域名范围问题。

PROXY 所使用的实际连接条目，需要在当前配置与应用选择中核对。若配置还包含自定义策略名称，应确认名称有对应定义，并且其成员符合当前环境。不能只因为名字里含有“代理”含义，就认为它一定指向当前选中的服务器。复制规则时也不要随意保留来源文件中的自定义名称，否则可能出现引用与实际对象不一致。

DIRECT 只是路径选择，不是成功保证

DIRECT 会让匹配请求走直接连接路径，但仍依赖本地网络、目标服务以及解析结果。某条规则改为 DIRECT 后仍失败，应沿直连路径继续排查，而不是认定规则没有匹配。相反，直连成功也不能说明原代理路径的认证、证书或传输参数正常。策略选择与网络可达性是两个结论，需要分别用记录和实际访问验证。

REJECT 是有意阻止请求的动作。为它添加规则之前，应先确认目标主机没有承载登录、验证或页面必需资源。只根据名称猜测用途，容易把共享接口一起拒绝。若修改后出现局部页面缺失，先临时移除新加的拒绝规则并复测；不要同时增加代理例外、改 DNS 与重写地址，否则无法判断究竟是哪项变化恢复了功能。

FINAL 不带域名参数

FINAL 是没有被前面规则处理时的兜底选择。常见写法是 FINAL,DIRECT 或 FINAL,PROXY，它不需要像域名规则那样再写一个匹配内容。兜底应放在规则列表末尾，因为它没有等待特定域名命中的条件。如果把它提前，后面的普通规则就可能永远到不了，表现为新增条目怎么修改都没有效果。

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

该片段表达“一个精确例外、一个后缀范围、其余直连”。若实际意图是默认代理，就应把末行改为 FINAL,PROXY，同时重新审视前面哪些直连例外需要保留。不要只复制末行而忽略整份文件的默认方向；默认方向改变后，即使前面的规则一字未动，许多未被列举的请求也会随之改变路径。

先写清意图，再选择兜底方向

选择 FINAL 之前，用一句话说明目标：是少数指定主机使用代理，其余直接连接，还是大部分请求使用代理，仅保留少量直连例外。前者通常更容易与 FINAL,DIRECT 对照，后者则要仔细维护例外与 FINAL,PROXY 的关系。这里没有适合所有网络的固定答案，决定依据应是用户自己的访问需求与已有连接条件。

兜底规则并不是故障自动切换。FINAL,PROXY 不表示前面的代理连接失败后再尝试其他策略；它关注的是前面的匹配条件是否命中，而不是连接有没有成功。规则命中与连接结果发生在不同环节。不要给同一个域名连续写两条不同策略，期待第一条失败时自动落到第二条；普通顺序匹配并不按这种方式提供重试。

维护时让一份规则列表只有一个清晰的最终出口，便于阅读和验证。若文件里存在多个 FINAL，先识别第一个实际可达的位置，再整理其后的无效条目。删除前保留副本，避免把本来属于其他章节的内容误当作规则。最终结果应能回答每条普通规则的作用，以及所有未列举请求会去哪里。

首条命中先于“看起来更精确”

对普通顺序规则，判断应从上到下进行，先命中的条目决定处理策略。不要预设 DOMAIN 一定优先于 DOMAIN-SUFFIX，也不要认为文件后方的新规则会自动覆盖旧规则。精确程度是安排顺序时的重要依据，却不是把文本顺序忽略掉的理由。需要保留的精确例外应放在可能覆盖它的宽范围规则之前。

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

访问 api.example.com 时，第一行已经给出结果，不需要再进入第二行。访问 www.example.com 时，第一行不匹配，第二行才处理。访问其他未列举域名时，最后一行兜底。这样的推演可以在真正连接之前完成；如果纸面上已经发现某条规则永远没有机会，就没有必要反复切换网络寻找原因。

场景一：只有指定网站使用代理

当需求明确为少量网站使用代理时，先用精确域名或后缀列出目标，再选择 FINAL,DIRECT。不要先加入大量地区、关键字与地址段规则，否则原本简单的意图会被不同范围交叉覆盖。网站实际依赖多个域名时，应根据请求记录逐步补齐，而不是根据页面名称猜测所有基础设施，或把极宽的共同字符串当作完整服务边界。

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

这个最小片段适合解释结构，不意味着任何真实网站都只需要一个后缀。补充规则时记录新增主机承担的功能，例如接口或静态资源，并检查新增范围是否包含不希望改变路径的请求。需要完整场景说明，可阅读只让指定网站走代理的规则写法，再回到这里核对顺序。

场景二：默认代理，但保留明确直连例外

另一种结构是在前面写明确直连条件，再以 FINAL,PROXY 处理其他请求。这时新增一条宽泛 DIRECT 规则，会把更多流量从默认代理路径中分离出去。修改之前先问清楚例外的依据是域名身份、网络地址还是地区归类；依据不同，应使用不同规则，不能用一条看似方便的后缀去表达实际上与域名无关的条件。

[Rule]
DOMAIN,api.example.com,DIRECT
IP-CIDR,192.0.2.10/32,DIRECT,no-resolve
FINAL,PROXY

示例中的两个例外分别依赖主机名与地址，不能认为它们互为备份。第一个条件是否可用，取决于请求的域名信息；第二个条件关注地址，而且带有 no-resolve。实际排查时应记录是哪条命中，而不是仅看最终都是 DIRECT 就把两者合并。保留匹配依据，有助于解释地址变化或请求形态变化之后的差异。

冲突排查与增量维护

发现冲突时，先从预期规则向上寻找所有可能提前命中的条目，包括关键字、地区和更宽地址段。不要只搜索同一个完整域名；一个不含该域名字面量的 GEOIP 规则也可能先处理请求。找到原因后，优先移动精确例外或缩小宽规则范围，而不是在文件不同位置重复添加相同内容。

每次修改后同时测试正例与反例。正例证明目标请求进入预期策略，反例证明范围没有意外扩张；只测试正例，宽规则造成的误命中可能长期不被发现。测试结果要记录模式、配置名称与操作顺序，避免下次把不同环境下的结论放在一起比较。无需记录敏感地址或完整认证参数，留下匹配依据与策略结果即可。

删除冗余规则也需要按顺序推演。两条文本相同的规则通常没有必要并存，但两个看似相近的条件可能覆盖不同对象。整理时先标记目的，再逐条移除，并在每一步复测主要操作。不要把清理规则与更新订阅、变更服务器放在同一次调整中；把变化拆开，才能明确回退到哪一步会恢复原来的行为。

Host 改变名称对应，不直接选择策略

[Host] 用于主机名映射，它解决的是某个名称对应哪个地址的问题，不是把该主机直接指定为 PROXY 或 DIRECT。设置映射之后，请求仍需要按当前处理方式决定路径。因此，目标名称能够解析到指定地址，不代表分流策略正确；策略正确，也不代表映射地址就是当前服务有效的接入位置。

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

这些地址仅为文档示例。实际填写之前必须确认自己管理的服务确实要求该映射，并了解目标地址的维护方式。不能把一次 DNS 查询得到的地址视为长期稳定入口。对使用动态调度的服务，固定映射可能绕过正常调度，在网络变化或服务迁移后造成间歇性失败；表面看像代理不稳定，实际可能只是映射已经过时。

把域名映射到另一个地址，也不会自动使该地址上的服务具有正确证书、虚拟主机配置或访问权限。访问加密站点时，名称与证书验证仍然重要。遇到名称或证书错误，应该检查服务端与映射是否匹配，不要通过放宽验证来掩盖问题。Host 适合已知目标的定向配置，不适合用来猜测陌生服务的可用地址。

URL Rewrite 处理请求地址，不替代代理配置

[URL Rewrite] 描述符合条件的 URL 如何改写或重定向。它与 DOMAIN 一类规则的区别在于匹配对象包含地址结构，而不仅是主机名。添加之前先确定需求究竟是改变访问路径，还是仅仅改变网络出口；后者应通过策略与分流处理，不需要为了走代理而重写网站地址。

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

示例把指定主机的明文地址重定向到对应的加密地址，使用 302 表达临时重定向。正则里的点经过转义，避免把任意字符当成域名分隔符；开头与结尾的边界限制匹配范围；括号捕获路径，替换内容中的 $1 引用该捕获结果。复制正则时要保持反斜杠和半角符号，不要让文本编辑器把它们替换成全角字符。

请求地址是否能够被观察和处理，取决于协议及应用内相应功能条件。不能因为配置里写了一个 HTTPS 正则，就认定所有加密请求的完整 URL 都可被读取。普通转发不等于获得加密内容。本页不以改变证书信任来实现示例；学习重写时应使用自己可控、条件明确的测试请求，不对陌生站点扩大处理范围。

避免循环、范围过宽与认证信息扩散

重定向后的地址如果再次满足同一条件，就可能出现循环。编写时要把输入与输出并排比较，确认协议、主机或路径至少有一处使新请求离开原匹配范围。连续跳转也可能来自目标站点自己的响应，不能仅凭浏览器提示就断定本地规则有循环。先停用本地重写做对照，再检查原始服务是否仍然重定向。

替换目标可能改变请求携带信息的去向，因此不要把含查询参数的完整地址随意改写到另一个主机。登录状态、一次性参数和应用内部跳转都可能对目标名称有依赖。测试时仅使用没有真实凭据的示例，并检查路径与查询部分是否按预期保留。正则匹配成功，只证明文本条件成立，不证明业务流程仍然有效。

Host 与 URL Rewrite 应分别验证。先只启用映射，确认名称对应和访问正常；再单独添加一条重写，观察是否出现预期跳转。若同时改变两者，失败可能来自错误地址，也可能来自新 URL，定位成本会明显增加。需要恢复时，撤销本次新增条目并重新发起请求，避免旧连接和缓存重定向继续影响判断。

从实际请求回到规则，不凭页面结果猜测

验证分流应同时核对三个问题：是否出现了新的请求、命中了什么条件、最后使用了什么策略。页面能打开只是最终现象，不能单独回答前两个问题。反过来，页面失败也可能发生在规则已经正确选择路径之后。结合应用内实际可见的连接与诊断信息判断，记录目标主机及相关规则，不要把所有失败统称为规则失效。

先确认基础网络可用，再核对 Global Routing 与当前配置名称，然后检查保存和载入状态。接着重新产生目标请求，沿规则顺序寻找首次命中的条件。只有确认策略符合预期后，才进入服务器连通性、协议参数和目标服务状态的检查。这样的顺序可以减少无效修改，也避免把一个服务器故障变成大量长期保留的直连例外。

Connectivity Test 与业务访问各自证明一部分

Connectivity Test 的结果应结合应用内所选测试方式解释。它能提供连接检查的参考，却不能覆盖真实业务使用的全部域名、路径和协议条件。测试成功后仍需访问实际目标；测试失败时也应核对测试对象是否适合当前环境。不要根据一个显示结果编造整条链路的健康结论，更不要把测试数值当成规则命中的证明。

服务器超时优先检查地址、端口、认证字段及协议相关参数是否与用户已有信息一致。TLS 场景还要留意名称与系统时间等条件，不应通过修改域名规则来掩盖参数错误。若需要按步骤排查，参考节点超时检查顺序；更常见的连接问题集中在连接故障问答。

最小复现比堆叠例外更有效

复杂配置无法解释时，在副本中保留一个明确目标规则与一条 FINAL，暂时去掉无关的映射和重写，再测试同一个操作。若最小配置符合预期，就逐组恢复原规则，直到找到改变结果的那一组。这里的临时简化只用于定位，不能未经检查就替换长期配置；恢复之后还要复测原来依赖的其他功能。

测试过程中保持网络、服务器选择与访问动作尽量一致。切换网络会改变解析与连接条件，切换服务器会改变代理路径，更新订阅则可能改变条目参数。如果一次同时发生这些变化，就无法从成功或失败推出是哪项起作用。需要切换网络做对照时，明确记录切换前后条件，别把它与规则修改混成同一次实验。

更新、回退与安全分享

配置维护应保留可用基线。每次大改之前复制文件，记录改动目的、涉及章节与预期行为；完成后用同一组主要操作复测。订阅更新的操作细节见订阅导入与更新说明。更新后出现差异时先比较内容，确认是服务器信息变化还是规则文件变化，再决定恢复哪一个对象。

向他人描述问题时，只提供必要的最小片段、模式与命中结果。删除订阅完整地址、认证字段、真实服务器信息，以及可能暴露个人访问行为的记录。配置文件不仅可能包含规则，也可能包含其他敏感设置；不要因为某一段代码看起来只有域名，就直接分享整个文件。展示结果时同样应检查记录中是否有个人信息。

恢复原文件后仍需重新确认选用状态，不能只把副本名称改回原名就认为完成回退。重新载入并重新发起请求，检查预期域名、反例与兜底三类结果。若只有旧连接仍表现异常，先结束它再测；如果新请求也异常，则继续沿模式、规则、策略、连接路径逐层检查，不要反复在同一条规则上改写不同语法。