Shadowrocket 速度慢怎么排查:节点、线路、协议与本地网络分层定位

把速度慢拆成本地网络、协议参数、线路质量、节点负载四层逐一排除,结合 Ping 测试与切换 Wi-Fi/蜂窝网络的对照方法,判断瓶颈在哪一层。

本文速览

Shadowrocket(小火箭)连接后速度慢,先固定目标、服务器与测试时段,再对照 Wi-Fi 和蜂窝网络;随后核对路由姿态、已有协议参数、线路波动与服务器负载。本文适用于已经持有自己的服务商配置或订阅的用户,重点区分“连接延迟低”“网页打开快”和“持续下载快”,通过单变量测试缩小故障范围,而不是根据一次 Ping 结果更换全部设置。

一、先把“慢”分成连接、首包与持续传输

先给结论:Ping 数字小不等于带宽大,连接开关打开也不等于目标请求已按预期经过代理。排查前,在 Home 记录当前服务器,在 Global Routing 记录当前姿态,再到 Config 确认正在使用的配置。保留配置副本,后续每次只改变一个变量。

网页很久才出现内容,可能涉及 DNS、连接建立或目标响应;网页很快打开但大文件速度低,更接近持续吞吐问题;视频开始正常、播放中间歇卡顿,则要观察波动、丢包和目标端限速。三种现象可以同时出现,不能统一归因为协议不够快。

本地接入规则选路协议连接线路传输目标响应
  1. 固定一个自己有权访问、能重复测试的目标页面或文件,不要每轮换网站。
  2. 分别记录连接耗时、页面开始显示的等待时间,以及稳定传输后的速度。
  3. 记录 Wi-Fi 或蜂窝网络、服务器名称、Global Routing 姿态与测试时刻。
  4. 每组重复三次,并记录失败次数;不要只保留最快的一次。

二、本地网络层:先做 Wi-Fi 与蜂窝网络对照

保持同一服务器、同一目标和同一配置,只改变接入网络。Wi-Fi 下慢而蜂窝网络正常,说明差异与接入网络或该网络通往服务器的路径有关,但还不足以认定路由器损坏。无线干扰、上行被占满、网络策略以及不同运营网络的路由都可能造成这种结果。

  1. 在 Wi-Fi 下完成一组测试,记录三次结果;靠近无线接入点,排除弱信号影响。
  2. 关闭 Wi-Fi,确认已使用蜂窝网络;断开后重新建立 Shadowrocket 连接,让新连接使用新的接入路径。
  3. 保持相同服务器和目标,再完成一组测试。下载测试会消耗蜂窝数据,先确认套餐余量。
  4. 回到 Wi-Fi 复测一次。如果仅某个接入点反复异常,再检查该网络的拥塞或限制。

如需测试普通网络是否正常,可以选择一个本来就能直接访问的目标,暂时断开连接后对照;此时流量按系统普通网络路径发送。先在 Settings → On Demand 记录并暂时关闭自动连接条件,避免测试时被重新连接,结束后恢复。不要用本就无法直接访问的目标判断本地网络是否故障。

重复出现的现象优先检查下一步
Wi-Fi 慢,蜂窝网络正常无线质量、接入拥塞、到服务器的路径同一 Wi-Fi 换接入点,保持服务器不变再测
两种网络都慢,直接访问的对照目标正常代理路径、服务器或目标端核对路由姿态,再比较已有服务器
直接访问与代理访问都慢本地网络占用、目标端响应暂停后台传输,并增加一个可直接访问的对照目标

三、路由层:确认测到的确实是同一条路径

在 Home → Global Routing 检查当前姿态。Config 按配置规则处理请求;Proxy 用于代理路径对照;Direct 用于直接连接对照;Scene 按所选场景处理,测试时还需核对具体场景。不要把不同姿态下的测速结果混在一起计算平均值。

使用 Config 时,规则按顺序匹配。DOMAIN-SUFFIX 匹配域名后缀,IP-CIDR 与 GEOIP 处理相应 IP 条件,FINAL 处理前面未匹配的请求。目标看似相同,页面里的图片或媒体却可能使用其他域名,因而走不同策略。检查请求记录里的目标与命中策略,比只看首页能否打开更可靠。

四、协议层:核对参数,不把换协议当作通用解法

在 Home 打开当前服务器的编辑页面,将地址、端口及协议参数与用户已有配置逐项对照。端口不是速度档位,不能将任意服务改成 443 来尝试提速。协议、端口与服务端监听配置必须配套;地址能解析,也不能证明认证与加密参数正确。

443
HTTPS 默认端口,不是所有代理服务的默认端口
2 类
本节区分 TCP 与 UDP 传输条件
8 bit
等于 1 Byte,比较速率时需统一单位
协议核对重点避免的操作
Shadowsocks服务器地址、端口、密码、加密方法及已配置的插件参数单方面更改加密方法或密码
VMess / VLESS用户标识、传输方式,以及启用 TLS 时的服务器名称等参数把传输方式或路径改成猜测值
Trojan密码、端口及 TLS 服务器名称通过关闭证书验证掩盖握手问题
Hysteria2认证信息、TLS 参数及接入网络的 UDP 可达性将配置中的带宽值当作线路保证
WireGuard密钥、对端地址、端口及隧道相关配置未确认原因便修改 MTU 或替换密钥

