Shadowrocket 故障排查手册

01 连接开关打不开：先查 VPN 配置授权

先区分三种现象：点击开关后出现系统授权提示；开关短暂开启又关闭；界面显示已开启，但系统没有稳定建立连接。它们分别偏向授权未完成、连接进程退出以及连接状态需要重新确认。不要把这三类情况都记成“节点坏了”。先退出其他正在工作的 VPN 连接，回到 Shadowrocket 的 Home，确认已经选中有效服务器，再尝试一次并记录屏幕上的原始提示。

授权提示出现时，完成系统确认

首次连接需要系统允许添加 VPN 配置。此提示用于创建系统管理的连接配置，不等于已经确认服务器能够访问。阅读提示中的应用名称，确认操作来自刚刚打开的 Shadowrocket，再按系统要求完成设备验证。如果先前取消了提示，回到应用重新触发连接；不要在尚未完成验证时来回切换其他设置，否则很难确认失败发生在授权前还是授权后。

随后进入系统 Settings，在 VPN 相关页面查看是否存在对应配置。不同系统的入口名称可能调整，可用 Settings 搜索 VPN 定位。配置存在只能说明系统保存了连接入口，不能证明当前服务器可用。如果找不到配置，先再次触发授权；如果设备受组织管理、相关选项不可用，应向设备管理员核对限制，而不是尝试改变服务器密码。

开关立即回落时，分离系统问题与配置问题

先关闭 On Demand，再手动连接一次，观察是否仍然立即断开。按需条件可能在网络变化时重新决定连接状态，关闭它有助于排除自动行为的干扰。记下正在使用的 Config 名称，检查最近是否编辑过无法解析的内容、引用了不存在的策略或留下不完整字段。优先恢复自己保存的上一份可用配置，而不是从不明来源换入整套设置。

如果之前一直正常，而删除系统 VPN 配置后才发生问题，可以在确认拥有必要配置备份后，重新通过应用发起系统授权。删除系统配置不是首选步骤；它不能修复错误的服务器参数，也不负责恢复订阅信息。需要重建时，先停止连接并记录 On Demand 状态，再只处理 Shadowrocket 对应的配置，避免误动其他工作用途的系统条目。

用可观察的状态结束这一轮排查

完成授权后，保持应用在前台，观察系统 VPN 状态是否稳定，再打开一个此前可以访问的普通网页。若开关稳定但网页失败，转到下一章处理路由与服务器，不再反复删除授权。若仍立即关闭，记录错误原文、是否每个服务器都如此、重启设备后是否复现。先正常重启再复测，比反复强制退出应用更容易得到清晰结论。

系统限制也要单独核对：屏幕使用时间、设备管理策略或其他网络配置可能影响 VPN 的建立。只查看与自己设备有关的授权状态，不随意移除组织配置。若设备本身的普通网络都不可用，应先恢复 Wi-Fi 或蜂窝网络；VPN 授权正常并不能替代基础网络。对权限提示的进一步解释，参见添加 VPN 配置提示说明。

02 连接后无法上网：分开核对路由与基础网络

系统显示 VPN 已连接，只表示连接扩展处于工作状态，不代表每个请求都成功抵达目标。先关闭 Shadowrocket，用同一网络访问一个已知可用的网页。若关闭后也失败，优先检查 Wi-Fi 是否需要网页认证、蜂窝数据是否可用，以及路由器是否正常联网。在公共 Wi-Fi 上，先完成网络自身的登录或使用条款确认，再建立连接，避免把认证页面打不开误判为规则错误。

用 Global Routing 对照确定故障层

基础网络正常后，记录当前 Global Routing，再对同一目标做短暂对照。配置姿态 Config 按当前规则分流；代理姿态 Proxy 适合检查所选服务器能否承载请求；直连姿态 Direct 用于对照不经过代理服务器时的表现。切换是诊断手段，不是永久解决方案。每轮测试完成后恢复原姿态，避免后续应用请求因临时设置而改变预期路径。

对照目标应固定，不要在三个姿态中分别打开不同网站。也不要只凭某个站点失败就宣布整个连接失效；目标可能自身故障，或其内容依赖其他域名。至少补测另一个独立目标，并记录是完全打不开、仅图片失败，还是登录环节失败。若 Proxy 可用而 Config 不可用，应查看请求命中了哪条规则，而不是继续更换服务器协议。

规则自上而下匹配，先找实际命中项

