官方手册 · 配置大全

Shadowrocket
规则与配置参考大全

先确认配置是否生效，再检查规则为什么命中。本页按文件结构、匹配条件与验证流程组织，适合查阅具体字段和定位分流结果。

首次导入用户已有订阅、选择服务器并建立连接，请先阅读快速上手教程；完成基础操作后，可回到本页理解 Config 和规则文件。教程负责连贯操作，本页负责解释配置之间的关系、边界条件与修改后的核对方法。

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

一份配置首先要能被正确读取，其次才是规则是否符合预期。Shadowrocket 的配置文件通常以分段方式组织：方括号中的名称标识段落，段落下面的内容按该段语法解释。相同的一行文字放在不同段落中，意义可能完全不同。查阅或复制示例时，应同时确认段名、行内容与目标策略，不能只截取中间几个关键字。

General、Rule、Host 的职责

[General] 保存通用设置，例如解析与绕过相关选项；[Rule] 保存决定连接去向的规则；[Host] 保存指定主机名的静态解析映射。它们分别回答“连接按什么基础条件处理”“这个目标走哪种策略”“这个名称对应哪个地址”。分工不同，也意味着调整其中一段不一定会改变另一段的结果。

段落主要用途核对重点
[General]通用连接与解析设置选项拼写、取值与当前网络条件
[Rule]按条件选择策略规则顺序、匹配字段与策略名称
[Host]指定名称到地址的映射域名与地址是否仍对应同一服务
[URL Rewrite]匹配并处理可见的 URL正则范围、目标地址和处理方式

从最小文件理解语法

下面的片段用于说明结构，不是适合所有网络的完整配置。示例域名与文档地址不代表可用服务。实际使用时，应保留当前配置中仍然需要的设置，并确认已有服务器可用。PROXY 是策略，不会因为写入文件而自动产生服务器；同样，写入一条域名规则，也不会自动修正该域名本身的解析或服务状态。

[General]
dns-server = system

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

[Host]
test.example.com = 192.0.2.10

分段标题使用英文方括号，规则字段用英文逗号分隔，普通选项使用等号连接名称与取值。输入法生成的全角逗号、弯引号和不可见空格，都可能使看似相同的文本无法按预期解析。复制后应在编辑器中逐行核对，尤其注意行尾是否粘入说明文字。解释性中文应写在正文或独立注释行，不要直接接到策略字段后面。

文件存在不等于当前使用

进入 Config 后，应先确认当前选用的是哪一份配置，再进入编辑。保存一个未被选中的文件，不会让正在运行的配置自动变成它。类似地，更新用户已有订阅通常改变的是服务器列表，不能据此认定规则文件也已更新。服务器来源、配置来源与当前选择状态应分别核对，避免在不同对象之间反复修改。

开始前保留一份本地副本，并记录原来使用的文件名称。若当前配置来自可更新的地址，还应区分远程原文与本地修改：后续重新获取内容时，本地改动可能需要重新核对。不要把“已保存”理解为“已验证”；保存只是文本写入完成，是否生效还要结合 Global Routing、连接状态和实际命中的规则判断。

读取报错时，先检查最近修改的段落，再检查是否重复粘贴了段名或把规则写进了错误区域。能够打开文件但连接结果不对，则转向模式、策略和匹配顺序检查。把语法问题与运行结果问题分开处理，可以避免为了修复一个逗号错误而同时改动解析、服务器和整套规则，最后无法确定真正原因。

02 Global Routing与策略选择

规则检查之前，先看 Global Routing。配置模式 Config 按当前配置决定连接去向；代理模式 Proxy 将通常由该模式处理的连接交给代理路径；直连模式 Direct 使用直连路径。本文讨论的域名、地址与最终兜底规则，主要应在 Config 下验证。模式改变后，同一条规则不再产生原先效果，并不必然说明文件出错。

三种姿态用于不同检查

姿态界面词检查用途
配置Config验证当前配置中的规则分流
代理Proxy辅助判断代理路径与服务器连通性
直连Direct辅助判断当前网络的直连表现

排查时可以临时比较不同姿态，但要把比较条件保持一致：同一网络、同一目标、同一服务器，并尽量发起新连接。如果 Proxy 下目标可访问，而 Config 下失败，优先检查配置把目标送到了哪里；如果两者都失败，则还需要检查服务器信息、解析与远端服务。一次切换不能直接证明所有规则都正确。

PROXY、DIRECT、REJECT 的区别

