Shadowrocket故障排查手册

01 / CONNECTION SWITCH

连接开关无法保持

开关点击后立即回落、系统授权没有完成、连接短暂出现后断开，是三种不同现象。先打开 Shadowrocket，停留在 Home，确认当前选择的是一条具备完整参数的服务器，而不只是一个空的订阅分组。记录开关回落前是否出现提示，以及系统设置中对应 VPN 的连接状态。此时不要先更换 DNS 或批量修改规则，因为隧道尚未建立，后面的设置还不足以解释故障。

先确认系统授权与选中项

首次启动连接时，系统可能要求允许添加 VPN 配置，并通过设备解锁方式确认。取消、离开弹窗或未完成确认，都可能使连接无法继续。回到应用重新操作，完整读完系统提示后再决定是否允许。若设备已经保存相关配置，在系统设置中搜索 VPN，核对当前配置是否存在、是否对应本次使用的应用。系统设置入口会随系统变化，以设备实际显示为准，不必套用固定菜单层级。

如果没有出现授权提示，先确认应用没有停留在编辑未保存的页面。回到 Home，重新选择已存在的服务器，再尝试一次连接。只有一条失败记录时，不足以判断配置已经损坏；应同时记录当前网络类型、是否刚从另一张网络切换过来，以及设备时间是否自动设置。时间明显错误会影响后续证书验证，但不要通过关闭证书验证来绕过这个问题。

排除自动连接与配置竞争

临时停用 On Demand，再进行手动开关测试。它的作用是按条件触发连接，若在排查过程中仍持续生效，可能让手动断开后又出现连接，看起来像开关失灵。还应检查设备是否有其他正在工作的 VPN 配置或组织管理的网络策略。只停止自己明确识别且允许调整的连接，不要删除来源不明的管理描述文件；受管理设备应由管理方确认允许使用的网络配置。

接下来保持当前服务器不变，分别在已正常接入互联网的 Wi-Fi 与蜂窝网络上重试。若只在某个需要网页认证的 Wi-Fi 出现问题，先断开 Shadowrocket，完成该网络的登录或使用条款确认，再回到应用连接。若所有网络都在同一阶段失败，而系统授权也已完成，重点转向当前服务器参数、配置解析提示和应用记录，不要把网络切换本身当作修复结果。

最后才重建系统配置

先彻底结束本次连接，再重新打开应用；仍异常时，可重启设备后复测。若明确需要移除并重新添加对应 VPN 配置，先确认已有服务器与配置已妥善保存，并能重新完成授权。移除系统 VPN 项目不等于恢复订阅，也不能修复服务器端故障。不要把重装作为第一步：本地资料未必能自动找回，且重装会抹去有价值的故障现场。

这一章的通过条件是：手动连接时不再立即回落，系统中对应连接状态能够保持，并且没有持续重复授权提示。若仍失败，把“点击后多久回落、弹窗原文、网络类型、是否启用自动连接”写成简短记录。相同的错误在两种网络上重复出现，比一句“开关打不开”更容易定位；涉及购买或安装来源的疑问，可先到正版核验说明核对应用。

02 / CONNECTED BUT OFFLINE

已连接但无法上网

系统显示 VPN 已连接，却不能打开网页时，应把“隧道存在”和“请求成功”分开看。一次网页访问可能依次经历域名解析、规则匹配、服务器连接、目标服务响应，任何一层失败都可能表现为加载转圈。先选定一个平时可以正常访问的页面作为固定测试对象，记录完整错误类型；不要不断更换网站，否则每次测试涉及的目标和访问条件都不同，难以比较。

建立直连与代理两组对照

先断开 Shadowrocket，确认当前网络本身可以访问测试页面。如果断开后仍然失败，应先处理 Wi-Fi 登录、蜂窝数据权限、路由器或目标服务问题。若基础网络正常，再连接并检查 Global Routing。临时测试时，保持服务器不变，只改变这一项；完成测试后恢复原本需要的模式，避免把用于定位的临时状态长期保留下来。

