Shadowrocket 规则与配置参考

一、配置文件结构与编辑边界

先确定当前启用的是哪份配置，再修改字段。Shadowrocket 可以保存多份配置文件，文件存在于 Config 列表中，不等于连接正在使用它。进入 Config 核对当前选择项，记录文件名称及来源，然后打开对应文件检查内容。若页面上看到的规则与预期不一致，应先排除选错文件，而不是继续增加相似规则。对远程来源的文件，还要区分本地修改与重新更新后的内容。

段名决定字段的解释方式

配置文本按方括号段名分区。[General] 放置整体行为相关选项，[Rule] 放置按顺序判断的分流条件，[Host] 放置指定主机名的地址映射，[URL Rewrite] 放置 URL 改写条目。同一行文字放到不同段里，含义并不相同；把域名规则误贴在 General 下，不会因为文字看起来正确就自动成为规则。检查结构时应从段名往下读到下一个段名。

[General]
bypass-system = true

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

[Host]
example.com = 192.0.2.10

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

上面的文本仅展示四个段落如何衔接，并非建议整体启用。Host 中的地址属于文档示例地址，URL Rewrite 也只演示明确的 HTTP 地址跳转。配置中的换行用于分开条目，英文逗号用于分开规则字段，等号用于连接部分设置的名称和值。全角标点、复制时混入的不可见字符和错误的段名，均应在测试连接前先排除，避免将文本错误误认为网络故障。

本地副本与远程更新

开始编辑前保存一份可回退的副本。若使用远程配置，先弄清更新动作会替换哪些内容；直接在来源文件中加入个人规则，后续刷新可能重新写入来源内容。较稳妥的工作方式是保留来源文件作为参照，在明确的本地副本中做实验，并记录每次更改的目的。不要同时替换 General、重排 Rule、加入 Host，再用一次访问结果判断全部修改是否正确。

Subscribe 与配置文件也应分别理解。已有订阅通常用于维护服务器条目，配置文件则描述连接如何处理；两者可能在使用流程中相互关联，但更新一方不能证明另一方已经改变。发现服务器列表刷新了而规则未改变时，应回到 Config 查看实际文件，而不是反复刷新 Subscribe。反过来，修改域名策略也不会自动补齐服务器地址、端口或认证字段。

用小范围修改建立可验证的结果

每轮只调整一个明确目标，例如把一个测试域名改为 DIRECT，或把一条过宽的 REJECT 条件收窄。修改前先写下预计命中的规则、预计采用的策略，以及如何查看新连接。保存并确认配置后重新建立相关连接，观察结果是否符合预期。旧连接可能沿用原来的处理路径，因此不要仅凭刷新已经打开的页面，就认定新规则已经接管全部请求。

分享配置前应删除个人连接信息、订阅地址和身份凭据。规则示例可以保留测试域名，故障描述可以保留必要的字段名称，但完整配置往往包含比问题本身更多的信息。需要他人协助时，优先提供相关段落、规则相对顺序和脱敏后的连接记录。这样既便于复现，也能防止讨论被大量无关条目干扰，尤其适合定位某个域名被错误分流的情况。

二、General：全局选项与 DNS 前提

General 影响配置的整体行为，不承担逐个域名选择策略的职责。查阅这一段时，应先看字段名称，再看值的类型，最后确认它是否与正在排查的问题有关。例如，域名解析失败需要核对 DNS 路径；某个域名错误走 DIRECT，通常先检查 Rule 与当前 Global Routing。把所有问题都归因于 General，容易引入更多变量，也会掩盖原本清晰的规则顺序问题。

字段和值按类型填写

General 常见写法为字段名、等号和值。布尔选项使用 true 或 false，地址类选项则按该字段允许的格式填写。不要把中文解释直接写成值，也不要因为看到别人的配置包含某个选项，就默认该选项适合当前网络。遇到不确定的字段，应先在应用内配置编辑说明中确认含义和可用值；保留原值通常比凭名称猜测更容易得到可解释的结果。

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

bypass-system 用于控制系统相关流量的绕过行为，它不是“全部连接直接访问”的同义词，也不应替代 Global Routing 的 Direct。改变这一项时，要关注受影响的是系统流量路径，而不是假定所有业务请求都会产生相同变化。排查普通网页访问时，如果当前问题与系统服务无关，可以先保留现有设置，避免为了修复一个域名而扩大调整范围。

DNS 解析与规则判断不是同一步

