2026-08-06 · 故障排查 · 约 10 分钟

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

按节点状态、线路质量、协议参数、本地 Wi-Fi 与蜂窝网络四层逐一排除,配合连通性测试与规则核对,找出变慢的真正环节。

本文速览

本文适用于已经拥有自己的服务商与订阅、能够连接但访问缓慢的用户。先确认应用与测试条件，再按节点、线路、协议、本地网络逐层做单变量对照，最后用规则与连接记录解释结果，避免把延迟、吞吐量和网页首开时间当成同一项指标。

一、建立基线：先分清哪一种“慢”

Shadowrocket（小火箭）是通过 App Store 获取的 Apple 平台付费客户端，采用一次性买断方式。核对正版时，应同时确认官方图标、开发者 Shadow Launch Technology Limited 与应用 ID 932747118；兼容范围和系统要求以 App Store 页面标注为准。客户端买断与用户已有连接服务是不同事项，购买应用本身不会改变线路带宽。

开始排查前，在 Config 保存当前配置副本，记录 Home 中选中的节点及 Global Routing 当前姿态。网页首开慢可能涉及 DNS、连接建立或目标站响应；持续传输慢更接近吞吐量问题；时快时慢则需要观察拥塞、无线干扰与连接重建。不要一开始就同时换节点、换协议、改 DNS。

4 层
节点状态、线路质量、协议参数、本地网络
4 姿态
Global Routing：Proxy / Direct / Config / Scene
3 次
每个对照条件至少重复测试三次，避免只取一次结果
  1. 选择同一个日常使用的目标页面，以及一个允许正常访问的较大文件，分别观察首开与持续传输。
  2. 固定设备、目标、节点与测试时段，暂停其他设备的大流量任务，每次只进行一个测试。
  3. 分别记录测试时间、网络类型、连接是否成功、首开耗时和稳定后的传输速率。记录值来自自己的设备，不使用节点名称中的宣传数字代替。
  4. 注意单位：MB/s 与 Mbps 不同，1 MB/s 等于 8 Mbps。比较前先统一单位。

二、节点状态：先确认能否建立有效连接

在 Home 选中当前使用的节点，执行 Connectivity Test。测试成功表示对应测试方法与目标能够完成一次探测，并不代表所有网站可用，也不代表持续传输带宽充足。不同测试方法的数值不宜直接混比，更不能把一次低延迟当成高速保证。

如果当前节点反复失败，先检查地址、端口、账号凭据与服务有效状态，再从用户已有配置中选择另一条可用节点做对照。订阅导入成功只说明应用取得并解析了内容，不代表其中每条连接都有效。需要更新时，在 Home 对对应订阅执行更新，并复核节点参数是否确实变化；不要删除原有可用条目后再尝试。

报错：Connection refused

原因：连接收到拒绝响应，常见于目标端口未监听或中间设备主动拒绝。解法：对照自己的服务配置核实地址与端口，再让服务维护方检查监听状态；单纯修改测速目标不能修复端口拒绝。

报错：Operation timed out

原因：指定时间内未完成相应网络操作，可能涉及不可达、丢包或服务无响应。解法：保留相同节点，切换 Wi-Fi 与 Cellular 对照，再用另一条已有节点复测，逐步区分本地网络与远端问题。

以上是网络诊断中常见的错误原文，具体显示会随日志来源而变化。记录报错时应一并保留发生时间、对应目标和操作阶段；“能连上 VPN”仅说明系统隧道已建立，不能据此认定代理服务器与目标站之间也已正常通信。

三、线路质量：把延迟、丢包与吞吐量分开观察

节点入口地址相同，不代表不同时段的实际路径与负载相同。晚间拥塞、无线丢包、远端出口负载及目标站限速，都可能让一次探测正常而文件传输缓慢。应把同一目标的重复结果连在一起看，而不是只保留最好的一次。

观察现象优先怀疑下一步对照
首开慢，开始传输后稳定DNS、握手或目标站响应记录首次打开与再次打开的差异，再查连接记录。
多个目标持续传输都慢公共链路或节点出口瓶颈保持网络不变，换另一条已有节点重复相同任务。
仅一个目标慢目标站、内容分发或特定路径先核对该域名实际命中的策略，不立即修改全局配置。
固定时段明显变慢时段性拥塞或负载使用相同条件分别记录两个时段，交给服务维护方对照。

如果使用网络诊断工具观察丢包，必须说明探测方式。某些服务器会限制 ICMP 响应，因此 ICMP 探测丢包不一定等于业务数据同等丢包。需要结合实际连接超时、传输停顿与重试现象判断，不能只凭一个百分比给线路下结论。

