Shadowrocket
规则与配置参考大全

配置文件描述的是连接处理方式，不是服务器账户本身。理解这一点，可以避免把“导入后出现服务器”和“选中了分流配置”当成同一件事。服务器信息回答连接到哪里、采用什么协议以及如何认证；配置文件则回答哪些请求直接连接、哪些请求使用代理、哪些请求应当拒绝。两者需要配合，但导入其中一项不代表另一项已经就绪。使用已有订阅时，应先确认 Home 中的服务器信息，再检查 Config 中实际启用的配置。

段名、字段与规则行

Shadowrocket 的配置文本使用带方括号的段名划分用途。[General] 放置通用参数，常见形式是字段名、等号和字段值；[Rule] 放置有顺序的分流规则；[Host] 描述指定主机名的地址映射；[URL Rewrite] 则处理符合条件的 URL。段名不是装饰性标题，放错位置会改变解析含义。不要将 General 的等号语法套进 Rule，也不要把用于说明的中文直接拼在规则参数后面。

[General]
bypass-system = true

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

[Host]
router.example.com = 192.168.1.1

这份片段展示段落之间的关系，不是适用于所有网络的成品配置。第一条规则让指定主机直接连接，第二条覆盖示例域及其子域，第三条针对一个私有地址段，最后一条负责兜底。Host 映射只是将示例主机名对应到地址，不代表该地址存在服务。实际保存时，应保留自己原有且理解用途的必要字段；若已有配置由远程来源维护，还要考虑下次更新是否会覆盖本地改动。

保存副本与确认活动配置

修改前先在 Config 中识别当前选中的配置，记录其名称以及可恢复的位置，再保存独立副本。仅仅打开某个文件进行编辑，不足以证明该文件正在参与连接处理。保存之后，需要回到配置列表确认选中状态，并用新连接验证。若编辑界面提示语法问题，应先修复再启用，不要带着解析错误继续添加更多内容，否则后续现象难以对应到具体变更。

文件副本和服务器备份也要分开理解。恢复一份规则配置，不一定恢复服务器的认证字段；重新导入订阅，也不一定恢复手动增加的规则。迁移前分别检查服务器、配置和必要的设置项。配置中可能包含私人域名、服务器标识或认证信息，向他人提供排错材料时，应先删除这些内容，只保留能够复现问题的最小规则和经过处理的连接记录。

怎样阅读本页的配置示例

示例中的 example.com 用于解释语法，不是可用订阅入口，也不表示该域名需要特定策略。示例地址与规则应按自己的实际环境替换。代码块中的空行用于分组；完整段落可以整体查阅，但零散片段应放回对应配置段。对不熟悉的选项，先确认应用内是否识别，再查其作用范围。字段名称相似，不等于行为相同，不能凭字面含义猜测后批量追加。

远程规则文件与本地配置还涉及维护责任。自行增加例外时，最好记下修改原因、验证对象与预期策略，并在每次更新后复查这些例外是否仍在。保留少量可解释的规则通常比堆积来源不明的长列表更容易维护。本手册后续章节按“设置运行条件、建立匹配范围、选择策略、观察结果”的顺序展开；排错时也应沿着同一条顺序回查。

先确认 Global Routing，再讨论 Rule 中的规则是否正确。配置文件已经保存，但当前姿态并非 Config，是“规则没有生效”最常见的判断前提之一。界面中的 Config、Proxy、Direct 对应配置、代理、直连三种姿态；它们决定连接处理的整体方向，而不是给某条规则增加不同优先级。需要测试分流时，应明确选择 Config，并在每轮验证前检查当前姿态是否被改动。

General 不是另一份规则表

[General] 的字段控制通用行为，不能用它替代逐域名的 Rule。比如 bypass-system 与 skip-proxy 涉及系统及特定目标的绕过处理，它们与普通 Rule 命中的层次不同。若某个目标已经在更早的绕过路径中处理，单纯向 Rule 增加一行 PROXY 可能看不到预期结果。因此排查时既要看规则，也要检查通用设置是否使连接没有经过预想的处理路径。

[General]
bypass-system = true
skip-proxy = 127.0.0.1, localhost, *.local
dns-server = system

这里保留系统绕过行为，并列出本机与本地域名形式，DNS 使用系统提供的解析设置。该片段用于认识字段，不建议覆盖原配置后直接使用。尤其是 skip-proxy，其列表属于通用字段的取值，不能据此推断 Rule 也接受相同的通配形式。读取已有文件时，先辨认该行属于哪个段，再根据该字段的语义理解逗号分隔项，避免把两类语法混在一起。