dns-server = system 表示使用系统 DNS 路径；自定义解析地址则需要结合当前网络的可达性与配置说明核对。规则需要的是可供判断的请求信息：有些条件使用域名，有些条件使用目标 IP。DNS 负责域名到地址的解析过程，Rule 负责选择处理策略，两者会相互影响，却不能相互替代。增加 PROXY 规则，并不保证一个不可达的解析端点会随之恢复。

使用 DNS over HTTPS 时，还要区分解析请求的传输方式和最终网站连接的策略。解析请求经过 HTTPS，并不表示之后所有网站流量都采用同一策略；网站是否走 PROXY，仍要看当前模式和命中的规则。若解析端点本身需要先解析主机名，也应考虑其启动解析路径。不要一次填入很多不同来源的地址后，单凭某次成功访问就认定每个地址都在正常工作。

从可对照的基础设置开始

对 DNS 做调整前，先保留能恢复的原配置，选择一个稳定复现问题的测试域名，并记录当时的网络类型。在同一网络、同一服务器和同一规则下，仅改变解析设置，观察解析结果与连接记录是否变化。若同时切换蜂窝网络、服务器及 DNS，就无法判断是哪一项带来了差异。网络切换后也可能出现缓存结果，因此验证时应建立新的请求，不只观察旧标签页。

延迟测试有数值而网页打不开，只能说明某种测试请求得到响应，不能直接证明域名解析、目标连接与页面全部资源都正常。网页可能同时请求多个主机名，其中一个解析失败就足以影响显示。应先找出实际失败的域名，再看它是否获得地址、使用何种策略以及连接在哪一步中断。针对这一现象，可继续阅读DNS 解析失败的排查顺序。

如果应用内显示的字段与示例有所差异，以当前应用内说明为准，不要强行加入未知选项。General 不适合靠大量复制来“补齐”，精简且能解释的配置更便于维护。每个保留字段都应能回答三个问题：它改变什么行为、为何需要改变、如何撤销。更完整的解析选择讨论见系统 DNS、自定义 DNS 与 DNS over HTTPS，本页则以分流判断所需的前提为主。

三、域名规则与 USER-AGENT 条件

域名规则适合描述“某个主机名或一组相关主机名应采用哪种策略”。一条基础规则由类型、匹配值和策略组成，使用英文逗号分隔。匹配值通常填写主机名，不填写完整网页地址，因此不带协议头、端口或路径。若需求是让一个网站的某个页面走不同策略，首先要确认域名规则是否具有足够的信息；它不能单凭路径区分同一主机上的两个页面。

DOMAIN 与 DOMAIN-SUFFIX 的范围

DOMAIN 用于精确匹配主机名，适合单独处理一个明确目标。DOMAIN-SUFFIX 用于匹配指定域名及其子域名，适合将同一域名体系下的请求放在一起处理。后者不是任意字符串结尾匹配，判断中包含域名边界；不要把它理解成只要字符最后相同就会命中。选择类型前先列出希望覆盖的主机名，有助于发现规则范围是否过宽。

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

这组规则中，api.example.com 先命中 DOMAIN，采用 DIRECT；www.example.com 未命中第一行，再命中 DOMAIN-SUFFIX，采用 PROXY。若调换前两行，精确域名也会先被后缀规则覆盖。这不是精确类型失效，而是匹配在前一行已经结束。需要保留例外时，应将较窄条件放在较宽条件之前，而不是期待类型名称自动形成优先级。

DOMAIN-KEYWORD 的命中边界

DOMAIN-KEYWORD 检查域名中是否包含指定关键字，不限于一个组织或一个域名体系。关键字越短，意外覆盖的可能性越大。它适合确实需要字符串条件的场景，不适合用一个常见词替代一长串已经明确的精确域名。设置为 REJECT 时尤其要谨慎，因为被误匹配的正常请求也会直接被拦截，随后可能表现为图片缺失、登录失败或页面持续等待。

[Rule]
DOMAIN,downloads.example.com,PROXY
DOMAIN-KEYWORD,ads,REJECT
FINAL,PROXY

示例先为一个确定的主机名设置例外，再执行关键字拦截。downloads.example.com 的字符中也包含 ads，因此例外位置直接影响结果。实际排查不能只看“这是不是广告域名”的主观判断，应核对真正参与比较的主机名和规则文字。若命中范围超出预期，优先换成 DOMAIN 或 DOMAIN-SUFFIX，而不是不断堆叠例外补救过宽的条件。

USER-AGENT 的适用限制

