Shadowrocket 配置字段
与规则参考大全

配置文件结构：先区分段落职责

Shadowrocket 配置文件通常以 .conf 组织内容，方括号中的名称表示段落，段落下的每一行表示设置、映射或规则。文件不是把所有参数连续堆放的一张清单：同样一段文字放在不同段落，含义可能完全不同，也可能无法解析。阅读陌生配置时，先找段落边界，再看具体字段，比直接搜索某个域名更容易判断整份配置的意图。

四个常用段落的分工

[General] 放置通用行为设置，例如 DNS 相关选项；[Rule] 描述流量匹配条件和对应策略；[Host] 为指定域名提供地址映射；[URL Rewrite] 按表达式处理符合条件的 URL。这些功能处在不同处理环节，不能相互替代。需要让域名直连时应先考虑规则，不应为了改变流量去向而随意改写域名解析结果。

从最小片段认识语法

下面的片段演示段落、赋值和规则三种写法。等号用于给设置赋值，逗号用于分隔规则字段，不能把两者互换。规则中的 PROXY 是策略，不是服务器地址；示例没有包含你的服务器信息，因此它只是规则结构参考。使用前仍需在应用中准备可用的已有服务器，并确认当前选择的连接对象。

[General]
dns-server = system

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

逐行阅读时，先检查英文逗号与等号，再检查关键字、参数数量和策略名称。中文输入法产生的全角标点容易看起来相似，却不一定被当作有效分隔符。段落名应保留原文；行首行尾多出的不可见字符、复制时混入的富文本符号，也可能让一条看似正确的规则失效。适合使用纯文本方式编辑，并保留清晰的空行。

完整配置与规则片段的区别

本页代码块多数只展示相关段落，不应把每一个代码块依次拼进同一文件。它们可能用于解释相互独立的情境，尤其多个 FINAL 不能当作多层后备规则堆放。把片段加入现有文件时，应合并到已有的对应段落，先检查是否已经存在同类规则，再决定插入位置，避免重复段落和相反策略增加阅读成本。

服务器订阅和配置文件也不是同一种数据。订阅通常负责提供或更新服务器条目，配置负责规定连接行为；拥有其中一项不代表另一项已经准备好。订阅应从你的服务商处获取，具体格式需要与导入入口相符。对链接类别有疑问时，可先阅读订阅导入方式说明，不要通过反复切换配置来解决链接格式问题。

这一章的检查终点是能说清每个段落的职责，而不是先填满所有段落。没有明确需求的功能可以不添加；较短、可解释的配置更容易验证。遇到陌生字段，先核对应用内说明和实际表现，不能因为它出现在某份配置中，就假定适合当前设备和网络。

General：通用设置与 Global Routing

[General] 是配置层的通用设置区，Global Routing 则是运行时的路由模式入口。两者相关，但不处在同一层：在文本里写好规则后，仍需确认当前模式是否会使用这些规则。排查“规则明明存在却不生效”时，应先检查模式和当前配置，再修改字段，否则容易在错误的前提下不断增加规则。

Config、Proxy、Direct 三种姿态

配置姿态对应 Config，用于按当前配置处理连接；代理姿态对应 Proxy，让通常受应用接管的连接采用代理方向；直连姿态对应 Direct，用于直连方向。这里描述的是整体选择，不代表系统所有连接都一定经过相同路径。系统保留行为、既有连接和未进入处理范围的流量，不能只凭模式名称判断。

如果同一目标在 Proxy 下可访问，而 Config 下失败，可以继续检查规则命中、DIRECT 路径和 DNS 差异，但这还不能直接证明某一条规则错误。测试前后必须保持服务器、目标和网络条件相同。完成对照后恢复原来的姿态，避免临时测试状态变成日常使用状态，使后续现象与配置文本脱节。

DNS 设置不等于流量策略

DNS 用于把域名解析为地址，规则用于决定连接如何处理。域名解析正确，不代表目标连接一定成功；选择了 PROXY，也不能据此推断每次解析请求的处理路径。DNS 还受应用设置、缓存、网络环境和请求方式影响。应把“解析到了什么地址”与“连接采用什么策略”作为两个问题分别检查。