结论：先定位慢的范围，再调整连接参数

若同一网络下只有一个目标慢，先检查该目标的规则与路径；若多个目标都慢，且换已有节点后恢复，优先提交原节点与线路的对照记录，而不是继续修改本地 DNS。

四、协议参数：核对服务端要求，不按名称猜速度

Shadowsocks、VMess、VLESS、Trojan、Hysteria2 与 WireGuard 的参数和传输方式不同。切换协议必须有匹配的服务端配置，不能把同一地址的类型改成另一种协议就期待正常工作。服务器端口由自己的服务配置决定；即使使用 443，也不代表协议、TLS 与认证参数一定正确。

修改参数前保留原值，每次仅改一项并重复基线测试。不要随意提高并发、填写远高于实际链路能力的带宽值，或反复改变 MTU；这些操作可能引入新的排队、丢包或连接问题。若订阅更新会覆盖节点字段，应先确认本次修改是否仍然保留。

五、本地网络：用同一节点比较 Wi-Fi 与 Cellular

保持节点、配置与目标不变，只切换本地网络，是区分无线环境与远端服务的直接方法。Wi-Fi 信号格数不能完整反映干扰、回程拥塞或路由器负载；蜂窝网络也受位置、覆盖和时段影响。蜂窝测试前确认流量资费，使用同样大小的测试任务即可。

  1. 在 Wi-Fi 下完成三次相同测试，记录是否伴随其他设备上传、视频播放或系统同步。
  2. 关闭 Wi-Fi，确认已切到 Cellular，等待连接稳定后再测试，避免把切网时的短暂重连记为长期慢速。
  3. 如果仅 Wi-Fi 慢，靠近路由器复测，并检查其他设备是否占满上行；具备条件时对照不同无线频段。
  4. 如果两种网络都慢，检查它们是否使用相同节点和相同规则，再回到节点与线路层继续定位。

六、规则核对：确认流量真的经过了预期路径

Global Routing 的 Proxy 让流量走当前代理策略，Direct 使用直接连接，Config 按当前配置规则处理，Scene 按已设置场景处理。排查时要记录当前姿态，而不是仅看 Home 的连接开关。在 Config 中选中了文件，也仍需确认当前是否按 Config 运行。

应用请求系统隧道规则匹配策略出站目标响应

下面是用于理解匹配顺序的最小规则片段，不是通用加速配置。example.com 是示例域名，192.0.2.0/24 是文档示例网段，不应作为真实业务目标照搬。应用到现有配置前，先明确哪些目标需要 DIRECT，哪些需要 PROXY。

[Rule]
DOMAIN-SUFFIX,example.com,DIRECT
IP-CIDR,192.0.2.0/24,DIRECT,no-resolve
GEOIP,CN,DIRECT
FINAL,PROXY

打开连接记录，找到刚才测试的目标，核对目标域名、命中规则及最终策略。若短暂使用 Proxy 对照后恢复，而 Config 下仍慢，应优先查规则、策略选择和 DNS 相关设置；这个结果只是缩小范围，并不能直接证明整份配置需要替换。完成对照后恢复原来的 Global Routing 姿态。

七、常见追问与排查记录交接

测试延迟很低，为什么看视频还是卡？

延迟测试与视频持续传输不是同一负载。固定同一视频清晰度，观察是否持续缓冲，再对照另一个目标；同时检查该视频域名实际走的是 DIRECT 还是 PROXY，避免用节点探测结果替代业务测试。

更新订阅后变慢，要不要把全部节点删掉？

先保留原配置与可用条目，核对更新后的地址、端口、协议及当前选中节点。确认是否发生节点切换，再使用同一目标复测；删除条目会损失对照条件，也不会修复远端拥塞。

每次从 Wi-Fi 切到蜂窝都要等一会儿，算速度慢吗？

先区分切网重连与稳定传输。检查 Settings → On Demand 的触发条件，等待连接稳定后再开始计时；若稳定后恢复正常，应记录重连现象，而不是与持续吞吐量混为一个问题。

应该给自己的服务维护方发哪些信息？

提供发生时间及所在时区、网络类型、节点标识、目标、错误原文与单变量对照结果。隐藏订阅 token、密码、私钥和完整认证链接；只发必要的诊断字段，避免把凭据暴露在公开交流中。

收尾时恢复测试前的 Config、Global Routing 与 On Demand 设置，并再次访问常用目标。保留一份简短记录：哪个条件改变了、现象是否稳定重现、恢复原值后是否再次变慢。能够反复验证的差异，比一次速度截图更有助于定位问题。更多规则语法可参阅配置大全，术语含义可查阅名词解释。

App Store 正版核对