PROXY 表示使用代理策略，具体可用路径还取决于当前服务器选择及相关策略设置；DIRECT 表示直接连接目标；REJECT 表示拒绝符合条件的连接。这些是规则中的策略关键字，与界面上的模式名称不是同一层级。尤其不要把整页的 Proxy 模式和某条规则末尾的 PROXY 当作完全相同的配置动作。

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

第一行只表达目标域名应该进入代理路径，并没有定义服务器地址、认证方式或传输参数。若已有服务器信息不完整，即使日志显示命中 PROXY，连接仍可能失败。反过来，命中 DIRECT 也只是选择直连，不意味着当前网络一定能到达目标。规则选择与路径可达性需要分别验证，不能由其中一个结果替代另一个。

REJECT 应只用于范围明确、确实希望阻止的目标。过宽的拒绝规则可能影响登录、图片、推送或应用初始化，因为同一个应用常常访问多个域名。测试拒绝策略时，先使用完整域名，记录受影响的具体请求，再决定是否扩大范围。不要因为某个请求名称看起来像统计或广告，就假定拒绝后不会影响其他功能。

策略名称也需要核对

某些配置会引用自定义策略名称。遇到这种写法，应查找配置中相应定义，确认名称存在、拼写一致并且当前仍能选择有效路径。不要随意把现成策略组改成服务器备注，也不要只复制引用它的一行规则。对于初次整理的文件，先使用可明确解释的内置策略完成最小验证，再研究自定义策略之间的关系，更容易分离问题。

应用连接开关与路由姿态也要分开看。开关关闭时，修改文件并不会让流量经过当前规则；开关开启时，系统显示连接状态，也不能代替网页或应用请求的验证。首次配置的操作顺序可参考教程主线，本页则继续解释具体规则为什么命中。修改后返回原来的姿态，能够避免临时排查设置变成长期使用状态。

03 DOMAIN系列域名规则

已知目标域名时，优先从域名规则开始。域名规则描述的是主机名，不是浏览器地址栏里的完整网址。填写 api.example.com 时，不要附带协议前缀、路径、查询参数或页面标题。一个网址中，主机名之后的斜杠及其后内容属于另一层信息，不能直接作为 DOMAIN 的匹配字段使用。

精确匹配与后缀匹配

DOMAIN 用于完整域名匹配。写入 example.com，不等于同时写入了 www.example.com。DOMAIN-SUFFIX 则适合覆盖一个域及其子域：以 example.com 为条件时，可用于该域本身及属于它的子域范围。两者区别决定了规则是否只影响一个入口，还是影响同一域下的一组服务。

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

选择后缀规则之前，应确认域名边界。它不是任意字符串结尾比较，也不应被理解为包含相似文字就命中。一个外观近似的名称，不一定属于相同域。排查时把日志中的完整主机名与规则字段逐字对照，尤其注意多出的子域、不同的顶级域和应用跳转后使用的另一个服务域名。

DOMAIN-KEYWORD 的范围更宽

DOMAIN-KEYWORD 按域名中的关键字匹配，适用于确实需要字符串范围的情况。它不理解品牌、服务归属或业务用途，因此相同文字可能同时出现在互不相关的域名里。关键字越短，意外覆盖越难预测。对于能够列出完整域名的场景，精确规则通常比宽泛关键字更容易解释，也更方便日后检查。

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

此例把明确的例外放在广泛规则之前。访问 ads.example.com 时，先命中精确拒绝；访问同域其他主机时，再由后缀规则选择代理。关键字规则放在后面，不会重新处理已经命中的连接。示例只是展示顺序，不能直接作为通用拦截清单；实际拒绝范围应由用户自己的目标和日志记录决定。

一个网页往往不止一个域名

页面主文档、图片、脚本、登录接口与媒体内容可能来自不同主机。只给地址栏中的域名设置策略，不能保证所有资源都走同一路径。遇到“首页打开但图片不显示”时，应查看失败资源实际访问的主机名，而不是立即把整类后缀改成相同策略。范围逐步扩大，有助于避免影响原本正常的其他服务。

域名规则还依赖连接处理时能获得相应名称。若应用直接连接数字地址，或名称与地址的关联在当时不可用，不能仅凭用户知道该地址属于某网站，就认定域名规则一定能够命中。此时应检查连接记录实际显示的目标类型，再决定是否需要补充地址规则。不要为了补救单个请求，直接把所有未识别连接一律改成直连。