USER-AGENT 按请求中可取得的 User-Agent 字段进行匹配，条件值可按支持的通配形式填写。它不是应用身份识别，也不能可靠地代表某个进程。请求可能没有该字段，多个应用也可能使用相近字段；对于加密且字段不可见的流量，更不能期待规则读取到它。因此需要长期稳定分流时，通常先考虑明确域名或目标地址，再评估这一条件是否适用。

[Rule]
USER-AGENT,ExampleClient*,DIRECT
DOMAIN-SUFFIX,example.com,PROXY
FINAL,PROXY

表中的 ExampleClient 只是示例字段前缀，不表示某个实际应用。验证 USER-AGENT 规则时，应先确认请求确实携带该字段且应用能够取得它，不应为了匹配一行规则就直接引入额外的流量解密设置。有关加密流量的可见性，应与普通域名分流分开评估。若无法确认字段内容，使用可观察的域名规则更容易建立明确的测试条件和回退方法。

四、IP-CIDR、IP-CIDR6 与 GEOIP

IP 类规则比较目标地址，而不是网站文字名称。一个域名可能解析到多个地址，同一个地址也可能承载多个域名，所以地址条件与域名条件并不等价。若需求是稳定指定某个网站的策略，应先判断域名规则是否更合适；若需求是处理明确的内网网段、单个目标地址或地址归属范围，再使用 IP 条件。选择依据应是实际要表达的边界，而不是哪种写法更短。

用前缀长度表达地址范围

IP-CIDR 用于 IPv4 地址范围，斜杠后的数字是网络前缀长度，不是端口，也不是可用地址数量。例如 192.168.0.0/16 表示一个私有地址范围，192.0.2.10/32 表示一个指定 IPv4 地址。填写时应使用明确的网络地址与前缀，避免把自己设备当前分配的地址直接当成整个网段。网段边界写错，规则可能覆盖远超预期的目标。

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

IP-CIDR6 对应 IPv6 地址范围。示例中的 2001:db8::/32 属于文档示例范围，不代表实际网络。若目标同时提供 IPv4 与 IPv6，仅配置 IPv4 条件并不能说明另一类连接也会受到相同处理。观察连接记录时应核对目标地址类型；同一网页出现不同结果，可能来自地址选择不同，而不一定是规则随机改变了执行顺序。

no-resolve 不等于关闭 DNS

no-resolve 是部分地址规则可附加的选项，用来避免为这条规则的判断主动触发域名解析。它不表示整个配置停止解析，也不表示目标永远没有地址。如果请求本身就是 IP，或判断时已经有可用地址，仍可按地址条件比较。对于内网地址规则，这个选项常用于减少为了判断网段而额外解析的情况，但是否添加仍应结合具体匹配目标决定。

缺少可用 IP 时，一条带 no-resolve 的规则不能凭域名文字判断目标属于哪个网段。反过来，不带这一选项的地址条件可能涉及解析，从而让 DNS 路径参与判断。若把很多地址规则放在域名规则之前，解析行为也可能变得更难解释。需要清楚的控制路径时，先用明确的域名条件处理已知目标，再让地址条件处理剩余连接，通常更便于检查。

GEOIP 是地址归属判断

GEOIP,CN,DIRECT 表示依据地址地理数据库，将归属标记为 CN 的目标交给 DIRECT。它不是按网页语言、域名后缀、公司注册地或用户所在位置判断。一个使用中文内容的网站可能连接到其他地区的地址，同一个域名也可能因解析结果变化而得到不同归属。解释 GEOIP 结果时，需要同时查看实际目标 IP，而不能只根据网站名称认定匹配错误。

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

这组规则优先处理 example.com 域名体系，再让 GEOIP 判断其余请求。若将 GEOIP 放到前面，某个已解析地址可能先被它命中，导致后面的域名规则没有执行机会。地址归属数据库也存在更新与识别边界，不能把归属判断当作精确的业务分类。对必须固定策略的少数关键域名，添加清晰的前置条件，比依赖其所有地址长期保持同一归属更可控。

排查局域网目标时，还要区分“规则选择 DIRECT”和“设备能够到达该目标”。DIRECT 只是选择直接连接，不能补齐局域网路由、修正目标端口或改变访问权限。若规则命中正确仍无法访问，应检查当前 Wi-Fi、目标设备状态以及地址是否已变化。先确认请求实际发向哪个地址，再检查网段规则，避免把地址过期或服务未监听误判为 IP-CIDR 语法问题。

