一个低延迟数字证明不了视频流畅

客户端测速可能是一次 TCP 建连、HTTP 请求或特定测试地址的往返时间，具体含义取决于实现。视频连续下载还受吞吐、丢包、拥塞和 CDN 路径影响。某节点能很快返回一个小响应，不代表它能持续供应高码率媒体，更不代表你的设备能及时解码。

先把测试变成可以复现的记录

  1. 选同一段视频、同一时间区间，手动固定画质。暂停其他大下载，保持账号、浏览器和播放器不变。
  2. 固定一个节点，播放几分钟，记录开始缓冲时间、卡顿次数，以及当时的接入网络。时间长短按实际故障频率调整，短测试可能看不到晚高峰问题。
  3. 播放器有统计信息时，记录缓冲余量、估计连接速度、丢帧和当前分辨率。不要将播放器自己的速度估计当成整条线路的带宽保证。
现象优先方向
缓冲余量经常见底，等待下载持续吞吐、线路拥塞、媒体请求分流
缓冲充足但画面掉帧解码负载、浏览器、硬件加速或设备性能
只有一个服务卡顿该服务的 CDN、账号条件或规则
所有节点都在同一 Wi-Fi 下卡无线干扰、本地上行占满或宽带问题
仅在特定时段出现记录相同时段对照，考虑共享链路拥塞

按节点、接入网络、设备三轮比较

  1. 同一网络和画质下，只换节点，重复相同片段。记录实际出口，避免自动选优在后台切换。
  2. 固定表现较好的节点，换有线连接或手机热点。使用蜂窝流量前确认测试用量，持续视频和下载可能消耗较多流量。
  3. 同一网络和节点下，换另一台设备或另一个浏览器。若只有一台设备掉帧，检查资源占用和播放器解码，别继续反复更换远端线路。

这些对照用于缩小范围，不会单独证明某运营商“限速”。服务器负载、缓存命中和媒体分发地址也会变化。保留测试时间与条件，比发布一个最高峰值更有参考意义。

需要命令行测量时，测自己有权下载的固定文件

macOS / Linux；替换 URL 和实际 HTTP 代理端口
curl --proxy http://127.0.0.1:7890 --location \
  --connect-timeout 10 --max-time 60 --output /dev/null \
  --write-out 'HTTP=%{http_code} bytes=%{size_download} avg_Bps=%{speed_download} total_s=%{time_total}\n' \
  'https://example.com/replace-with-test-file'
# 此处为 Bash 续行语法。

Windows PowerShell 中运行时，先将上面的多行命令合并为一行并去掉续行反斜杠，再把 curl 改成 curl.exe、/dev/null 改成 NUL。不要把 Bash 的行末反斜杠原样当作 PowerShell 续行符。

上面的 URL 是占位符，必须换成你有权访问、大小已知的静态文件。先确认 HTTP 状态与实际下载字节，404 错误页不能作为测速样本。speed_download 是平均字节每秒，换算 Mbps 约为数值乘 8 再除以 1000000。达到超时可能只下载了一部分，应明确标为部分样本。不要对他人站点循环压测。

通过 HTTP 代理访问 HTTPS 时，连接计时包含本地代理入口、隧道和远端响应等影响，不能把某一个计时字段直接命名为“节点物理延迟”。一个下载目标测得快，也不能证明另一家视频 CDN 同样快。

检查媒体请求，再做最终验收

在浏览器网络面板查看失败的媒体、清单和 API 请求，并对照客户端连接记录。首页走代理、媒体域名走直连时，先按失败请求修正规则；403 或地区提示应另查权限与服务策略。仅凭看到 h3 或 QUIC 不能断定它是卡顿原因，更不应默认长期关闭所有 UDP。

改完后恢复正常规则和画质，完整播放原先会卡的片段，随后撤销测试规则、临时代理和下载任务。最终保留能够重复改善实际播放的设置，记录它解决的具体场景。