连接开关、按需连接与规则各管一层

Home 中的连接开关负责启动或停止连接处理；Global Routing 决定运行姿态；活动配置中的 Rule 决定 Config 姿态下的匹配策略。这三个条件必须分别确认。On Demand 处理的是满足条件时是否按需建立连接，不负责为每个域名选择 PROXY 或 DIRECT。出现网络切换后状态变化时，应先检查连接是否仍然建立，再看运行姿态，最后才检查规则顺序。

首次建立连接时，系统可能要求允许添加 VPN 配置。这个授权表示应用可以使用相应的系统网络能力，不代表已有服务器一定可达，也不是规则正确的证明。若尚未完成首次连接流程，可返回快速上手教程按顺序操作。系统要求以 App Store 页面标注为准，不应依据别人的旧截图推断当前设备是否兼容。

用姿态切换做有限的对照测试

对于同一个测试目标，可以短暂比较 Direct 与 Proxy 的新连接结果，以区分直接路径问题和代理路径问题；完成对照后再回到 Config。测试期间保持目标、网络和服务器不变，才能减少变量。某个页面在 Proxy 下打开而在 Config 下失败，只能说明分流路径值得检查，不能直接认定所有 DIRECT 规则都有问题；页面可能同时访问多个域名，需要逐个查看对应记录。

同样，Direct 下可以打开页面，也不表示这项服务永远应该直连。网络位置、解析结果、目标服务的访问条件都可能改变。合理的配置应表达明确需求，而不是把某次测试结果固化为普遍结论。对于 General 中不确定的设置，优先恢复已知可用的副本，再逐项核对；不要通过反复切换多个开关来碰运气，这会掩盖真正的处理边界。

域名规则优先解决“按哪个主机名选择策略”的问题。常用类型包括 DOMAIN、DOMAIN-SUFFIX 和 DOMAIN-KEYWORD，区别在于匹配范围，不在于规则名称长短或所谓权重。三者仍然按照在 Rule 中的实际位置参与判断。编写前先把目标主机名从 URL 中分离出来，不要把协议、端口、路径、查询参数一起填入域名参数。

DOMAIN：明确指定一个主机

DOMAIN,api.example.com,PROXY 面向指定主机名，适合只改变单个接口或建立窄范围例外。它不自动表示整个 example.com 域，也不等同于所有子域。一个应用可能把登录、图片、文件下载分在不同主机上，仅添加一个 DOMAIN 后主页面能打开，并不能证明所有相关连接都采用相同策略。需要根据实际记录补充目标，而不是根据应用名称猜测域名。

DOMAIN-SUFFIX：覆盖域及其子域

DOMAIN-SUFFIX,example.com,PROXY 用于匹配该域及其子域，例如 www.example.com 和 api.example.com。这里的域名后缀有域标签边界，不应按任意字符串结尾理解。写规则时直接填写 example.com，不必为表达子域覆盖而增加 https://、斜杠或路径。需要排除其中某个主机时，将它的精确规则放在这条宽范围规则前面。

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

这个顺序表达“状态主机直接连接，其余示例域使用代理”。如果交换前两行，状态主机会先被后缀规则覆盖，后面的精确例外便没有机会执行。精确规则之所以实现例外，是因为排在前面，而不是因为 DOMAIN 自动高于 DOMAIN-SUFFIX。维护文件时，应把例外与所属的宽范围规则放在相邻位置，以便检查两者关系。

DOMAIN-KEYWORD：范围更宽，需谨慎验证

DOMAIN-KEYWORD,example,PROXY 根据域名中的关键词匹配，范围可能跨越多个互不相关的域。它不是按品牌、网站归属或页面内容判断，也不会理解某个英文词的业务含义。短关键词容易覆盖额外目标，尤其是多个单词在主机名中相连时。除非确实需要关键词范围，否则应优先使用 DOMAIN 或 DOMAIN-SUFFIX，让规则意图能够通过域名本身核对。

为什么按网页地址写规则仍可能漏匹配

网页地址栏只显示入口地址，页面资源可能来自其他主机。跳转、登录验证、媒体资源和接口请求都可能建立独立连接。应在连接记录中查看真正失败的目标，区分是入口请求失败还是后续资源失败。不要因为页面中显示某个路径，就尝试用 DOMAIN 匹配路径；域名规则只能表达主机层面的范围，URL 路径属于另一类处理条件。

