Shadowrocket 故障排查

01 / VPN 配置与连接状态

连接开关打不开或立即断开

先区分未获授权和连接后退出

在 Home 打开连接开关后，先观察系统是否出现添加 VPN 配置的请求，以及开关是在授权前没有变化，还是短暂连接后回到 Not Connected。这两类现象对应不同层次：前者应检查系统授权，后者还要检查当前配置能否启动。不要先删除服务器列表。把发生时间、所用网络和屏幕上的完整提示记下来，能够避免把一次没有确认的系统请求误判为节点故障，也便于后续复现。

首次允许添加 VPN 配置时，应在系统弹窗中确认，再按设备要求完成身份验证。若之前取消过请求，返回 Shadowrocket 重新操作，留意应用是否仍在前台。随后到系统 Settings 中搜索 VPN，确认是否存在对应配置，以及是否有其他连接处于活动状态。菜单位置会随系统变化，以设备实际显示为准；受管理设备还可能由组织策略限制修改，此时应先向设备管理员确认权限边界。

按最小变更恢复连接环境

先关闭当前连接，再检查其他已启用的 VPN 或网络过滤功能，避免多个功能争用同一连接环境。一次只暂停一项，测试结束后恢复原状态。若在家中 Wi-Fi 能连接、在另一网络不能连接，应继续检查该网络是否需要网页认证。公共网络的登录页未完成时，连接请求可能始终失败；先在断开状态完成网络登录，再重新尝试，不能把登录页打不开直接归为配置损坏。

确认已有一个字段完整的服务器记录，并检查当前选中项是否仍然存在。订阅更新或删除分组后，先前的选择可能已经变化。若应用明确提示配置字段错误，应沿提示检查最近修改的文件，而不是连续点击开关。把新增的规则、重写或其他可选设置暂时撤回到备份状态，保留基础连接条件。这样能判断故障来自启动配置还是远端连接，同时避免把原本正常的参数一并改乱。

如果系统里保留了旧的 Shadowrocket VPN 配置，可以在完成应用内配置备份后，先停止连接，再移除对应的系统 VPN 配置，回到应用重新触发授权。这里只处理系统连接记录，不等于恢复订阅内容，也不保证能够找回本地数据。不要把删除应用当作第一步；没有备份时，重新安装可能使原有服务器、规则和诊断线索一起丢失，反而让排查失去对照。

开关被自动改回时检查触发条件

如果手动关闭后又自动连接，或切换网络时状态立即变化，检查 On Demand 是否启用。它依据已配置条件工作，不应与手动开关的单次操作混为一谈。为了建立基线，可记录条件后暂时停用，再分别测试一次手动连接与断开。若状态稳定，按条件逐项恢复，特别留意指定无线网络、蜂窝网络与域名触发之间是否存在相反动作。具体条件说明见On Demand 设置文章。

03 / 服务器与协议握手

节点超时与连接被重置

把测试结果和业务访问分开

Connectivity Test 的结果是指定测试方法与测试目标下的一次观测。出现超时，可能是服务器不可达、测试目标不响应、协议握手失败，也可能是当前网络对相关传输有影响。先查看实际使用的测试方式和目标设置，再用真实网页请求作对照。一次测试失败不能单独证明已有服务器失效；反过来，测试出现数值也不能证明登录、视频或其他业务都能正常完成，两种结果回答的问题并不相同。

先确认服务器地址和端口来自用户已有的有效信息，检查复制时是否混入空格、换行或中文标点。地址字段通常应填写主机名或地址本身，不应误填整条订阅链接。还要区分连接地址、TLS 的服务器名称以及传输层的 Host：它们在某些配置中可以不同，但必须与服务端约定一致。不要为了“看起来统一”把三个字段改成同一值，否则可能把原本正确的路由或证书验证条件破坏。

按协议核对成组参数