如果 Proxy 可以访问而 Config 不行，优先检查当前启用的 Config、命中规则和对应策略，不要立即认定服务器失效。如果 Direct 可用而 Proxy 失败，则应转向所选服务器、协议参数及代理路径。注意，连接状态下的 Direct 测试与完全断开应用并不等同：解析设置等条件可能仍有差异，因此它只是辅助证据，不能替代基础网络测试。

检查真正命中的规则

确认 Config 列表中实际启用的是预期文件，而不是刚导入但未选中的另一份。规则通常按顺序匹配，较早命中的条目会影响后续处理；因此只在文件末尾追加规则，未必能改变已有匹配结果。查看请求记录时，应同时核对目标域名、命中规则与最终策略。若配置使用策略组，还要查看组内当前选择，组名正确并不等于组内指向了可用服务器。

下面是用于理解顺序的精简规则片段，不是完整配置，也不应直接覆盖正在使用的文件。第一条只匹配示例域名，第二条处理指定私有地址范围，最后一条作为未命中前项时的收尾策略。实际排查应在备份副本中做最小修改，并确认该修改确实处在当前启用的配置里。

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

区分全部失败与单个服务失败

若所有页面都失败，先查公共路径：服务器、解析和默认策略；若只有一个服务异常，再查该服务的域名、登录状态、目标端限制及其使用的其他连接。一个页面可能访问多个域名，首页成功不代表其中的图片、登录接口或媒体请求也走了同一路径。不要仅凭页面主体能显示，就认定规则已经全部正确。

每轮测试都应重新建立目标连接，必要时关闭对应页面再打开，减少旧连接复用造成的误判。恢复正常的标准是目标页面及关键功能均可用，记录中的策略与预期一致，而且再次测试仍能复现成功。若现象只在某个应用里发生，检查该应用自己的联网权限与缓存，再查 Shadowrocket；常见概念可对照常见问题，避免把应用登录错误归为连接故障。

03 / SERVER TIMEOUT

节点超时与协议参数

Connectivity Test 的结果应结合测试方式阅读。超时表示本次测试没有在限定条件下获得预期响应，不等于已经证明服务器永久不可用；能测出响应，也不等于真实网页访问一定成功。先保留测试方式与错误提示，再使用同一条服务器进行实际请求。若测试成功但业务失败，继续检查目标、规则和解析；若二者都失败，再逐项核对服务器入口与协议参数。

从地址、端口和认证开始

打开对应条目的编辑页，将地址、端口和协议类型与自己的原始服务器资料逐项比较。地址栏不应混入不属于该字段的路径或多余空格，端口应与服务端实际监听端口一致。通过订阅导入的条目也可能因链接过期或资料变更而陈旧；先确认原始资料是否仍有效，而不是反复修改客户端直到偶然出现一次成功。

认证字段应完整对应当前协议。Shadowsocks 需要匹配加密方法与密码；VMess、VLESS 等需要核对用户标识及服务端要求的传输设置；Trojan 应核对密码和安全连接相关参数。不同协议中看起来相似的字段，不能直接互相套用。复制时注意全角符号、换行和首尾空格，但不要把完整认证内容发给他人，请用字段是否一致来描述结果。

把 TLS 与传输错误分开

服务器地址、TLS 使用的名称以及传输所需的主机字段可能不同，但它们必须来自你的服务器资料，而不是靠猜测填写。出现证书错误时先校正设备时间，并核对名称和服务端证书状态。不要将跳过验证作为常规修复方案；这样即便暂时改变了报错，也没有解决身份验证不匹配的根因，还会降低安全连接的可靠性。

若服务端使用特定传输类型，客户端的路径、主机字段及相关开关必须与之对应。一个字段缺失就可能让入口可以建立连接，但后续握手失败。先恢复为原始资料中的参数再测，不要同时尝试多种路径和多个安全选项。错误由超时变成明确的认证或握手提示，也是一项有效进展：它说明失败所处的阶段发生了变化。

判断网络路径与服务器端边界

在保持条目不变的情况下更换网络，若只在其中一种网络失败，应记录网络类型与协议传输特征。部分协议依赖 UDP，某些网络对此类流量的处理不同，但不能仅凭一次失败就确认原因。Hysteria2 的背景可阅读Hysteria2 协议基础；排查时仍以实际错误和可重复的网络对照为依据。

