YouTube 卡顿缓冲、画质自动降级怎么排查
快速结论
先做一个动作定性：在同一节点上开播放器的统计信息，同时下载一个大文件。下载能跑满而视频依然卡，问题就不在带宽，而在 YouTube 这条路径本身——最常见的是视频流域名没跟着走代理、UDP 通道被挡、或播放器降了码率不肯回升。下载同样慢，才是线路带宽问题，那条线索见晚高峰排查那篇。还有一类根本不是网络：4K 与高级编码由 CPU 软解时，画面卡但网络一切正常。
节点延迟很低、测速跑得也不难看，YouTube 却每隔十几秒转一次圈，或者刚点开 4K 就自己掉回 480p。这一页专门处理 YouTube 特有的卡顿：如果你的症状是整条线路在晚上都变慢（网页、下载、会议一起卡），那属于带宽与拥塞，请走晚高峰速度慢的分层排查；如果是 Netflix 之类的解锁失效，见流媒体解锁失效的处理顺序。
三十秒定性：卡顿来自哪一侧
一个动作就能分开两大类原因：播放视频的同时，用同一节点下载一个大文件。
- 下载能跑起来，视频照样卡 → 不是带宽，往下看 ①②③④。
- 下载同样慢、同样断续 → 是带宽或拥塞，那是另一条线索，见本文 ⑤。
- 下载和播放都正常，只有 4K 卡 → 先怀疑本机解码，见 ④。
同时把播放器的统计信息打开（播放画面上点右键即可看到），后面几步都要靠它给的连接速度、缓冲区长度和编码格式来判断。
现象与成因速查
| 你看到的现象 | 最可能的成因 | 对应小节 |
|---|---|---|
| 页面能开，视频一直转圈不出画面 | 视频流域名没走代理 | ① |
| 播放几十秒断一次，禁用 UDP 后好转 | UDP / QUIC 通道不稳 | ② |
| 清晰度自己往下掉且不回升 | 播放器保守降码率 | ③ |
| 只有 4K 或高编码卡，CPU 占用高 | 本机软解 | ④ |
| 网页、下载、会议一起卡 | 线路带宽不足 | ⑤ |
① 视频流的域名没跟着走代理
这是 YouTube 最特有的一条：网页界面和视频流不是同一批域名。规则里放行了主站，却漏掉了承载视频数据的分发域名，结果就是页面正常打开、画面永远加载不出来，或者只有开头几秒能播。
判断依据很直接：临时切到全局模式，如果立刻正常，就是规则漏项。回到规则模式后，把 YouTube 相关的域名整组一起放行，而不是只加主站，改法见 Clash 使用教程。
② UDP 与 QUIC 这条路走不通
YouTube 的传输会优先走基于 UDP 的通道。而 UDP 的转发链条比 TCP 长：客户端要支持、协议要支持、机场落地也要支持，任何一环处理不好都会表现为「连得上但一直缓冲」。
判断依据：在浏览器里禁用该通道，或在客户端把 UDP 走向改为拒绝/回落 TCP，卡顿明显好转就锁定在这一层。这不是修复，是定位——长期方案是换一条 UDP 转发正常的线路。
③ 播放器把码率降下来就不肯升回去
自动清晰度是按实时可用带宽调整的，一次抖动就可能让它切到低档，并在之后一段时间保持保守。它不会主动告诉你「网络其实已经好了」。
验证方法：手动锁定清晰度，然后观察。
- 锁定 1080p 后能连续播完 → 带宽本来就够，是判断偏保守，属于误报。
- 锁定后频繁缓冲、缓冲区长度一直很短 → 带宽确实不够，回到 ⑤。
④ 卡的是你的设备，不是网络
4K 和较新的视频编码格式，如果显卡不支持硬件解码，就会落到 CPU 上软解。表现是画面掉帧、风扇转、而统计信息里的连接速度和缓冲区都很健康。
判断依据两条：播放 4K 时 CPU 占用接近满载；把清晰度降一档后立刻流畅。这两条同时成立，就与机场无关，换多少节点都没用。
⑤ 线路带宽确实不够
到这一步，才轮到带宽。这里只给方法，不给数字：不要抄任何「4K 需要多少兆」的表格，直接从播放器统计信息读你正在看的这段视频的实际码率，再对照同一时刻的实测下载速度。经验上的量级关系是：分辨率每上一档，码率是成倍增长的，4K 与 1080p 之间是数倍差距，而流畅播放需要的余量要高于码率本身。
如果实测速度稳定低于码率，那就是容量问题，处理方式与选型思路见晚高峰排查，以及针对高码率观看需求的流媒体机场专题。同时注意长时间高清观看的流量消耗，估算方法见流量倍率与用量估算。
值得记录的三项观测
与其每次卡顿都重来一遍，不如固定记三个数：统计信息里的连接速度、缓冲区长度、以及当前码率。连续几天在同一时段记录，你就能分清是偶发抖动还是这条线路的常态——后者是换线路的依据，不是继续调参数的理由。
顺带一句边界：同一条线路上 YouTube 卡而 Gmail、搜索都正常，这很常见，因为 Google 各服务对网络的要求本来就不同，差异见 Google 各服务的网络要求。
常见问题
- 测速能跑几十兆，为什么 YouTube 还是卡？
- 测速走的是测速服务器，YouTube 视频流走的是它自己的分发域名，两者的路径和落点都不同。测速数字只能证明这条线路的峰值能力，证明不了到视频节点这一段是否顺畅。用下载大文件与播放同时对照，才能分清是带宽还是路径问题。
- 画质为什么自己从 1080p 掉到 360p？
- 播放器会根据实时可用带宽自动切换码率，这是它的正常逻辑。一旦发生过卡顿，它倾向于保守，短时间内不会主动升回去。手动锁定清晰度可以验证：锁定后能连续播放，说明带宽其实够，是判断偏保守；锁定后频繁缓冲，说明带宽确实不足。
- 4K 卡顿但 1080p 流畅，是线路的问题吗？
- 不一定。要先排除本机：4K 与新的视频编码如果没有硬件解码支持，会由 CPU 软解，表现为画面卡顿、风扇狂转，而网络毫无问题。看一眼播放时的 CPU 占用和播放器统计里的编码格式就能分开这两件事。
- 关掉浏览器的 QUIC 之后就好了，为什么？
- YouTube 的传输会优先使用基于 UDP 的通道，而部分线路、协议或客户端配置对 UDP 的转发不如 TCP 稳定。此时禁用该通道会让它回落到 TCP，卡顿随之消失。这说明问题出在 UDP 这一段，而不是带宽。
- 看 YouTube 很费流量吗？
- 分辨率越高，单位时间消耗越大，4K 与 1080p 的差距是数倍量级。具体数值不要抄别人的表格，打开播放器的统计信息读你自己这段视频的实际码率，再按观看时长估算，方法见流量倍率那篇。
继续这条路径
- 晚高峰速度慢延迟高：丢包严重时的分层排查顺序
白天流畅、一到晚上就卡顿掉速，延迟翻倍、视频会议丢包严重。这类问题绝大多数不在客户端，而在国际出口的高峰拥塞与你本地这条宽带上，本质是拥塞而不是故障。本页按「出口 → 本地链路 → 客户端与测速方式」分层排查，每层给出可复现的判断依据，并说明什么时候该停止折腾、把它当作选型问题处理。
- Netflix 提示代理怎么办：只能看自制剧的解锁排查
播放时提示检测到代理、片库缩水到只剩自制剧、昨天还能看今天就不行——这三种是不同的失效方式，处理动作也不一样。本页按出口 IP 是否被识别、流量是否真的走了代理、账号与 DNS 残留的顺序排开五个顺位，逐条给出判断依据，并说明解锁失效为什么是常态、什么时候该等公告、什么时候该换。
- Google 各服务的网络要求差在哪：为什么有的能开有的不能
同一条线路上，Gmail 收发正常、搜索却一直要人机验证、Play 商店干脆加载不出来。这不是线路时好时坏，而是 Google 各服务对网络的要求本来就不同。本文用三条差异线把搜索、Gmail、Drive、Play 商店、学术、Maps 分类说明，并纠正几个常见误解。