Shadowrocket 设置参考

Settings / 作用范围

设置范围、默认值与修改记录

先区分应用设置与请求处理

Settings 不是所有网络行为的唯一入口。Home 中选择的服务器决定可供转发的连接目标，Global Routing 决定使用配置规则还是统一选择 Proxy、Direct，Config 保存规则及相关参数，Settings 则包含应用层面的连接、测试、展示与维护选项。排查前应先辨认问题属于哪一层。网页走向不符合预期时，直接修改测试参数通常没有帮助；Widget 显示未及时变化，也不能单凭显示判断规则失效。

一个设置项需要同时记录四件事：所在页面、当前值、期望改变的行为、如何证明改变有效。例如调整 DNS，目标应是某个域名能够稳定解析，而不是让测试数字更小。调整 On Demand，目标应是满足指定网络条件时按预期连接，而不是让应用在后台一直保持可见。把目标写成可重复的动作，才能判断设置是否真正起作用，也便于发现无关修改。

怎样理解默认状态

“默认”至少有三种含义：首次打开时显示的应用初始值，导入配置后文件写明的值，以及系统当前网络提供的值。三者不一定相同。设备经过数据恢复、iCloud 同步或配置切换后，看到的内容也不宜再称为出厂状态。本手册对无法从当前设备直接确认的默认数字不作推定；推荐值以保留已验证设置、减少额外变量为原则，而不是要求所有设备填写同一组参数。

建立可以回退的修改流程

开始修改前，保存当前可工作的 Config 副本，记录选中的服务器、Global Routing、网络类型以及连接开关状态。只需在自己的记录里写清名称与变化，不要把订阅完整地址或密码贴到公开页面。随后只改一个项目，保存并按界面要求重新建立连接，再用同一项实际访问操作验证。若同时更换服务器、修改 DNS 和切换规则，即使恢复正常，也无法知道哪一步消除了故障。

“已保存”和“已用于新连接”是不同的状态。部分参数会在重新建立隧道或新建请求时体现；已经存在的连接可能继续使用此前的路径。验证时先停止原来的测试请求，必要时关闭再打开客户端连接，然后重新发起访问。不要在下载、通话或其他持续传输中反复切换参数，否则中断本身会混入故障现象，使日志难以对应到某一次修改。

建议的基线不是整套重置，而是保留当前能够解释的设置。没有明确需求时，测试方法、端口、同步范围和自动连接条件都先维持现状；遇到问题再按本页对应章节逐项查阅。需要确认应用来源时，前往正版核验说明，核对开发者 Shadow Launch Technology Limited 与应用 ID 932747118。购买和安装问题应在商店流程内处理，不用通过修改网络配置来代替。

DNS / 域名解析

DNS 设置与解析路径

DNS 解决的是名称到地址的问题

DNS 将域名转换为网络地址，不等同于代理连接本身。一次访问可能先得到地址，再由规则决定连接去向；也可能涉及代理端对目标名称的处理。具体路径受配置与协议影响。因此，服务器测试有结果但网页打不开，并不能直接归因于 DNS；域名能够解析，也不能证明目标服务可访问。应把名称解析、服务器连接、规则选择和目标响应分开验证，避免用一个结果概括整条链路。

先到 Config 确认正在使用的文件，检查其中是否显式设置 DNS，再对照 Settings 中设备实际提供的相关选项。不要仅凭某个输入框留空就认定没有 DNS 行为：留空可能表示使用其他来源的设置。若文件中写了 dns-server，应阅读该项及相关说明，而不是只改另一个页面上的显示值。配置覆盖关系不清楚时，先复制文件，在副本上验证实际生效结果。

默认来源与建议取值

没有明确解析需求时，先保留现有可工作的 DNS 方案。使用系统解析来源可以作为对照，但不表示适合所有网络，也不意味着所有请求都绕开代理。下面片段展示 system 的写法，只用于理解参数位置；它不包含服务器信息，也不是可以替代个人配置的完整文件。修改前应保留原有值，并确认当前文件没有其他影响解析路径的设置。

[General]
dns-server = system

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

不要为了增加“备用”数量而堆叠多个不清楚用途的解析地址。多个来源可能给出不同结果，也会引入超时与缓存差异。选择其他解析方式前，要确认当前应用界面或配置语法确实支持对应格式，并且在所在网络可达。涉及加密解析时，应区分传输加密、解析服务可达和访问目标可达这三个条件；只满足其中一个，无法推出整体请求一定成功。