如果你自己的其他有效条目在同一网络正常，而当前条目在多种网络均失败，应向原有服务方核实服务器监听、认证和服务状态。仅有客户端记录时，无法直接确定远端进程是否运行，也无法修复服务端配置。反馈时提供脱敏后的失败阶段、发生条件与测试结果即可，不需要公开订阅全文。修复后用真实请求复测，并确认重连仍然成功，避免将偶发测试通过误当作已经恢复。

04 / SUBSCRIBE

订阅导入与更新失败

订阅更新通常包含获取链接内容、识别格式和替换本地条目几个阶段。无法获取、内容无法识别、更新成功但服务器不可用，分别属于不同问题。先看提示属于哪一类，再处理对应阶段。用户已有的订阅链接应来自自己的原始资料；订阅是配置数据的入口，不是应用购买凭证，更新订阅也不是更新 Shadowrocket 应用，二者需要分开操作。

核对链接而不公开凭据

检查 Subscribe 条目中的地址是否完整，尤其是问号后的参数。某些分享方式会把链接截断，或者在末尾附加中文标点、说明文字和换行。应从原始来源重新复制，与当前保存内容逐段比较。不要只检查域名相同就认为地址一致，路径或参数改变也可能指向完全不同的内容。以下地址仅展示结构，不可作为实际服务使用，也不是可点击的获取入口。

https://example.com/sub?token=xxxx

完整订阅链接可能具备访问权限，处理它时应像处理密码一样谨慎。不要提交到陌生的转换页面，也不要在反馈截图中展示。若需要确认链接是否过期，可查看你自己的服务管理页面或联系原有服务方。重新复制链接之后，先更新现有订阅并核对结果，不要连续创建多个同名分组，否则后续很难分辨当前选中的是旧数据还是新数据。

按获取、格式、条目三层定位

获取阶段失败时，检查当前基础网络、域名解析以及链接的访问条件。某些链接需要在特定网络路径下才能到达；此时应记录更新发生在断开状态还是连接状态，并保持其他条件不变做对照。网页能打开一个登录页面，不代表订阅接口能返回应用需要的内容。如果实际返回的是网页、错误说明或身份验证页面，继续重试通常不会使它自动变成服务器列表。

格式无法识别时，应确认复制的是订阅地址，而不是管理面板地址或某个网页分享地址。不要随意修改返回内容的编码或删除看不懂的字段；先确认原有服务方提供的格式是否适用于 Shadowrocket。若能够导入但只有部分条目出现，可能与数据格式、条目有效性或参数识别有关，应保留旧数据并逐项比对，而不是直接删除整个分组。

更新成功后检查选择与引用

更新可能使服务器名称、分组内容或可选条目发生变化。当前选择若引用了已经移除的条目，表现可能像“更新以后不能用”。回到 Home 检查当前选中项，再查看 Config 中是否存在按名称引用的策略或分组。先用更新后的有效条目完成直接测试，之后再恢复复杂规则，这样能够把数据变化与规则引用错误分开。

手动更新稳定后，再考虑打开应用时自动更新等设置。自动更新并不保证每一次打开都能取得新数据；它同样受网络、链接有效期和返回内容影响。频繁重复更新还可能触发原有服务的请求限制，应遵循对方给出的刷新要求，失败时保留提示并等待合理间隔，不要用连续点击代替诊断。详细操作可对照订阅更新教程。

本章的验收应包含一次完整闭环：保存正确链接、完成手动更新、确认条目变化、重新选择服务器并实际访问目标。若旧条目仍然工作而更新失败，可先保留可用状态，再排查更新入口；若更新正常但所有连接失败，转到节点超时章节。反馈时描述“获取失败”“识别失败”或“更新后连接失败”，比只说“订阅坏了”更有助于定位。

05 / PERFORMANCE

速度慢与连接不稳定

速度慢可能指首个页面打开慢、持续传输慢、视频间歇停顿，也可能指 Wi-Fi 切换后短暂失去连接。这些现象不应混为一谈。先用一句话定义症状，例如“每次首次打开等待较久，但开始传输后正常”，再选择对应检查方向。响应时间、吞吐能力和稳定性是不同指标，不能用一次 Connectivity Test 的结果概括全部体验。