此外，客户端需要在对应连接中获得可用的域名信息，域名规则才有匹配依据。直接访问 IP、应用自行处理解析或已有连接被复用时，观察结果可能与地址栏直觉不同。域名规则后仍需安排地址规则与 FINAL，以覆盖没有命中域名条件的连接。排查时以记录中呈现的目标信息为准，不要把“没有看到域名命中”直接解释为规则解析失败。

整理长规则表时，可以先按业务需求写最窄的精确例外，再写域级覆盖，最后才考虑确有依据的关键词规则。每次增加范围较宽的条目，都应测试一个应当命中的目标和一个不应命中的目标。只验证成功样本会忽略误匹配；双向验证能更早发现关键词过短、后缀写错或者例外顺序颠倒的问题。

地址规则根据连接目标的 IP 判断策略，与“某个网站属于哪里”不是同一概念。一个域名可能解析到多个地址，不同网络或不同时间也可能返回不同结果。服务还可能使用分布式基础设施，因此应把 IP-CIDR 和 GEOIP 理解为地址层面的条件，而不是固定的网站分类。遇到同一域名时而直连、时而代理，先比较每次连接的目标地址，再判断地址规则是否参与了结果。

IP-CIDR：明确表达一个 IPv4 网段

IP-CIDR,192.168.0.0/16,DIRECT 表达一个地址范围，其中斜杠后的前缀长度决定范围大小。前缀越长，范围越小；要匹配单个 IPv4 地址，可使用 /32。网段地址应与掩码边界相符，不要把普通网址、端口或任意起止地址填进这一参数。维护局域网规则时，应依据当前网络实际使用的地址段，不要将某个私有网段误认为所有本地服务的共同地址。

[Rule]
IP-CIDR,192.168.1.10/32,DIRECT,no-resolve
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
FINAL,PROXY

第一条说明单地址写法，第二条覆盖更大的地址范围，因此第一条在这个示例中不会改变最终策略，只是便于观察范围关系。若两条策略不同，顺序就会直接影响结果。IPv6 地址应使用 IP-CIDR6，并采用 IPv6 前缀表示法，不能因为浏览器显示了域名，就认定连接只使用 IPv4。排错记录中出现 IPv6 目标时，应检查相应的 IPv6 规则与实际网络可达性。

no-resolve：控制为匹配而触发的解析

地址规则末尾的 no-resolve 用于避免仅为匹配该规则而触发域名解析。它不是让整个应用停止 DNS，也不是禁止所有解析请求。如果目标已经是 IP，或连接处理中已经有可用于判断的地址，该参数并不意味着地址规则永远跳过。需要按域名先处理、地址规则只补充已知地址的场景，可以结合此参数减少不必要的解析，但应通过实际记录确认效果。

GEOIP：按地址数据库分类

GEOIP,CN,DIRECT 根据目标地址在数据库中的分类匹配，而不是根据域名后缀、网页语言或用户所在地判断。数据库可能存在更新延迟或归属差异，不能用它证明服务的运营主体或数据存放位置。某个域名需要稳定采用指定策略时，明确的域名规则通常比依赖地址分类更容易解释；GEOIP 更适合作为已理解其边界的补充条件。

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

该例先处理明确域名，再按地址分类补充，最后交给 FINAL。若域名规则已命中，不会继续比较 GEOIP 来重新选择策略。反过来，提前放置范围较宽的地址条件，可能使后面的域名意图无法实现。不要把不同类型的规则看成互相投票的条件；它们共用同一条顺序链，先命中的条件决定这次判断的出口。

USER-AGENT：依赖可取得的请求信息

USER-AGENT,Example*,DIRECT 演示根据 User-Agent 模式匹配的写法。它不等于按应用名称分流，也不保证可以识别设备上的每个应用。请求必须具备可供判断的相应信息，才可能匹配。对于加密的 HTTPS 流量，不能假定仅启动连接开关就能读取其中的 HTTP 请求头；信息不可见时，应改用能够核对的域名或地址条件，而不是不断扩大模式。

诊断时建议先用一条明确的 DOMAIN 规则建立对照，再考虑 USER-AGENT 这样的补充条件。不要为测试某条规则就扩大证书信任或修改大量请求处理设置。若目标应用会改变请求头、使用不同网络库或复用连接，模式匹配也可能变化。规则的可靠性取决于实际可见的输入条件，不取决于名称是否看起来更接近应用本身。