核对参数时按一整条记录与原始信息比较，而不是从不同记录中拼接字段。传输方式、路径、Host 和 TLS 的组合通常存在依赖：只改其中一项，连接可能在建立后立即被关闭。对于从已有订阅导入的记录，优先重新核对订阅中的对应项，再判断是否需要手动编辑。VMess 等术语的含义可查术语手册，这里的表格只是排查顺序，不是完整的协议配置清单。

证书相关错误还应检查设备日期与时间是否准确，系统是否存在尚未完成的网络认证，以及服务器名称是否正确。不要把关闭证书验证当成通用修复；这样可能掩盖地址填错、证书过期或名称不匹配的问题。若已有信息要求使用特定名称，应向原信息来源核实准确值。确认设备时间和名称后仍报错，保留错误类别与发生网络，交由服务器维护方检查证书链和服务端监听状态。

用网络对照缩小远端问题

在条件允许且不会产生意外流量费用时，保持同一服务器、同一测试目标，仅在 Wi-Fi 与蜂窝网络之间切换。如果只在某一网络超时，问题更可能与该网络的解析、传输限制或路径有关；如果多个网络都失败，应继续检查远端服务状态与认证信息。部分协议依赖 UDP，网页能直连并不意味着该传输一定可用。不要在没有依据时随意修改端口或传输方式，它们需要服务端配合。

若用户已有多个可用记录，可用另一个已知正常记录做单次对照，但不能据此评价整组服务质量。连续批量测试可能增加噪声，让暂时拥塞与真实配置错误混在一起。完成排查后，向服务器维护方提供协议类型、出错阶段、网络类型和脱敏提示即可；密码、完整标识和订阅地址不应出现在公开截图里。若认证已成功但仅特定目标失败，应回到规则与 DNS 章节，而不是继续反复重填认证字段。

05 / 吞吐、延迟与目标差异

连接正常但速度慢

先把“慢”变成可比较的现象

速度慢至少包含页面首次打开等待长、持续传输吞吐低、视频反复缓冲，以及交互请求偶尔卡住几种现象。它们不一定有共同原因。先记录具体应用、目标域名、网络类型和发生阶段，再用相同目标重复少量测试。Connectivity Test 的数值主要反映其测试条件下的结果，不等同于业务吞吐；一个测试响应较快的记录，也可能在目标服务路径上拥塞，因此不能仅按单项测试结果确定日常选择。

先断开连接检查基础网络的稳定性，留意 Wi-Fi 信号、路由器负载，以及是否有其他设备同时进行大量传输。蜂窝网络还受到信号、所处位置和网络切换影响。测试期间保持设备位置与网络不变，暂停会明显占用带宽的同步任务。若基础网络本身波动很大，应先恢复稳定环境，再评估代理路径；否则每次结果的差异可能只是无线条件变化，与刚修改的配置没有因果关系。

区分解析等待和持续传输问题

如果首次打开某个域名很慢，页面开始加载后却能持续传输，优先检查 DNS 与连接建立阶段。若所有页面都能很快出现文字，但图片和视频持续缓慢，则更值得检查目标路径、远端负载和实际分流结果。用不同类型页面作对照时，应明确它们内容大小并不相同，不要把某个轻量页面打开快当成全部恢复。浏览器缓存也会改变观感，复测应注明是否是首次请求或已缓存内容。

在 Config 下检查慢请求是否走了预期策略。某些页面同时访问多个域名，主站走 PROXY 而资源域名走 DIRECT 时，可能出现正文已显示、图片一直等待的混合现象。应从实际请求记录找出失败的资源域名，再判断是否需要补充规则，而不是为了方便扩大 DOMAIN-KEYWORD 的范围。规则过宽会影响无关目标，增加路径绕行。指定网站的写法可参考DOMAIN-SUFFIX 与 FINAL 示例。

若 Proxy 与 Config 都慢，保持测试目标一致，比较同一网络下用户已有的另一个有效记录。结果只能说明本次路径存在差异，不能直接推导长期质量。服务器负载、目标服务限速和跨网络路径都可能随时间变化。连续运行大流量测试会额外消耗数据并影响其他请求，宜在有限次数内收集足够信息。需要持续测量时，应先确认自己的流量条件，避免排查本身成为新的带宽占用。