修改域名条件后，应重新发起请求。浏览器和应用可能复用已有连接，使新规则暂时没有机会处理相同会话。可以关闭相关页面后再打开，必要时重新建立连接，再查看新产生的记录。判断依据是新请求的目标与匹配结果，而不是页面是否仍保留之前加载的内容；缓存页面无法证明网络请求使用了哪一条规则。

维护时给每组规则保留简短用途说明，例如记录“完整域名例外”或“整个业务域”。当某个域名失效，先核对服务是否换用了其他主机，再考虑删除规则。长期积累的规则若缺少用途记录，很容易出现相同域名被重复写入不同策略的情况；这种冲突最终由顺序决定，不会自动合并为更合理的结果。

04 IP-CIDR、IPv6 与 GEOIP

地址规则针对目标 IP，而不是域名文字。IP-CIDR 用于 IPv4 网段，IP-CIDR6 用于 IPv6 网段，GEOIP 则根据地址数据库的地区归属进行判断。三者都与目标地址有关，但信息来源和覆盖方式不同。选用前应先确定自己需要的是明确网段，还是基于地区归属的一类地址。

CIDR 前缀表示地址范围

CIDR 写法由地址和斜杠后的前缀长度组成。对于 IPv4，前缀越长，范围越小；单个地址可使用三十二位前缀。IPv6 的地址长度不同，不能照搬 IPv4 的前缀含义。手工填写时，应从用户已有网络信息中确认范围，不要只凭地址前几个字符相同，就判断它们应该放在同一条网段规则里。

[Rule]
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR,198.51.100.8/32,PROXY,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

上面的地址属于文档示例范围，只用于展示语法，不代表可连接的实际服务器。第二行展示单个 IPv4 地址，第三行展示 IPv6 前缀。实际配置中，地址范围必须与需要处理的目标一致；把示例原样复制进去，并不会解决任何现实服务的分流问题，也不应该据此判断服务器是否可用。

no-resolve 控制匹配时的解析行为

当连接目标仍以域名形式表示时，检查地址规则可能涉及解析。规则末尾的 no-resolve 用于避免仅为这条地址规则主动触发域名解析；若处理时已有目标地址，仍可根据地址判断。它不是关闭所有 DNS，也不是强制连接不使用域名。将这个选项理解为整套解析开关，会导致对结果的错误预期。

是否添加该选项，要看规则目的。若只希望处理本来就以地址发起的连接，或者不希望地址规则为域名目标增加解析步骤，可以考虑使用。若期待某个域名先解析再落入指定网段，则必须核对实际匹配路径，不能一边限制为规则主动解析，一边又要求它总能根据尚未取得的地址命中。配置结果要以连接记录核对。

GEOIP 不等于服务所属地区

GEOIP,CN,DIRECT 判断的是目标地址在数据库中的地区归属，不依据页面使用何种文字、域名后缀、公司注册地或用户所在地进行判断。使用内容分发网络的服务可能在不同时间解析到不同地址，数据库归属也可能与业务认知不一致。因此，地区规则适合作为较宽的分类条件，不能替代对重要业务域名的明确规定。

规则匹配对象常见边界
IP-CIDRIPv4 地址范围域名解析结果变化后可能不再落入范围
IP-CIDR6IPv6 地址范围只补 IPv4 规则不能覆盖 IPv6 连接
GEOIP地址数据库归属不表达域名或服务的业务归属

同一个域名可能同时返回 IPv4 与 IPv6 结果。若只为其中一种地址编写规则，另一种连接可能继续落到后面的地区规则或 FINAL。排查“相同网址有时直连、有时代理”时，应同时看地址族、实际目的地址与新连接时间，不要只比较网址文字。网络是否具备可用的 IPv6 路径，也要单独验证。

推荐把明确域名例外放在较宽的地址或地区分类之前，并保留最终兜底。若某个业务必须使用固定策略，直接描述其域名通常比猜测它会解析到哪个地区更稳定。确实需要地址范围时，保留来源和用途记录，避免服务调整地址后，旧规则继续影响已被分配给其他用途的连接。

05 匹配顺序、USER-AGENT 与 FINAL

在常规的 [Rule] 列表中，规则按配置顺序检查，连接命中后采用对应策略。不能把这个过程理解为“自动挑选写得最具体的一条”。具体条件只有排在适当位置才有机会命中；如果前面的宽泛条件已经覆盖目标，后面的精确条件不会再替它改写结果。整理配置时，顺序与条件本身同样重要。

先写例外，再写较宽范围

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