检查当前启用的 Config，不只查看文件列表中最近编辑的那个文件。规则通常自上而下匹配，先命中的条目决定处理方式；靠后的宽泛规则不能纠正前面已经命中的错误策略。尤其注意 DOMAIN-KEYWORD 范围较宽、REJECT 是否误拦，以及 FINAL 是否符合预期。下面仅展示匹配语法与先后顺序，不建议整段替换现有配置。

[Rule]
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.168.0.0/16,DIRECT
GEOIP,CN,DIRECT
FINAL,PROXY

若日志可查看，选取一次刚发起的请求，对照目标域名、命中规则、最终策略及错误结果。不要仅看列表里选中的服务器名称：规则或策略组可能改变实际出口。若请求命中 REJECT，先判断是否属于原本要阻止的域名；若为业务必需域名，只调整对应的窄范围条目，并保留原值。不要为了让一个页面打开而清空整份规则。

按可复现结果选择下一章

如果所有姿态都失败，但关闭连接后正常，继续检查 DNS 与连接进程；如果只有 Proxy 失败，进入节点超时章节；如果只有 Config 失败，围绕规则与策略引用缩小范围。局域网打印机、路由器管理页不可达时，应额外核对目标地址是否确属本地网段，以及已有 IP-CIDR 是否覆盖它。不要把示例中的私有网段当作所有家庭网络的完整清单。

最终验证应包括原来失败的操作，而非只看网页标题能否显示。重新加载页面、提交一次必要的普通请求，并确认系统连接仍稳定。涉及登录与支付的操作，先确认网站本身地址正确，再测试连接；不要通过关闭证书验证来处理网页报错。若仍不能判断，可在FAQ中对照相同症状，但保留本轮的三姿态结果，避免从头重复试验。

03 节点超时：按地址、传输与认证逐层检查

超时描述的是在规定时间内没有得到预期响应，并不直接说明哪一段出了问题。可能是服务器域名没有解析、目标端口不可达、协议握手不匹配，也可能只是 Connectivity Test 使用的测试目标暂时不可用。先记录测试入口、错误原文、是否只有单个服务器失败，以及真实网页请求是否同样失败。测试结果是线索，不是服务器状态的完整证明。

先核对 Add Server 中的基础字段

打开已有服务器条目，对照自己持有的原始信息，逐项检查 Type、Server、Port 和认证字段。Server 中不要混入不属于该字段的路径、空格或协议前缀；Port 必须与服务器实际监听端口一致。手动填写时尤其容易把展示名称当作服务器地址，或将订阅地址填进单个服务器字段。先确认信息类型，再修改内容，避免在错误入口中反复粘贴。

如果地址使用域名，域名解析失败会让后续连接根本无法开始。可以对照同一网络下其他域名是否正常解析，再进入 DNS 章节。不要自行把域名替换成随机找到的 IP：服务器可能依靠 SNI、证书域名或特定路由工作。只有在自己掌握服务器对应关系、并明确保留正确 TLS 参数的情况下，地址对照测试才有解释价值。

协议相同，不代表附加参数相同

Shadowsocks 需要核对加密方式与密码；VMess、VLESS 需要核对标识字段及所用传输；Trojan 应检查密码、TLS 和 SNI；Hysteria2 还要留意当前网络能否承载所需的 UDP 通信。若使用 WebSocket 等传输，Host 与 Path 也必须与服务器端一致。不要只改 Type 就期望不同协议互通，也不要凭端口数字猜测协议类别。

出现证书相关错误时，先核对设备日期、SNI 与证书域名是否匹配，再确认服务器证书是否有效。不要把 Allow Insecure 当作普遍修复开关；绕过验证可能掩盖地址错误或异常证书。TLS 连接到了某个端口，不代表认证已成功，也不代表请求抵达预期服务器。有关字段含义，可参阅Trojan 参数与 TLS 核对说明。

用最少的对照判断网络边界

在条件允许时，保持同一条服务器配置，分别用 Wi-Fi 与蜂窝网络测试。只有某个网络失败，说明应优先检查接入环境或该路径，而不是重新生成全部认证信息。反过来，同一网络下仅某条服务器失败，才更值得围绕该条目的地址、端口和服务器状态调查。每次切换网络后等待连接状态稳定，再发起相同请求，避免把切换瞬间的中断记作持续故障。

如果手动条目可以使用、订阅中的同一条目不能使用，将两者字段逐项比较，注意订阅更新可能覆盖本地修改。若所有已有服务器都失败，也不能直接认定客户端损坏；它们可能共用域名、认证或同一服务端入口。向自己的服务提供方反馈时，给出时间、接入网络类型、协议与脱敏错误，不发送完整凭据到公开讨论区。完成更正后，重新验证实际请求，而非只追求测试列表出现一个数字。