规则由匹配条件和处理策略共同构成。匹配条件回答“是不是这类连接”，策略回答“命中后怎样处理”。PROXY、DIRECT、REJECT 是不同处理结果，不是三种连接质量等级。把所有目标都改成同一个策略可能暂时绕开某个现象，但会丢失原配置的分流意图。应先明确每类目标的需求，再选择最小范围的匹配条件与相应策略。

自上而下，首条命中即停止

在 Rule 规则序列中，先出现并满足条件的规则决定策略。不能假定更精确的 DOMAIN 总会覆盖较早的 DOMAIN-SUFFIX，也不能假定地址规则天然低于域名规则。所谓“例外优先”需要通过排列位置实现。阅读复杂配置时，应该从第一条相关规则向下检查，而不是只搜索目标域名后停在最符合直觉的那一行。

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

在这个例子中，两个指定主机先被单独处理，其他示例域交给 PROXY；未命中域名条件的连接继续检查地址规则；前面均未命中才进入 FINAL。若把 FINAL 移到最前面，后续规则就失去了正常参与匹配的机会。FINAL 不带域名或地址参数，写作 FINAL,PROXY，不要误写成普通三段式规则。

命中 PROXY 不等于能够连通

规则匹配成功只证明策略选择符合条件。后续仍可能发生服务器不可达、认证失败、目标拒绝或解析异常。PROXY 通常交由当前所选代理路径处理；若现有配置使用命名策略或策略组，还需确认相应名称确实存在且指向预期选择。拼写错误、删除了被引用的组、组内选择改变，都可能表现为“规则写对了却打不开”，但问题不在匹配条件本身。

DIRECT 也不是绕过当前网络限制的承诺，而是让连接直接前往目标。若本地网络无法访问该目标，DIRECT 的失败属于路径问题。REJECT 则是明确拒绝，并不负责修复页面布局、删除已经缓存的内容或区分同一主机里的不同用途。一个主机同时承载登录和其他资源时，整域拒绝可能一起影响正常功能。相关边界可继续阅读REJECT 规则写法与匹配限制。

如何选择 FINAL 的策略

FINAL 是未命中连接的默认决定，不是“智能判断”开关。选择 PROXY 表示未明确分类的连接使用代理路径；选择 DIRECT 表示未分类连接直接连接。应根据自己的配置目标、现有规则覆盖范围及可接受的失败方式决定。仅修改 FINAL 可能改变大量此前未被注意的连接，因此必须同时观察正常样本和异常样本，不能只测试一个网页就结束。

维护时应保留一个清晰的 FINAL，并让它位于规则序列末尾。多个 FINAL 不会形成备用线路，较早的兜底会先结束判断。规则顺序也不是服务器故障切换机制；某条 PROXY 规则命中后连接失败，不会因此自动继续向下尝试后面的 DIRECT。匹配过程与连接建立是两个阶段，不能把后续规则当成失败后的补救步骤。

当规则表越来越长时，建议清理完全重复的条目，检查被上方宽范围规则覆盖的条目，并为重要例外保留修改记录。不要仅按字母排序整个 Rule 段，因为排序会改变优先关系。可读性应服务于执行顺序：同一组的精确例外、范围规则和补充规则保持相邻，末尾兜底独立可见，后续查阅才容易确认配置是否仍与需求一致。

DNS 负责把主机名解析为地址，分流规则负责根据可用条件选择连接策略，Host 则可以为指定主机提供映射。这三个概念有关联，但不能相互替代。页面打不开时，先判断是没有得到地址、得到了不合适的地址，还是地址可用但连接路径失败。直接更换全部 DNS 设置可能暂时改变现象，却无法解释真正的故障位置。

General 中的 DNS 设置

dns-server = system 表示使用系统提供的解析设置。它的效果依赖当前网络环境，不代表每次都得到同一个答案。若已有配置采用其他明确的解析方案，应保留其完整语义，先检查字段是否识别、地址是否可达以及与现有配置是否协调。不要把网上一串解析地址直接追加进来，尤其不要混入不理解用途的扩展参数后就据此判断规则是否有效。

[General]
dns-server = system

[Host]
router.example.com = 192.168.1.1

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

示例将指定主机映射到私有地址，并明确给它安排 DIRECT。这里同时写出 Host 与 Rule，是为了表达解析结果和处理策略的两个独立意图。不能把“映射到了本地地址”直接等同于“必然采用直连”，也不能认为有一条 DIRECT 就会自动生成正确的地址。实际设备还需要能够到达该私有地址，并且目标服务确实在对应端口工作。

Host 不修改目标服务的身份