这个示例中，登录域名先采用直连；同一域的其他主机由后缀规则进入代理；关键字规则只会处理前面尚未覆盖、且域名包含相应文字的目标。若把后缀规则移到第一行，登录域名也会先命中代理。文件并不会因为登录域名那一行更长或更精确，就自动给予它更高优先级。

重复规则的处理也应按顺序理解。同一域名先写 DIRECT、后写 PROXY，不是同时保留两条可选路径，而是前面符合条件的规则先产生结果。检查冲突时，不只搜索完全相同的行，还要搜索能够包含该域名的后缀、关键字及其他更宽条件。看似不同的文字，可能对同一个请求形成覆盖关系。

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

USER-AGENT 针对请求中的 User-Agent 信息设置条件。它不是应用名称检测，也不能仅凭规则里出现某个应用名称，就保证识别该应用的所有连接。只有处理时能够取得对应请求信息，相关规则才有判断依据。对于加密连接，不能假设所有请求头都天然可见；不要把这类规则作为覆盖所有连接的唯一条件。

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

例子中的客户端标识只是演示匹配形式，不指向实际应用。使用时要从能够核对的请求信息中确认真实字段，并检查实际匹配情况。相同应用的不同组件可能使用不同标识，系统服务也可能代为发起请求。若目标可以用域名明确描述，通常应保留域名条件作为可解释的依据，而不是依赖猜测得到的请求头文字。

FINAL 只负责最后的兜底

FINAL 用于前面规则都没有命中时选择策略，通常放在列表末尾。它不是提高优先级的标记，也不是修复规则错误的开关。若将其提前放入规则列表，后续规则就可能失去匹配机会。决定使用 FINAL,PROXY 还是 FINAL,DIRECT，应根据未分类连接的期望路径，而不是照抄另一份文件的习惯。

以代理兜底时，未明确分类的请求会依赖已有代理路径；以直连兜底时，尚未覆盖的业务可能直接尝试当前网络。两种选择都需要实际验证。最重要的是能够解释结果：某个目标命中最终规则，往往说明前面的条件没有覆盖它，而不是最终规则“抢走”了本来应该命中的连接。应检查目标名称、地址和规则范围。

合并配置时，先确定保留哪一条最终规则，再把具体条件放在它前面。直接把两个完整文件首尾相接，常常会留下多个段落、重复规则和提前出现的兜底。推荐以一份可用文件为基础，按用途逐组搬入规则，每搬一组就检查目标的命中变化。这样发生异常时，可以定位到最近加入的范围，而不必从几百行内容重新猜测。

06 General、DNS与 Host 映射

解析与分流相关，但不是同一个过程。DNS 将名称转换为地址，规则决定符合条件的连接采用哪种策略。一个域名可以已经命中代理规则，却仍因解析失败而无法访问；也可以解析正常，但选中的路径无法到达返回地址。因此，“延迟有数值”不能直接证明目标网页的名称解析、传输和应用响应都已完成。

先保留能解释的基础设置

[General] 中的选项应结合当前配置和应用内说明理解。对于解析排查，先记录原来的 DNS 设置，再一次只调整一个因素。示例中的 dns-server = system 表达使用系统解析来源的配置方式，不是适合每个网络的固定答案。当前网络、解析服务可达性和配置中的其他选项，都可能改变最终表现。

[General]
dns-server = system

[Host]
test.example.com = 192.0.2.10

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

静态映射与策略在这个例子中分别书写。[Host] 指定测试域名的地址，[Rule] 指定该域名采用直连。改变地址映射并不等于改变策略，改变策略也不等于地址一定正确。示例地址仅用于文档，不应拿来验证实际网页。实际服务的映射必须来自用户能够核对的网络信息。

Host 映射不能代替服务配置

静态映射适用于确实需要固定名称与地址关系的场景，例如用户自己的测试环境。它会绕过该名称原本的动态解析结果，因此也可能保留已经失效的旧地址。使用内容分发、地址轮换或按地区返回不同结果的服务时，手工固定地址可能破坏原有选择。不要把偶然一次成功的地址长期保留为通用修复。

即使地址可以连接，HTTPS 还需要名称与证书等条件匹配。把某域名映射到另一台服务器，不会自动让那台服务器拥有该域名的证书或站点内容。若出现证书提示、响应了错误站点或连接被拒绝，应恢复原来的映射并核对服务端信息，而不是继续扩大规则范围。域名、地址和服务身份是三个需要同时一致的对象。

解析失败的检查顺序