04 Subscribe 失败：区分获取、解析与覆盖

订阅问题至少分成三步：客户端能否取回内容，返回内容能否识别，以及导入结果是否按预期落入列表。错误出现在第一步时，反复修改节点协议没有作用；内容已经导入却无法连接，则应转查上一章。本章始终以用户已有自己的订阅为前提。订阅链接属于访问凭据的一部分，即使看起来只是普通网址，也不应展示在截图、公开日志或可被他人复制的说明中。

先确认地址完整，再看获取路径

在 Config 的 Subscribe 相关入口核对已有地址，确认复制时没有丢失查询参数、截断末尾或带入换行。若应用提供订阅条目的编辑与更新入口，以当前界面原文为准；不同入口的名称与位置应结合已安装界面核对。不要把服务说明页、账户登录页或某个单服务器分享内容当作订阅地址。已有信息到底是哪一种，应先向原信息提供方确认。

一次更新失败时，先记录失败发生在关闭连接还是开启连接的状态。获取订阅本身也要走网络路径，当前服务器失效可能使更新请求无法抵达。可以在基础网络可用的前提下，短暂关闭连接重新更新；若原本必须通过已有可用路径才能获取，则先选用自己已经验证过的条目。不要连续高频重试，避免把临时限流和原始故障叠加在一起。

返回成功，不代表内容就是有效订阅

网络请求得到响应后，返回的也可能是登录页面、到期提示、验证页面或错误说明。此时“无法解析”通常不是客户端需要任意转换格式，而是内容本身并非预期的服务器条目。检查自己的订阅是否仍有效，地址是否已被更换，提供方是否调整了返回格式。不要把未知网页内容直接覆盖进正在使用的 Config，更不要把订阅凭据提交给陌生的在线转换页面。

如果某些条目能导入、部分条目缺失，需比较缺失部分的协议类型、字段完整性及当前应用支持情况。不要自行补造密码或认证标识，也不要通过反复修改编码碰运气。可用脱敏后的字段名和错误文本说明情况，而不是公开原始响应。完整导入入口的差异见Subscribe、Add Server、扫码与剪贴板入口说明。

更新前保护本地编辑，更新后检查选择状态

订阅通常代表远端管理的一组信息，更新后可能改变名称、排序、地址或条目数量。本地临时修正过的参数未必会一直保留。更新前记录自己修改了哪些字段，必要时保存应用支持的配置备份；更新后先核对原来选中的服务器是否仍存在，再检查 Global Routing 和当前 Config。列表刷新成功，并不自动等于正在使用的条目已经变成可用条目。

遇到更新后列表变空，不要立即删除所有历史条目。先确认更新目标是否选错、订阅是否返回空内容、账户状态是否变化，以及有没有可恢复的本地记录。如果已有某个手动条目仍可使用，可先保留它作为验证基线。删除再添加只适合已确认有完整原始信息、且能够重新获取内容的情况；它不是所有解析错误的通用解决方法。

最后选取更新后的一条服务器，检查必要参数，再测试同一普通网页。若订阅更新成功而服务器超时，停止围绕 Subscribe 重试，转到连接参数章节。若只有自动更新失败、手动更新正常，应观察失败时的网络状态与时间条件，不要先推断是后台机制损坏。客户端买断与已有订阅的有效期属于不同事项，重新购买应用不能修复订阅地址失效。

05 速度慢：区分握手、吞吐与目标服务

“慢”可能是打开页面前等待很久，也可能是页面立即响应但大文件传输缓慢，还可能只有图片、视频或某个应用受影响。先给症状一个可重复的描述：同一目标首次打开需要多久、再次打开是否改善、切换网络是否改变。不要把 Connectivity Test 的结果直接当成下载速度。短请求的往返时间与持续传输能力是不同指标，单次测试不能覆盖拥塞、丢包与目标服务负载。

建立可比较的测试条件

选择同一设备、同一接入网络与同一目标，尽量在接近的时间做对照。暂停正在进行的云同步、大文件传输或应用更新，避免其他任务占用网络。记录当前服务器与 Global Routing，再分别观察首次访问和重复访问。首次慢而再次明显改善，可能涉及 DNS、TLS 握手或内容缓存；持续传输始终缓慢，则更应关注路径质量、拥塞和服务器实际承载情况。