五、PROXY、DIRECT、REJECT 与 Global Routing

规则的最后一个主要字段通常是处理策略。条件回答“哪些请求”，策略回答“命中后怎么处理”。PROXY、DIRECT、REJECT 是不同的处理结果，不是三个速度档位，也不代表连接质量等级。阅读一份配置时，可以先把策略单独列出来，确认每种结果是否符合用途，再检查各条条件是否把请求送到了正确位置。

策略名称对应实际处理动作

PROXY 将请求交给代理路径，仍依赖当前可用的服务器信息与相关选择。它不会从规则中的测试域名生成服务器，也不会修复订阅里已经失效的条目。DIRECT 使用直接连接目标的路径，但仍依赖本地网络、解析结果和目标服务状态。REJECT 则拦截匹配请求，适用于确认应阻止的目标；将它用于不够明确的范围，容易产生看似零散的页面故障。

如果配置支持并使用自定义策略名称，必须确认名称在当前配置中有实际定义，而且引用文字完全一致。不要把别人文件里的策略组名称直接粘贴到自己的规则末尾，随后期待它自动对应现有服务器。空格、大小写或名称变动也应逐项核对。对初次排查而言，先使用能解释清楚的基础策略建立对照，再引入更复杂的策略组织方式，更容易定位错误。

Global Routing 决定如何应用配置

Global Routing 的 Config、Proxy、Direct 分别对应配置、代理、直连三种使用姿态。需要按 Rule 逐条分流时，应确认使用 Config。Proxy 与 Direct 可用于整体路径对照，但不能把它们视为检查每条规则是否正确的方法；模式已经改变时，连接结果不能直接用来证明某行 Rule 生效。记录故障时，应同时写明模式与配置文件，二者缺一都可能使复现条件不完整。

用模式对照缩小范围

假设某个目标在 Proxy 下可访问，在 Config 下失败，不应立刻认定整个配置不可用。先回到 Config 查看该目标命中的规则：可能被 REJECT 拦截，也可能被交给不可达的 DIRECT 路径，还可能使用了不同的自定义策略。若目标在两种姿态下都失败，再进一步检查服务器、DNS 和目标服务。模式对照提供的是线索，不是某个字段一定有错的最终结论。

切换 Global Routing 后需要观察新连接。已经建立的会话可能继续传输，应用也可能复用原有连接，因此连续切换模式再快速刷新同一页面，结果未必干净。测试时保持其他条件不变，重新发起能够明确识别的请求，并以连接记录确认当前路径。若只看网页是否出现内容，还会受到缓存影响：显示旧页面并不能证明刚才的网络请求成功。

客户端购买与连接服务应始终分开理解。Shadowrocket 是 Apple 平台付费客户端，客户端一次性买断 ≠ 线路套餐；用户仍需使用已有的订阅或服务器信息。应用获取、正版图标与开发者核对见App Store 正版下载说明，设备兼容性和系统要求以 App Store 页面标注为准。配置字段的作用是管理已有连接行为，不是提供额外的连接资源。

六、匹配顺序、例外规则与 FINAL

Rule 的核心原则是从上到下逐条比较，命中后采用对应策略，不再继续向下寻找更符合直觉的条件。规则类型本身没有“精确域名永远胜过网段”这样的自动优先关系。所谓优先级，首先体现为文件里的位置。判断一条规则为何没有生效，应从它上面的条目开始查，而不是只反复核对它自己的语法。

先处理例外，再处理范围

建议按需求组织条件：明确例外在前，较宽的域名或地址范围在后，最后放兜底规则。这是一种便于维护的编排方式，不是强制要求所有文件必须采用同一分类顺序。真正决定结果的仍是每个目标第一次命中的位置。例如，某个局域网服务需要单独处理，就要确认前面的宽泛域名条件或地址条件不会先接管它，不能仅因为它属于内网便假定自动优先。

[Rule]
DOMAIN,api.example.com,DIRECT
DOMAIN,ads.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 在第一条命中，不再进入后缀判断；ads.example.com 在第二条被拦截；其他 example.com 子域名采用 PROXY。之后才处理尚未命中的地址范围与 GEOIP。读规则时可以选三个具体目标，分别从第一行手动向下推演，将第一次成立的条件画出来。这个过程能直接暴露例外放错位置、条件重叠及兜底放得过早的问题。

FINAL 是无条件兜底

