Shadowrocket 网速慢怎么办:节点、线路、协议、本地网络四层排查

按本地网络、协议参数、线路质量、节点负载由近及远逐层定位速度瓶颈,每层给出可在 iPhone 上直接完成的检查动作。

本文速览

Shadowrocket(小火箭)显示已连接,并不表示整条访问路径都具备足够带宽。本文面向已经持有自己的服务商配置或订阅的用户,从直连基线、Global Routing、协议参数、跨网线路到节点负载逐项排查;通过固定测试对象、每次只改一个条件,区分网页首开慢、持续下载慢和连接超时,避免反复修改无关设置。

一、先区分延迟、吞吐与连接失败

访问速度由多个环节共同决定:iPhone 到无线接入点或蜂窝基站、本地运营商到远端服务器、服务器处理能力,以及服务器到目标网站的路径。Home 中的延迟结果只覆盖特定测试方式下的响应过程,不能直接换算为下载速度。一次很低的延迟,也无法证明长时间传输没有丢包或拥塞。

先描述症状,再选择测试。网页首次打开停顿、打开后正常,优先观察域名解析和建立连接;文件一开始就慢,优先比较带宽与路径;下载时快时慢,优先观察无线干扰、丢包和共享负载。连接一直超时则属于可达性问题,应先恢复连接,再讨论提速。

4 层
本地网络 → 协议参数 → 线路质量 → 节点负载
8 bit
等于 1 Byte;Mbps 与 MB/s 不应直接比较
3 次
每个条件建议重复测试的次数,记录中间结果

例如,80 Mbps 的数值理论上相当于 10 MB/s,但实际文件传输还会受到协议开销、目标站限速和网络波动影响。这只是单位换算,不是速度承诺。测试时记下网络类型、所选节点、路由模式、目标网站和时间段,后续才能进行有效对照。

二、第一层:建立本地网络的直连基线

先使用不依赖代理也能正常访问的同一个网站或文件作为基线。在安全、允许直连的场景下,临时停止 Shadowrocket 的连接,再进行测试。如果直连已经慢,继续调整代理协议通常无法解决问题。不要用两个不同网站的下载数值判断代理是否拖慢网络,因为两者可能使用不同的服务器与带宽限制。

  1. 记录原设置

    在 Home 记录所选节点与 Global Routing 当前值,再到 Settings → On Demand 查看按需连接状态。诊断期间如需手动断开,可暂时停用 On Demand,避免系统依据既有条件重新建立连接。

  2. 测直连基线

    在 Home 停止连接,确认连接状态已变化。使用 Safari 打开固定测试对象,记录首次加载和持续传输表现;不要在此时同时运行系统更新、照片同步或大文件上传。

  3. 换接入网络

    在 iPhone 的 Settings → Wi-Fi 切换无线连接,分别以 Wi-Fi 和蜂窝网络测试同一对象。留意蜂窝数据用量;两组测试应尽量在接近的时间完成。

  4. 恢复后复测

    返回 Home,恢复同一节点和路由设置,在相同网络再次测试。结束后恢复原来的 On Demand 条件,不把诊断时的临时设置长期遗留。

若只有 Wi-Fi 慢,先靠近路由器,比较不同频段的连接,并检查是否有人大量上传。上传占满同样可能使网页请求排队。若只有蜂窝网络慢,比较不同位置与时段,检查当前数据套餐是否存在限速。不要根据状态栏信号格数就认定网络带宽充足。

三、第二层:核对路由姿态与协议参数

本地网络正常后,先确认测试流量实际经过哪里。Home → Global Routing 中,Proxy、Direct、Config、Scene 是不同的路由姿态。Config 根据当前配置中的规则决定去向;Scene 按所配置的场景条件应用相应设置,不能把它当成固定的全局代理。若目标网站命中了 DIRECT,测试结果就不能用来衡量所选代理节点。

设置项 含义 排查时核对
Proxy 采用代理路由姿态 确认所选代理或策略组没有在测试中发生切换。
Direct 采用直连路由姿态 适合进行路由对照,不代表代理节点速度。
Config 按当前配置执行规则 查看目标连接的匹配规则与最终策略。
Scene 按场景设置应用条件 确认当前网络命中的场景及其路由设置。

在 Config 中,可以用下面这段规则理解测试对象的去向。这是规则语法示例,不是完整配置;example.com 是示例域名,PROXY 表示代理策略,实际使用前应核对当前配置中的策略定义。规则按顺序匹配,较早命中的规则可能决定最终结果。

DOMAIN-SUFFIX,example.com,PROXY
FINAL,DIRECT

然后在 Home 打开已有节点的编辑页,核对类型、地址、端口和认证信息。Shadowsocks 的加密方式、VMess 或 VLESS 的身份与传输设置、Trojan 的密码与 TLS 参数都必须和服务器配置一致。服务器使用 TCP 端口 443,不意味着任意协议填入 443 就能正常工作;端口相同也不代表传输内容相同。