不要同时切换服务器、DNS 和规则后再比较结果，因为改善后也无法确定是哪一项起作用。若已有多条自己管理的服务器，可一次只换一条，用同一请求复测。也不要把网络切换时的短暂中断计入稳定速度。等待 Wi-Fi 或蜂窝连接稳定，确认系统没有仍在进行认证，再开始下一轮，才有可解释的结果。

只有部分内容慢时，检查域名与策略

一个页面往往同时请求主站、静态资源、图片和接口等多个域名。主页面快而资源慢，可能是资源域名命中了另一策略，或某条过宽规则改变了出口。观察刚刚发生的请求记录，核对慢请求的实际域名与命中策略。只针对确认错误的域名调整规则，不要把所有相关域名一律改为同一处理方式。目标服务也可能按地区、账户或缓存分发不同内容，不能仅凭服务器测试正常就排除目标端差异。

若 Config 慢而 Proxy 表现正常，可以围绕策略组、规则顺序与 DNS 查询路径检查；若两者都慢而 Direct 对同一可直达目标正常，应继续看当前服务器路径。但 Direct 对某个目标失败并不能作为服务器更快或更慢的证据，因为两条路径可能根本不具备相同的可达性。对照的前提是目标在两种方式下都能完成相同操作。

UDP、MTU 与传输参数不要盲调

实时通信、部分流媒体和特定协议可能依赖 UDP，普通网页可用并不能证明 UDP 路径正常。若只有这些功能异常，先核对服务器支持与当前接入网络限制。对 Hysteria2 等协议，不能用调整带宽字段代替基本连通性验证；填写更大的数值也不等于获得更高的实际吞吐。优先依据自己服务器的配置说明，保留原值，再做单变量测试。

遇到小请求正常、大请求卡住的现象，可以把路径 MTU 作为后续调查方向，但不要未经证据反复修改。类似表现也可能来自丢包、目标服务限速或连接重置。先收集是否只在某个网络发生、是否与特定协议绑定、切换到已有可用服务器后是否消失。只有已确认相关性，且了解恢复方法时，再尝试与部署相符的参数调整。

设备发热也会影响实际体验。长时间高负载传输、屏幕常亮与后台任务可能同时存在；暂停测试让设备恢复正常状态，再复测短时间请求。不要在设备温度明显升高时连续做大量测速。最终判断应回到原任务：网页能否及时完成、视频是否持续缓冲、文件是否稳定传输，而不是只追求某个测试入口显示更小的数字。

06 DNS 异常：确认解析来源与请求去向

DNS 负责把域名转换为可用于连接的地址。域名无法解析时，代理握手可能还没有开始；域名能解析但地址不适合当前路径时，也可能表现为超时或访问到错误位置。典型线索是多个域名同时失败、首次打开等待很久，或切换网络后某些目标失效。不要仅凭“某个 IP 可以访问”就断言全部是 DNS 问题，因为 HTTPS 还涉及域名、SNI 与证书验证。

先看当前 Config，而不是记忆中的设置

打开当前实际使用的配置，检查 General 中的 dns-server，以及是否另有影响解析的映射或规则。下例表示采用系统提供的解析来源，只用于解释语法，不保证适合每个网络。修改前保存当前值，尤其不要把已有的分流解析安排直接覆盖成单个地址。系统 DNS 的具体来源可能随 Wi-Fi、蜂窝网络和设备管理设置变化，不能视为固定不变。

[General]
dns-server = system

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

检查是否存在手动 Host 映射或旧地址记录。它们可能绕过你正在调查的普通解析路径，使更换 dns-server 后看起来没有变化。若某个域名被固定到过期地址，先对照自己的原始配置来源，再决定移除或修正。不要把公开讨论中的某个地址直接填入映射；域名对应关系可能随地区、服务部署与时间改变。

加密解析同样需要可达的基础路径

采用加密 DNS 时，解析服务自身也必须能够连通；若访问它需要先建立代理，而代理服务器地址又依赖同一路径解析，可能形成启动阶段的依赖问题。排查时先确认服务器域名能否完成首次解析，再检查后续目标域名。不要同时更改解析服务与代理地址，否则很难辨认到底是解析恢复还是服务器路径改变。

某个公共 Wi-Fi 可能只允许其预期的解析与认证流程。在认证完成前，更换解析设置未必有帮助。先关闭连接完成网络登录，再按原配置连接复测。若仅某个网络出现问题，将同一配置带到另一个自己可用的网络对照；如果配置不变而结果变化，应优先调查网络对解析请求的处理，而不是立即改写全部域名规则。

