Clash 看 YouTube 一直转圈、首页能打开但视频播放失败，未必是节点速度不够。问题也可能出在代理模式、分流规则、DNS 解析、浏览器缓存，或当前网络对连接的限制。排查时不要一次改很多设置，建议先确认 Clash 正在接管流量，再逐项检查 YouTube 相关域名是否走对策略，最后用不同视频和节点验证。这样既能缩小范围，也能避免把原本正常的配置越改越复杂。
先判断卡在哪个环节
YouTube 播放涉及网页、接口、缩略图和视频流等多类请求。页面可以打开，不代表播放所需的所有连接都正常；反过来，节点测速延迟低，也不代表它能稳定传输长时间的视频数据。先观察故障表现，比直接换节点更有用。
| 表现 | 优先怀疑 | 先做什么 |
|---|---|---|
| YouTube 页面打不开 | 代理未接管、系统代理设置或节点不可用 | 确认 Clash 已启动，并测试其他需要代理的网站 |
| 页面能开，缩略图或评论加载不全 | 相关域名分流不一致、DNS 解析异常 | 检查 YouTube 域名规则及连接记录 |
| 视频能播，但画质低或持续缓冲 | 节点带宽、丢包、线路拥塞或视频流规则 | 换节点做同一视频对照测试 |
| 只有一个浏览器或设备异常 | 浏览器缓存、扩展程序或设备代理设置 | 用无痕窗口或另一浏览器复测 |
| 切换节点后短暂恢复又卡住 | 自动测速策略切换、线路不稳定或连接复用 | 临时手动固定一个节点，再重复播放测试 |
排查前先记录当前节点、代理模式、视频画质和故障时间。选择一段可重复播放的视频，先以较低画质播放两三分钟，再逐步提高画质。若不同视频都卡，问题更可能在网络路径或代理配置；若仅某一条视频异常，则也要考虑视频本身、地区可用性或 YouTube 服务端状态。
确认 Clash 正在接管浏览器流量
先检查客户端主界面中的运行状态。Clash Verge、Clash Verge Rev、Clash for Windows 等桌面客户端通常提供系统代理开关；如果使用 TUN 模式，还要确认 TUN 已启用且系统已授权。ClashX、Clash for Android 和 Mihomo 的入口名称可能不同，但排查目标相同：确认浏览器请求确实经过当前运行的代理内核，而不是直接连接网络。
- 确认 Clash 内核已启动，配置文件已成功加载，界面没有提示配置解析失败。
- 查看系统代理是否开启。若使用规则模式，确认浏览器没有单独设置其他代理地址，也没有启用与 Clash 冲突的代理扩展。
- 若依赖 TUN 接管流量，检查 TUN 状态、系统权限和虚拟网卡是否正常。修改 TUN 或系统代理后，按客户端提示重新连接或重启内核。
- 在客户端的代理页面选择一个确定可用的策略组和节点，不要只看测速结果，还要实际打开网页并播放视频。
建议先用浏览器访问一个平时需要代理的网站，再回到 YouTube 测试。如果两个网站都无法访问，优先检查 Clash 是否运行、节点是否有效、系统代理或 TUN 是否接管成功。如果其他代理网站正常，只有 YouTube 异常，则把排查重点转到 YouTube 分流规则、DNS 和视频流连接。
检查 YouTube 分流规则与命中策略
规则模式下，网页不同请求可能命中不同规则。YouTube 页面常见的相关域名包括 youtube.com、youtu.be、googlevideo.com、ytimg.com 和 youtubei.googleapis.com。其中，视频数据通常通过 googlevideo.com 下的主机名传输。若页面域名走代理、视频流域名却命中直连，可能出现首页可用但播放转圈、画质无法提升或缓冲中断。
打开 Clash 客户端的连接记录或 Dashboard 连接页面，在开始播放视频后观察新出现的连接。重点看目标域名、命中的规则类型和最终使用的策略组。不同版本界面的字段名称可能略有差异，但应能判断请求是走代理、直连还是被拒绝。播放时如果看不到与 YouTube 相关的连接，也要重新确认浏览器是否由当前 Clash 接管。
如果确认视频流域名走错策略，可检查配置中的规则顺序或客户端提供的规则覆写功能。规则按从上到下的顺序匹配，先命中的规则会决定后续策略；因此，针对 YouTube 的规则应放在可能覆盖它的宽泛规则之前。下面只是说明规则结构的示例，策略组名称必须替换为配置中真实存在的名称：
rules: - DOMAIN-SUFFIX,youtube.com,Proxy - DOMAIN-SUFFIX,youtu.be,Proxy - DOMAIN-SUFFIX,googlevideo.com,Proxy - DOMAIN-SUFFIX,ytimg.com,Proxy - DOMAIN-SUFFIX,youtubei.googleapis.com,Proxy
示例中的 Proxy 只是占位名称，不是所有配置都自带的策略组。若订阅使用规则集或覆写模板，直接编辑生成配置可能会在更新订阅后丢失；优先使用客户端支持的规则覆写、脚本或自定义规则入口。修改后重新加载配置，并再次检查连接记录确认规则确实命中预期策略，而不要仅凭规则文件里出现了域名就判断已经生效。
排查 DNS、缓存与浏览器干扰
DNS 解析异常会让请求连接到错误地址，或造成某些视频主机连接失败。若更换策略组仍无法改善，可以先在客户端中确认 DNS 功能状态，检查最近是否修改过 DNS 上游、增强模式或 fake-ip 相关设置。排查时一次只调整一个项目，并在每次调整后重新连接、清理对应缓存或重启浏览器，再用相同视频复测。
如果刚改过 DNS 配置，先恢复到客户端原先可用的配置，确认基础解析正常后再测试播放。不要为了追求速度随意叠加多个 DNS 插件，也不要在不了解用途时复制整段陌生配置；DNS 设置与 TUN、系统解析方式以及规则模式存在关联，改动过多反而难以判断原因。对于 fake-ip 配置，若只某些应用或域名异常，应重点查看相关过滤项及客户端日志，而不是直接关闭整个 DNS 模块。
- 在无痕窗口打开同一视频，排除旧缓存、登录状态或站点数据造成的影响。
- 临时停用广告拦截、隐私保护和代理类扩展，再重新加载视频页面；某些扩展会拦截播放器接口或媒体请求。
- 清除浏览器中 YouTube 的站点缓存后重新登录测试。清理前确认是否会影响需要保留的站点登录状态。
- 检查设备系统时间是否准确。时间异常可能影响 TLS 证书校验，造成连接失败或安全警告。
- 如只有一台设备出问题，分别用另一浏览器或另一网络测试，判断故障是否局限在当前设备。
浏览器中的“安全 DNS”或加密 DNS 设置也可能改变域名解析路径。如果 Clash 已负责 DNS 处理，但浏览器又单独使用另一组解析服务，实际行为可能与预期不同。可以暂时恢复浏览器默认 DNS 设置进行对照测试；只有明确知道网络环境和配置目的时，才应长期调整该选项。
用对照测试判断节点与线路
节点延迟低不等于视频体验好。延迟测试通常只测一次短请求，无法完整反映持续下载时的带宽、丢包、晚高峰拥塞和线路稳定性。测试节点时，应保持规则、设备、浏览器和视频不变，只切换节点，这样才能确认播放差异是否来自线路。
- 选择一个稳定的 YouTube 视频，先记录当前节点下的缓冲表现和可选画质。
- 在 Clash 代理策略组中手动切换到另一个节点，等待连接建立后重新加载同一视频。
- 分别测试不同地区或不同线路的节点。如果某个节点可以稳定播放，而另一个节点反复缓冲，优先选择表现稳定的线路。
- 再测试自动选择或自动测速组。如果手动节点正常、自动组异常，检查自动组是否频繁切换，或测速目标是否能代表实际视频传输质量。
- 在不同时间段重复测试。若白天正常、晚间明显变慢，可能是线路高峰拥塞，而不是配置突然失效。
测速时不建议一边播放一边连续触发全组测速，也不要把多个节点的带宽简单相加来推断单个视频会更快。单个媒体连接最终仍受所选线路质量、远端服务和设备网络共同影响。如果同一节点在其他网站下载也明显变慢，问题更可能与节点线路或本地网络有关；如果只有 YouTube 慢，则回头检查相关域名是否被拆分到不同策略。
常见问题
为什么 YouTube 首页能打开，视频却一直转圈？
页面和视频流可能连接到不同域名。检查连接记录中 googlevideo.com 相关请求的命中规则和策略组；如果视频请求走了直连或错误节点，而页面请求走代理，就可能出现页面加载但视频无法播放的情况。
延迟很低，为什么播放还是卡？
延迟只反映短请求的往返时间，不代表持续传输能力。视频播放还受带宽、丢包、拥塞、节点出口和高峰时段影响。用相同视频对照测试多个节点，观察持续播放和画质变化，比单看延迟数字更可靠。
要不要把所有 Google 域名都强制走代理？
通常不建议在没有确认影响范围时把所有 Google 域名一律改到同一策略。不同服务请求可能有不同用途，宽泛规则还可能覆盖其他配置。先从连接记录中找出实际失败的域名，再用范围尽量明确的规则测试，并留意规则顺序和策略组名称。
切换节点后仍然卡，需要立即重装 Clash 吗？
通常不必先重装。先检查节点是否可用、配置是否成功加载、系统代理或 TUN 是否接管、规则是否命中，以及浏览器扩展和 DNS 是否干扰。只有在确认配置文件损坏、内核持续报错或客户端无法正常启动后，才考虑备份配置并修复或重新安装。
排查 YouTube 缓冲问题，最有效的方法是逐项验证：确认 Clash 接管流量，检查 YouTube 视频流域名的实际分流，排除 DNS 与浏览器干扰，再通过同一视频对比节点表现。每次只改一个设置并保留测试结果，通常能更快找到故障环节；如果最终确认是特定线路在高峰期不稳定，选择播放更连贯的节点，往往比继续堆叠规则更实际。