报错:certificate has expired

原因与解法:这类 TLS 错误表示证书时间验证未通过,可能是证书过期或设备时间异常。先校准系统时间,再向自己的服务商核实证书状态,保持证书验证开启。

报错:Connection refused

原因与解法:连接被目标端点或中间设备明确拒绝,常见于端口未监听或访问策略拒绝。核对地址、端口和协议,不把反复测速作为修复手段。

报错:Operation timed out

原因与解法:请求未在限定时间内完成,可能涉及路径丢包、端口不可达或远端无响应。先换接入网络测试同一配置,再向自己的服务商确认远端状态。

以上是网络与 TLS 诊断中常见的错误原文,实际显示可能带有额外上下文。记录完整错误和发生时间,区分解析、连接、握手或传输阶段;不要只截取“超时”两个字就直接归因于节点负载。

四、第三层:用交叉测试识别线路问题

线路质量是本地接入网络与远端之间的路径表现,包括往返延迟、抖动、丢包和拥塞。它与服务器的地理距离有关,但不是单一的距离关系。标注相同地区的两个已有节点,也可能经过完全不同的互联路径;节点名称不能代替路径质量证据。

使用自己已有的配置做交叉测试:先固定节点切换接入网络,再固定接入网络切换已有节点。保持目标对象与测试方式一致,每组重复三次,记录中间结果。不要把一次瞬时峰值当作持续速度,也不要高频并发测试,否则测试本身就可能占满连接。

观察到的组合 优先检查方向 下一步动作
同一节点在 Wi-Fi 慢,蜂窝正常 Wi-Fi 接入或其运营商路径 结合直连基线,区分无线问题与远端路径差异。
同一节点在两种网络都慢,其他已有节点正常 该节点的路径或服务端状态 保留节点配置不变,在另一个时间段复测。
只有一个网站慢,其他目标正常 目标站、域名解析或节点到目标的路径 比较同站不同资源,确认实际命中的路由策略。
所有节点和直连同时变慢 本地网络或测试对象 暂停其他传输,更换固定测试对象后重建基线。

结论:固定变量再换网络

同一配置只在一种接入网络下异常时,先保留协议参数,把排查重点放到该接入网络及其远端路径;不要同时改 DNS、端口和协议,否则无法知道哪项变化影响了结果。

网页首开慢但持续传输正常时,才重点检查 DNS:比较同一域名第一次与再次打开的表现,并结合连接记录确认解析与连接耗时。第二次更快也可能来自浏览器缓存,不能单凭这一点断言 DNS 有故障。随意更换解析地址可能改变目标分配或规则匹配,修改前应备份当前配置。

五、第四层:区分节点负载与目标站限制

节点负载包含服务器处理能力、出口带宽、并发连接及服务端限速。客户端能观察到的是响应和传输表现,通常无法直接读取远端 CPU 或出口占用。因此,“延迟不高但下载很慢”只能说明延迟与吞吐不一致,不能直接证明服务器超载。

不要为了提高测速数字而直接增大并发或持续运行下载。多连接测速可能暂时得到更大的总吞吐,但不能代表单个网页请求更快,也会消耗流量。若两个协议的服务器、端口、出口或路径不同,测试结果就不能被概括为“某协议一定更快”。

结论:用证据定位远端瓶颈

只有在直连正常、参数一致、多个目标都慢且跨接入网络可复现后,才优先向服务商核实该节点的出口和负载;附上时间段与对照结果,比反复更换客户端设置更便于定位。

六、整理记录并恢复日常配置

一轮排查结束,应能回答三个问题:本地直连是否正常、目标请求实际走哪条策略、异常是否跟随节点或接入网络变化。若仍无法判断,就保留最小可复现条件,不继续叠加修改。尤其不要同时更新订阅、更换规则和调整协议,这会让原始问题失去可比性。

  1. 记录 iPhone 使用 Wi-Fi 还是蜂窝网络,以及每次测试的日期、时间和持续时长;不需要公开完整公网地址。
  2. 记录 Home → Global Routing 的值、当前配置与所选节点的脱敏名称,说明测试期间是否发生自动切换。
  3. 记录直连基线、同节点跨网络结果、同网络不同已有节点结果,并注明速度单位是 Mbps 还是 MB/s。
  4. 保留错误原文,发送前遮盖地址中的敏感信息、认证字段和订阅凭据。
  5. 恢复日常使用的 Config、规则与 Settings → On Demand 条件,确认常用网站路由符合预期。

需要进一步核对规则与路由姿态时,可阅读技术参考或代理模式说明。Shadowrocket 是 Apple 平台的闭源商业应用,主要用于 iPhone 与 iPad;系统要求以 App Store 页面标注为准。客户端一次性买断不等于线路套餐,本文仅说明如何检查用户已有配置,不提供、销售或推荐节点与订阅。

App Store 下载先核对正版三要素