IPv4、IPv6 与规则匹配要一起观察

同一域名可能返回 IPv4 和 IPv6 地址，设备选择的实际路径会受网络能力影响。若只有具备 IPv6 的网络出现异常，应记录解析结果类型、实际连接目标与失败方式，而不是立即全局关闭相关能力。IP-CIDR 与 IP-CIDR6 分别处理不同地址族，只有前者的本地规则不一定覆盖后者。域名规则与地址规则的匹配时机也不同，调整前应先确认请求到底命中了哪一条。

GEOIP 判断依赖地址归属信息，不等于能准确表达每个域名的业务用途。CDN 地址可能变化，共用地址也可能服务多个域名。对确定的少量业务需求，优先检查是否能用更明确的 DOMAIN 或 DOMAIN-SUFFIX 表达，而不是不断扩大地址范围。保留 FINAL 作为可解释的兜底，并确认策略符合当前使用目的。

修改后重新发起失败请求，注意应用或系统可能仍持有缓存。可以先关闭相关页面、重新打开，再观察新请求；若需要重新连接，也应先记录断开前后的设置。不要反复重启所有设备来代替验证。成功标准是目标域名得到合理结果、请求进入预期策略并实际完成，而不是某个解析测试单独显示成功。关于关键字的定义，可对照名词解释。

07 耗电、发热与频繁重连：检查活动来源

长时间保持 VPN 状态并不必然代表异常耗电；真正需要观察的是传输量、重连频率、设备温度及同期其他应用的活动。系统电池页面呈现的是一段时间内的统计，不是单次请求的精确成本。先记下异常开始时刻、当时使用的网络与应用，再比较相近时长、相似任务下的表现。不要把某一轮统计中较高的占比直接解释为客户端持续满负载。

先排除持续传输与后台业务

检查是否存在照片同步、大文件传输、视频播放或应用更新。它们经过连接时，可能让网络扩展持续处理流量；此时业务应用与连接扩展的统计需要一起看。暂停相关任务后，保持其他条件不变观察一段时间，判断是否仍然明显发热。不要在测试耗电时同时进行大量 Connectivity Test，这些操作本身也会制造连接与数据传输。

系统电池页面中的后台活动还应结合实际使用场景解释。屏幕常亮、蜂窝信号较弱、热点共享和高温环境都可能增加消耗。把设备放回正常温度与稳定网络后再比较，能够减少误判。若连接关闭后仍然持续发热，先排除设备与其他应用活动，不要把所有问题都归入 Shadowrocket 的规则配置。

On Demand 与网络切换分开验证

On Demand 按系统条件触发连接。如果 Wi-Fi 与蜂窝网络频繁切换，或接入点短暂失联，可能出现多次建立与断开的过程。先记录按需条件，再临时关闭 On Demand，保持同一网络手动连接，观察重连是否减少。若确实减少，应回头检查条件是否重叠、当前网络是否稳定，而不是永久维持一个自己不理解的触发配置。

从睡眠唤醒、离开 Wi-Fi 覆盖范围或经过网络认证时，短暂重建连接可能是环境变化的结果。异常之处在于网络已稳定后仍持续重复。观察日志中是系统触发连接、服务器握手失败，还是业务请求不断重试。把三者分开，才能确定该改 On Demand、检查服务器，还是处理持续发请求的应用。只看状态图标闪动不够。

日志、规则与连接失败的成本

为了排查而打开较详细的日志后，完成采样就恢复平常使用的记录级别。长时间保留大量详细记录会增加存储与处理工作，也可能留下隐私信息。日志应围绕短时间内的一次复现收集，不需要连续保存全部日常请求。分享前遮盖域名中的身份信息、服务器地址与认证内容，只保留定位所必需的错误上下文。

失效服务器也会让业务请求重复等待与重试。如果当前规则将大量日常流量导向一个不可用策略，表面上是后台耗电，根因却可能是持续失败。先确认实际使用的服务器可用，再查看是否有某个域名被误拦后反复重试。规则数量多本身不能证明是耗电原因，应以实际请求、失败频率和调整后的对照结果作为依据。

如果只有某个协议在当前网络上持续重连，使用自己已有的另一条可用配置作对照，保持目标与任务不变。不要同时改变协议、服务器与业务负载后就归因于某个设置。对 WireGuard 等依赖具体部署参数的条目，也不要随意修改保活相关值；是否需要以及应取何值，必须结合服务器与网络环境判断。

