文章
机场测速很快但视频卡顿：晚高峰、分流与播放缓冲排查
测速和视频播放访问的服务器、使用的连接方式与负载形态可能不同。因此，“测速很快”只能说明那次测试表现不错，不能排除视频路径上的问题。先记录卡顿条件，再做小范围对照，比反复跑满速测试更有用。
先区分三种现象
开始播放等待很久，需要观察建连与首段内容获取。播放一段时间后缓冲，需要看持续传输和播放需求。画面掉帧但缓冲充足，还应检查设备解码或播放性能，不能只从代理方向处理。
如果平台提供播放统计，记录清晰度、缓冲时长、掉帧以及可见错误。界面中的“连接速度”也应结合平台自身定义，不能直接当成整个套餐的带宽。
先确认视频实际走哪个出口
在客户端连接记录中查看视频播放时相关请求的出站。网页主域名和媒体资源可能分别建立连接，仅检查首页是否经过代理并不充分。
如果规则把不同请求送往不同出口，应结合平台行为和配置判断是否符合预期。先固定一个节点进行诊断，减少自动切换带来的变量。
做四个受控对照
- 保持节点不变，在同一内容上调整播放清晰度，观察缓冲是否改善。
- 保持清晰度和网络不变，切换一个候选节点。
- 保持节点不变，比较不同时间段的表现。
- 保持播放条件尽量一致，比较 Wi-Fi 与更稳定的本地接入方式。
记录每次变化和结果，不把连续点击多个选项后恢复的现象归因于最后一次操作。
如何理解晚高峰变化
若白天可用、晚上明显变差，应继续比较本地网络、多个节点和不同目标服务。只有某个节点变差与所有节点同时变差，指向的范围不同。没有对照数据时，不能直接确定是哪一段容量不足。
网络质量需要综合吞吐量、延迟、抖动和丢包等指标；单一下载峰值不足以描述实时体验。Cloudflare 网络质量研究说明
不建议的“修复”方式
反复下载大文件测速可能额外消耗配额，并与播放竞争当前连接。把所有设置改成看似激进的参数，也会降低诊断价值。先恢复能够解释的简单配置，再逐项验证。
平台的地区限制、账号权限或服务异常也可能导致内容不可播放。若出现明确平台提示，应按平台规则和支持说明处理，不能把所有提示都解释为带宽不足。
可以保留的结论
如果某节点在自己的主要时段、常用设备和目标内容上持续可用，它就是一个有实际依据的候选。记录这些条件，比发布“任意内容永不卡”的结论更准确。