按现象定位解析失败

如果只有某个域名失败，先检查拼写、访问目标是否仍有效，以及相同域名在同一网络中的重复表现。若多个互不相关的域名都失败，再查看 Log 是否出现解析相关错误。用地址直接访问只能作为有限线索：许多服务依赖域名、证书与请求头，地址访问失败并不能证明网络不通。对照测试应尽量使用正常的域名访问，不要把证书错误误认为 DNS 故障。

如果只在切换 Wi-Fi 后发生问题，记录切换前后是否需要完成网络登录、系统是否获得可用连接、客户端是否重新建立隧道。某些网络在完成登录前不能正常解析或访问外部目标，此时改写 DNS 可能掩盖真正的入口问题。先恢复系统网络的基本可用性，再验证 Shadowrocket；如果原网络正常而另一网络持续失败，保留这一区别，比反复替换配置更有诊断价值。

缓存会让改动后的现象不立即出现。应用、系统、浏览器和远端服务都可能保存部分结果，因此不要只刷新一次页面就下结论。重新建立客户端连接后，关闭旧测试页面并新建请求，观察同一域名多次表现，同时记录时间。清理缓存应以设备实际提供的操作为准；不需要为了验证单个域名而删除全部配置、重装应用或清空其他无关数据。

完成排查后，将保留的 DNS 来源、适用网络和验证域名写入自己的配置备注。不要把某次临时测试值同步到全部设备后才确认效果。若希望继续理解 DOMAIN、IP-CIDR 与名称解析之间的区别，可查阅术语表；开关已打开但仍无法访问时，可按服务器、模式、DNS 与规则排查清单复核整条链路。

Global Routing / Config

Global Routing、规则与配置覆盖

模式决定怎样使用规则

Global Routing 是解释流量去向的第一项检查。配置姿态 Config 按当前配置文件处理请求；代理姿态 Proxy 让进入客户端处理范围的流量按代理模式处理；直连姿态 Direct 按直连模式处理。这里描述的是客户端处理方式，不代表设备上所有系统流量都可以据此作绝对推断。测试某条规则前必须确认处于 Config，否则文件写得正确，也可能不是当前行为的决定依据。

日常需要按域名或地址分流时，建议使用已经核对的 Config。Proxy 与 Direct 可以帮助缩小故障范围，但不宜把临时对照结果直接当作长期方案。切换模式时记录原值，测试结束后恢复。Direct 下能够访问，只能说明该次直连路径可用；Proxy 下能够访问，也不证明 Config 中每条策略都正确。模式、规则和服务器应分别形成证据，不能互相替代。

规则顺序与最终匹配

规则通常按顺序检查，具体规则应放在宽泛规则之前，最终项负责接住尚未匹配的请求。DOMAIN 对照完整域名，DOMAIN-SUFFIX 覆盖相应域名后缀范围，IP-CIDR 与 IP-CIDR6 面向地址段；GEOIP 按地址地理信息进行匹配，其结果还受数据库与地址归属影响。不要把 GEOIP 当作网站内容来源的判断，也不要认为一个域名只会长期对应一个固定地址。

[Rule]
DOMAIN,example.com,DIRECT
DOMAIN-SUFFIX,example.org,PROXY
IP-CIDR,192.0.2.0/24,DIRECT
IP-CIDR6,2001:db8::/32,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

示例中的域名与文档地址段用于说明语法，不是实际服务器，也不构成通用分流建议。PROXY 需要已有可用的代理连接，DIRECT 表示直接连接，FINAL 则说明其余请求的处理方向。若将最终项改成 DIRECT，未命中的请求就会走不同路径。因此阅读配置时不能只找包含目标域名的一行，还要检查更靠前的规则以及最终项，确认请求实际落在哪个分支。

文件选择比文件名称更重要

导入一个配置文件，不等于已经启用它；编辑某个文件，也不等于当前连接正在读取该副本。每次验证前回到 Config 确认所选文件，再检查保存结果。文件名称相近时，可在个人备注中写清用途，例如日常基线与临时测试，不要依赖列表位置记忆。对包含多个段落的文件，只修改目标段落，保留原有服务器和其他必要参数，避免复制片段时意外丢失上下文。