[General]
dns-server = system

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

dns-server = system 表示使用系统 DNS 设置作为此项配置来源，并不承诺当前网络的解析结果一定合适。它适合作为理解语法的起点，而不是所有环境的统一答案。若需要调整解析方式，应先记录原值，每次只改一项，并分别验证目标域名和其他常用域名，防止只解决单个目标却影响其余请求。

缺省值与显式设置的边界

从配置中删除某个通用字段，通常意味着交回缺省处理，并不一定等同于把字段写成某个布尔值。缺省行为还可能结合应用设置，因此不要把“没有这一行”解释成“该功能必然关闭”。迁移配置时保留有明确用途的字段即可；对含义不清的选项，先在副本中试验，不要一次复制整组所谓优化参数。

涉及 IPv6、DNS 和网络范围的设置，会同时影响规则能够观察到的连接信息。例如目标可能优先使用 IPv6 地址，而配置只写了 IPv4 网段；这时不是简单增加一个通用开关就能解释全部现象。应先看实际连接地址，再决定补充地址规则、调整解析行为，还是保留默认选择。改变地址族可能影响其他服务，需要完整复测。

On Demand 与配置规则分开管理

On Demand 关心何时建立连接，[Rule] 关心连接进入处理后如何分流。不能把域名规则写成按需连接的触发配置，也不能因为系统自动连接了就认定特定规则已经命中。先按应用内入口确认 On Demand 的条件，再单独验证配置规则，两个过程分别记录结果，排错时才有清楚的边界。

通用字段的合理目标是让行为可预测，不是让文件尽可能复杂。确认当前模式为 Config、正在使用预期配置、所选服务器可用之后，再进入规则细节。若连基础连接都尚未完成，请返回快速上手主线核对系统授权与连接步骤，本页后续章节以基础连接已可验证为前提。

域名规则：精确、后缀与关键字

域名规则适合描述“哪些主机使用哪种策略”。它通常比不断追踪服务的地址变化更容易维护，但前提是处理连接时能够获得相应域名信息。页面上看到的网址、应用实际连接的主机、登录服务和资源域名可能不同，不能只复制浏览器地址栏的主域名，就假定已经覆盖一次访问产生的全部请求。

DOMAIN：只匹配完整主机名

DOMAIN 用于完整域名匹配。下面第一条仅指定 api.example.com，不会自动扩展到其他同级主机。域名字段不应包含协议、路径或端口；https:// 和 /login 属于 URL 的其他部分，直接放进 DOMAIN 字段不能实现按页面路径分流。需要精确控制某个入口时，应优先采用这种范围明确的写法。

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

维护精确规则时，可以给每个例外写一行简短注释，说明它为什么与其他主机不同。注释应解释业务用途或测试结论，不应保存账号、令牌和完整敏感链接。精确规则数量增多后，先按服务分组整理，再考虑是否确实需要后缀规则；仅为了减少几行文字而扩大匹配范围，往往会增加意外命中的概率。

DOMAIN-SUFFIX：覆盖根域与子域

DOMAIN-SUFFIX,example.com,PROXY 适用于 example.com 及其子域范围，例如 www.example.com 和 api.example.com。它按域名后缀边界理解，不是任意字符串包含关系，因此不应把相似拼写的另一域名视作自然覆盖对象。填写时通常使用根域形式，不要在开头加星号，也不要把路径接在后面。

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

这个顺序表达了先处理例外、再处理一般范围。访问 local.example.com 时，前面的精确规则先命中；访问其他匹配子域时，后缀规则才有机会执行。如果把后缀规则放在最前面，后面的精确规则不会因为“更具体”而自动获得优先权。规则不是浏览器样式选择器，不会在全表中重新计算哪一条最精细。

DOMAIN-KEYWORD：使用前先评估范围