不要用随机参数修改代替证据

连接长时间停顿、部分大内容失败而小请求正常时，可以进一步检查路径与传输相关条件，但不宜盲目调整 MTU、并发或协议参数。这些参数存在网络与服务端约束，改小或改大都可能带来副作用。先保留默认或已知正常值，记录问题是否只发生在特定网络。只有取得明确的错误线索或维护方给出适配值时，才进行单项对照，并保留原值以便立即恢复，不能照抄不相关场景中的设置。

设备发热、低电量状态、后台同步和目标应用自身解码，也可能让“页面卡顿”看起来像网络变慢。可用另一个应用访问相近类型内容，对照是网络等待还是界面操作迟缓。若单个目标始终慢、其他目标正常，应同时考虑目标服务状态，避免无限修改客户端。完成修复后，验证常用页面、持续传输与网络切换三个场景，确认改善不是短时缓存造成，再恢复日常配置与原有后台任务。

07 / 活动时间与重复连接

耗电增加与设备发热

先确认耗电比较条件一致

系统电池页面显示的应用占比，是所选时间范围内的统计结果，不等于该应用在所有情境下的固定耗电。使用时间、前台亮屏、网络条件和其他应用活动都会改变占比。先比较相近使用强度与相同网络下的时间段，查看是否伴随大量数据传输、反复连接或设备持续发热。仅看到占比变高，不能直接判断发生异常；其他应用使用减少，也会让同一活动在总量中的比例上升。

记录耗电是否始于某次配置修改、订阅更新、网络切换或应用更新，并区分屏幕开启和待机状态。待机期间持续有网络活动时，先考虑照片同步、文件传输、影音播放等任务是否正在通过连接。客户端处理其他应用的数据会产生工作负载，但真正的流量来源可能是后台任务。检查时先暂停明确的大流量活动，再观察连接是否稳定，不要只根据一个统计名称推断全部耗电来源。

检查 On Demand 与网络反复切换

弱 Wi-Fi 与蜂窝网络来回切换，可能触发重复握手与恢复连接。若 On Demand 规则在两个网络上配置了不同动作，切换时还会进一步改变状态。先在信号稳定的位置保留一个网络进行对照，记录自动触发条件后暂时停用，再观察待机活动是否明显变化。测试结束后恢复需要的规则。不要为了降低耗电永久移除自己依赖的连接条件，先找到真正导致重复触发的网络或规则组合。

如果服务器认证持续失败，或远端连接反复被关闭，设备可能不断尝试恢复。应先按节点超时章节解决错误，再评价耗电表现。仅把屏幕锁定不会让不正确的认证条件自行恢复。观察记录中是否短时间反复出现同类错误，以及是否总在切换网络后发生；有规律的重试比单次电量变化更能说明问题。必要时停止当前连接，避免在没有成功可能的条件下持续重试，并保留一段脱敏记录。

减少排查本身造成的额外活动

批量 Connectivity Test、频繁自动更新订阅和持续详细记录，都可能增加排查期间的网络与处理活动。只在需要时启用足够定位问题的诊断级别，取得线索后恢复日常设置。不要为了观察耗电把多个测试循环同时运行，也不要连续刷新大量目标页面。若关闭这些临时任务后恢复正常，应先调整测试频率，而不是改动原本能稳定工作的协议参数；诊断负载与日常连接负载需要分开评价。

设备发热还会影响性能，让网络页面表现出卡顿。应在停止大流量任务、设备回到正常温度后再进行对照。充电状态、屏幕亮度和当前环境温度也会影响观察，因此比较时尽量保持一致。不要仅凭外壳温度认定具体组件损坏。若断开连接后仍持续异常，应检查系统电池页面中的其他活动，并按设备系统提供的说明处理，不能把所有设备耗电问题都归到某一个网络配置上。