Host 可以改变连接使用的地址，但不会把另一台服务器变成原域名的合法服务。HTTPS 还涉及证书与主机名校验；映射到错误地址后，即使网络层可以建立连接，也可能出现证书错误或服务不匹配。遇到这类问题，应撤回映射并核对地址，不应把关闭身份校验作为常规解决办法。私有服务同样需要正确配置自己的域名与证书。

维护 Host 时要注意地址可能变化。移动设备切换网络后，原本存在的私有地址未必仍然可达，也可能对应另一台设备。固定映射适合明确、稳定且能够验证的目标，不适合把一次解析结果长期写死给公共服务。特别是使用分布式地址的域名，固定单个 IP 可能绕过正常的地址选择，造成部分地区可用、部分网络失败的现象。

解析结果与规则命中的先后关系

域名规则可以直接依据域名判断；地址规则则需要可用的 IP 信息。有些地址判断会涉及解析过程，前文的 no-resolve 正是用于控制是否为了匹配而主动解析。若一条明确的 DOMAIN 已经命中，后续 GEOIP 并不会再推翻结果。因此分析连接记录时，应把目标域名、解析地址、命中规则和最终策略一起看，不能只比较地址的地理分类。

当记录里只有 IP 时，不要立刻认定 Host 或 DNS 失效。应用可能直接连接 IP，或者连接信息在当前观察阶段没有呈现域名。反过来，能看到域名也不代表所有解析都经过相同路径。排错应围绕可复现的单个请求，使用相同目标、相同网络和新建连接，逐步确认哪个环节提供了匹配依据。

缓存与旧连接会影响验证

修改解析设置或 Host 后，已有连接未必立刻改变目标地址，应用自身也可能保留解析结果。应先保存配置，按需要重新建立连接，再让目标应用发起新请求。不要用仍在播放的媒体或长期保持的消息连接判断新规则；这些连接可能在修改前就已经建立。即使重新加载页面，也应检查记录确认是否真的出现了新的目标连接。

如果多个无关域名同时解析失败，应优先检查当前网络与解析路径，而不是为每个域名添加 Host。若只有一个域名异常，先检查拼写、既有映射及目标服务状态。Host 是精确管理地址的工具，不是修复所有 DNS 问题的通用清单；让映射保持少量、明确且可撤回，通常更有利于移动设备在不同网络之间稳定切换。

URL Rewrite 与 Rule 的职责不同。Rule 为连接选择 PROXY、DIRECT 或 REJECT 等策略；URL Rewrite 针对可处理的请求 URL 进行匹配与改写。需要改变某个域名的连接路径时，应先使用 Rule，而不是用 URL Rewrite 代替分流。需要按完整 URL 的特征处理请求时，再检查是否具备相应的请求可见性与处理条件。

先理解正则匹配的对象

URL Rewrite 的匹配部分通常使用正则表达式，必须分清开头锚点、字符转义与匹配范围。域名中的点在正则中具有特殊含义，要表达字面上的点，应写作 \.。开头的 ^ 限定从 URL 起始位置匹配；缺少必要边界会使匹配范围变宽。不要把正则片段直接放入 DOMAIN，因为两者使用的匹配语言不同。

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

该例仅演示重定向语法：匹配指定主机的精确路径，将请求引导到另一个路径，并使用 302。末尾的 $ 限定字符串结束，因此带查询参数的 URL 不会自动与此例等同。目标地址仍然是语法示例，不应作为实际服务测试。与任意匹配相比，先写窄范围、可解释的条件，能够更容易判断重定向是否只影响预期请求。

查询参数、路径边界与重定向循环

URL 中的路径、查询串和主机名属于不同部分。若要允许查询参数，应明确设计匹配范围及保留方式，不能简单删除所有边界后期待行为保持不变。参数中可能包含登录状态、签名或一次性标识，随意丢弃会使请求失效。对带认证用途的请求，优先保持原样，先在不涉及私人信息的测试目标上理解表达式的实际结果。

还应确认改写后的目标不会再次落回同一条规则。如果来源范围包含目标范围，客户端或目标服务可能不断重定向，最终表现为页面反复加载或提示跳转次数过多。多个改写条目之间也可能相互指回。排查时画出“原 URL、改写目标、服务端再次返回的位置”这条顺序链，分别确认每一跳，不要只看第一条表达式是否匹配。

HTTPS 不会自动暴露完整请求