用户已有的订阅与配置文件也不能混为一谈。订阅更新可能改变服务器列表，但规则是否变化，要看导入内容及实际操作。订阅里没有某个服务器时，当前选择可能需要重新确认；这不表示 DNS 必须重填。更新前后比较可用服务器、所选项目与当前 Config，比直接重建全部数据更容易识别原因。任何包含凭据的链接都应保留在自己的设备中，不作为公开排错材料。

如果发生“同一域名有时走不同路径”，检查是否存在多个相关域名、不同地址族、旧连接复用或资源请求跳转。页面本身与其中的图片、视频、接口不一定使用同一个域名。应在 Log 中找到真正失败的请求，再调整相应范围；只给页面主域名添加规则，未必覆盖全部资源。修改 DOMAIN-SUFFIX 时尤其需要考虑覆盖范围，避免为修复一个目标而改变大量无关请求。

On Demand / 连接触发

On Demand 与连接状态

自动触发不是持续可用保证

On Demand 用于按已保存条件触发 VPN 连接，其行为还取决于系统网络状态和设备允许的操作。它不是服务器健康检查，也不会修复错误密码、不可达地址或失败的 DNS。手动连接尚未稳定时，建议先不增加自动触发条件，完成服务器与规则验证后再启用。否则自动尝试连接会与人工排查交织，让“何时开始连接”和“为什么连接失败”难以区分。

首次添加 VPN 配置时，系统会显示授权提示。只有确认正在执行 Shadowrocket 的连接操作时，才按系统提示完成授权；提示内容和身份验证方式以设备实际显示为准。已有 VPN 配置也可能受到设备管理策略或其他连接状态影响。遇到无法授权或状态立即恢复的情况，先查看系统提示，不要反复删除应用数据。系统层面未允许建立隧道时，修改规则文本不能解决授权问题。

条件、初始状态与建议选择

进入设备上的 On Demand 页面，先记录当前是否启用，以及已经存在的网络条件。不同界面提供的条件和显示方式可能不同，本页不假定所有设备都有相同选项，也不把恢复后的状态称作默认关闭。建议从一个可以明确验证的条件开始，不要一次添加多组相互交叠的条件。若需要按 Wi-Fi 环境区别处理，应准确核对网络名称，并考虑同名网络可能不是同一个实际环境。

验证自动触发时，先停止持续传输，记下起始网络和开关状态，再执行一次网络切换，等待系统完成连接过程后发起实际请求。一次测试只改变一个条件，分别记录 Wi-Fi、蜂窝网络和设备锁定前后的现象。不要把刚切换网络时的短暂中断当作长期故障，也不要只看状态图标；网络切换、隧道重建和应用新建连接之间可能存在时间差。

关闭后重新连接的处理

如果手动关闭后很快又出现连接，先检查 On Demand 是否仍启用，并确认当前环境是否满足触发条件。需要临时停止时，应先处理自动触发设置，再关闭连接，然后重新观察。反复点击 Home 开关而不核对条件，可能形成关闭与重新触发的循环。若关闭自动触发后仍出现异常，记录系统 VPN 状态与操作时间，再查看其他可能影响连接的系统设置。

Wi-Fi 登录页面也是常见边界情况。某些网络需要先通过系统提示完成登录，之后才具备正常访问条件。若自动触发在网络尚未准备好时开始连接，可能表现为持续等待或访问失败。处理顺序应是确认该网络的正常接入要求、完成系统登录、验证基础连接，再观察 On Demand。不要在尚未接入成功的网络里反复替换服务器，把接入问题误判成客户端配置问题。

锁定设备后，应用界面不在前台并不等于 VPN 必然停止；同样，Widget 留有连接文字也不代表当前请求已经成功。系统负责调度相关网络组件，后台表现不能仅由前台画面推断。判断时应在恢复使用后重新发起请求，并对照实际状态及 Log。频繁打开应用、关闭应用或连续切换开关，会改变原本要观察的条件，反而不利于判断自动连接的稳定性。

最终保留的条件应能用一句话解释清楚：在什么网络状态下，希望何时连接。若需要多个例外，应逐条验证并记录，不必追求条件数量。设备换机或恢复数据后，再做一次完整测试，因为旧条件仍存在不代表新设备的网络环境相同。基础授权与首次连接步骤可回到教程页复核，本页用于解释这些操作之后的设置边界。

Ping / Connectivity Test

Ping、测试方法与结果解释

测试测到哪一段，结论就到哪一段