恢复验证至少覆盖一次正常使用和一段相近条件的待机观察。成功标准不是占比必须降到某个固定数字，而是重复重连已停止、后台任务符合预期、相同使用方式下不再出现异常发热。反馈时提供统计时间范围、网络类型、是否启用 On Demand，以及是否运行过大量测试。不要公开完整流量记录，因为其中可能包含访问域名、服务器信息或私人活动；可先保留与异常时间相邻的必要片段。

09 / iPad 网络与多任务场景

iPad 连接与恢复专项

把购买恢复和配置迁移分开

在 iPad 上恢复使用时，先确认 App Store 中登录的是拥有相应购买记录的账号，再按iPad 获取说明处理。系统要求与购买兼容性以 App Store 页面标注为准。应用能够重新取得，不代表旧设备的服务器和 Config 已自动出现在新设备上；购买记录与用户配置是两件事。首次打开后应逐项确认已有订阅、服务器信息与文件是否完整，而不是直接打开开关后凭连接失败判断恢复过程出错。

从其他设备迁移配置时，应使用自己保存的有效备份或已有信息重新导入，并核对所选服务器、Global Routing 和当前 Config。相同的分组名称不代表内容完全相同，尤其要检查地址、认证参数和规则末尾的 FINAL。若导入只完成了服务器列表，没有相应规则文件，Config 下的表现可能与旧设备不同。先按照快速上手建立基础连接，再恢复复杂规则，比一次迁入所有可选设置更容易定位缺失项。

多窗口不是多个独立连接环境

iPad 的分屏与多窗口便于同时查看手册和应用，但系统网络连接状态仍需统一理解。切换窗口、调整窗口大小或返回主屏幕，不应被当成新建一套独立 VPN 会话。诊断时固定一个浏览器窗口和一个测试目标，避免另一窗口仍显示缓存页面而造成矛盾印象。若一个窗口正常、另一个失败，先比较它们访问的域名、登录状态与是否真的刷新，再查请求记录，不要仅按窗口差异推断路由规则失效。

部分 iPad 只有 Wi-Fi，另一些还支持蜂窝网络。对没有蜂窝网络的设备，可在自己有权使用的另一无线网络上做对照，但要注意通过个人热点接入时，上游网络本身也可能变化。保持服务器与测试目标不变，注明使用的接入方式。公共无线网络仍需先完成认证页面；如果锁屏后回到前台不能访问，应先确认无线网络是否仍连接，再检查 VPN 状态，而不是立刻删除系统 VPN 配置。

锁屏、后台任务与受管理设备

锁屏后下载停顿不一定是连接故障，目标应用自己的后台执行规则也会影响任务持续性。先解锁设备，用浏览器发起一个新的小请求，判断连接是否可用。如果新请求成功而旧任务没有继续，应检查原应用的任务状态；如果所有新请求都失败，再查看 On Demand、网络切换和服务器重连记录。不要把某个文件任务的暂停直接当成系统级断网，也不要通过持续点亮屏幕来掩盖根因。

由学校、企业或其他组织管理的 iPad，可能存在 VPN 配置、证书、网络过滤和修改权限限制。检查系统是否明确显示管理状态，并向管理员确认允许的使用方式。不要移除不理解的管理配置或证书来试错，因为它们可能关联必要业务与设备权限。对于自己的普通设备，也应先记录已有系统配置，确认影响范围后再操作。无法添加 VPN 的问题应回到授权章节，不能用修改服务器认证参数解决。

iPad 与另一设备在同一 Wi-Fi 上表现不同，仍要逐项比较设备自身的系统时间、DNS、当前 Config 和服务器选择，而不能因为无线网络相同就排除本地差异。浏览器隐私相关设置、已保存的网络条件与目标应用权限，也可能使请求路径或表现不同。测试应围绕同一目标和同一访问动作进行，优先从应用中的实际请求记录确认差异。若只比较两个不同应用的首页，很难得到可靠的网络结论。