DOMAIN-KEYWORD 检查域名中是否包含指定关键字，范围比固定域名更宽。关键字可能出现在多个互不相关的域名里，因此它适合确有共同命名规律、且已了解影响范围的场景。不能把品牌词、短缩写或常见英文词当成天然准确的服务边界，否则可能把无关连接带入同一策略。

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

上面的片段只是关键字规则的语法演示，不宜直接作为日常分流方案。它说明匹配依据是字符串，而不是站点归属、服务类型或页面内容。若连接记录已经给出了稳定的完整主机名，应优先考虑 DOMAIN 或 DOMAIN-SUFFIX，让规则的含义能够直接从文本中读出，并且能通过有限测试验证。

一次访问为什么可能需要多条规则

登录、图片、接口和媒体资源可能使用不同域名。主页面成功但登录失败时，应查看失败连接的实际主机，而不是立刻扩大到整组模糊关键字。逐个补充明确域名后重试，确认新规则真正改变了对应连接。涉及跳转时还要核对跳转后的目标，原始入口命中并不能证明最终目标也采用相同策略。

若记录中只有地址而没有可用域名，继续增加 DOMAIN 规则可能没有效果。应检查请求是否直接使用地址、域名信息是否可获得，以及地址规则是否提前命中。域名规则解决的是已知主机的匹配问题，不承担服务发现功能。常见疑问也可结合常见问题中的分流排查内容交叉核对。

地址与请求条件：GEOIP、IP-CIDR、USER-AGENT

当目标以地址形式出现，或需要按网段表达访问范围时，可以使用地址规则。它与域名规则的主要差别是匹配对象不同：域名描述主机名称，地址描述连接目的地址。同一域名可能解析到多个地址，同一地址也可能承载多个域名。因此地址规则更适合明确网段，不适合在缺少依据时替代所有域名规则。

IP-CIDR：地址与前缀长度

IP-CIDR 使用 IPv4 地址和前缀长度描述一个网段。斜杠后的数字是网络前缀位数，不是端口，也不是连接数量；数值越大，覆盖范围越小。单个 IPv4 地址可以用 /32 表达。编写前应核对实际网络范围，避免把一个设备地址误写成过大的网段，让其他连接也被归入同一策略。

[Rule]
IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
IP-CIDR,10.0.0.0/8,DIRECT,no-resolve
IP-CIDR,172.16.0.0/12,DIRECT,no-resolve
FINAL,PROXY

这些片段表达常见私有地址范围的直连意图，但是否需要全部加入，仍取决于设备所处网络。规则只决定应用处理范围内的策略，不能保证路由器已经允许访问，也不能替代本地网络权限和目标设备的访问设置。若目标实际上位于另一网络，单纯写成 DIRECT 不会自动建立到那一网络的通路。

no-resolve 的作用与代价

no-resolve 是地址类规则的附加选项，用于避免仅为了尝试这条规则而触发域名解析。它不是“关闭 DNS”，也不表示后续连接不需要解析。对于已经是地址的目标，仍可以按网段判断；对于只有域名、尚无可用地址的请求，不能期待这条规则主动解析后再覆盖它。局域网地址片段常使用这个选项以减少不必要的解析。

如果你的目标是按某个域名解析后的地址归属分流，添加 no-resolve 前要理解它可能改变命中条件。排错时对比“有可用地址信息”和“没有可用地址信息”的请求，比把该选项反复删加更有价值。不要把地址规则中的这个选项机械复制到 DOMAIN 或 FINAL 行，各种规则的字段要求并不相同。

GEOIP：依赖地址归属数据

GEOIP 按地址归属数据判断区域，例如下面的 CN 表示相应区域代码。它不根据网站使用的语言、企业所在地或域名后缀判断。服务采用分布式部署时，解析地址的归属可能与用户直觉不同；数据也可能存在滞后。需要稳定例外时，用明确域名规则放在前面，而不是要求区域规则表达服务身份。

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