先确认失败发生在解析阶段，还是已经取得地址之后。连接记录若显示名称解析失败，优先检查 DNS 配置及其可达性；若已经显示目的地址，再检查策略、服务器和目标响应。不要只依据浏览器中的一句错误提示做判断，因为不同底层原因可能显示成相似页面。保留一次完整失败请求的时间和目标，有助于对应日志。

其次检查是否存在遗留的 [Host] 映射。对同一个域名，静态映射可能使修改 DNS 服务器后的测试看不出变化。确认配置中没有固定旧地址，再比较系统解析与当前配置解析的结果。比较时还要考虑缓存，避免把旧记录当成新配置的输出；应重新建立相关请求，必要时重新连接后再观察。

还要区分解析请求的路径与业务连接的路径。业务规则写了 PROXY，不能据此认定所有解析流量必然使用相同服务器；应检查当前解析相关设置的实际含义。调整 DNS 时，不要同时更换服务器、修改最终策略并添加 Host 映射，否则即使网页恢复，也无法知道是哪一项真正改变了结果。

涉及内网名称时，还应确认该名称是否只有当前局域网的解析环境才能回答。离开原来的网络后，名字无法解析可能是环境变化，而不是规则文件损坏。反过来，在外部网络保留只适用于某个局域网的固定地址，也可能使连接持续失败。网络条件改变后，应先复核这些带有环境依赖的设置。

更详细的故障顺序可阅读延迟正常但网页打不开的 DNS 排查说明。本页的原则是先确定失败阶段，再修改与该阶段直接相关的选项；解析完成后再讨论路由，路由正确后再讨论目标服务，避免把所有问题都归结为“换一个 DNS”。

07 URL Rewrite的范围与边界

[URL Rewrite] 用于根据 URL 条件进行处理，与 [Rule] 的连接策略分流不同。前者关注可取得的网址信息以及相应处理动作，后者关注连接走哪条路径。需要让某域名使用代理，应先考虑域名规则；需要让一个明确的旧页面地址跳转到新地址，才进入重写条件与动作的讨论。

先写出完整目标，再收窄正则

重写规则通常包含匹配表达式、目标及处理方式。下面的例子演示将一个精确的旧地址以临时重定向形式指向新地址。它只用于解释语法与匹配边界，不要求用户实际访问示例域名。实际编辑时，应在当前应用中确认该行被正确接受，并用新发起的请求核对结果，而不是只看文件能否保存。

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

表达式开头的 ^ 约束起始位置，结尾的 $ 约束结束位置，域名中的点写成 \. 表示字面上的点。如果不转义，点在正则中通常可以表示任意单个字符，从而把本来不想匹配的地址也包含进来。先理解每个符号再修改，比从长表达式中删改几个字符更容易保持范围可控。

此例不覆盖子域、额外路径或查询参数。地址末尾增加问号参数后，精确结束条件就可能不再符合预期。如果确实需要处理参数，应先明确参数应保留、丢弃还是重新组织，再按目标设计表达式。不要直接加入一个覆盖全部内容的宽泛片段，因为它也可能把登录回调、资源路径或后续页面一并包含。

重定向与连接策略分别验证

重定向会让请求继续访问新的目标。新目标仍然需要解析，也需要按适用的路由条件建立连接。旧地址所在域名走直连，并不意味着跳转后的另一个域名也使用直连。排查时至少记录初始地址和最终地址；若只查看第一条请求，很容易误以为策略没有生效，实际失败的却是后续目标。

不要通过 URL Rewrite 修复服务器认证错误、协议字段缺失或 DNS 服务不可达。这些问题发生在不同层级，改变网址文字不能补齐底层参数。若问题表现为连接建立之前就超时，应先回到服务器、解析和策略检查。只有确认请求进入了可处理的阶段，才有必要继续核对正则与重定向行为。

HTTPS 信息可见性需要单独理解

HTTPS 的完整路径和请求头位于加密连接中，不能假设只要加入重写行就能读取并改写所有内容。是否能够应用具体规则，取决于协议、应用行为以及相关配置条件。涉及证书信任的设置会改变安全边界，不应当成让规则生效的默认步骤；普通域名分流也不以读取加密内容为前提。

遇到重写未生效，先排除表达式没有覆盖实际地址、请求复用旧连接或结果来自缓存等原因。不要立即扩大处理范围，更不要把全部域名加入需要额外处理的集合。对于自己无法核对用途的证书或配置，应先停止修改，保留原有可用状态，再逐项确认来源与必要性。规则越宽，验证成本和影响范围也越大。