建立可以比较的测试条件

固定设备、网络、服务器和目标内容，关闭正在进行的大量后台传输，再重复相同操作。基础网络测试应先在断开 Shadowrocket 后完成；若此时也慢，应优先检查信号、路由器负载及网络本身。比较不同时间段时要记录条件变化，因为目标服务和远端路径的负载也会变化。不要把两个不同网站在不同时间的表现直接用来评价同一条服务器。

如果只在 Wi-Fi 慢，靠近接入点复测，并检查设备是否在弱信号或拥挤环境下工作。若蜂窝网络稳定而同一 Wi-Fi 频繁中断，应先缩小到接入网络这一层；反之则检查蜂窝信号、设备数据设置和网络切换时机。不要一开始就重置所有网络设置，这会改变太多条件，并可能清除已有网络信息，让后续比较失去依据。

按等待发生的阶段分支

首次打开慢而后续正常，优先观察解析与连接建立过程。若每一个新域名都等待，而同一页面刷新较快，可能与 DNS 或初次握手有关；但缓存也会造成类似差异，需要多次验证。若页面迅速开始加载，但大文件持续传输不稳定，应关注链路丢包、远端负载、目标限速以及本地同时运行的流量，而不是只调整解析设置。

当只有一个应用慢，先看它实际请求的目标及规则命中。媒体、图片和登录接口可能使用不同域名，某个环节落到不同策略会使整体体验不一致。切换 Global Routing 做短时对照时，应重建目标连接，避免旧会话继续沿用原来的路径。若 Proxy 稳定而 Config 波动，检查策略组是否自动切换，以及同一业务的不同域名是否被分到不同出口。

使用统计辅助，不把读数当结论

Data 可以帮助观察流量发生在哪些服务器或应用相关视角中，但统计范围、连接复用和系统行为会影响读数。它适合验证“请求是否经过了预期位置”，不适合仅凭一个数字确定远端带宽。具体含义可参考Data 页统计解读。记录流量时应同时记下测试窗口，避免把先前连接留下的累计值当成本轮结果。

协议参数不应因为“可能更快”而随意改动。服务端要求的传输方式、加密方法和安全设置首先必须匹配。特别是涉及 UDP 的协议，应结合当前网络能否稳定承载相关流量判断，不存在适用于所有网络的固定最优选项。若只有特定协议在某网络反复失败，应保留相同网络下其他有效连接的对照结果，再向原有服务方核实。

最终应在真实使用场景中验收，例如连续浏览同类页面、完成一次实际文件传输，或在网络切换后重新访问。测试成功不能只靠某一瞬间的高读数，还应确认重复操作没有明显卡顿。若问题集中在特定时段或目标，保留时段与目标类别即可，不要无限增加客户端设置。已经定位到远端或基础网络的限制后，继续修改本地规则通常不能改善根因。

06 / DNS AND ROUTING

DNS 解析与规则路径

DNS 负责把域名转换为可连接的地址，但域名能解析不代表地址可达，地址可达也不代表安全连接和应用请求一定成功。常见现象包括域名解析错误、首次访问等待、只有某些域名失败，以及规则得到意外结果。先记录错误是否明确涉及解析，再检查当前启用的配置与 DNS 设置来源，不要把所有无法打开网页的情况都归为 DNS 故障。

确认当前生效的解析来源

查看当前 Config 与相关 DNS 设置，确认使用的是系统解析、自定义解析，还是包含 DNS over HTTPS 的方案。不要只看刚编辑的文件，还要确认该文件确实已启用。配置中若存在多处解析设置，应先弄清覆盖关系，再做修改；同时检查设备上是否有组织管理的解析配置。不同来源叠加时，表面上只改了一项，实际请求路径却可能没有改变。

先保存原始设置，再用最简单且已经确认可工作的解析方式建立基线。DNS over HTTPS 需要访问其服务端点，因此它自身也依赖可用的连接与正确的名称验证。若把解析服务的到达路径安排在一条尚未建立的代理路径上，可能形成相互依赖。不要为了解决一个域名失败就连续叠加多个解析地址，否则超时与回退过程会更难观察。