FINAL 用于处理前面所有条件都未命中的连接，常见写法是 FINAL,PROXY 或 FINAL,DIRECT。它没有域名或地址匹配值，因此字段数量与普通域名规则不同。应把它放在 Rule 段的最后一条有效规则位置。若在它后面继续追加 DOMAIN 条目，这些条目不会因为更具体而重新得到判断机会，反而会造成“明明写了却始终不生效”的误解。

选择 FINAL 的策略之前，要明确默认路径。FINAL,PROXY 表示未单独分类的连接走代理路径，FINAL,DIRECT 则让它们直接连接。两种选择都不能脱离现有规则来评价；同一组前置条件搭配不同兜底，会形成不同的覆盖范围。修改兜底通常影响面很大，应该先核对几个关键目标的实际命中位置，避免为了修复一个站点而改变全部未分类流量的路径。

重复规则与远程内容的整理

重复条目不一定导致语法错误，但会增加阅读成本。两条条件完全相同却使用不同策略时，后面的条目通常被前面遮住；条件相似但范围不同，则要逐个目标判断。整理时不要只按字母排序，因为排序可能破坏原本有意保留的例外顺序。可以先标注每组规则的目的，再删除确定冗余的条目，并在每次整理后重新验证关键域名。

合并来自不同来源的片段时，最常见的问题是重复段名、重复 FINAL，以及将整段内容直接插在已有兜底之后。正确做法是先识别片段属于哪个段，移除不需要重复的段头，再把规则放到预期位置。对含有自定义策略引用的片段，还要先确认依赖是否存在。片段能被复制进文本，并不代表它与当前配置的结构、策略和默认路径兼容。

维护较长列表时，变更记录应说明“为什么在这里”，而不仅是“增加了什么”。例如某个精确域名被放在后缀规则前，是为了保留直接连接的例外；某条关键字规则被撤下，是因为覆盖了正常资源。后续排错时，这些背景比数量更有帮助。若出现预期之外的命中，先缩小到相关的几条规则做验证，确认后再合回完整文件，不要靠持续追加相反规则来碰运气。

七、Host 与 URL Rewrite 的作用边界

Host、URL Rewrite 与 Rule 分别处理地址映射、请求地址改写和策略选择，不应混为一类。配置包含这几个段，不代表每次排错都需要同时调整它们。若目标只是让某个域名走 PROXY，优先使用 Rule；若目标是为明确主机名指定地址，再考虑 Host；只有需要改变符合条件的 URL 时，才检查 URL Rewrite。把功能边界分清，可以减少看似有效却难以解释的修补。

Host 指定主机名的地址映射

Host 中的基础写法是主机名、等号和目标地址，不填写完整网页 URL。它改变的是该主机名所对应的地址信息，不直接指定 PROXY 或 DIRECT。即使 Host 为域名提供了一个地址，连接仍需按当前模式及相关规则处理。不要在 Host 行末随意追加策略字段，期待它同时承担域名分流；应将地址映射与策略条件分别写在各自对应的段内。

[Host]
service.example.com = 192.0.2.10

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

示例地址仅用于文档说明，不能用于实际访问。设置真实映射前，应确认地址由目标服务的可靠配置提供，并知道何时需要撤销。网站可能使用动态地址、多个服务入口或不同地址承载不同内容；长期固定一个曾经可用的地址，可能在服务调整后失效。临时用 Host 做诊断时，应该记录原始状态，测试完成便恢复，避免把诊断条件悄悄变成长期依赖。

Host 也不能把任意服务器变成目标网站。HTTPS 连接仍会涉及主机名、证书和服务端处理逻辑，地址能建立连接不表示证书与内容就一定匹配。若更改映射后出现证书错误，不应直接降低校验要求来维持访问，而应核对域名与地址是否确实属于同一服务。对原本使用多个地址的目标，还要注意固定映射可能改变可用性与连接选择行为。

URL Rewrite 按明确条件改写地址

URL Rewrite 的条目通常包含匹配表达式、替换目标和处理方式。下面演示将一个明确主机名的 HTTP 地址跳转到 HTTPS，使用 302 表示临时重定向。正则中的点号需要转义，否则它会代表任意字符；开头的锚点用于限定从地址起始处匹配。示例只展示基础结构，启用前必须先在受控目标上检查匹配范围和实际响应，不应直接扩展到所有域名。

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

改写规则不能保证目标提供 HTTPS 服务，也不能保证登录、路径或请求方法在跳转后保持原有业务语义。若需要保留路径，应先理解捕获组与替换引用的关系，并通过多个地址验证，而不是只测试网站首页。规则还应避免将改写后的目标再次送入另一条反向规则，否则可能形成循环跳转。看到浏览器提示跳转过多时，首先检查条件与目标之间是否相互覆盖。

