摘要：测速和大文件下载都很快，只能证明部分链路带宽充足。单个平台在线视频仍卡，要区分缓冲与掉帧，再查CDN、DNS、IPv4/IPv6路径、浏览器和解码。
有位读者留言：超六类网线、万兆网卡，Speedtest下载约8.2Gbps，Steam和迅雷下载能到约5.9Gbps，但在线视频尤其是B站仍然会卡，DNS使用8.8.8.8。
这组数据至少能说明：电脑到测速节点、大文件下载源之间的链路很快。它不能直接证明，浏览器到某个视频分发节点的每一段都稳定。
目前还不知道读者说的“卡”是缓冲转圈、清晰度下降，还是画面掉帧，所以不能把根因直接归给DNS、平台或网卡。下面给一套能复现的排查顺序。
先给结论
-
• 万兆宽带解决的是“总容量”，单个视频请求不一定能用满。 -
• Speedtest、Steam、迅雷和在线视频可能连接完全不同的服务器与线路。 -
• 8.8.8.8并不是所有地区、所有运营商的固定最优DNS，换DNS也不是万能答案。 -
• 缓冲转圈优先查分段下载、CDN与网络路径；缓存充足却掉帧，优先查浏览器、编码和硬件解码。 -
• 不要一次同时换DNS、关IPv6、换浏览器和重置路由器，否则无法知道哪一步有效。
第一步：先确认“卡”的表现
缓冲转圈
画面停住并出现加载动画，进度条前方没有足够缓存。重点看：
-
• 是否只在一个平台出现。 -
• 是否只在晚高峰出现。 -
• 同一视频换浏览器或客户端是否仍卡。 -
• 卡顿时网络请求是否出现超时、重试或速度骤降。
画面掉帧
进度条已经缓存，声音可能正常，画面仍不连贯。优先看：
-
• 视频编码是AVC、HEVC还是AV1。 -
• 浏览器是否启用了硬件加速。 -
• 显卡驱动、CPU/GPU解码占用。 -
• 同一清晰度换客户端或播放器是否正常。
这一步如果分错，后面再高的宽带也可能越查越偏。
第二步：做三个最小对照
一次只改一个变量。
对照一：同一视频换客户端或浏览器
如果客户端正常、某个浏览器卡，先检查扩展、硬件加速、缓存和浏览器版本，不要先动全屋网络。
对照二：同一设备换一个视频平台
如果其他平台稳定，家庭内网和网卡大概率不是唯一矛盾，重点转向当前平台的节点、线路或播放端。
对照三：同一账号换另一台设备
电脑卡、手机或电视正常，继续查电脑端。所有设备都只在同一平台卡，再看出口线路和平台节点。
第三步：不要把公共DNS当作加速开关
DNS负责把域名解析成地址。不同DNS可能返回不同的CDN节点，因此它可能间接影响线路，但不会把一条不稳定路径直接变成稳定路径。
可以先记录当前DNS，再分别测试：
-
• 运营商自动分配DNS。 -
• 一个国内公共DNS。 -
• 当前使用的公共DNS。
每次改动后刷新本地DNS缓存，再用同一个视频、同一时间段对照。没有稳定改善就恢复原设置。
不建议在没有对照数据时只凭“8.8.8.8名气大”判断它一定更快。
第四步：分别测试IPv4和IPv6
同一个域名可能同时有IPv4与IPv6地址，实际走哪条路径由系统、浏览器和网络环境共同决定。
如果路由器或电脑支持，可以在不长期关闭任何协议的前提下做短时对照：
-
1. 记录当前设置。 -
2. 分别测试IPv4和IPv6访问时的卡顿表现。 -
3. 观察是否只有其中一条路径持续异常。 -
4. 测试结束恢复原设置。
不要因为一次卡顿就永久关闭IPv6；也不要把“有IPv6地址”当成线路一定更好。
第五步：卡顿时看真实请求
如果愿意进一步定位，可以打开浏览器开发者工具的Network面板，播放同一个视频，观察媒体分段请求：
-
• 是否大量请求处于Pending。 -
• 是否出现失败、重试或状态码异常。 -
• 单个分段下载时间是否忽快忽慢。 -
• 切换清晰度后是否明显改善。
同时用系统任务管理器观察CPU、GPU视频解码和网络占用。网络占用很低但GPU解码满载，更像本地播放问题；分段请求频繁超时，才继续追线路和节点。
万兆网卡和超六类网线有没有问题
测速约8Gbps、大文件下载约5.9Gbps，已经说明这套有线链路能跑出远高于千兆的吞吐。仍然可以检查驱动、网卡温度、节能设置和丢包，但不应因为单个平台卡就先认定超六类网线或万兆网卡不合格。
真正有效的下一步，是先拿到“卡”的具体表现，再做浏览器、设备、平台、DNS和IP路径的单变量对照。