这个示例先保留 api.example.com 的明确策略，再对其他连接尝试区域匹配。若没有前面的例外，该域名解析到符合区域条件的地址时可能使用 DIRECT。配置是否符合预期，必须看实际命中的规则和目的地址，不能只看站点名称。地址数据库相关行为还应结合应用当前可用的数据与设置核对。

IP-CIDR6 与 USER-AGENT 的边界

IP-CIDR6 用于 IPv6 网段。下面的地址属于文档示例范围，只演示前缀写法，不能作为真实服务地址使用。IPv4 规则不会自然覆盖 IPv6 目标；若某个连接实际采用 IPv6，应针对其真实需求处理，不能因为 IPv4 规则没有命中就认定整个规则列表失效。

[Rule]
IP-CIDR6,2001:db8::/32,PROXY
USER-AGENT,ExampleClient*,PROXY
FINAL,DIRECT

USER-AGENT 依赖请求中可观察的 User-Agent 信息，并可用通配形式描述字符串。示例中的 ExampleClient 只是演示值，不表示某个实际应用。它不是按设备上安装的应用名称匹配，也不等同于按进程匹配；请求没有对应信息、信息不可见或客户端改变标识时，规则就不能提供预期覆盖。

尤其对加密连接，不应假定普通分流能够读取其中的 HTTP 请求头。不要为使一条 USER-AGENT 规则成立就盲目扩大解密范围。本页的基本分流示例不需要增加此类处理。通常优先使用能够明确观察和验证的域名或地址条件，把 USER-AGENT 视为有适用前提的补充，而不是服务识别的通用方法。

策略与优先级：先匹配的规则先决定

规则的左侧描述条件，右侧描述命中后的策略。PROXY、DIRECT、REJECT 是最常见的策略关键字，分别用于代理、直连和拒绝方向。规则被命中不等于目标一定可访问：命中只说明已经作出处理选择，之后仍可能因服务器不可用、目标拒绝或网络条件失败。应分别验证“选对了策略”和“策略路径可用”。

PROXY 与 DIRECT 都需要可用路径

PROXY 使用当前代理选择所对应的处理方向，不会在缺少服务器信息时自动补全可用连接。若所选服务器失效，规则写得正确也会失败。DIRECT 则依赖设备当前网络对目标的可达性，并不是比代理更高一级的修复方式。两种方向都应通过同一目标的实际请求验证，不能只看规则文字判断速度或稳定性。

REJECT 用于明确拒绝匹配请求。它表达管理意图，不是连接失败后的备用策略。将大范围域名设为 REJECT 前，应了解该范围是否包含登录、验证和资源接口；否则可能出现主页面能打开、部分功能持续失败的现象。排查此类问题时优先查拒绝记录，不要先修改服务器参数。

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

具体规则必须放在宽泛规则前面

规则通常按列表自上而下尝试，先命中就采用对应策略，不会等所有条件检查完后再选择“最精确的一条”。上面的顺序先处理两个例外，再对 example.com 的其余范围应用后缀规则。若把后缀规则移到第一行，两个例外就会被前面的范围覆盖。阅读配置时应像执行流程一样逐行判断，而不是只查找有没有某条规则。

优先级来自所在位置，不来自关键字本身。DOMAIN 不会天然压过 DOMAIN-SUFFIX，域名规则也不会天然压过地址规则。为了让维护者容易理解，可以采用“明确例外、服务范围、网络范围、最终策略”的编排方式，但这是一种组织习惯，不是应用自动进行的排序。导入后应检查实际列表，确认编辑结果保持了预期顺序。

FINAL 是兜底，不是自动故障转移

FINAL 不需要填写域名或地址条件，常放在规则列表末尾，指定前面均未命中时的方向。它不是“前一条连接失败再执行”的指令。如果某条规则已经匹配 PROXY，而代理连接失败，不能期待下一行 DIRECT 自动接管。条件匹配和路径故障是两套问题，混在一起理解会造成错误的后备设计。

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