一轮观察结束后，恢复正常日志、确认 On Demand 回到预期状态，并记下设备温度与电量趋势是否改善。持续异常且无法通过任务暂停、稳定网络和可用服务器消除时，再保留脱敏记录进入更新后排查。系统电池数据有统计窗口，修改后应等待可比较的使用时段，不能期待开关切换几秒钟就改变整段历史比例。

08 更新后与 iPad 异常：恢复基线再核对差异

异常恰好发生在更新之后，不代表更新一定是唯一原因。应用更新、系统更新、订阅刷新、服务器变更与网络切换可能在相近时间发生。先列出最后一次成功连接与第一次失败之间的变化，再按最少变量复测。保留当前 Config 与原始服务器信息，不要立即清除所有数据。购买恢复只解决应用取得资格，不等于自动恢复用户自己编辑的全部本地内容。

更新后先确认当前选择与系统授权

打开 Home，检查选中的服务器、Global Routing 和系统连接状态，再确认当前启用的 Config 是否仍是预期文件。若曾使用策略组，检查组内选择是否发生变化。配置列表存在不等于它正在生效；名称相似也不等于内容相同。优先对照自己保存的可用基线，确认差异之后再修改，不要把全部设置重置为默认来代替定位。

如果系统 VPN 配置被移除，或设备迁移后需要重新授权，按第一章完成系统提示。若应用能够打开但所有连接都失败，先在当前网络关闭连接验证基础访问，再用原本可用的服务器测试。必要时正常重启设备后复测一次，并记录结果。更新记录与系统要求应在 App Store 页面核对，不凭网络文章中的旧截图判断当前界面是否“缺少功能”。

iPad 与 iPhone 对照时，先统一条件

同一已有订阅在 iPhone 可用、在 iPad 不可用，先确认两台设备是否真的使用同一条服务器、相同协议参数与相同 Config。订阅名称一致不代表两台设备最近更新到的内容一致。还要核对 Global Routing 与 DNS，尤其是某一台设备保留了本地编辑时。不要在没有逐项比较前认定是 iPad 专属兼容问题。

网络条件也可能不同：iPad 可能只连 Wi-Fi，而 iPhone 实际通过蜂窝网络传输。先让两台设备连接同一 Wi-Fi，使用同一目标进行测试，再分别观察结果。若只有 iPad 失败，检查其 VPN 授权、设备管理限制、网络认证状态和系统日期。若两个设备同时失败，则应转查共用服务器、订阅或路由器，不必继续追查平板界面布局。

iPad 横屏、分屏或窗口布局可能改变入口的摆放位置，但不会把同名字段变成不同的服务器参数。按 Home、Config、Settings 等界面词寻找相关功能，空间不足时先恢复到便于操作的完整窗口再核对。不要因为某个入口没有出现在手机截图的位置，就新建一份重复配置。入门操作仍以入门指南为主，本页处理差异与异常。

重新取得应用前，明确备份与购买边界

确实需要重新取得应用时，只通过 App Store；先核对原购买账户与已购项目，具体步骤见已购项目恢复说明。正版信息应核对开发者 Shadow Launch Technology Limited、官方图标与应用 ID 932747118。Shadowrocket 是闭源商业应用，系统要求与设备购买适用范围以 App Store 页面标注为准，不从旧说明推断所有设备的资格。

重新安装前，确认已有订阅地址、手动服务器参数与本地 Config 已以自己能够恢复的方式妥善保存。备份可能含有密码、私钥与访问凭据，应使用自己受控的存储，不贴到公开页面。应用购买记录、系统 VPN 配置和用户自己的连接数据属于不同层次，前者能够恢复并不证明后两者已经恢复。重新打开后仍应按首次授权与验证流程检查。

形成可复现的故障记录

若所有本地步骤仍不能解决，准备一份短记录：设备类型、系统与应用当前显示的信息、网络类型、失败入口、脱敏错误原文、最后一次正常操作，以及已验证过的对照结果。明确是开关回落、域名解析失败、握手失败还是特定业务超时。不要只写“更新后不能用”，也不要一次提交大量不相关截图，让真正的失败步骤被淹没。

对服务器认证、订阅有效性与服务端协议参数的问题，应向自己的信息提供方确认；对系统授权或设备管理限制，则围绕设备设置处理。确认恢复后，再检查 On Demand、Global Routing、日志级别和临时测试规则是否已经回到预期。一次完整排查的终点，不是偶然打开一个网页，而是在已记录的正常配置下，原来失败的操作可以重复完成。