区分域名规则与地址规则

DOMAIN、DOMAIN-SUFFIX 等规则基于域名信息匹配，IP-CIDR、IP-CIDR6、GEOIP 等涉及地址匹配；两类条件的使用时机不同。某条地址规则生效，不代表前面的域名规则写对了；反过来，域名规则命中也不保证最终得到的地址适合当前路径。先通过请求记录核实实际命中，再判断是解析结果问题，还是规则把请求送到了不合适的策略。

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

这段示例只用于说明规则类型和顺序，不代表适合所有环境。精确域名规则与后缀规则在这里存在覆盖关系，实际配置应只保留确有需要的条目。FINAL 是收尾策略，不是修复解析的开关。排查时可以在副本中缩减到与目标有关的最少规则，先观察目标走向，再逐条恢复原配置；每恢复一组就重新测试，便于定位冲突。

避免用不等价测试得出结论

直接在浏览器输入某个地址，不能简单替代原域名访问。安全连接通常需要正确的主机名称，网站也可能依赖该名称区分服务；因此“输入地址失败”并不能单独证明网络不通。也不要把其他设备查到的解析结果长期写进配置，远端地址可能变化，且不同网络得到的可用路径可能不同。优先检查实际请求中的错误与解析记录。

修改 DNS 后，旧连接和缓存可能仍然影响结果。先断开并重新连接，再关闭目标页面后重试；必要时重启对应应用。不要在一次页面刷新没有变化时立即认定修改无效，也不要不断清除全机设置。若只有某一个域名失败，核实域名拼写、目标服务状态以及其他网络上的表现；若全部域名失败，再查解析服务可达性和配置来源。

涉及局域网名称、设备发现或单位内部域名时，还要考虑它们是否只能通过当前网络提供的解析方式获得结果。把所有解析统一交给另一条路径，可能使外部网页正常却无法访问内部服务。应针对需求设计最小例外，而不是关闭全部规则。系统 DNS、自定义 DNS 与 DNS over HTTPS 的区别，可继续阅读DNS 设置对照，然后回到本章按同一目标验证。

07 / BATTERY AND BACKGROUND

耗电异常与后台连接

耗电排查应先区分持续传输、反复重连和单纯保持连接。系统电池页面中的应用占比是某个统计区间内的相对值，不等于某个开关必然消耗了固定电量；不同区间的屏幕使用、信号质量和后台活动都会影响它。先记下异常出现的时段、设备是否发热、是否刚完成大量同步，再判断 Shadowrocket 的连接行为是否与耗电同时发生。

建立同条件下的观察窗口

选择相近的使用方式，分别记录连接开启与关闭时的设备状态。比较时尽量保持屏幕亮度、网络、后台任务和使用时长一致；不要拿待机状态与持续观看媒体直接对照。如果断开后设备仍明显发热，应检查系统更新后的处理、照片同步、大量文件传输等其他活动。VPN 连接承载了流量，并不意味着流量的源头一定是代理客户端本身。

查看 Data 与请求记录，确认空闲时是否仍有持续大量请求，或同一目标在短时间内反复失败。自动刷新页面、云端同步和其他应用的后台任务，都可能让连接持续工作。先识别业务来源，再决定是否调整该应用的后台行为；不要为了降低统计占比而直接删除正在使用的配置，这样会失去对实际流量路径的判断依据。

处理反复重连而不是隐藏现象

若记录显示连接不断建立又中断，先检查网络信号和当前服务器稳定性。弱信号环境中的重试不仅影响体验，也会增加设备工作量。保持配置不变，在稳定 Wi-Fi 下观察；若恢复正常，再检查原网络的信号与切换行为。若多种网络都重复断连，则按节点超时章节核对认证、传输与远端状态，不要把它仅仅归为电池问题。