Ping 与 Connectivity Test 用于提供连接线索，但测试方法不同，覆盖的链路也不同。有的测试侧重服务器地址可达，有的尝试建立传输连接，有的会经过代理访问测试目标。先查看设备上实际选择的测试方式与目标，再解释结果。列表里出现一个耗时值，不等于目标网页、完整规则链路和所有协议功能都已验证；没有结果，也可能是该测试方式不被远端网络响应。

基础网络探测、端口连接与经过代理的请求不是同一种动作。服务器可以不响应某类探测，却仍正常接受代理连接；也可能很快接受端口连接，但在认证或后续转发阶段失败。因此“数值很小却打不开网页”并不矛盾。解释测试结果时，应明确它是否使用了实际代理协议、是否完成身份认证，以及测试目标是否就是发生故障的服务，避免把局部成功扩大成整体成功。

默认方法与建议参数

Ping 页面的初始方法、超时和目标，以本机当前显示为准；恢复设置或切换使用习惯后，不能假定所有设备一致。建议先保留已知测试方法，使用同一目标做前后对照。超时时间太短可能将正常波动记成失败，太长则会延长等待，并不会让失败连接变得可用。没有证据说明等待阈值不合适时，不需要先调整数字，更不需要把所有测试项目一起改动。

测试目标应稳定、明确并适合验证当前问题。若应用提供自定义目标，先确认填写格式符合界面要求，不要随意加入凭据或使用需要登录后才能访问的页面。目标本身发生跳转、限流、维护或证书问题，都可能影响结果。更换测试目标时保留旧目标用于对照，并明确这是改变了测试条件，不能把新旧数值直接当作服务器性能排名。

建立可重复的测试组

准备一组简单的验证动作：在固定网络下测试当前服务器，使用同一 Global Routing 和 Config 访问目标，再检查失败请求的 Log。重复数次，记录是否持续失败、偶发失败或只在特定操作后失败。避免同时启动大量测试，尤其是在网络较弱或服务器连接数量有限的环境里；测试本身也会消耗连接资源，密集并发可能制造与日常单次访问不同的现象。

若服务器测试正常而网页失败，按目标域名解析、规则命中、认证与远端响应继续检查。若测试失败而网页正常，先确认测试方法是否适用，而不是立即删除可用服务器。若只有某个服务器持续失败，核对用户已有服务提供的地址、端口、协议参数和有效状态；这些信息应由原有来源确认，不能通过反复调大超时猜出正确值。

对含 TLS 的连接，还要区分服务器地址与用于校验证书的名称。它们在合法配置中可能不同，具体要求以用户已有服务器信息为准。证书校验失败不应以降低校验要求作为常规处理；先检查设备时间、名称填写、证书链和服务端状态。端口能够建立连接，只证明前面的传输阶段有响应，不代表加密协商和后续请求已经完成。

测试结束后恢复临时修改的目标和方法，并把保留的参数写入修改记录。如果问题只发生在某种网络，至少保留两组同条件结果，再进入 Log 章节定位阶段。需要核对协议字段名称时，可查看功能与设置说明和术语表；这些页面解释概念，本节关注的是测试证据能支持多大的结论。

Log / Data

Log、请求记录与排错证据

围绕一次请求读取日志

Log 的用途是把现象对应到处理阶段，而不是要求用户逐行解释全部记录。开始排错前，先记下当前时间、网络、服务器、Global Routing 与 Config，再发起一次明确的失败动作。随后只查看相近时间段的相关记录，寻找域名、连接目标、规则或错误信息之间的联系。一次网页访问可能产生许多资源请求，最早出现的失败未必就是导致整个页面无法使用的关键请求。

先看请求是否进入客户端，再看是否得到解析结果、选用了什么策略、是否建立连接、远端是否返回响应。若记录里找不到目标，不应直接断言规则正常，可能是请求未重新发出、被应用缓存、走了不同的系统路径，或者当前记录方式没有覆盖该信息。应重新建立一个明确的新请求，再核对日志范围。通过排除阶段来缩小问题，比只搜索某个固定错误词更可靠。

记录范围与默认状态

Log 可见内容和详细程度，以设备提供的选项及当前状态为准。某些细节只有启用相应记录后才出现，开启之前的请求不会因此补齐。建议日常保留满足基本观察的记录方式，仅在复现问题的短时间内增加详细程度。更多日志可能增加存储和处理负担，也会包含更多访问细节；完成诊断后应恢复原设置，并按实际需要清理不再使用的记录。