这个片段表示只给明确范围使用 PROXY，其余使用 DIRECT。把最后一行改成 FINAL,PROXY，则未命中部分会使用代理方向。这两种设计都可以表达清楚的意图，没有脱离需求的统一答案。选择时应列出哪些服务必须有明确例外，并在修改最终策略后复测原本没有专门规则的目标，不能只测试已写入规则的域名。

用逐条推演检查冲突

对一个目标进行人工推演时，先写出它的实际域名与地址，再从第一条规则开始问“当前信息是否满足条件”。一旦找到首个命中项就停止，记录策略和所处位置。如果推演结果与实际记录不一致，再检查当前配置、DNS 结果、已有连接以及是否获得相同目标信息。这个方法能把宽泛规则遮挡、错误例外和兜底遗漏分开处理。

不要用重复规则表达优先级，也不要依靠多个 FINAL 猜测执行结果。删除重复项前先核对它们是否带有不同策略或附加选项；合并后保留一份能够解释的顺序。维护完成的标准是能对常用目标说明“为什么命中这一行”，而不是规则数量更多。若策略正确但仍失败，下一步应转入连接诊断，不应继续堆叠同条件规则。

Host 与 URL Rewrite：地址映射和 URL 处理

[Host] 和 [URL Rewrite] 经常与规则文件一起出现，但它们不是分流规则的不同拼写。Host 改变指定域名的解析映射，URL Rewrite 处理满足表达式的 URL，而 Rule 决定连接策略。先明确你要改变的是“名称对应的地址”“请求的 URL”还是“连接的去向”，才能选择合适段落，避免多处修改后无法解释结果。

Host 映射需要真实有效的目标地址

下面的 Host 示例把完整主机名指向一个文档示例地址。该地址仅用于演示格式，不能直接用于访问真实服务。实际使用时，只有在你掌握目标地址、确认服务接受相应主机名并能维护地址变化时，才适合固定映射。共享部署、负载均衡和服务迁移都可能让长期固定的地址失效。

[Host]
api.example.com = 192.0.2.10

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

Host 行本身没有指定 DIRECT 或 PROXY。示例中连接策略由 Rule 段落决定，不能把映射成功当作策略正确。即使域名已经解析到指定地址，目标端仍需正确提供对应服务，证书也应与访问的主机名相符。遇到证书或主机错误，应恢复映射并核对目标，不应通过降低验证要求来掩盖地址选择问题。

如果某个域名以前可访问、固定映射后反而失败，先删除或恢复这一条 Host，再以相同条件重试。服务地址可能变化，网络也可能返回不同可达地址。排错时记录固定映射前后的结果，才能判断问题是否由映射造成。对于没有持续维护能力的域名，保留正常解析往往比手工固定地址更容易保持一致。

URL Rewrite 的三个部分

URL Rewrite 通常包含匹配表达式、替换目标和处理动作。下面展示将指定示例域名的 HTTP URL 重定向至 HTTPS 的形式：表达式从地址开头匹配，括号捕获路径，替换部分通过 $1 引用捕获内容，末尾 302 表示重定向动作。它是独立的语法例子，不表示所有网站都应该添加相同规则。

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

表达式中的点需要转义，才能表示域名中的字面点号；不转义的点在正则表达式中通常具有更宽泛的含义。开头的 ^ 限定从 URL 起始位置匹配，减少误中包含相似文本的其他地址。编写时应同时测试应该命中的请求和不应命中的请求，而不只是确认一个成功例子。

重定向不是代理策略切换

重定向会让客户端发起新的请求，新目标仍需按适用规则处理。它不等于把原连接设置成 PROXY，也不能修复服务器密码或协议参数错误。如果替换后主机发生变化，还应分别检查原始主机和目标主机的规则。循环重定向通常来自规则互相指回、服务端跳转与本地处理冲突，应先停用相关 Rewrite 缩小范围。

URL 是否能够被处理，还取决于协议、请求信息可见性及相关功能设置。不能从一个普通 HTTP 示例推导出可以读取任意 HTTPS 路径。加密连接的路径与请求头并不天然暴露给普通分流处理，本页不要求为此启用额外解密功能。只想按主机分流时，优先使用域名规则，保持处理范围与需求一致。