On Demand 可能在条件满足时重新触发连接，因此手动断开后又出现连接不一定是异常。需要对照测试时，先暂时停用相关自动连接条件，并记录原设置，结束后再恢复。若条件设计在两个状态间来回变化，可能导致频繁触发；应明确希望在哪类网络连接、在哪类网络保持断开，而不是同时保留互相矛盾的条件。

缩减诊断开销与无效请求

详细记录适合短期定位，不宜在问题已经解决后继续保留不必要的高强度诊断。若此前主动打开了额外记录或频繁测试，应在取得证据后恢复正常使用状态。也要检查订阅自动更新、策略测试和用户自行设置的定时行为是否过于频繁；这些操作的价值在于获得必要信息，不是刷新越密集就越稳定。

如果设备在锁屏后仍有业务传输，系统保持必要连接可能属于正常行为；如果没有预期业务，却持续出现大量失败请求，则应查找请求来源或错误的重试循环。一次失败后的少量重连不等同于持续异常，必须结合观察窗口判断。不要根据某个瞬间的温度或电量跳变，得出应用长期耗电的结论。

完成调整后，应在与基线相同的网络和使用条件下再观察一轮，确认重连次数减少、异常请求停止，同时实际访问仍然正常。若客户端关闭后相同耗电仍持续，问题范围应转向系统或其他业务。向支持方反馈时，可以提供统计区间、屏幕使用情况、网络类型和脱敏后的活动特征；无需提供完整浏览记录，也不要公开包含认证信息的配置。

08 / CHANGE AND RECOVERY

更新后异常与配置恢复

“更新后不能用”首先要说清更新了什么：App Store 中的应用、系统、订阅内容，还是 Config 文件。这些变化可能恰好发生在同一天，但影响层次不同。应用更新不会自动修复过期订阅，订阅更新也不代表规则引用仍然有效。先把最后一次正常使用到首次异常之间的变化列出来，只记录实际发生的操作，不凭时间接近就认定某项变化必然是原因。

先保留现场，再建立最小配置

在继续修改前，保存当前配置副本、所选服务器名称和 Global Routing 状态。备份文件本身可能含有敏感信息，应存放在你能控制的位置。已有备份时，也要确认它对应的是哪个时间点、包含哪些内容；服务器列表、规则文件与系统 VPN 授权并不是同一种资料。不要假定备份了其中一项，就一定可以恢复完整工作状态。

先重启应用并重新建立连接，确认异常仍然存在。然后保持当前有效服务器不变，使用简化路径测试实际访问；若 Proxy 正常而原 Config 失败，重点检查配置解析、规则顺序与策略组引用。若所有路径都失败，再查服务器、授权和基础网络。最小测试的目的，是减少变量，不是建立一份长期替代所有需求的新配置。

按变更类型分别回查

订阅更新后异常，应先确认当前选中项是否仍在更新后的列表中，原策略组是否引用了已经变更的名称。Config 更新后异常，应检查导入提示、启用文件和收尾规则，确认新文件没有被保存成另一份未启用的副本。若配置来自你自己的既有来源，可保留新旧两份对照；每次只恢复一部分设置，避免把损坏内容整份覆盖回去。

应用或系统更新后异常，先核对系统中的 VPN 授权是否仍可正常工作，以及设备是否正在进行其他更新后处理。不要看到一次连接失败就立即清除全部网络设置。若能稳定复现，记录具体步骤和错误原文，并在 App Store 页面查看当前应用说明及相关信息。应用获取与更新均通过 App Store，来源核对可参阅正版获取页。

恢复时逐项验证，而非一次覆盖

使用备份恢复时，先确认备份里的服务器信息仍然有效。旧配置即使语法正确，其中的地址、认证或引用也可能已经变化。建议先恢复必要服务器并测试，再恢复核心规则，最后恢复自动连接和其他可选行为。每一步成功后都记录状态；若下一步失败，就能把范围缩小到刚恢复的内容，而不必从头猜测所有设置。

只有在保存了必要资料、理解恢复步骤且普通排查无法继续时，才考虑重装。重装不能修复远端服务器失效，也不能让已经过期的链接重新有效。已购恢复与本地配置恢复应分别处理：前者关系到 App Store 购买记录，后者依赖你自己的备份。不要把重新取得应用误认为所有本地配置会自动回来。