Hysteria2 与 WireGuard 依赖 UDP 传输条件;其他协议的实际传输还要结合配置判断。如果同一份 UDP 配置仅在某个 Wi-Fi 下持续超时,而蜂窝网络正常,应优先核对接入网络是否限制 UDP。只有服务端已经提供另一种兼容配置时,协议对照才有意义,不能只修改客户端的协议名称。

五、线路与节点层:用 Ping、时段和持续传输交叉判断

Ping 一般反映往返时延,而不是持续吞吐。某些服务器不响应 ICMP,Ping 超时仍可能建立业务连接;TCP 连接测试也只覆盖特定端口的连接阶段,不等于文件下载测试。使用 Home 中的 Connectivity Test 时,先确认测试方法和目标,避免把不同方法的数字直接排序。

线路质量涉及本地到服务器及服务器到目标的路径;节点负载则涉及服务器的 CPU、可用带宽、连接数或限速。单靠客户端一次测量通常不能将两者完全分开,应把现象与时间、接入网络和目标一起记录。

  1. 固定服务器测时段:在问题时段与另一时段重复同一测试。仅固定时段变慢提示拥塞或负载相关,但不能直接证明是哪一端拥塞。
  2. 固定目标换已有服务器:只比较自己已有、可正常使用的配置。某一台持续慢而其他正常,范围可收窄到该服务器或相关路径。
  3. 固定服务器换目标:一个目标慢、其他目标正常,更应检查目标端限速、目标路径或不同规则命中。
  4. 观察持续传输:记录稳定阶段与停顿次数。低延迟但频繁停顿,仍可能存在丢包、重传或服务器排队。

如果表现为“晚间所有目标都慢、换蜂窝网络仍慢、换另一台已有服务器恢复”,可以将记录交给自己的服务商核对负载和线路。这个结果仍不能区分服务器资源不足与共享出口拥塞;需要服务端监测进一步确认。不要把地理距离近或 Ping 最低当作唯一选择标准。

六、出现报错时:先处理连接失败,再测速度

持续报错说明当前测试可能根本没有进入稳定传输阶段。下面列出网络日志中常见的错误片段,实际措辞取决于底层连接与错误来源,并非每种协议都会显示相同文本。仅在自己的记录确实出现对应信息时参考,不能用这些词反推未显示的故障。

报错: i/o timeout

原因与解法:某次网络读写未在期限内完成,可能涉及不可达、丢包或对端无响应——保持服务器不变切换 Wi-Fi/蜂窝网络复测,再核对超时发生于连接还是传输阶段。

报错: connection refused

原因与解法:连接请求被对端或中间设备拒绝,不属于单纯带宽不足——核对地址、端口与服务是否仍有效,向自己的服务商确认对应端口的服务状态。

报错: certificate has expired

原因与解法:证书校验认为有效期已结束,也需排除设备时间异常——先检查系统日期与时间,再由服务维护方核对证书,不以关闭证书验证作为提速措施。

如果自己的订阅近期调整过地址或端口,可在 Home 中找到对应订阅并执行更新,再核对当前选中的服务器。更新后先检查 Config 与 Global Routing 是否仍符合原测试条件。订阅更新只是同步已有配置,不能保证线路性能,也不应成为反复测速时同时变化的变量。

七、常见追问与恢复检查

Ping 只有几十毫秒,为什么下载还是很慢?

时延与吞吐是不同指标。保持当前服务器和目标,测一段稳定传输,记录速率单位、停顿与时段;再换一个目标对照。不要仅凭 Ping 排除带宽限制或目标端限速。

Wi-Fi 慢,蜂窝网络快,是协议选错了吗?

不能直接下结论。先保持同一协议与服务器,切换接入网络后重建连接;若差异稳定复现,再核对 Wi-Fi 的拥塞、UDP 限制及路径差异,避免同时改协议与网络。

要不要直接修改 MTU 或打开所有选项?

先保留原值。小请求正常、大传输停顿只能作为线索,不能单独证明 MTU 问题。只有获得与现有隧道匹配的参数或明确诊断依据后,才做单项修改并复测。

测完以后需要恢复哪些设置?

恢复原服务器、Global Routing 姿态和 Config;到 Settings → On Demand 恢复原自动连接条件,再重新连接并检查常用目标。删除测试记录前保留最终有效设置。

向自己的服务商反馈时,提交接入网络、服务器标识、协议、测试时段、目标类型及重复测试结果即可;分享截图或日志前,遮盖订阅 token、密码、用户标识与密钥。若仍无法区分线路与负载,明确写“客户端对照尚不能确定”,比仅提交“速度慢”更便于继续定位。

App Store 正版下载与核验