可见性与额外设置分开评估

对加密请求，能否执行某种 URL 级处理，取决于应用能取得哪些请求信息以及相关功能是否已满足前提。不要把域名分流能工作，理解成所有 URL 路径都可被读取；也不要为一条示例改写顺带开启不理解的流量解密配置。证书与加密处理涉及额外信任边界，应在确有需求并理解影响时单独配置，本页不将它作为普通规则分流的前置步骤。

若 Host、URL Rewrite 与 Rule 同时存在，排错时一次只停用其中一类变化。先恢复原始地址映射并建立新请求，观察目标 IP；再检查 URL 是否发生预期改写，最后核对策略命中。这样能够区分“访问了错误地址”“跳到了错误位置”和“选择了错误路径”。不要把三类问题都用新增 DOMAIN-SUFFIX 解决，因为策略选择正确也无法抵消错误映射或循环跳转。

八、配置验证、故障定位与回退

验证配置的目标不是让测试页面偶尔打开，而是确认结果可重复、原因可解释、修改可撤销。开始前记录当前网络、Global Routing、配置文件与所用服务器，选择一个能稳定复现问题的目标。随后检查配置是否保存并处于使用状态，再发起新连接。若这一步没有确认，后续看到的结果可能来自旧文件、旧会话或页面缓存，无法用于判断刚修改的规则。

按连接链条拆分问题

一次访问可以拆成域名解析、条件判断、策略选择、目标连接和内容返回几个检查点。先确定失败发生在哪一段：没有解析结果时检查 DNS；命中错误规则时检查顺序；PROXY 连接失败时检查已有服务器信息与可达性；目标响应异常时再检查网站服务。顺序不是为了固定所有网络实现的内部流程，而是为了在操作上一次排除一个变量，避免同时修改不相关字段。

1. 确认 Config 当前选择与 Global Routing，排除文件和模式不一致。
2. 核对真实请求的主机名、目标 IP 与地址类型，不只看地址栏。
3. 查看命中的规则及策略，按文件顺序手动复核。
4. 保持其他条件不变，只调整一个字段，再建立新连接。
5. 复测关键业务，确认恢复后保存变更理由及回退副本。

网页往往包含主页面、图片、接口和认证等多个请求。首页能显示而登录失败，可能是某个关联域名被 REJECT 或走了另一条路径，不能仅根据地址栏中的主机名判断全部流量。检查时应找出实际失败的请求，再核对其条件。若一个关键字规则命中了多个资源，先收窄该规则做对照，通常比把整个网站及所有子域名都改成同一策略更容易发现根因。

根据现象选择下一步

Connectivity Test 可以帮助比较服务器响应，但其测量对象和方式与真实业务请求并不完全相同。一个数值正常，不能证明所有目标、所有协议与所有资源都成功；某种测试没有响应，也不应脱离具体服务状态判断全部连接失效。应将测试结果作为线索，与实际连接记录相互印证。需要检查已有服务器字段时，回到导入来源逐项核对，不用更换规则来掩盖地址或认证错误。

建立最小复现，再合回完整配置

当完整文件很长时，复制成专用测试文件，仅保留理解当前问题所需的 General 设置、一个明确目标条件和 FINAL。先验证基础路径，再逐组加入原来的规则，直到问题重新出现。每次加入都保留原有相对顺序，并记录新增范围。这样可以定位发生遮挡的具体条目，而不是在数百行中反复猜测。测试完成后回到正式文件合并已验证的改动，并确认没有误选测试文件长期使用。

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

这份片段仅用于理解“指定目标与其余连接分开”的验证方式，并不包含建立连接所需的全部信息。复现说明应包含预计策略、实际策略和对应规则位置，同时隐藏订阅地址、认证信息及个人标识。若配置更新后问题再次出现，比较更新前后的相关段落，确认是来源内容覆盖了修改，还是实际服务器、DNS 或目标地址发生变化，不要直接把所有更新都归为同一种原因。

回退后应重新确认原来的关键目标能够访问，再结束排查。保留一份简短记录：问题现象、最先命中的条件、最终修改和恢复方法。一般疑问可继续查看疑难解答；首次连接流程见使用教程；购买、恢复与商店核对见正版核对说明。规则维护的完成标准，是下一次遇到同类问题时能够按同样步骤验证，而不是依靠记忆再次试改。