若问题仍存在，应整理一个最小复现说明：设备类型、网络类型、最后一次正常状态、发生过的变化，以及简化配置后的结果。删除其中的凭据和不相关历史，不要发送整份日常流量记录。成功恢复的标准应包括重新打开应用、切换网络后再连接、目标业务正常，以及自动连接条件符合预期；只在当前会话暂时可用，还不足以说明恢复已经完成。

09 / IPAD CHECKLIST

iPad 专项检查与验收

iPad 的基本连接链路与 iPhone 相同，但使用场景常涉及大屏多任务、不同 Wi-Fi、局域网设备和跨设备迁移。遇到问题时，不要直接照搬另一台设备的结论；同一份订阅在另一台设备可用，只能说明部分条件可能正常，不能证明本机已启用相同配置。系统要求、兼容性与购买适用性均以 App Store 页面标注为准，不根据设备外观推断支持情况。

把应用获取与配置迁移分开

先确认 iPad 上安装的是正确的 Shadowrocket。正版核验应检查开发者 Shadow Launch Technology Limited、官方图标与应用 ID 932747118；具体入口见iPad 获取说明。能从购买记录取得应用，并不代表另一台设备的订阅、当前选择、规则和自动连接条件已经同步过来。迁移后必须逐项核对，不要把空列表误认为购买没有生效。

若使用自己的备份导入配置，先确认文件完整，并检查本机实际启用项。某个服务器名称出现在列表里，不代表当前已经选中它；某个 Config 已经导入，也不代表已经启用。建议在 iPad 上重新完成一次基础流程：选择有效条目、手动连接、访问固定目标，再恢复规则和自动连接。首次授权仍应在本机完成，不能以其他设备已授权替代。

检查本机网络与权限差异

部分 iPad 只有 Wi-Fi 连接，排查时不一定具备蜂窝网络对照条件。可以在你有权使用的另一张网络上测试，但应先确认该网络本身可用。连接校园、单位或公共 Wi-Fi 时，先断开 Shadowrocket 完成必要的网页认证；受管理设备还可能有组织设置，应向管理方确认，而不是自行移除相关配置。

如果网页正常而局域网设备不可达，检查目标地址是否属于当前局域网，以及相关应用是否具备需要的本地网络权限。打印、投屏和设备发现不一定只依赖普通网页请求，不能通过一个外部页面的访问结果替代测试。确认规则中是否对相应私有地址安排了合适路径；但仅添加一条地址规则，也未必涵盖发现机制和设备自身的权限要求。

处理多任务与网络切换

使用分屏或切换应用后出现异常，应先回到 Shadowrocket 查看实际连接状态，而不是依据之前留下的页面画面判断。页面可能保留旧内容，目标应用也可能复用已有会话。重新发起一个请求，观察记录是否出现，并核对策略；若没有新请求，检查目标应用自身是否仍在加载、是否被暂停，避免把业务没有发起误判为代理没有转发。

锁屏唤醒、切换 Wi-Fi 或离开接入点后短暂失败，应等待网络本身稳定，再尝试重建目标连接。若每次唤醒都重复断连，记录是否启用 On Demand、原网络是否需要再次认证，以及同一网络上的基础访问是否正常。临时停用自动连接做一次手动对照后，应恢复原条件，不能为了排查而长期保留不符合使用需求的状态。

完成本机闭环再恢复日常使用

先用 Safari 中固定的测试页面验证基础访问，再测试真正遇到问题的应用，最后验证局域网或多任务场景。每一步都记录成功条件；若某一类业务失败，就保留前面已通过的基线继续排查，不要重新调整所有项目。需要查看概念时可查术语手册，需要重新走完整操作主线时回到快速上手教程。

最终验收包含本机重新打开应用、手动重连、实际业务访问，以及常用网络切换后的再次访问。若只有这台 iPad 失败，保留本机授权、网络、配置和权限方面的差异记录；若自己的多台设备在相同服务器上同时失败，应把检查重点转向服务器或订阅状态。按这一顺序收拢证据，可以减少重复导入和反复重装，也能让后续反馈明确落在可处理的故障层。