Shadowrocket（小火箭）显示已连接，只能说明系统 VPN 隧道已建立，不代表每个服务器、目标网站和传输协议都能正常工作。本文以用户已有自己的服务商与订阅为前提，先固定测试条件，再按节点、线路、协议、本地网络逐层替换；通过首屏等待、持续传输、报错与网络切换结果，把问题缩小到可以核对的具体环节。
一、先确认请求路径，再判断“慢”发生在哪里
结论：先核对请求是否经过预期策略，不要仅凭连接开关或 VPN 标识判断服务器速度。在 Home 确认当前选中的服务器，再查看 Global Routing。Proxy 将流量按代理模式处理，Direct 按直连模式处理，Config 依据当前配置中的规则决定策略；这些模式的测试结果不能混在同一组记录里。
使用 Config 时，先在 Config 确认正在使用哪份配置。某个网页可能命中 DIRECT，另一个网页才经过代理。若 Global Routing 当前使用 Scene，先核对相应场景的设置，再将排查条件固定下来，不要让场景变化和服务器切换同时发生。需要短暂使用 Proxy 对照时，先记下原模式，测试结束后恢复。
- 选定同一个目标网页，区分“首次打开等待很久”和“开始传输后速度低”。
- 在 Home 执行 Connectivity Test，记录测试方式、结果和选中的服务器；测试值只作为该测试目标的参考。
- 重新发起目标请求，结合可用的连接记录核对目标域名与实际策略，不把 DIRECT 请求当作服务器测速。
- 遇到间歇断开时，检查 Settings → On Demand 的连接条件，确认测试期间没有因网络变化反复重连。
二、建立对照记录：每次只改一个变量
结论：一次测试只替换一个条件，结果才有解释价值。不要同时更新订阅、切换服务器、改协议和换 Wi-Fi。先暂停其他设备的大量传输，保持同一台 iPhone 或 iPad、同一个目标、同一种测试方式，并记录测试时段。网页缓存会让第二次打开明显更快，因此缓存命中与重新获取内容也要分开记录。
下面是记录模板，不是本站实测结果。A、B 指用户已有订阅中的两个服务器；选择 B 时尽量保持协议和地区等其他条件相近。如果订阅中没有合适的对照项，直接写明条件不同，不要把结果解释成单一因素造成。
| 测试轮次 | 固定条件 | 仅改变的条件 | 记录内容 |
|---|---|---|---|
| 基线组 | 服务器 A、原配置、同一目标 | 不改变 | 首屏等待、持续传输、是否报错 |
| 节点组 | 原网络、相同路由模式 | A 换为 B | 是否稳定改善，是否仍有停顿 |
| 网络组 | 服务器 A、原协议、同一目标 | Wi-Fi 换为蜂窝网络 | 同一请求能否完成，重连耗时另记 |
| 时段组 | 服务器 A、原网络、原配置 | 测试时段 | 高峰与非高峰是否有规律差异 |
结论：先找能重复的差异
若只有某一次请求变快，先重复同组测试；只有在其他条件固定、差异持续出现时，才沿该变量继续检查，避免把缓存或短时波动当作修复效果。
三、节点层：低延迟不等于持续传输快
结论：节点测试能帮助判断可达性与响应时间，不能直接代表带宽。一次短请求只传输少量数据，即使很快返回，也不能说明大文件或视频分片能够持续快速传输。服务器负载、出口容量、到目标站点的路径，都可能在延迟正常时限制吞吐。
- 只慢一个服务器：在 Home 换到已有订阅中条件相近的另一个服务器，重复同一目标测试。如果只有 A 持续异常，优先核对 A 的状态及连接参数。
- 只慢一个目标：保持服务器不变，测试另一个自己日常使用的目标。若其他目标正常，继续检查该目标的规则、解析结果和服务器到目标的路径。
- 所有服务器都慢：先保留当前配置，进入本地网络对照，不要马上认定订阅中的全部服务器都故障。
- 订阅信息可能过期：通过应用内订阅更新操作获取自己服务商提供的最新信息，核对是否更新成功，再重新选择服务器；不要直接修改订阅管理的条目来长期覆盖错误。
地区名称只能作为服务商提供的标识，不能仅凭名称推断实际中转路径或可用带宽。向自己的服务商反馈时，提供条目名称、测试时间、网络类型与异常目标，比只描述“延迟很低但很卡”更容易定位问题。
四、线路层：用时段和目标差异识别路径问题
结论：客户端通常不能仅靠一个延迟数字分清接入链路、中转路径、服务器出口和目标站点中的哪一段拥塞。线路层排查应依赖对照证据：同一服务器是否只在某些时段变慢，同一网络是否访问多个服务器都不稳定，以及更换目标后现象是否消失。
- 固定服务器比较时段。在不同时间重复同一组请求。若晚间持续变慢、其他时段恢复，只能说明有时段相关的拥塞线索，尚不能确定发生在哪一段。
- 固定目标比较路径。在自己已有的服务器中做对照。若只有部分服务器到同一目标慢，记录这些服务器的共同条件，交由服务商进一步核对。
- 区分等待与传输。首个响应等待很长、后续传输正常，更需要核对解析和连接建立；已经开始传输却反复停顿，则继续观察拥塞、丢包或目标限速的可能性。
- 分开网页与媒体测试。视频应用的清晰度自适应和缓冲会影响观感，不宜把一次播放流畅直接等同于线路容量充足。
不要用反复断开重连代替记录。重连后可能建立了新会话，也可能恰好避开瞬时拥塞；如果没有固定服务器、目标和网络，无法知道改善来自哪一环。服务器线路或出口信息需要由自己的服务商确认，客户端侧的观察只能逐步缩小范围。
五、协议层：先核对参数，不盲目更换类型
结论：协议必须与服务器端一致，不能把类型改成另一种协议来“提速”。Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 的认证、传输和服务端配置不同。只有服务商已经提供相应连接信息时，才具备对照条件；比较时还要注明服务器与路径是否相同。
| 协议或传输 | 优先核对 | 排查边界 |
|---|---|---|
| Shadowsocks | 地址、端口、密码、加密方法 | 加密方法必须与服务器配置一致。 |
| VMess / VLESS | UUID、传输类型、TLS、Host、Path | Host 与 Path 是否需要填写取决于所用传输，不能互相替代。 |
| Trojan | 密码、端口、TLS 与服务器名称 | 证书名称不匹配应核对配置，不以关闭验证作为提速方法。 |
| Hysteria2 | 认证、TLS、UDP 可达性及带宽相关参数 | 基于 QUIC，依赖 UDP；网络限制 UDP 时可能无法正常建立连接。 |
| WireGuard | 密钥、Endpoint、地址及 MTU | 基于 UDP；MTU 必须结合路径验证，不存在适合所有网络的固定最佳值。 |
端口号也要逐项照原始配置核对。例如 HTTPS 常用 TCP 443，但填写 443 并不代表任意协议都能使用该端口，更不代表该连接一定使用 TCP。不要将 Hysteria2 的 UDP 连接与 TCP 443 的可达性混为一谈。对于带宽相关字段，不要填入远超实际线路能力的数值来尝试获得更高速度。
若小请求能完成，大响应经常停住，可以把 MTU 或路径 MTU 问题列入待查项，但这不是直接诊断。先排除目标站点差异和本地网络问题，再按服务商提供的配置做受控测试。调整前保留原值，每次只改一个参数，失败后恢复，不批量套用所谓通用优化数值。
六、本地网络层：用 Wi-Fi 与蜂窝网络交叉验证
结论：同一服务器与配置只在某个本地网络变慢时，应优先检查该网络的无线质量、上行占用和传输限制。Wi-Fi 信号格数不等于实际可用容量，路由器附近也可能存在干扰；蜂窝网络则会受到位置、信号质量、套餐状态和基站负载影响。
- 固定服务器与目标，先在原 Wi-Fi 完成一组测试，暂停本机和其他设备正在进行的大量上传或备份。
- 切换到蜂窝网络，等待 Shadowrocket 重新连接后，再发起同样请求。将网络切换造成的重连等待与网页响应时间分开记录，并留意流量消耗。
- 若蜂窝正常而 Wi-Fi 持续异常，靠近路由器再测；条件允许时，在同一路由器的不同无线频段分别验证。
- 若是需要网页认证的 Wi-Fi，先完成网络登录。登录页未完成时，VPN 标识不能证明互联网出口可用。
- 在 Settings → On Demand 核对按需连接条件，避免网络切换后自动连接行为影响测试；调整前记录原设置，完成后恢复。
DNS 也需要单独观察。DNS 常见查询可使用 UDP 或 TCP 53，加密 DNS 的传输方式则不同。如果每次首次访问等待很久，而建立连接后传输正常，检查当前配置中的 DNS 设置、解析是否成功以及是否发生重试。不要仅凭“换了 DNS 后某次变快”就判定所有速度问题均由 DNS 引起。
七、出现报错时：先按原文定位失败阶段
结论：报错说明的是某个阶段失败，不等于直接给出了根因。下面列出网络诊断或连接日志中可能出现的常见原文片段，实际完整信息以设备记录为准。保存发生时间、目标和对应服务器，不要将订阅地址、密码、UUID 或密钥一并公开。
报错：connection refused
原因与解法：连接被明确拒绝，可能是端口未监听或被主动拒绝；先核对服务器地址和端口，再让自己的服务商确认该入口的监听状态。
报错：i/o timeout
原因与解法：某一步网络读写未在时限内完成，单凭此句不能判断是本地网络还是远端故障；固定服务器切换 Wi-Fi 与蜂窝网络，并结合完整日志确认超时发生阶段。
报错：TLS handshake failed
原因与解法：TLS 握手未完成，可能涉及名称、证书、设备时间或连接中断；核对原始 TLS 参数与系统时间，再比较另一网络，不以关闭证书验证作为常规处理。
若没有报错但持续缓慢，保留成功与失败两组记录同样重要。连接建立成功后才出现的停顿，与认证失败或 TLS 握手失败不是同一类问题。不要只截取最后一行就判断需要更换协议，应结合前后请求和复现条件阅读。
八、常见追问与结束排查的判断标准
延迟很低，为什么视频还是一直缓冲？
先保持服务器不变，比较同一目标的持续传输表现，再检查播放清晰度和缓冲状态。短时延迟测试不覆盖持续吞吐，也不覆盖服务器到视频内容服务器的全部表现。
切到 Proxy 就快了，是否一直用 Proxy？
先回到 Config 核对该目标命中的规则和策略。DOMAIN-SUFFIX、GEOIP、IP-CIDR 与 FINAL 会影响请求去向；两种模式速度不同是检查规则的线索，不是永久切换模式的充分理由。
只有 Wi-Fi 慢，要不要重新导入订阅？
先固定服务器，在 Wi-Fi 与蜂窝网络各重复测试。如果同一配置在蜂窝网络稳定正常，优先查 Wi-Fi 接入与路由器，不先删除订阅；更新订阅也不能修复无线干扰。
换成 Hysteria2 就一定更快吗？
不能保证。先确认自己的服务商提供 Hysteria2 参数，并验证当前网络允许相应 UDP 通信；比较时固定目标和时段，注明服务器路径的差异，不从协议名称直接推断结果。
结束排查时，至少应形成一条能够复现的描述，例如“固定同一服务器和配置，在同一位置，Wi-Fi 下持续停顿，蜂窝网络下三次请求均完成”。这类记录只能将优先检查范围指向本地网络或接入路径，仍需后续验证；它比笼统地说“连接了但很慢”更适合继续排障。
- 恢复测试改动：还原原有 Global Routing、On Demand 条件及临时协议参数，确认日常使用的配置仍然正确。
- 反馈必要信息：提供测试时段、网络类型、服务器条目名称、目标与报错片段；认证信息和订阅令牌应遮盖。
- 分别处理归属：本地网络问题检查路由器与接入条件，服务器入口或线路问题向自己的服务商核对，规则问题回到 Config 检查。