还应防止重定向循环：新地址如果再次符合原来的匹配条件，就可能不断触发相同动作。测试时检查地址是否反复变化、页面是否提示跳转次数过多，以及日志是否出现重复目标。修复办法是让旧地址条件足够明确，并确保目标不再落入同一个条件，而不是通过更换代理服务器掩盖循环。

维护配置时，把连接规则和 URL 处理分别成组记录。删除或停用重写后，如果基础访问恢复，就应在这一段继续缩小问题，而不是立刻改动整套分流。对于仅需要按域名选择路径的用户，保持重写段为空或不加入该段即可；配置的完整性取决于是否满足实际需求，不取决于是否把所有可用功能都写进文件。

08 配置修改、验证与故障定位

修改配置应形成可以回退的闭环：保留原文件，确定一个明确目标，只改一组相关条件，重新发起请求，再核对实际命中和连接结果。一次验证最好只回答一个问题，例如“这个完整域名是否进入代理”，而不是同时判断解析、协议、所有页面资源和整套规则是否正确。问题越具体，结果越容易解释。

建立最小的核对记录

开始前记录当前选中的配置、Global Routing 姿态、已有服务器选择、网络环境和要测试的目标。记录不需要包含订阅地址或认证内容。若向他人描述故障，应先隐藏密码、完整订阅链接及其他识别信息；本地日志里出现的查询参数也可能含有敏感内容，不能仅遮住服务器名称就认为已经处理完毕。

  1. 在 Config 中确认当前文件并保留副本，明确准备修改的段落。
  2. 检查英文标点、段落位置、策略拼写和最终规则位置，保存后确认文件可被读取。
  3. 切回用于验证的 Config 姿态，并确认连接开关处于预期状态。
  4. 重新打开目标页面或发起新请求，对照连接记录中的目标、命中规则与策略。
  5. 若结果不符，恢复最近一组修改，再沿失败阶段检查，而不是继续叠加例外。

根据现象缩小检查范围

观察结果优先检查下一步
配置读取失败段名、英文标点与字段数量恢复最近修改，逐行重新加入
总是命中 FINAL目标类型与前面的条件范围核对实际域名、地址及可用请求信息
命中预期策略但超时解析、服务器与目标可达性分开验证所选路径，不继续堆规则
部分资源失败子资源域名与重定向目标针对失败请求检查，不扩大整个列表
更换网络后异常局域网映射、解析条件与地址族复核环境依赖设置，再比较同一目标

若所有请求都落到 FINAL，先检查当前是否真的使用了刚编辑的文件，再看域名字段是否误带完整网址，以及前面的条件是否依赖无法取得的信息。若只有一个目标不符合预期，搜索所有覆盖它的条件，尤其是更早出现的后缀和关键字。最终规则只是显露出前面没有命中的事实，不应成为第一个被反复改动的对象。

若命中策略正确但仍失败，暂停增加规则。确认用户已有服务器信息与对应协议一致，包括地址、端口、认证及传输相关字段。不同协议的相似字段不一定能互相替代；修改规则无法修复认证失败。需要辨认字段时，可阅读VMess 与 VLESS 字段说明，并以用户已有服务信息逐项核对。

订阅、配置与服务器分开维护

订阅更新后出现变化，应先比较服务器列表和当前选择，而不是假定规则文件发生了变化。删除重复条目之前，确认它属于哪个已有订阅，避免手动导入与订阅更新同时保留相同内容。关于分组、更新与重复处理，可继续阅读多个订阅的管理说明；分享内容的类型则见单节点链接与订阅地址的区别。

完成验证后，应保留最终有效的一份修改说明，写清目标、原因与检查结果。已经失效的临时例外及时删除，避免几次排查以后留下互相覆盖的规则。远程配置重新获取后，也要重新检查本地差异。长期维护的重点不是规则数量，而是每一组条件是否仍能解释、是否有明确用途、是否能够在异常时恢复。

最后再检查应用获取与使用边界。Shadowrocket 以 iPhone、iPad 为主要使用设备，Mac、Apple TV、Apple Vision 的兼容性与购买适用范围以 App Store 页面标注为准。应用更新通过 App Store 管理；本页配置片段不改变系统要求，也不包含网络服务。购买前核对开发者 Shadow Launch Technology Limited、官方图标和应用 ID 932747118。

如果基础操作还没有完成，返回教程按主线重新核对；如果已经定位到具体问题，可在疑难解答查找对应分类。保留一份能稳定复现结果的最小配置，再逐步恢复其他规则，通常比不断追加宽泛条件更容易找到原因，也能减少对原本正常连接的影响。