HTTPS 的路径与请求头位于加密通信之内，不能假定普通分流已经具备读取和改写完整 URL 的条件。域名分流可用，不表示路径改写也一定可用。涉及 HTTPS 请求处理时，还需独立理解应用内相关功能、证书信任范围与目标应用的校验方式；部分应用可能采用更严格的证书校验，不能承诺所有请求都能够按相同方式处理。

REJECT 与内容处理的区别

Rule 中的 REJECT 面向匹配连接，并不分析页面里的每个元素。若页面内容与必要接口共用同一域名，拒绝该主机会同时影响其他请求。URL Rewrite 可以表达更细的 URL 条件，但仍受实际可见性、协议方式和目标行为约束。不能把某条改写或拒绝规则解释为适用于所有应用的内容清理方案，也不应把加载失败一概视为规则达到了目的。

验证改写时，应记录原始 URL 的结构、预期目标以及实际出现的跳转，而不是保存包含私人参数的完整地址后公开分享。检查目标是否保持原有协议要求，是否意外丢失路径或参数，再确认最终页面是否完成正常功能。与分流测试一样，还要验证一个不应受影响的请求，防止正则过宽而改变同站的登录、支付或其他必要流程。

维护上建议把临时测试条目与长期需要的条目分开记录，删除失去使用依据的表达式。远程配置更新后，也要检查相关规则是否改变了匹配范围。关于拒绝策略与域名范围的进一步说明，可查阅REJECT 原理、匹配范围与做不到的事；先掌握连接层的边界，再决定是否确实需要请求层处理。

有效的排错应同时回答四个问题：目标是什么、命中了哪条规则、采用了什么策略、最终在哪个阶段失败。只描述“打不开”不足以确定问题在规则、解析还是连接路径。开始前先选择一个可以反复访问的测试目标，记录当前网络、活动配置与服务器选择，避免在测试过程中自动切换多个条件。测试材料应删除私人地址参数和认证信息。

建立最小可复现的规则组

先复制可恢复的配置，再为目标增加一条窄范围 DOMAIN 规则，放在可能覆盖它的规则之前。保存并确认选中后，使用 Config 姿态发起新连接。查看请求或连接记录中可用的目标、规则和策略信息；不同界面呈现可能有所区别，应以当前应用显示为准。若已命中预期策略，便停止继续改匹配条件，转去检查解析结果与路径可达性。

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

这个片段刻意把单个测试主机与其余连接分开，便于观察规则选择，不是通用配置建议。请使用自己明确掌握的实际测试目标替换示例主机。完成验证后，应将有效修改合回原配置，并恢复原有兜底意图；不要因为临时片段更短，就忽略原文件中其他必要规则、通用参数与本地服务例外。

按现象分层，不把所有失败归为规则错误

Connectivity Test 可以辅助判断相关连接条件，但测试结果不能直接替代目标应用的业务请求。某个测试有响应，并不保证目标域名解析正确，也不保证所有协议、端口与资源都可用。反过来，单项测试失败也需要结合测试方式解释。应把诊断工具当作缩小范围的线索，再用实际目标的新连接确认最终行为。

订阅更新与规则更新分别处理

已有订阅更新失败时，先核对地址完整性、当前网络和账户有效状态，而不是立即重写 Rule。服务器列表为空与分流命中错误属于不同层次的问题。单条分享链接和订阅地址的更新机制也不同，不应把其中一种当成另一种重复导入。入口辨认可查阅订阅导入四种入口；格式区别见分享链接与订阅地址说明。

如果远程配置更新后行为改变，先比较被改变的段落，再确认自己添加的例外是否仍然存在。不要同时更新订阅、替换配置并更换服务器，然后尝试从单次结果推断原因。订阅为空或解析失败的专项分支，见订阅更新失败与列表为空自查。本页只处理配置与匹配逻辑，不涉及服务来源推荐。

恢复、复测与长期维护

若修改后出现更大范围异常，先恢复已知可用的配置副本，并核对 Global Routing、服务器选择与通用设置是否一并恢复。恢复后重新建立连接，用同一组目标复测，确认基线仍然可用。不要在失败配置上不断叠加互相冲突的例外；每一条临时规则都应能说明用途，否则后续排错会越来越依赖偶然结果。

长期维护建议保留一份简短的变更记录：修改了哪个配置段、为什么修改、哪些目标验证通过、如何恢复。定期检查失效域名、重复规则、过宽关键词和不再使用的 Host 映射。购买恢复、兼容性及 App Store 搜索问题，可查阅已购恢复说明和商店搜索核对步骤；重新走操作主线则返回快速上手教程。