日志中的错误往往是阶段性结果，而不是最终原因。例如超时可能来自地址不可达、服务器未响应、远端目标等待或网络切换，不能只凭一个词确定责任。需要把错误发生前后的记录连起来，再与实际操作时间对应。若改变一项设置后错误阶段发生变化，也应记下来：从解析失败变成连接失败，说明请求推进了一步，但还不能称为整体恢复。

Data 与连接状态的边界

Data 中的流量或相关统计可以帮助确认一段时间内是否有数据活动，但它们不等同于目标服务成功响应。累计值可能包含其他后台请求，也可能保留此前连接的数据。应先了解当前页面统计的时间范围，再做短时间对照；不清楚范围时，不要拿累计变化推断某一条规则的命中情况。需要精确定位目标时，仍以对应请求记录和可重复访问为主要证据。

如果问题间歇发生，先保持配置不变，让复现条件足够清楚。记录它是否与切换网络、设备锁定、订阅更新或持续传输有关，再在同样条件下进行有限次数测试。每次失败都改一个不同设置，会使记录无法比较。保留一个稳定基线和一个单项修改后的副本，能够避免后续排错时忘记原来的状态，也便于验证恢复是否依赖某个临时选择。

整理记录时应保护订阅地址、服务器凭据、个人域名与设备信息。截取必要的时间段，保留错误类型、规则关键字和阶段，移除认证数据以及可识别个人的信息。不要将完整配置与日志一并公开，也不要认为隐藏密码字段就等于移除了所有敏感内容：订阅地址中的查询参数、连接地址和某些名称都可能关联个人服务，应逐项检查。

确认解决后，再按原条件测试一次，并恢复临时开启的详细记录。不要把删除全部历史日志当作常规修复步骤；清理只能改变可见记录与空间占用，不能自动纠正服务器参数或规则。完整的处理顺序可结合连接后无法访问排查文章阅读，先由现象定位阶段，再决定应调整哪一项。

Widget / iCloud

Widget、iCloud 同步与设备恢复

Widget 是操作入口，不是完整诊断页面

Widget 用于在系统提供的位置查看状态或执行快捷操作，具体可用内容以设备实际提供的组件为准。它的刷新由系统调度，显示时间不一定与刚刚发生的网络变化完全同步。组件显示与 Home 不一致时，先打开应用确认当前服务器、连接状态和实际请求，再观察刷新。不要为了修复显示滞后而重写配置，也不要只看组件文字就判定连接持续成功或已经停止。

添加组件时，通过系统的组件编辑流程选择 Shadowrocket，并核对当前组件提供的配置项。若组件允许选择相关内容，应确认它指向仍然存在且适用的项目。恢复数据、调整名称或删除旧项目后，原有选择可能需要重新检查。建议先使用能清楚说明用途的简单展示，避免同时放置多个含义相近的入口，以免在未确认状态时连续触发连接操作。

同步内容与购买资格分别处理

iCloud 同步用于处理应用支持同步的数据，不等同于 App Store 的购买记录，也不表示当前 VPN 会话能够在设备之间直接迁移。购买应用、同步设置和授权建立连接是三个独立过程。新设备上能从已购记录获取应用，并不能据此认定所有配置已经同步；看到配置出现，也仍要确认本机网络授权、服务器选择和规则是否正确，再开始连接验证。

默认同步状态与可同步范围以本机 Settings 显示为准。启用之前，先核对系统 iCloud 登录与相关访问权限，再保存本地可用配置副本。不要在两台设备上同时大幅修改同一份内容后才等待同步。同步不是带有无限历史记录的备份工具，不能假定所有旧值都能找回；重要的配置变更应在自己的安全存储中另留可恢复副本，并保护其中的凭据。

同步延迟与冲突的处理

发现另一台设备未出现变更时，先确认两端网络可用、iCloud 相关权限正常，以及应用中的同步状态。随后等待合理时间并检查内容，不要连续执行导入、覆盖与删除来“催促”同步。若两端已经不同，分别保留副本，再确定哪一份是需要保留的基线。是否自动合并、覆盖或保留冲突内容，应以实际界面结果为准，本手册不假定固定的冲突处理方式。

不同设备可以需要不同的网络策略。iPhone 的蜂窝网络场景与 iPad 常用 Wi-Fi 环境不同，On Demand 条件、测试目标的可达性和本地端口用途也可能不同。因此同步后应重新检查与环境相关的项目，不能只因为文件名称相同就跳过验证。先用同一 Config 建立最小可用连接，再逐项恢复自动触发与组件入口，能够避免把同步成功误当成全部配置适用。