维护时给每条映射写出撤销条件

有效的维护记录不仅说明为什么增加，还应说明什么时候删除。例如临时测试某个服务地址，测试结束后就恢复正常解析；为某次迁移增加重定向，则在入口统一后重新评估。没有撤销条件的临时条目容易成为长期故障来源。修改文件前搜索同域名在其他段落的出现位置，避免一处恢复、另一处仍在改变请求。

当连接表现与预期不符时，依次列出原始 URL、映射地址、改写后的 URL 和最终命中策略。四项中只要有一项与你的假设不同，就先处理该层。这样可以区分地址过期、表达式过宽、目标跳转和策略选择错误，而不是把所有异常都归结为规则失效。复杂功能应建立在最小配置已验证的基础上。

配置导入与维护：保留来源、选择与回退

配置管理的关键不是保存了多少文件，而是能确认当前生效的内容、知道哪些部分会被更新覆盖，并能恢复到已验证状态。已有订阅应从你的服务商处获取；导入前先辨认链接提供的是服务器列表、完整配置还是其他数据。不同入口期待的内容可能不同，链接能在浏览器打开，也不等于它就是当前入口能够解析的格式。

导入前先确认数据类别

服务器订阅更新后可能改变服务器名称、条目数量和参数，规则配置更新后可能改变策略和顺序。两者应分开记录。若你只想添加已有服务器，不应为了让导入成功而替换整份已经验证的配置；如果导入的是完整配置，则要先检查其中是否包含 General、Host、Rewrite 等额外设置，了解它是否会改变现有网络行为。

在 Config 中管理文件时，导入完成后还要确认选中的是预期配置。文件存在于列表里与文件正在生效不是同一件事；编辑了一个副本，也不代表运行时已经切换到该副本。建议使用用途明确的文件名区分日常配置与测试配置，并记录选择状态。具体导入入口按应用内显示操作，初次使用可参照使用说明。

把一次改动缩小到可验证范围

例如只想让本地服务直连，可以先添加一条精确域名规则，而不是同时替换 DNS、增加网段、改变 FINAL 并加入 Rewrite。每增加一个变量，就多一个需要解释的分支。保留副本后只修改相关段落，使用同一个目标重试，再确认其他常用目标没有受影响。成功之后再决定是否扩展规则覆盖范围。

# 本次仅增加 local.example.com 的直连例外
[Rule]
DOMAIN,local.example.com,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

注释应写清“本次改变了什么”和“怎样验证”，不要只写模糊的优化、修复或加速。文件名、注释和测试记录也不应包含真实订阅令牌。订阅链接往往具有访问凭据性质，复制给他人排错前应移除完整查询参数及敏感服务器信息。保留必要的语法结构即可，不需要公开真实凭据才能解释规则问题。

远程更新与本地修改要分别看待

远程配置再次更新时，本地改动可能被替换，具体取决于你采用的管理方式。更新前记录自定义条目和所在位置，更新后比较规则顺序、最终策略及额外段落。不要仅凭文件名称相同就假定内容未变，也不要在发现规则消失后立即重复导入多份。先确认更新对象和生效选择，再恢复必要的自定义内容。

服务器条目名称变化也值得核对。若其他配置内容引用了某个名称，更新后的名称不一致可能导致引用失效。即使本页主要使用内置策略，也应检查服务器选择是否仍指向预期对象。导入和更新完成后，分别验证服务器连通性、Config 姿态和规则命中，避免把服务器更新问题误判成规则语法问题。

恢复配置不等于恢复购买或账号状态

配置文件用于网络行为，不负责恢复 App Store 购买。Shadowrocket 是 Apple 平台付费应用，唯一获取入口是 App Store；购买与已购恢复请阅读已购项目恢复说明。系统要求以 App Store 页面标注为准。客户端一次性买断 ≠ 线路套餐，应用购买不会自动为配置补充服务器，仍以你已有的服务信息为前提。

