01 · 系统连接层
开关打不开或立即断开
先判断系统有没有建立隧道，再检查隧道里使用的服务器。
把“无法启动”与“启动后不通”分开
打开 Home 中的连接开关后，观察它是否保持开启，以及系统是否显示 VPN 已连接。如果开关立即复位，问题通常发生在系统授权、隧道启动或配置加载阶段；如果开关持续开启但网页打不开，应转到下一章。服务器测试失败并不等于系统不能建立隧道，反过来，系统显示连接也不能证明远端服务器可用。先记录准确现象，避免在权限问题上反复刷新订阅。
首次连接时，iPhone / iPad 会要求允许添加 VPN 配置。确认提示来自刚刚主动打开的 Shadowrocket，再按系统要求完成授权与设备验证。如果此前取消了提示，回到客户端重新连接；若一直不出现提示，进入系统 Settings，检查 VPN 配置是否存在，以及设备是否受到管理限制。系统要求以 App Store 页面标注为准，不能仅凭设备外观或机型名称判断兼容性。
检查配置冲突与自动触发
暂时关闭其他正在运行的 VPN 连接以及可能占用同类网络扩展的过滤功能，再单独启动 Shadowrocket。这里的目的不是认定某个功能有问题，而是减少同时控制系统网络路径的组件。若设备由学校或单位管理，不要自行删除管理描述文件；先确认管理策略是否允许建立个人 VPN。无法修改的系统限制，需要由设备管理员处理，修改节点参数不能绕过这些限制。
如果手动关闭后又自动连接，先检查 On Demand，而不是把它视为开关失灵。按需连接条件可能在网络切换或应用发起请求时重新触发。测试期间记下原来的条件，暂时停用自动触发，然后只做一次手动连接。若关闭后仍显示 VPN，核对系统正在使用的是哪一项配置；同一个状态图标并不说明当前一定由 Shadowrocket 建立连接。
用最小配置判断启动失败的位置
保留当前 Config 的副本，选择一份结构简单、来源明确且此前可用的配置进行对照。若只在某份 Config 下立即断开，重点检查最近加入的规则、脚本引用或不完整配置内容；若所有配置都无法启动，优先回到系统权限与扩展状态。每次只替换 Config 或 SERVER 中的一项，否则即使恢复，也无法知道是哪一步解决了问题。不要把远端配置更新和系统重启同时进行。
应用无响应时，可先结束客户端前台进程并重新打开，再尝试一次；仍无变化时重启设备，排除暂时的系统扩展状态异常。不要连续快速拨动开关，启动与停止本身需要时间，反复操作会让状态判断更加困难。若系统报出具体错误，保留原文、出现时机与复现步骤，错误信息通常比“连不上”三个字更有定位价值。
恢复连接后保留验证结果
重新授权或恢复配置后，先保持 On Demand 关闭，完成手动连接与断开各一次，再访问一个此前失败的页面。只有手动流程稳定，才逐项恢复自动条件。若开关可用但随后出现无法访问、超时或解析错误，说明排查已经进入下一层，应转到对应章节继续，而不是重复删除 VPN 配置。最终记录哪份配置可启动、哪些系统功能暂停后有变化，便于后续恢复原来的使用环境。
02 · 请求路径
连接后无法上网
以断开时的基础网络为起点，再比较 Global Routing 的三种状态。
先证明基础网络可用
断开 Shadowrocket，确认当前 Wi-Fi 或蜂窝网络本身可以完成正常访问。公共 Wi-Fi 可能要求先打开认证页面、接受使用条款或重新登录；未完成认证时，即使服务器参数完全正确也可能连接失败。先完成网络认证，再启动客户端。如果断开后同样无法访问，优先检查路由器、信号、流量限制与系统网络状态，不要从规则文件开始修改。
基础网络正常后，重新连接，只访问一个确定可用的测试页面，并记录是所有应用失败，还是仅浏览器、某个应用或某个域名失败。若只是一个应用异常，检查其蜂窝数据权限、应用自身网络设置和缓存；若所有请求都受影响，再观察 SERVER、Global Routing 与 Config。不要用一个已经缓存的页面作为成功证据，刷新页面或打开新的普通页面更容易形成有效对照。
用三种状态划分故障范围
| 界面状态 | 请求处理方式 | 排查用途 |
|---|---|---|
| Config | 按当前配置规则选择策略。 | 检查规则匹配与策略引用。 |
| Proxy | 主要请求使用所选代理路径。 | 缩小规则因素的影响范围。 |
| Direct | 主要请求直接访问。 | 与当前基础网络路径对照。 |
如果 Proxy 可以访问而 Config 不行，说明至少有一条代理路径可用，应重点检查 Config 中的规则顺序、策略名称和最终回退。若 Direct 正常而 Proxy 失败，先检查所选服务器和远端连接，不要立即改 DNS。三种状态只是定位工具，并不能覆盖所有特殊配置；本地网络地址、DNS 请求和系统流量仍可能受其他设置影响，测试结束后应恢复日常需要的状态。
检查规则是否交给了正确策略
进入 Config，确认实际启用的是预期文件，而不是只把文件下载到了列表。规则通常按顺序寻找匹配项，靠前的宽泛规则可能让后面的精确规则没有机会生效。下面的片段用于说明顺序，不是适用于所有网络的完整配置。PROXY 必须能指向当前配置可用的策略；如果文件使用自定义策略名称，应检查名称是否存在且拼写一致。
[Rule]
DOMAIN-SUFFIX,example.com,PROXY
GEOIP,CN,DIRECT
FINAL,PROXY若只影响某个域名，观察该请求实际命中了哪条规则，以及最终选择了什么策略。被 REJECT 命中的请求会按配置被拒绝，不能据此判断服务器故障。修改时优先加入范围明确的测试规则，而不是直接删除所有规则；验证后再决定是否调整原规则。需要理解匹配顺序时，可参阅代理模式中的规则说明，避免把临时测试配置长期保留。
以可复现的对照收尾
如果 Proxy、Config 都失败，换一个自己已有且参数确认有效的服务器，再换另一种基础网络进行交叉测试。只在一个网络失败，检查该网络的认证、UDP 可达性或本地限制；同一服务器跨网络都失败，转到节点超时章节。如果只有域名访问失败，转到 DNS 章节。每得到一个结论都先恢复无关设置，不要把多次试验留下的临时开关叠加成新的故障来源。
03 · 远端连接层
节点超时与握手失败
区分传输不可达、认证失败与目标访问失败，不把所有错误都归为超时。
先核对端点，再解释测试结果
从你的服务商处获取当前有效的服务器信息，核对地址、端口、协议和认证字段。订阅中的显示名称只是辨认标签，不代表服务器地址，也不能证明节点仍然有效。手动录入时检查首尾空格、全角符号和复制遗漏，尤其不要把网页上的说明文字一起粘贴。若使用订阅节点，先确认订阅更新时间与当前节点属于同一个分组，避免修改了未被选中的条目。
Connectivity Test 的结果取决于测试方式与目标。某次测试失败，可能是远端连接失败，也可能是测试目标不可访问；某次测试成功，也只说明该次测试完成，不能代替持续下载或全部应用的验证。先在设置中确认当前采用哪种测试方式，再用实际页面访问复核。不要把不同测试方式产生的数值直接比较，更不要根据一次结果判断整条线路的长期质量。
按协议检查必要字段
Shadowsocks 要核对加密方法与密码是否和服务器端一致；VMess、VLESS 要核对相应身份字段以及传输设置；Trojan 要核对密码和 TLS 相关信息。Hysteria2 依赖 UDP 传输，当前网络无法稳定传递 UDP 时，TCP 网页正常也不能证明它能工作。WireGuard 则要检查密钥、地址和允许的路由范围。协议不能只改名称，其他字段必须与服务端共同匹配。
| 错误现象 | 优先检查 | 不宜直接推断 |
|---|---|---|
| 连接超时 | 地址、端口、网络路径与服务器在线状态。 | 不能直接认定密码错误。 |
| 认证失败 | 身份字段、密码、订阅有效状态。 | 不能靠更改 DNS 修复认证。 |
| TLS 握手错误 | 系统时间、SNI、证书名称与传输设置。 | 不应直接关闭证书验证。 |
TLS 错误不要用跳过验证掩盖
服务器地址、TLS 使用的名称和传输层 Host 不一定相同，必须按服务端提供的信息填写，不能凭显示名称猜测。系统日期与时间明显错误时，证书有效期判断也可能失败，应先开启系统自动时间并确认时区。证书名称不匹配时，应核对 SNI 与服务端证书，而不是把跳过验证作为常规解决办法；这样做会改变连接的信任边界，却未必修复真正的配置错误。
如果同一条服务器在 Wi-Fi 超时、蜂窝网络正常，保留相同的 SERVER 与 Config，只改变网络再测一次，观察是否稳定复现。若该协议依赖 UDP，可把结果与自己已有的另一种传输方式进行对照，但不要随机修改端口或切换到未经服务端配置的协议。客户端与服务器必须对应，单方面调整不能凭空创建服务端未开放的能力。
整理服务商能够处理的证据
跨网络仍失败时，向你的服务商提供协议、故障时间范围、错误类型和已完成的对照结果，请其确认服务器状态与账号权限。不要公开完整订阅链接、密码、私钥或身份字段。若需要说明节点，可先提供显示名称或经脱敏的地址片段；完整信息只在确认必要且可信的支持渠道提交。本站处理客户端使用说明，不代替服务端检查，也不根据超时现象推荐替代服务。
修复后使用同一个目标重复访问，并确认不只是测试按钮恢复。若握手成功但页面仍慢，转到速度章节；若远端域名无法解析，先阅读 DNS 章节。保留最终有效的参数来源与修改项，下一次订阅更新覆盖手动变更时，才有依据判断究竟是服务端参数更新，还是本地临时修正被还原。
04 · 导入与更新层
订阅失败或列表为空
把下载失败、内容解析失败与更新后的节点不可用分别处理。
确认链接类型与输入位置
订阅链接从你的服务商处获取，应是给客户端使用的订阅地址，而不是账号登录页、订单页或浏览器收藏的管理页面。按教程中的导入步骤添加已有订阅，核对输入位置与链接内容。复制时注意换行、空格和截断；包含特殊字符的地址不要手工删减参数。二维码也可能承载单个服务器而非订阅，导入后应根据实际内容判断，不要只凭二维码外观分类。
订阅地址往往包含访问凭据，应按密码管理。不要把它粘贴到公开评论、截图或不明在线转换页面，也不要把整条链接写进故障描述。需要展示结构时，仅保留域名和路径形态，隐藏查询参数中的敏感部分。若链接已经公开，联系你的服务商重置相关凭据；仅从本地删除记录不能撤回已经泄露的访问权限。
先区分下载错误与解析错误
更新时直接提示连接失败、解析域名失败或超时，说明客户端尚未取得预期内容，先检查基础网络、DNS 和订阅服务器的可达性。若能够取得响应却无法导入，则检查返回内容是否为客户端支持的订阅格式。账号过期提示、网页验证页面和访问拒绝页面都可能以文本形式返回，但它们不是节点列表，不能通过反复刷新变成有效配置。
HTTP 状态也要结合响应解释：权限相关错误通常需要核对链接或账号状态，请求过多则应停止连续刷新并稍后重试，服务器错误需要服务端恢复。不要把返回的所有错误统称为“格式不兼容”。如果服务商提供面向不同客户端的订阅选项，应选择明确适用于 Shadowrocket 的内容；不要凭名称相近就使用另一种配置格式，也不要随意改写地址参数。
保留旧列表，再做单次更新
更新前记录旧列表是否仍能使用，并在必要时备份手动服务器。获取新内容失败，不一定意味着已经保存的节点同时失效；反过来，更新成功也不代表每个节点都能连接。先执行一次手动更新，观察节点数量、分组与名称是否发生预期变化，再选一个条目验证连接。不要以连续点击作为测试方法，它可能触发服务端频率限制，让原本可判断的问题变得复杂。
更新后列表为空，应检查账号有效状态、服务端是否返回空内容，以及是否有筛选条件隐藏了条目。若只是部分条目消失，可能是服务端调整了内容，也可能是导入解析失败；应把响应类型和错误提示交给服务商核对。不要先删除整个订阅组，因为这样会同时丢失旧列表和可对照的信息。手动更改的节点也可能在下一次刷新时被覆盖，要提前明确它属于订阅还是本地条目。
恢复自动更新前验证路径
若服务商的订阅入口只能在某种网络路径下访问，先用已有可用连接完成一次更新，并记录当时的 Global Routing。不要在没有可用节点时，把唯一的订阅更新路径也强制交给失效代理。不同配置可能影响订阅请求的走向，应按实际日志与结果判断，而不是假设所有订阅请求一定直连或一定走代理。
手动刷新稳定后，再检查打开时自动更新的设置与触发时机。自动更新失败时，保留手动成功与自动失败的环境差异，例如网络尚未就绪、认证页面未完成或应用刚恢复前台。详细操作可继续阅读Shadowrocket 订阅更新方法。最终验收要同时包括列表取得、内容解析和节点实际连接三个环节。
05 · 性能与传输层
速度慢与间歇性卡顿
分别测量等待、传输和稳定性，避免用一个延迟结果解释所有体验。
先把“慢”描述成可以复测的现象
页面很久才开始显示、开始后下载缓慢、视频反复缓冲和网络偶尔完全停顿，是不同的问题。等待首个响应可能与解析、握手和目标服务器有关，持续传输速率则还受线路带宽、丢包与设备状态影响。记录一个固定目标、一个固定动作和大致观察时段，再做对照。不要把不同网站、不同文件大小或不同时间段的结果放在一起，得出节点突然变快或变慢的结论。
先暂停系统更新、云同步和其他大流量任务，确认设备没有处在明显过热状态，再测试同一个目标。测速本身也会占用带宽，不要同时运行多个测试。若问题只在某个应用出现，检查该应用的内容服务器、缓存和后台下载；其他应用正常时，客户端未必是瓶颈。测试记录应同时写清 Global Routing 与 SERVER，避免把直连目标误当成代理性能证据。
按本地网络、远端线路、协议逐层对照
保持同一个服务器与配置，分别在 Wi-Fi 和蜂窝网络测试。仅 Wi-Fi 慢时，靠近接入点、检查路由器负载和当前频段干扰，再与同一网络里的普通访问比较。仅蜂窝慢时，观察信号变化、流量限速与移动状态。若断开客户端后同样缓慢，应先处理基础网络；代理无法补足本地链路已经丢失的容量，也不能让拥塞的接入网络恢复稳定。
基础网络稳定后，使用自己已有的其他服务器进行对照。如果只有一个端点慢，可能与该服务器负载、出口路径或目标之间的连接有关；若所有端点都只访问某个网站慢，应把目标服务本身纳入排查。节点名称中的地区标签不是实际路由图，地理位置更近也不必然更快。先保留测得的差异，再向你的服务商询问线路状态，不根据名称做质量判断。
理解延迟、丢包与吞吐的区别
低延迟适合交互，但不直接等于高下载速率。丢包会触发重传，网络抖动会让实时通信与视频缓冲更明显；一次短测试不一定能覆盖这些问题。用稳定的日常任务重复验证，比只看列表里的一个数值更可靠。不要在持续下载期间反复切换服务器，已有连接可能尚未结束，新旧请求混杂后很难知道哪个结果属于哪条路径。
Hysteria2 使用 QUIC 相关传输机制，在某些网络条件下与 TCP 路径表现不同，但前提是当前网络能稳定传递 UDP。不能因为协议名称就保证速度，也不能把所有慢速归因于加密。需要调整传输参数时，以服务端要求与客户端支持项为准，先保存原值，再逐项验证。协议基础可参阅Hysteria2 协议说明，不要复制不适用于当前服务器的参数。
只对已定位的层次调整参数
MTU 不合适可能表现为小请求成功、大传输停顿，但它不是所有卡顿的默认解释。只有问题具有稳定复现特征、其他层次已经排除时，才按服务端或网络环境要求做小范围调整，并记录原值。随意把 MTU 调得很小会增加额外开销；同时更改 DNS、MTU 与协议，则会让任何改进都无法归因。对移动网络中的偶发抖动，保留多个时段的结果比一次调整更有意义。
最终以实际任务验收：同一页面是否稳定打开，同一段内容是否持续传输，切换网络后能否恢复。暂时更快不等于根因已经解决，至少复测原来失败的场景。完整的分层记录方式见小火箭速度慢的逐层排查。若访问等待主要集中在域名解析阶段，继续阅读下一章，不必先更换全部服务器。
06 · 名称解析层
DNS 失败与域名异常
分别检查目标域名、服务器域名和加密 DNS 端点的解析路径。
先确认失败发生在哪个域名
DNS 把域名转换成连接所需的地址。需要解析的可能是你访问的网站，也可能是代理服务器自身，或者 DNS over HTTPS 使用的端点域名。服务器域名解析失败时，代理尚未建立；目标域名解析失败时，可能已经完成代理连接。先从错误记录中区分对象，再判断应该检查基础网络 DNS、当前 Config 的 DNS 设置，还是远端解析路径。
“域名打不开、IP 能打开”只能作为线索，不能单独证明 DNS 故障。HTTPS 网站通常还依赖正确的域名与证书名称，直接访问地址可能得到不同页面或证书错误。更可靠的方法是查看对应请求的解析错误、解析耗时和返回状态，并与同一域名的正常网络结果比较。不要为了测试而关闭证书验证，也不要把临时得到的 IP 长期写入所有访问规则。
系统 DNS、自定义 DNS 与 DoH 的边界
系统 DNS 通常跟随当前网络设置，方便适应局域网与认证环境，但结果可能随 Wi-Fi 切换而变化。自定义 DNS 把解析交给指定服务，需要确保当前网络确实能够访问它。DNS over HTTPS 使用 HTTPS 传输解析请求，仍然需要一条可到达端点的网络路径；启用它不等于远端代理已经可用，也不保证能解释所有局域网内部名称。
如果 DoH 端点的域名又依赖尚未建立的代理解析，可能出现循环依赖：建立代理需要解析服务器，解析又被要求通过代理完成。排查时先恢复一条能完成启动解析的路径，再逐项验证加密 DNS。不要把服务器地址随意改成网上找到的 IP，端点地址、证书名称和 SNI 的关系必须保持符合服务端要求，否则可能从解析错误变成握手错误。
检查规则与解析之间的关系
DOMAIN、DOMAIN-SUFFIX 依赖请求对应的域名信息；IP-CIDR、IP-CIDR6 和 GEOIP 则按地址相关条件判断。需要地址的匹配可能涉及解析，因此调整规则顺序也可能改变表现。下面只列出规则示例，地址范围用于文档演示，不代表真实服务；应结合当前 Config 的策略定义和实际命中记录理解，不能把片段直接当作完整 DNS 配置。
[Rule]
DOMAIN,example.com,PROXY
DOMAIN-SUFFIX,example.com,PROXY
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
IP-CIDR6,2001:db8::/32,DIRECT,no-resolve
FINAL,PROXYno-resolve 用于相关 IP 规则时，表示不为匹配该规则主动进行域名解析，并不是关闭全部 DNS。若希望按域名明确分流，可优先使用范围清楚的域名规则，再观察地址规则是否仍有必要。不要为了绕过一次解析失败，把所有域名交给宽泛的关键词规则；这样容易产生误匹配，让其他正常请求也被带到不合适的路径。
注意缓存、IPv6 与局域网名称
更改 DNS 后，应用、系统或客户端可能仍保留旧解析与既有连接。先断开相关连接、重新发起请求，再看新的日志，而不是只刷新已经建立连接的页面。若域名同时返回 IPv4 与 IPv6，只有其中一条路径不可达也可能产生间歇性失败。应确认失败请求实际使用的地址族，再决定是否针对当前网络调整，不要把关闭 IPv6 当作所有设备的固定优化。
打印机、路由器管理页和单位内部域名可能依赖本地解析方式。公共 DNS 不能保证解析这些名称，局域网访问异常时应检查本地网段与解析路径是否被代理设置改变。每次只恢复一项 DNS 设置，确认普通域名与内部名称都满足需求后再结束测试。更详细的取舍可阅读Shadowrocket DNS 设置说明，把选型与故障处理分开进行。
07 · 后台与资源层
耗电异常与后台活动
比较相近使用条件下的实际活动，先找持续重连与大量传输。
先读懂系统电量统计
系统电池页面显示的是所选时间段内的使用占比，不是软件固定功耗。其他应用用得少时，一个后台网络组件的占比可能上升，即使绝对耗电没有明显增加。比较时保持屏幕使用、信号、充电状态与传输任务尽量接近，并记录设备是否发热。不要只凭一次百分比就认定更新导致耗电，也不要在刚完成系统迁移、照片同步时做最终判断。
代理运行时会处理其他应用的网络流量，系统对这些活动的归因方式可能与用户直觉不同。先查看是否有云备份、视频播放、应用更新或热点共享在持续传输，再看客户端的 Data 与连接记录。记录与系统统计可能采用不同时间范围，不能直接把两个总量相减得出异常流量。需要比较时，从一个明确起点开始观察，并保持观察窗口一致。
排除持续失败与自动重连
远端不可达时，反复握手、解析与重新连接会消耗额外资源。若日志中同一错误密集重复，先修复服务器、DNS 或认证问题，而不是寻找一个“省电协议”掩盖失败。弱信号环境本身也可能增加无线通信开销，可在信号稳定的 Wi-Fi 下保持相同配置进行对照。如果只有一个服务器持续重连，保留错误信息后换用自己已有的有效服务器验证。
检查 On Demand 的触发条件是否与当前网络反复冲突。例如网络在多个接入点之间切换，或认证状态不断变化，可能让连接频繁建立与停止。测试期间先记录原条件，暂停自动触发，完成一段手动连接观察；再逐条恢复，找到导致重复动作的条件。不要在未确认自动行为之前频繁强制结束应用，这既不能解释根因，也可能使下一次触发重新开始完整连接流程。
把诊断功能与日常配置分开
排错时开启的详细日志、大范围连接记录或高频测试，不应在没有需求时长期保留。它们可能增加处理与存储活动，尤其在请求很多的情况下。结束排查后恢复适合日常使用的记录级别，关闭自己临时添加的周期性测试，并保留必要的脱敏结果。不要通过批量关闭所有功能来宣称解决耗电，应记录具体停用了哪项功能，以及前后是否能稳定复现差异。
订阅频繁刷新也可能带来额外网络请求，但是否值得调整要看实际触发频率。先确认是不是每次打开都更新、是否存在失败后的重复尝试，再按个人需求降低无效动作。远端 Config 的定时更新与订阅刷新是不同流程，需要分别检查。若配置包含自己不理解的脚本或额外处理，先备份并用简单配置对照，再决定是否保留，避免把未知处理长期带进后台。
建立可比较的观察窗口
在相近的网络和日常任务下，分别观察当前配置与简化配置。保持屏幕亮度、热点状态和下载任务一致，避免一边观看视频、一边比较静置耗电。可先做一个较短的对照，确认没有持续错误，再延长到有代表性的日常使用时段。若设备明显发热或电量下降伴随基础网络异常，应同时检查系统其他后台任务，不要只观察 Shadowrocket。
恢复后检查网络切换、锁屏再唤醒和 On Demand 是否符合需求。仅在前台测试稳定，并不能说明后台状态已经正常。需要提交问题时，提供电池统计所选时间范围、当时的网络、是否持续传输和重复错误类型，隐藏订阅与服务器凭据。若停用客户端后设备仍异常发热或耗电，继续检查系统与硬件状态，避免把独立问题长期归因于代理连接。
08 · 变更与恢复层
更新后异常与配置恢复
先列出同时发生的变更，再分别验证应用、系统、订阅与 Config。
不要把时间相邻当成因果关系
应用更新后第一次连接失败，可能同时发生了系统升级、订阅到期、服务器参数变化或远端 Config 更新。先列出最近改变过的项目，并记录更新前最后一次正常使用的环境。不要仅凭“刚更新”就删除配置；同一时段内的服务端变化也可能造成相同现象。用当前配置在另一网络复测，再使用简单配置验证，通常能更快区分应用启动问题与远端连接问题。
先确认当前启用的 Config 与 SERVER 是否符合预期，检查 Global Routing 是否改变，以及 On Demand 是否重新触发。应用可以正常打开却无法访问时，沿用前面的请求路径检查；应用打不开、系统扩展报错或持续闪退时，先保存可取得的诊断信息，再按系统层恢复。不要在尚未记录错误前连续重装，否则最有价值的现场与手动参数可能一起丢失。
备份的不只是订阅地址
订阅可以重新获取服务端条目，但不一定包含本地手动节点、策略选择、规则修改和其他个性设置。备份前确认内容范围，优先保存自己有权持有的原始资料与 Config 副本。备份文件也可能包含密码、身份字段或订阅凭据，应保存在受保护的位置，不上传到公开空间。只截一张节点名称列表，通常不足以恢复完整参数。
恢复时先导入最基本的一项服务器或一个订阅，验证连接，再恢复 Config 和额外设置。整份备份一次性还原，可能把导致故障的旧设置一起带回。若某项设置恢复后故障立即出现，就保留该项前后的差异继续检查；不要继续导入剩余内容掩盖边界。无法判断的远端配置变更，应与提供该配置的一方核对，不直接删除不理解的字段。
按平台完成受控更新
iPhone / iPad 从指定的App Store 产品页核对应用，开发者为 Shadow Launch Technology Limited，应用 ID 为 932747118，系统要求以 App Store 页面标注为准。Mac、Windows、安卓与 Linux 的 Shadowrocket 安装包从本站全平台下载页获取，实际安装包位于本站 /dl/shadowrocket/ 路径，不从不明提示跳转更新。
安装遇到系统拦截时，先确认文件确实来自本站并符合设备架构。Mac 根据“关于本机”选择 Apple 芯片或 Intel，提示无法验证开发者时在系统“隐私与安全性”中检查“仍要打开”；Windows 的 SmartScreen 可在确认来源后查看“更多信息”与“仍要运行”。安卓按系统提示为当前安装来源允许安装未知应用，完成后可收回权限。组织管理的设备仍须遵守管理员策略。
Linux 应选择与系统匹配的 deb、rpm 或 AppImage；AppImage 运行前需要执行权限。Mac 提示应用已损坏时，在确认来源且应用已放入 Applications 后，可按下载页说明使用下方命令移除隔离属性。这一操作只针对指定应用，不要扩大到整个目录。各平台的完整边界与操作见安装放行说明，不需要为了更新关闭整个系统的安全机制。
xattr -cr /Applications/Shadowrocket.app恢复后再验证原来的失败场景
完成更新或恢复后，不只检查能否打开应用，还要验证连接、订阅刷新、规则命中与网络切换。iPhone / iPad 版在 App Store $2.99 一次性付费，Mac、Windows、安卓、Linux 版免费；客户端获取费用与已有线路服务分别管理，恢复应用不等于恢复服务商账号权限。若最小配置仍可稳定复现异常，保留系统环境、错误原文与操作顺序，再通过应用内提供的支持入口提交脱敏信息。
09 · 平板与网络切换
iPad 专项与交叉验证
平板上的购买记录、配置数据与网络环境，需要分别核对。
已获取应用不等于配置自动出现
iPhone 与 iPad 使用同一购买记录时，应在正确的 App Store 账号下检查已购项目，但购买关系和配置数据是两回事。另一台设备已经有订阅，并不说明当前 iPad 自动具备同一份服务器与 Config。首次在平板使用时，按快速上手教程重新核对导入、Global Routing 与连接授权，不要把空列表理解成应用失效或购买未完成。
iPhone / iPad 版在 App Store $2.99 一次性付费，Mac（Apple 芯片与 Intel）、Windows、安卓、Linux 版免费。客户端一次性买断 ≠ 线路套餐；服务商对账号、设备数或同时连接的限制，需要从你的服务商处确认。若手机正常、平板失败，先检查是否允许同时连接，不要反复购买客户端，也不要把账号权限问题当作 iPad 独有的网络故障。
把“同一个网络”核对到具体接入方式
手机可能正在使用蜂窝网络，而 iPad 连接的是 Wi-Fi，看起来同时访问，实际出口却不同。做交叉测试时，明确两台设备的接入方式、所选 SERVER 和 Config，并尽量使用同一个测试目标。只有这些条件接近，差异才有解释价值。若 iPad 使用手机热点，流量还会经过热点共享与手机的接入网络，不能直接等同于手机自身应用的连接路径。
在校园、酒店或办公 Wi-Fi 上，iPad 可能需要单独完成认证。先断开代理，打开普通页面确认认证状态，再建立连接。若只能访问局域网而不能访问外部目标，检查网络是否尚未完成登录；若外部目标正常而打印机、共享设备失败，检查局域网路由与本地名称解析。不要为了修复一个打印机访问问题，把所有请求永久改为 Direct，应保留范围明确的本地规则。
锁屏、分屏与前后台切换的判断
锁屏后暂时没有新流量，不必然说明隧道断开。重新点亮屏幕时，先观察系统 VPN 状态，再发起一个新的请求，区分连接保持、自动重连与应用自身恢复缓慢。分屏或台前调度改变的是前台应用组织方式，不能只凭 Shadowrocket 不在当前窗口就判断代理停止。若确实只在唤醒后失败，记录当时是否更换了 Wi-Fi、是否触发 On Demand，以及恢复需要哪一步。
仅蜂窝网络型号还需核对系统中相应应用的数据使用权限，以及当前数据套餐是否可用；仅 Wi-Fi 型号则应集中检查无线网络与热点路径。系统版本、设备管理策略和节能设置也可能造成两台设备表现不同。不要直接照抄另一台设备的所有系统设置，先找与症状相关的差异，再做单项修改。系统要求以 App Store 页面标注为准，不用屏幕尺寸推断支持情况。
用交叉矩阵形成可执行结论
| 对照结果 | 优先方向 | 下一步 |
|---|---|---|
| 仅 iPad 失败 | 本机授权、Config、时间与设备限制。 | 用最小配置重新验证。 |
| 两台设备仅在同一 Wi-Fi 失败 | 认证、路由器与当前网络路径。 | 更换接入网络，保持服务器不变。 |
| 同一服务器跨设备跨网络失败 | 服务端状态与参数有效性。 | 向你的服务商核对。 |
迁移配置后若只有部分应用不通，检查是否遗漏自定义策略、手动规则或 DNS 设置。二维码和单节点分享通常不能代表整份 Config，导入成功也不代表规则已经同步。先逐项确认两台设备实际启用的内容，再比较结果；隐藏凭据的截图只能辅助辨认界面，不能代替配置差异检查。涉及敏感数据时，不要为了方便对照而公开完整导出文件。
排查结束前，恢复临时关闭的自动连接条件，删除明确不再需要的测试规则，保留一份已验证的配置与简短记录。记录应写明失败条件、有效处理和仍未解决的边界，而不是只写“重启好了”。若需要继续查阅，连接问题回到本页前两章，订阅问题回到订阅章节，常见操作疑问可阅读新手常见问题。这样下一次出现相同症状时，可以从已有证据继续，而不是重新尝试所有开关。