Shadowrocket（小火箭）显示已连接，不等于每个请求都已成功到达目标。本文面向已经拥有自己的服务商与订阅、能够建立连接但网页或视频加载缓慢的用户：先固定测试条件，再逐层区分本地接入、协议参数、跨网线路与节点负载，最后用 Ping 和 Log 留下可复查的证据。
一、先固定测试条件，区分延迟与吞吐量
“慢”至少有三种表现：点击后长时间没有响应、页面开始加载后持续缓慢、连接时快时慢。第一种可能涉及 DNS 解析或握手，第二种更需要检查可用带宽与拥塞，第三种则要结合网络切换、丢包和服务端负载判断。只看状态栏的 VPN 标记，无法区分这些情况。
测试前在 Home（首页）记录当前选中的节点，以及 Global Routing（全局路由）的当前取值。不要同时更新订阅、切换协议并修改 DNS；否则即使速度恢复，也无法知道哪一步起作用。下列测试次数是排查建议，不是应用默认值。
- 选定一个已经能够访问的网页和一个固定的视频片段，分别观察首次响应与持续加载；整个排查过程保持目标一致。
- 暂停照片同步、系统更新和其他大流量任务，保持设备位置与接入网络不变。
- 每组条件重复观察 3 次，记录网络类型、节点备注、测试时间与失败现象，不只记录最快的一次。
- 每次只改变一个条件；比较结束后恢复原来的路由与配置，再进行下一组测试。
二、本地网络：先比较 Wi-Fi 与蜂窝网络
第一层先检查 iPhone 或 iPad 到本地网络出口的这一段。Wi-Fi 信号强只说明无线接收情况，不能证明路由器出口没有拥塞。相同节点在蜂窝网络下正常、在某个 Wi-Fi 下缓慢，是接入网络或该网络至节点路径存在差异的线索，不能直接判定服务端故障。
- 在当前 Wi-Fi 下，先访问一个原本就能直接访问的常用页面，确认本地网络是否也有明显等待。若临时断开 Shadowrocket 测试，仅访问适合直接访问的内容。
- 进入 Settings → On Demand（按需连接），记录当前条件。默认值以当前应用显示为准；若它会干扰手动断开对照，建议仅在这轮测试中暂时关闭，并在结束后恢复原值。
- 保持同一节点与同一配置，关闭 Wi-Fi，使用设备可用的蜂窝网络重复测试；注意流量消耗。
- 若仅 Wi-Fi 异常，靠近路由器重测，并检查同一网络是否正进行大流量传输；不要先修改所有协议参数。
端口号是检查路径的线索，不是调速参数。将服务商给定的代理端口随意改成 443，或把所有 DNS 请求都理解为端口 53 的流量，都可能造成新的连接问题。
三、协议参数：核对原始配置，不凭名称判断快慢
第二层检查客户端记录与服务端要求是否一致。Shadowrocket 中的 Shadowsocks、VMess、VLESS、Trojan、Hysteria2、WireGuard 对应不同的协议与配置字段；它们不是可以只改名称就互换的速度档位。用户已有订阅时，应先对照自己的服务商提供的有效参数。
| 协议或字段 | 应核对的内容 | 不要据此推断 |
|---|---|---|
| Shadowsocks | 服务器地址、端口、密码与加密方法是否一致。 | 端口可连通，不代表认证与后续转发成功。 |
| VMess / VLESS | 身份参数、传输方式，以及配置中实际启用的 TLS 与传输相关字段。 | 不能只保留地址和端口，忽略其余必需参数。 |
| Trojan | 密码、TLS 相关要求，以及服务器名称是否符合服务端配置。 | 不能把关闭证书验证当作常规提速办法。 |
| Hysteria2 | 认证信息、TLS 要求，以及当前路径对 UDP 的可用性。 | 基于 QUIC 不意味着在所有接入网络都更快。 |
| WireGuard | 密钥、端点、地址与路由范围是否与已有配置一致。 | 握手可见不代表 DNS 与目标路由均正确。 |
上述字段没有适用于所有服务端的统一推荐值；默认值以当前应用显示为准，连接参数以已有服务端配置为准。若问题恰好出现在订阅更新后，先记录更新前后地址、端口或传输字段的变化，再向自己的服务商确认。不要删除原记录后反复导入，以免丢失对照条件。
结论：先验证参数一致，再比较协议表现
若一种配置反复在握手阶段失败，先处理认证、TLS 或传输参数；只有两种配置都能稳定完成同一请求时，速度比较才有意义。
四、线路质量：把 Ping 与实际请求分开看
第三层观察本地网络到节点、节点到目标之间的路径。应用内 Ping（延迟测试）的结果必须结合当前测试方式理解：ICMP 回应、TCP 建连与经过代理完成网页请求，测到的不是同一件事。节点不回应 ICMP，也不能直接说明代理服务不可用。
低延迟说明某次探测的往返时间较短，并不等于持续传输带宽充足；探测正常但视频持续缓冲时，应继续比较实际传输和时段差异。不要将一次超时换算成整条线路的丢包率。
- Ping 快、网页首次响应慢：检查 Log 中是否存在 DNS 等待、连接重试或 TLS 错误，同时核对请求实际命中的路由。
- 首次响应快、持续加载慢：在固定目标下复测，检查本地带宽占用、线路拥塞与服务端限速条件。
- 同一节点只在某个接入网络慢：优先保存 Wi-Fi 与蜂窝网络的对照结果，定位接入路径差异。
- 只有单个网站慢：用另一个正常目标对照；目标站点、其内容分发路径及节点出口都可能参与影响。
切勿仅凭“距离更近”就认定线路更快。地理距离、运营网络互联、拥塞与目标站点选择的内容分发位置是不同因素，需要通过相同条件下的请求结果判断。
五、节点负载：先确认请求确实经过所选节点
第四层才比较已有节点的服务端表现。进入 Home → Global Routing，先记录当前取值。Config（按配置分流）、Proxy（代理）、Direct（直连）、Scene（场景）的含义不同；当前默认值以应用显示为准。日常取值按已有配置要求选择，排查时如需临时使用 Proxy 对照，应在测试结束后恢复原值。
在 Config 下，选中某个节点不代表每个请求都会经过该节点。DOMAIN-SUFFIX 按域名后缀匹配，IP-CIDR 按地址网段匹配，GEOIP 按地址地理归属匹配，FINAL 是兜底规则；实际结果还取决于规则顺序与策略。Scene 则需结合已有场景定义核对，不能当作固定的代理策略。
- 对同一目标发起一次新请求，在 Log 中核对其策略、出站或相关连接记录；字段名称以当前应用显示为准。
- 如果请求走了 Direct，先处理路由原因，不要将这次速度归因于选中的代理节点。
- 若已有多个可用节点，保持目标、接入网络和路由姿态不变，只切换节点进行对照。
- 在不同时间重复同一测试。仅高峰时段变慢可能涉及拥塞或负载，但不能仅凭客户端结果确认服务器 CPU、在线人数或限速状态。
六、Log 报错：按发生阶段处理，不按关键词猜速度
打开应用内 Log（日志，入口与可记录内容以当前应用显示为准），重现一次缓慢或失败的请求，然后只检查对应时间附近的记录。以下英文是网络日志中常见的错误文本；具体前缀、大小写与完整上下文可能不同，不能把这些文字视为每次故障都会出现的固定提示。
报错：i/o timeout
原因：某个网络操作在规定时间内未完成，单凭这行文本无法区分 DNS、建连或后续读写阶段。
解法：查看前后记录中的目标与操作阶段，保持同一节点切换接入网络复测，再判断是否需要核对服务端。
报错：connection refused
原因：连接收到明确拒绝，可能涉及目标端口未监听或网络设备主动拒绝。
解法：核对服务器地址与端口是否仍与已有配置一致，并向自己的服务商确认对应端口服务状态。
报错：certificate has expired or is not yet valid
原因：证书有效期校验失败，可能涉及证书状态或设备时间错误。
解法：先检查设备日期与时间；时间正确时核对服务端证书，不通过关闭校验掩盖问题。
- 日志中的错误若指向订阅更新地址，只能说明更新操作异常，不能直接证明已导入节点的转发速度异常。
- 对外提供日志前，隐藏订阅凭据、密码、密钥及不必要的访问记录；保留时间、错误阶段与对照条件。
- 不要长时间反复重连来替代取证。连续重试可能改变连接状态，却没有解释最初是哪一段等待。
七、常见追问与恢复检查
Ping 只有几十毫秒，为什么视频还是一直缓冲？
Ping 不是吞吐量测试。先固定一个视频片段，保持同一节点分别在 Wi-Fi 与蜂窝网络观察持续加载；再核对 Log 中该请求是否确实使用了所选出站。
切成 Proxy 后正常，回到 Config 又慢，怎么查？
先在 Config 下重现同一目标，核对命中的规则与策略，再到 Config（配置）检查相关规则顺序。重点查看 DOMAIN-SUFFIX、IP-CIDR、GEOIP 与 FINAL 对该请求的处理，不要直接把整份配置长期改成全局代理。
只要更换协议就一定能提速吗？
不能。只有自己的服务端支持对应协议、参数完整且路径允许所需传输时，比较才成立。先验证连接与请求稳定，再在同一目标和同一接入网络下比较。
检查完成后，哪些设置需要改回去？
恢复测试前记录的 Global Routing、Settings → On Demand 条件与临时修改的配置；重新打开原目标验证。保留有效的单项修正，不把测试用的临时姿态当成日常默认设置。
完成一轮检查后，应能写出“哪个网络、哪个节点、哪个路由姿态、哪个目标、哪个阶段出现等待”。如果这些条件还没有固定，继续改 DNS、端口或协议只会增加变量；先补齐对照记录，再处理已定位的环节。