换机或重新安装时，先通过原购买账号的 App Store 已购记录获取应用，具体重新获取与通用购买适用性以 App Store 页面标注为准。然后检查受支持数据是否恢复，核对服务器和订阅内容是否仍有效，最后按系统提示完成本机连接授权。详细流程见已购恢复说明与换机后恢复 Shadowrocket，无需把购买问题和同步问题混在同一步处理。

在 iPad 上，页面可能因横屏或分栏显示而改变位置，但应按 Home、Config、Settings 等界面词定位，不按某个固定屏幕坐标操作。可结合iPad 购买与界面说明查阅。完成恢复后，重新核对 Widget 指向和 On Demand 条件，确保快捷入口与实际保留的数据一致。

Proxy / 端口与回退

Proxy 端口、参数边界与回退检查

本地监听端口与远端服务器端口

“端口”需要先辨认属于哪一端。Add Server 中的服务器端口由用户已有的服务信息决定，填写后用于连接远端；Settings 中如果提供本地 Proxy 监听相关项目，则用于本机或被允许来源发起的代理请求。两者职责不同，不能为解决远端连接失败而随意替换本地端口，也不能把本地端口填到服务器信息里。修改前同时核对地址、端口与协议，确认自己调整的是哪一层。

本地 HTTP 或 SOCKS5 接入与远端服务器协议也不是同一个概念。接入方使用哪种方式，应与本地实际提供的服务一致；远端则仍按已保存的服务器参数工作。单纯让某个端口处于监听状态，不代表 DNS、规则与远端转发都已通过验证。若没有需要显式接入本地 Proxy 的应用或设备，建议保留当前状态，不必为了普通 VPN 连接主动配置额外监听用途。

默认端口与访问范围

具体端口数字、监听范围和认证选项，以设备上的 Settings 为准，不在本手册中指定一个适用于所有安装状态的固定值。调整时先记录原值，确认预期使用方是否已经填写该端口。端口变更后，相关使用方也要同步修改；只改一端会表现为连接被拒绝或持续等待。遇到冲突时应先确认冲突来源，不要连续尝试一串数字而不记录最后保留的值。

仅限本机使用与允许局域网来源访问的风险不同。扩大监听范围之前，应确认当前网络是否可信、是否提供并正确使用认证，以及哪些来源能够到达该端口。不要为方便一次测试而长期保留超出需要的访问范围。局域网请求能否到达，还取决于网络隔离与系统状态；在应用中打开相关选项，并不意味着所有设备都能访问，也不表示应该继续扩大权限。

协议参数不靠 Settings 补偿

Shadowsocks、VMess、VLESS、Trojan、WireGuard、Hysteria2 等协议各有对应字段，应以用户已有服务提供的信息为准。地址、端口、认证内容、传输方式与加密相关参数不一致时，调节 Ping、Widget 或日志级别都不能补齐缺失字段。导入后仍应核对协议类型及必要参数，特别是手动录入内容；不要凭另一条可用连接的字段结构推断当前协议也使用相同设置。

服务器提供域名时，域名可能随地址变化而继续指向有效服务，随意替换为某次解析出的地址可能破坏名称校验或后续更新。涉及 TLS 名称、传输路径等字段时，应保留已有信息中的明确要求，不因为端口测试有响应就删除相关参数。每次只修正一个已确认的录入问题，再进行实际连接测试，保留修改前后的错误阶段用于比较。

恢复到最后一个已验证状态

排查结束仍未恢复时，按修改记录逆序撤销：先恢复临时端口和测试项目，再恢复 DNS，重新选择原有 Config 与服务器，最后核对 On Demand。不要一次清除全部数据，因为这会同时丢失可用基线和故障证据。恢复后重新建立连接，用相同目标测试；若原配置也出现问题，再检查网络与已有服务状态，而不是继续假定所有变化都来自客户端设置。

需要重新核对购买与系统要求时，使用App Store 获取说明。Shadowrocket 是付费商业客户端，客户端一次性买断 ≠ 线路套餐；已有服务的有效性与客户端购买分别确认。Settings 的合理终点不是所有项目都被改动，而是每个保留值都有明确用途、每个自动行为都能解释、发生问题时能够回到最后一个已经验证可用的状态。