主题
延迟只有几十毫秒，网速为什么还是慢？先查丢包
延迟测的是一个小包的往返时间，跟带宽能不能跑满是两码事。延迟低但速度慢，首先怀疑丢包——用 1400 字节的大包连续 ping 一两分钟，丢包率一出来，答案多半就有了。
故障表现
- 客户端显示节点延迟几十到一百多毫秒，看起来很健康；
- 实际测速远低于套餐带宽，或速度剧烈波动、忽快忽停；
- 网页首屏时间长，视频反复缓冲，下载曲线呈锯齿状起伏；
- 多线程测速分数尚可，单个文件下载却很慢。
如果延迟测试本身全部超时，属于连接问题而非速度问题，见节点超时排查。
最常见原因
延迟、带宽、丢包是三个独立指标。 延迟反映一个小数据包跑完往返的时间；带宽是链路单位时间能承载的数据量；丢包率是传输中损失的比例。延迟测试的包又小又稀疏，轻度拥塞时常能顺利通过，于是出现「延迟漂亮、速度拉胯」的错位。
TCP 重传是丢包的放大器。 TCP 把丢包解读为拥塞信号：每次丢包触发重传，同时收缩拥塞窗口，速度被打回低位后再缓慢爬升。持续丢包时窗口反复被打断，吞吐远低于链路的名义带宽；而且往返时间越长、窗口恢复越慢——同样的丢包率下，远距离节点的速度损失通常比近距离节点更明显。
其余成因还包括：节点带宽超售、跨境链路高峰拥塞（时段规律明显的见晚高峰定位方法）、家中 Wi-Fi 环境差，以及部分网络对 UDP 流量的 QoS 限制。
快速判断方法（附命令）
先做小包与大包的对照。对同一个目标（可用节点入口地址，从配置或客户端日志获取）各 ping 50 次：
:: Windows：先小包，再 1400 字节大包
ping -n 50 目标地址
ping -n 50 -l 1400 目标地址# macOS / Linux
ping -c 50 目标地址
ping -c 50 -s 1400 目标地址小包几乎不丢、大包丢包率明显升高，说明链路在有负载时不稳，符合拥塞特征；两者都丢，链路质量问题更基础。
再用 mtr 看丢包发生在哪一跳：
# macOS / Linux（100 个探测包，显示 IP 与 AS 信息）
mtr -zb -c 100 目标地址Windows 没有自带 mtr，可用 pathping 目标地址 替代，或安装 WinMTR。解读时注意一个常见误区：中间某一跳单独显示高丢包、后续跳恢复正常，多为路由器对 ICMP 限速所致，不代表真实丢包；只有从某一跳开始持续延续到最后一跳的丢包，才值得当真。
分平台测试步骤
Windows
按上面的命令跑完小包与大包对照，再跑一次 pathping；测速时分别记录多线程与单线程的结果。
macOS / Linux
ping 加 mtr 可覆盖大部分场景；mtr 尽量在问题发生的时段运行，好与正常时段对照。
手机端
没有现成的命令行工具，用测速 App 分别在 Wi-Fi 与蜂窝数据下各测一轮：蜂窝下正常、Wi-Fi 下拉胯，问题多在家庭网络一侧。
读懂单线程与多线程的差距
多线程测速同时开几十条连接，单条流因丢包降速时其他流补上，总带宽依然好看；单线程只有一条 TCP 流，丢包的损失原样呈现，更接近网页浏览、视频播放的真实体验。两者差距悬殊时，基本可以断定瓶颈是丢包而非带宽不足。
如何判断是不是机场线路的问题
分两步定位责任段：直连 ping 国内目标干净、ping 机场入口丢包高——问题在你到入口的公网段，换节点（不同节点常有不同入口）或换网络环境验证；到入口干净、走代理后单线程速度依旧上不去，且多个节点表现一致——机场跨境段的可能性大。向客服反馈时附上这些材料，定位效率会高很多：问题时段、节点名称、小包与大包的 ping 结果、mtr 或 pathping 的文本输出、单线程测速数字，以及已换网络复测的说明。长期高峰丢包严重的线路，可考虑专线类型（见 IEPL 与 IPLC 详解），或对照稳定性榜单更换服务商。
FAQ
丢包率多少算有问题？
没有放之四海的标准。偶发的低比例丢包对体验影响有限；丢包持续存在并伴随速度骤降、网页卡顿，就值得处理——重点看趋势和伴随症状，而不是纠结某个具体数字。
ping 目标不通，是不是等于全部丢包？
不一定。不少服务器和节点入口禁用了 ICMP 响应，ping 不通不代表链路断了。换一个确认可 ping 的目标，或直接用应用层的表现来判断。
客户端里显示的延迟和 ping 出来的对不上？
正常。客户端的延迟测试多为 HTTP 请求耗时，包含代理转发、TLS 握手等开销；ping 是纯 ICMP 往返。两者衡量的对象不同，数值没有直接可比性。
UDP 类协议会不会更抗丢包？
Hysteria2 这类基于 UDP 的协议自带更激进的拥塞控制，在高丢包链路上的表现可能好于传统 TCP 类协议，但也更依赖网络对 UDP 的友好程度，原理与适用场景见 Hysteria2 详解。