用 Clash 播放 YouTube 时频繁缓冲，很多人第一反应是「节点太慢」，然后不断切换国家、重启客户端，甚至重新购买订阅。实际上，YouTube 卡顿可能同时受到代理模式、分流规则、DNS 解析、TUN 接管范围、节点带宽与本地网络影响。尤其是视频页面可以打开，但画面停在加载圈、清晰度反复下降，往往说明网页请求与视频 CDN 请求没有走同一条稳定路径。本文以 Clash Verge Rev、Mihomo 等常见客户端为例，按照「确认现象 → 检查模式 → 核对规则 → 优化 DNS → 测试 TUN → 判断节点质量」的顺序，帮助你定位真正的瓶颈。
开始前建议先固定一个测试条件：使用同一台设备、同一个 YouTube 视频、同一网络环境，并暂时关闭其它 VPN、浏览器代理插件和下载任务。不要在每一步都同时换节点、改 DNS、开 TUN，否则即使问题消失，也很难知道是哪项修改起了作用。代理工具应遵守所在地区的法律法规以及学校、公司网络政策；本文只讨论 Clash 的网络排障与配置思路。
先判断：YouTube 卡顿属于哪一种问题
YouTube 的「卡」并不只有一种表现。若视频页面完全打不开，首页缩略图也加载失败，通常优先检查代理是否生效、规则是否把 Google 相关请求送去了直连，以及 DNS 是否能够正确解析域名。若页面可以打开，视频也能开始播放，但每隔几十秒就停顿，则更像是节点带宽不足、晚高峰拥塞、视频 CDN 路由不稳定或清晰度过高。
还有一种容易被误判的情况：视频能播放，但画质从 1080p 自动降到 360p。此时不一定是 Clash 配置错误，YouTube 的自适应码率算法可能根据最近几秒的吞吐量主动降级。如果拖动进度条后能继续播放，却很快再次降画质，说明当前链路的持续下载速度不足；如果只有某几个视频卡顿，而其它视频正常，也可能是不同视频使用了不同的 CDN 节点。
- 页面和缩略图都打不开：优先检查系统代理、Clash 运行状态和 Google 域名规则。
- 页面正常、视频一直转圈：检查视频域名是否命中代理，确认节点支持稳定的大文件传输。
- 能播但频繁降清晰度：重点比较节点持续带宽、延迟抖动和丢包，而不是只看一次测速结果。
- 只有浏览器卡、手机正常：排查浏览器扩展、QUIC、系统 DNS 和桌面端代理模式。
- 所有设备同时卡顿：更可能是订阅节点、家庭宽带出口或 YouTube 高峰期线路问题。
播放视频时打开 Clash 的连接或日志页面，搜索 youtube、googlevideo、ytimg 和 googleapis。如果能看到相关请求，并且策略列显示为代理策略组，说明流量至少进入了 Clash；如果请求全部显示 DIRECT，或者完全没有出现在连接列表里，就不要急着责怪节点，先修正代理接管范围。
检查代理模式：先用可控方式确认流量进了 Clash
Clash 常见的运行方式包括规则模式、全局模式和直连模式。日常使用通常推荐规则模式，因为国内站点和本地服务可以保持直连；但排查 YouTube 卡顿时，短时间切换到全局模式有助于排除规则误判。测试时只需要播放同一个视频一两分钟，不建议长时间全局代理，因为所有应用流量都会经过节点，可能增加带宽消耗，也可能影响网银、企业内网或本地服务。
确认系统代理已开启
在 Clash Verge Rev 中，先确认客户端本身处于运行状态，再检查系统代理开关。Windows 可以到系统代理设置里确认地址和端口是否与 Clash 的 mixed-port 对应；macOS 则检查当前 Wi-Fi 或有线网络的代理选项。浏览器若安装了 SwitchyOmega 等代理扩展，还要确认扩展没有覆盖系统设置，避免出现「系统代理开着，但浏览器实际使用另一端口」的情况。
如果使用 Firefox，需要特别注意它可以单独配置代理，不一定继承操作系统设置。Chrome、Edge 等浏览器大多跟随系统代理，但企业策略、扩展程序或隐私工具也可能改变行为。最简单的验证方式是：打开 Clash 连接面板，然后访问一个已知会产生外部请求的页面，观察面板是否出现新的连接记录。没有记录时，应先修客户端端口和代理接管，不要继续修改 DNS。
用全局模式做一次对照测试
将 Clash 临时切换为全局模式，并选择一个当前延迟较低、负载较小的节点，然后重新打开 YouTube。若全局模式下明显改善，而规则模式下卡顿，问题通常位于规则顺序、策略组选择或域名匹配。若两种模式表现完全一样，则应继续检查节点带宽、DNS、TUN 或本地网络。
全局模式测试结束后记得切回规则模式。不要把「全局能播放」直接理解为「节点一定很好」，因为全局模式只是让更多相关域名使用了同一个出口，可能暂时绕开了规则集中的错误分类。长期方案仍应是为 YouTube 相关请求设置清晰、可验证的策略。
核对 YouTube 分流规则：不要只代理网页域名
YouTube 并不是只访问 youtube.com 一个域名。页面、缩略图、账号鉴权、播放器脚本和视频分片可能来自不同主机。常见域名包括 youtube.com、www.youtube.com、youtu.be、googlevideo.com、ytimg.com 以及部分 Google 相关服务域名。不同订阅模板的规则集写法不完全一致，有些只覆盖网页域名，却没有覆盖实际承载视频内容的 googlevideo.com，于是会出现「页面能开，视频缓冲」的典型现象。
在连接面板中播放视频并拖动进度条，观察新增连接的最终策略。重点不是看到一个 youtube.com 请求就算成功，而是确认视频播放过程中持续出现的相关连接没有被判为 DIRECT。如果连接列表显示 googlevideo.com 走直连，而 youtube.com 走代理，基本可以确定分流不完整。
若客户端支持自定义规则或覆写，可以在规则集靠前位置添加针对 YouTube 的域名规则，并指向稳定的代理策略组。示例只是表达匹配思路，策略组名称必须替换成你配置中实际存在的名称：
rules:
- DOMAIN-SUFFIX,youtube.com,YouTube
- DOMAIN-SUFFIX,googlevideo.com,YouTube
- DOMAIN-SUFFIX,ytimg.com,YouTube
- DOMAIN-SUFFIX,youtu.be,YouTube规则顺序非常重要。若在这些条目之前已经有宽泛的 GEOIP,CN,DIRECT、某个覆盖范围很大的规则集，或者把 Google 服务统一送往直连的条目，后面的 YouTube 规则可能永远不会生效。修改后应重新加载配置，再关闭并打开一次视频页面，确认面板中的策略已经变化。不要只编辑了 YAML 文件却忘记点击「重新载入」或切换到当前配置。
不同内核对域名嗅探、HTTP/3 和规则匹配的处理可能存在差异。若你使用 Mihomo 内核并开启了增强模式，真实域名通常更容易出现在连接日志中；但开启嗅探并不等于所有连接都会自动获得正确规则。排障时仍应以实际连接记录为准，不要仅凭配置文件里的规则文字推断结果。
DNS 与 TUN 设置：解决解析错误和漏代理
DNS 问题经常被忽略。浏览器访问 YouTube 时，先要解析网页、图片和视频主机；如果 DNS 返回的地址不可达，或者本地解析结果与代理出口不匹配，可能出现页面加载慢、播放器反复重连和清晰度突然下降。尤其是在规则模式下，系统 DNS、浏览器 DoH、Clash 内置 DNS 可能同时存在，导致「浏览器解析一套地址，Clash 连接又使用另一套地址」的分裂情况。
如果客户端提供 DNS 模式选项，可以先使用配置文件推荐的模式，不要同时叠加浏览器 DoH、系统代理和第三方 DNS 工具。启用 fake-ip 或 redir-host 后，应观察 Clash 日志是否出现异常的 DNS 超时、反复查询或大量 fallback。DNS 服务器并非越多越好，堆叠过多上游反而会让故障难以复现。建议一次只保留一套清晰的解析路径，并在改变后重新测试同一个视频。
TUN 模式适合浏览器不遵循系统代理、应用使用自定义网络栈，或者你希望在路由层接管更多 TCP/UDP 流量的场景。开启 TUN 后，流量通常会经过虚拟网卡，再由 Clash 内核依据规则处理。它能解决一部分「系统代理已开但某个应用仍直连」的问题，但也会引入权限、路由冲突和 DNS 接管等新变量。
- 首次启用 TUN 前，关闭其它 VPN、网络加速器和虚拟网卡工具。
- 确认客户端获得管理员权限或系统要求的网络权限。
- 开启后观察 YouTube 连接是否出现在 Clash 面板，而不是只看网页能否打开。
- 如果出现所有网站变慢、局域网设备无法访问或 DNS 大量超时，先关闭 TUN 回到系统代理模式。
- 不要在没有对照测试的情况下同时启用 TUN、全局模式和多个 DNS 劫持工具。
对于普通浏览器用户，推荐先采用规则模式加系统代理；只有确认目标应用不读取系统代理，或者需要接管 UDP、QUIC 等流量时，再尝试 TUN。设置稳定后不要频繁切换内核模式，因为每次模式变化都可能改变 DNS、路由表和连接复用状态。
判断节点质量：看持续速度，而不是只看延迟
YouTube 播放需要的是持续、稳定的吞吐量。节点延迟低并不代表视频一定流畅：延迟测试通常只发送很小的数据包，而视频播放会持续下载大量分片。一个延迟 80 毫秒但高峰期带宽稳定的节点，可能比延迟 40 毫秒但频繁丢包的节点更适合观看视频。
建议在同一时间段测试三个节点，每个节点播放同一个视频，并固定清晰度。观察以下指标：开始播放需要等待多久、拖动进度条后恢复速度如何、缓冲是否规律出现、清晰度能否稳定保持，以及 Clash 面板中的连接是否频繁重连。不要只看测速网站的瞬时峰值，视频场景更重视连续五到十分钟的平均表现。
节点负载也会影响体验。订阅中标记为低倍率、专线或高速的节点不一定全年稳定，晚高峰仍可能拥塞。若某个节点白天流畅、晚上固定卡顿，说明更像是共享带宽或出口拥塞；若所有时间都卡，则需要检查线路质量、节点到 YouTube CDN 的路由或订阅服务本身。切换节点时，最好等待旧连接关闭后再重新加载视频，避免播放器继续复用旧连接。
| 观察结果 | 更可能的原因 | 优先处理方式 |
|---|---|---|
| 全局流畅，规则模式卡顿 | 规则顺序或策略组误判 | 检查 YouTube、googlevideo.com 的命中策略 |
| 所有节点都卡，网页也慢 | 本地网络或 DNS 异常 | 关闭其它 VPN，重新检查 DNS 与系统代理 |
| 只有一个节点卡顿 | 节点拥塞或线路质量差 | 切换同地区其它节点并做持续测试 |
| 页面正常但视频转圈 | 视频 CDN 域名未正确代理 | 检查 googlevideo.com 和连接日志 |
| TUN 开启后改善明显 | 浏览器或应用未遵循系统代理 | 保留 TUN，排除路由和 DNS 冲突 |
浏览器与播放器设置：避免把本地问题误判为节点问题
确认 Clash 分流正确后，还可以检查浏览器自身。某些浏览器会优先使用 QUIC，也就是基于 UDP 的 HTTP/3 连接；如果当前节点、TUN 或本地防火墙对 UDP 支持不稳定，播放器可能频繁重连。可以暂时关闭浏览器的 QUIC 或 HTTP/3 功能做对照测试。如果关闭后明显稳定，说明问题可能集中在 UDP 路径，而不是普通 HTTPS 代理本身。这个选项因浏览器版本而异，修改前建议记录原始状态。
浏览器扩展也可能造成重复代理。代理切换扩展、隐私防跟踪扩展、广告过滤器和脚本拦截器都有可能修改 YouTube 请求。排查时可以打开无痕窗口，或暂时停用与网络请求有关的扩展，再播放同一视频。无痕窗口通常不会自动加载所有扩展，但具体行为取决于浏览器设置，仍应以扩展管理页面为准。
如果只在高画质下卡顿，可以先把清晰度固定为 720p 进行比较。若 720p 长时间稳定，而 1440p 或 4K 持续缓冲，说明当前链路的有效吞吐量不足，并不代表 Clash 完全失效。对于移动热点、校园 Wi-Fi 和高峰期家庭宽带，降低清晰度往往比反复修改规则更有效。若低清晰度也频繁卡顿，则继续检查节点和 DNS。
常见问题
YouTube 页面能打开，但视频一直转圈，最先查什么？
先打开 Clash 连接面板，在播放并拖动视频进度条时搜索 googlevideo.com。如果视频相关连接显示为 DIRECT，优先修正规则；如果已经命中代理，继续比较不同节点，并检查 DNS 是否存在超时或解析分裂。不要只检查 youtube.com，因为实际视频分片经常由其它域名承载。
全局模式能看，规则模式不能看，是否必须一直开全局？
不建议把全局模式当作长期方案。这个现象通常说明规则没有覆盖完整，或 YouTube 相关域名被更早的直连规则截获。应在连接日志中找出实际请求的主机名，再把必要域名加入正确的代理策略组。修正后切回规则模式，既能保持 YouTube 稳定，也能让国内网站和局域网服务继续直连。
开启 TUN 后 YouTube 变流畅，但局域网访问异常怎么办？
先确认是否存在其它 VPN、虚拟网卡或代理软件与 TUN 抢占路由。检查局域网网段、DNS 劫持和绕过列表，必要时暂时关闭 TUN，使用系统代理与规则模式完成对照。若只有浏览器使用，系统代理通常更简单；如果多个应用都不遵循系统代理，才考虑保留 TUN 并逐项修正绕过规则。
更换节点后暂时流畅，过一会儿又卡，是 Clash 配置失效了吗？
不一定。更换节点后恢复、晚高峰再次卡顿，常见原因是共享出口拥塞、节点带宽不足或到视频 CDN 的路径变化。可以在相同时间测试多个节点，记录持续播放表现。如果只有某个节点反复卡顿，保留其它节点并调整策略组；如果所有节点都受影响，则应检查订阅服务、家庭宽带和本地网络。
与一些只提供浏览器开关、却无法查看连接命中结果的代理工具相比，Clash 的优势在于可以同时核对代理模式、域名规则、DNS 路径和节点策略：例如页面走代理但 googlevideo.com 直连时，连接面板能直接暴露问题；遇到浏览器不认系统代理，也可以用 TUN 做明确对照。若你正在寻找一套能够细分 YouTube 流量、保留国内直连并方便定位卡顿原因的客户端，可以先从适合自己设备的 Clash 版本开始了解。