切换设备前，应分别保存需要保留的配置与服务器信息，并确认敏感数据的存放位置。系统备份、应用内导入与 App Store 已购恢复承担不同职责，不能互相替代。重新安装后能打开应用，并不能证明原来的规则、订阅和选择状态已经恢复。按顺序检查这些项目，比直接导入所有旧文件更容易避免混乱。

当订阅更新失败或列表为空时，先检查链接格式、有效性和服务商侧状态，不要通过重写 Rule 段落处理解析问题。可参照订阅更新失败或节点为空的自查步骤。维护结束后保留最近一次已验证副本，清理不再使用的测试文件，降低后续误选旧配置的机会。

验证与排错：从现象回到实际命中

验证规则应建立一条可复述的证据链：当前使用哪个配置，处于哪种 Global Routing 姿态，请求的真实目标是什么，命中哪一条规则，最终采用什么策略，连接又在哪个环节失败。只说“网络不通”不足以区分问题。先把现象缩小到单个目标和单次测试，再按处理层逐项核对，通常比反复替换整份配置更有效。

第一步：固定测试条件

先记录当前网络、所选服务器和配置名称，选一个可重复访问的目标。测试时尽量保持条件不变，不要同时切换网络、服务器和规则。应用可能复用旧连接，配置修改后既有连接不一定立刻重新匹配；必要时结束相关请求并重新发起，再检查新连接记录。避免把旧连接的结果当作新规则的执行结果。

可用下面的片段建立最小对照，但应在副本中测试，并把示例域名替换为你明确掌握的目标。它的用途是减少规则数量，让命中更容易解释，不是作为全部日常流量的通用方案。如果最小对照正常，再逐组恢复原配置；若恢复某组后复现异常，就集中检查该组的范围、顺序和附加设置。

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

第二步：分清测试工具的含义

Connectivity Test 可帮助观察服务器在相应测试方式下的可达性，但不能替代每个目标的实际访问。某个测试成功，不代表所有协议、端口和远端服务均可使用；测试失败也需要结合测试方法和真实请求判断。应同时观察目标访问结果和连接记录，不要把一个测试数值当成整套规则正确的证明。

第三步：按症状进入对应层

解析失败时，先核对域名拼写、DNS 设置和 Host 映射；连接超时时，检查实际目的地址、策略路径及目标服务；出现明确拒绝时，检查 REJECT 规则和目标返回的拒绝是否属于同一层。应用返回的业务错误不一定是网络错误，目标服务的登录状态、请求权限和接口条件也可能导致失败，需要避免越过证据直接修改网络配置。

如果页面只有一部分资源失败，按失败请求逐个核对主机和策略，不要立刻把所有流量改成同一方向。若同域名在不同网络表现不同，应记录解析结果和地址族，再检查是否受地址归属规则影响。若问题只在更新后出现，则比较更新前后的配置内容和服务器选择，先找变化，再考虑新增补丁规则。

第四步：把回退也作为测试

恢复到已验证配置后重复相同请求，如果问题消失，说明本次配置变化值得重点检查；如果问题仍然存在，则应继续检查网络、服务器和目标本身。回退不是简单地宣布配置无效，而是一个控制变量实验。每次测试只保留一个差异，记录预期与实际结果，才能让后续修改有依据，而不是凭一次偶然成功继续叠加设置。

提交问题描述时，提供界面姿态、目标类别、规则片段、预期策略和实际命中即可。移除订阅完整链接、密码、令牌与个人地址，连接记录中不相关的域名也应删去。保留首个命中项附近的必要上下文，比只截一行规则更有帮助，因为顺序问题常发生在它前面的宽泛规则，而不是该行本身。

需要复习首次导入、授权与连接流程时，返回使用说明；需要集中查找短问答时，进入常见问题；购买与正版信息则以App Store 正版核验为入口。本页的查阅顺序始终是先确认配置结构，再确认条件与顺序，最后用实际连接验证，不以规则数量替代可解释性。