先判断：YouTube 卡顿不一定是节点延迟高

使用 Clash 播放 YouTube 时，视频卡顿、画质反复下降、缩略图无法显示、播放器一直转圈，甚至页面完全加载失败，表面上都像是「代理速度不够」。但实际链路至少包含 DNS 解析、YouTube 页面资源、视频分片、字幕接口、广告或统计请求等多个部分。只要其中一类请求没有按照预期经过代理，就可能出现网页能打开、视频却加载失败，或者视频可以播放但缩略图和评论区域一直空白的情况。

排查时不要一开始就反复更换节点。先确认问题属于哪一种：所有 YouTube 视频都卡顿，通常与节点出口、带宽或线路质量有关；只有部分视频无法播放，可能是地区限制、规则命中错误或特定 CDN 连接异常；视频开头正常、播放几分钟后缓冲，则要重点观察节点持续带宽、连接复用和视频分片是否频繁切换；只有浏览器失败而手机应用正常，则还要检查浏览器代理、QUIC、扩展程序和本机 DNS。

ℹ 正确排查顺序：先确认 Clash 核心正在运行，再测试节点与出口，接着检查模式和规则，之后处理 DNS、TUN 与浏览器协议。每次只改一个变量，并记录修改前后的结果，避免多个设置同时变化后无法判断真正原因。

检查 Clash 核心、节点和代理端口

打开 Clash Verge、Clash Verge Rev、Mihomo 或其他客户端，先观察核心状态是否为运行中。若核心没有启动，系统代理即使显示已开启，浏览器也可能连接到一个没有进程监听的本地端口。进入客户端的连接日志或运行状态页，确认配置已经成功加载，并检查本地 mixed-port、HTTP 端口或 SOCKS 端口是否被其他程序占用。常见端口包括 7890、7891，但不要直接照抄，必须以当前配置显示的端口为准。

接着在代理列表中选择一个稳定节点，不要只看客户端展示的延迟数字。延迟测试通常只测一个小型 HTTP 地址，不能代表 YouTube 视频 CDN 的持续下载能力。一个节点可能测速只有几十毫秒，但高峰期间带宽很低；另一个节点延迟稍高，却能稳定维持高清视频所需的吞吐量。建议分别测试自动选择组、手动节点和备用节点，每次播放同一段视频，观察前两分钟的缓冲状态。

如果客户端提供「测速」「连接测试」或「延迟测试」，可以用它做初筛，但最终应以实际播放为准。播放时打开 Clash 的连接面板，查看是否出现与 YouTube 相关的主机名、连接状态和策略组。若连接记录不断出现超时、连接被关闭或重复重试，优先换节点；若连接稳定但速度仍然很慢，则进一步检查视频流量是否被错误地分到直连、拒绝或低质量策略。

用不同画质区分带宽与规则问题

在 YouTube 播放器中先固定为 360p 或 480p，等待一两分钟后再切换到 1080p。低画质能够稳定播放、高画质持续缓冲，通常说明节点的持续带宽或视频 CDN 路径不足；所有画质都无法开始，则更像是规则、DNS、代理端口或连接协议问题。若 1080p 初始播放正常，几分钟后开始卡顿，可能是节点共享带宽在高峰期下降，也可能是视频分片连接被中途重置。

测试期间不要同时下载大文件、运行网盘同步或开启多个高清视频窗口。代理节点的可用带宽是共享资源，后台下载会让 YouTube 的自适应码率误判网络状态，播放器随后主动降到低画质。完成基础测试后，再逐步恢复其他网络任务，才能判断卡顿究竟来自 Clash 路由还是本机带宽被占满。

检查 Rule、Global 与 Direct 模式

Clash 的运行模式会直接决定 YouTube 请求如何处理。Rule 模式根据规则匹配域名，适合日常使用，但前提是规则集完整且顺序正确；Global 模式会把大多数流量交给当前选定的代理组，适合短时间验证节点和规则问题；Direct 模式则绕过代理，如果本地网络无法稳定访问 YouTube，视频页面可能会停在加载状态。

排障时可以暂时切换到 Global，并手动选定一个确认可用的节点。如果 Global 模式下 YouTube 立即恢复，而 Rule 模式仍然卡顿，说明节点本身大概率没有问题，应回到连接日志检查规则命中情况。重点观察 YouTube 页面域名、视频分发域名和相关静态资源是否都进入同一个代理策略，而不是只有首页域名经过代理。

规则配置中常见的错误是只处理了 youtube.com，却遗漏了 youtu.be、googlevideo.com 或播放器实际连接到的其他 CDN 主机。视频内容通常不会全部从主站域名传输，播放请求可能被分配到不同的内容分发地址。不要凭记忆无限添加域名，应该在 Clash 连接日志中找到实际出现的主机，再根据域名后缀建立规则。 

rules:
  - DOMAIN-SUFFIX,youtube.com,STREAMING
  - DOMAIN-SUFFIX,youtu.be,STREAMING
  - DOMAIN-SUFFIX,googlevideo.com,STREAMING
  - MATCH,DIRECT

上面的片段只是说明规则结构，策略组名称必须替换成你配置中真实存在的组名。规则顺序也很重要：如果前面已经有一条更宽泛的规则把相关请求送往直连，后面的 YouTube 规则不会生效。修改后要重新加载配置，并在连接面板中确认新请求确实命中了预期策略。

DNS、IPv6 与 QUIC：网页能开但视频仍卡的重点

DNS 负责把域名解析为 IP 地址，但解析结果也可能影响 YouTube 分配给你的 CDN 节点。若 DNS 请求走了不稳定的本地线路，或者解析结果与实际代理出口地区不匹配，可能出现页面可以打开、视频分片速度很低的情况。Clash 的 DNS 设置中，应确认启用了与当前内核兼容的 DNS 模式，并观察日志中是否存在频繁超时、解析失败或 fallback 反复切换。

如果你开启了 fake-ip，要留意系统、浏览器和安全软件是否能够正常处理虚拟地址。部分旧软件或企业网络环境会把 fake-ip 视为异常解析，导致连接建立失败。遇到「网页标题能显示，但播放器一直转圈」时，可以临时切换到 redir-host 或客户端提供的兼容模式进行对比。测试结果只用于定位问题，不代表某一种 DNS 模式在所有网络环境下都更快。

IPv6 也是常见变量。设备和网络运营商可能优先返回 IPv6 地址，但当前节点或代理链路对 IPv6 支持不完整，于是浏览器不断尝试一条不可用路径。可以在 Clash 日志中查看连接失败的地址类型，并暂时关闭系统 IPv6 或客户端的 IPv6 解析选项做对照。如果关闭后恢复播放，说明应进一步调整 IPv6 策略，而不是继续更换大量节点。

现代浏览器可能使用 QUIC，也就是基于 UDP 的 HTTP/3。某些代理节点只对 TCP 连接稳定支持，UDP 转发能力较弱，浏览器却持续尝试 QUIC，就可能出现视频加载慢、播放中断或连接反复重建。可以暂时在浏览器中关闭 QUIC，或在 Clash 客户端中确认 UDP 转发是否可用。关闭后如果明显稳定，说明问题集中在 UDP 路径；如果没有变化，则恢复原设置，继续检查 TCP、DNS 和节点带宽。

浏览器代理与 TUN 模式的选择

仅开启系统代理时，支持系统代理的浏览器请求通常能够进入 Clash，但某些应用、扩展、播放器进程或基于 UDP 的连接可能不会遵守系统代理。此时浏览器首页能够访问，不代表所有视频请求都经过同一条路径。先确认系统代理地址和端口与 Clash 当前监听端口一致，再检查浏览器是否安装了独立代理扩展或设置了另一套 SOCKS 代理。

TUN 模式通过虚拟网卡接管更底层的网络流量，适合需要让不支持系统代理的程序也经过 Clash 的场景。开启前应确认客户端具有创建虚拟网卡和修改路由的权限，并留意它是否与公司 VPN、杀毒软件、虚拟机网卡或其他网络加速器冲突。TUN 不是自动提速开关，它解决的是流量接管范围问题；如果节点本身带宽不足，开启 TUN 不会让低速节点变快。

建议采用逐级验证的方式：先关闭 TUN，只用系统代理测试 YouTube；然后开启 TUN，保持同一个节点、同一个视频和同一个画质再次测试。如果只有 TUN 开启后失败，查看路由模式、DNS 劫持、严格路由和 IPv6 相关选项；如果两种模式都失败，则不要把时间集中在 TUN 上，应回到节点质量和规则命中情况。

现象 优先检查项目 建议动作
页面打不开，所有请求超时 核心状态、系统代理、节点 确认端口监听并切换稳定节点
页面能开，视频一直转圈 视频 CDN 规则、DNS、IPv6 查看连接日志并核对实际主机名
低画质正常，高画质缓冲 节点持续带宽、线路拥塞 测试备用节点，减少并发下载
只在 TUN 模式下失败 虚拟网卡、路由、VPN 冲突 关闭冲突网络工具并逐项恢复设置
播放数分钟后中断 UDP、QUIC、连接重置 暂时关闭 QUIC，观察 TCP 播放稳定性

一套可复用的排查流程

  1. 确认核心运行：检查 Clash 客户端状态、当前配置和本地监听端口，确保系统代理没有指向旧端口。
  2. 固定测试条件：选择一条节点，打开同一个 YouTube 视频，暂时关闭后台下载，并把画质固定为 480p。
  3. 切换 Global 验证：在 Global 模式下手动选择节点。如果恢复播放，再回到 Rule 模式检查规则顺序和策略组。
  4. 查看连接日志：确认页面域名、视频 CDN 域名和相关请求是否都经过代理，记录超时或失败的实际主机。
  5. 测试 DNS 与 IPv6：一次只改变一个选项，比较解析失败、连接速度和视频持续播放时间。
  6. 处理 QUIC 和 TUN：先用系统代理测试，再单独对比关闭 QUIC 或开启 TUN 后的表现，避免同时启用多个实验设置。
  7. 最后评估节点：如果规则和本机设置均正常，而高画质仍持续缓冲，应更换线路或联系服务商确认节点带宽，而不是继续堆叠规则。

常见问题

为什么 YouTube 首页能打开，视频却一直加载？

首页和视频内容往往不是同一组域名。页面可能已经通过代理加载，但视频分片请求被规则送往直连、错误策略组或不可用的 CDN 路径。打开 Clash 连接日志，重点查看播放开始后新出现的主机名，并确认它们没有命中 Direct、Reject 或失效节点。

节点延迟很低，为什么播放仍然卡顿？

延迟只反映小数据包往返时间，不能代表持续下载速度、国际出口质量和高峰期带宽。YouTube 播放更依赖稳定吞吐量。应使用同一视频比较不同节点的缓冲表现，并观察高画质连续播放数分钟后的速度，而不是只依据测速排序。

开启 TUN 后是否一定能解决视频卡顿？

不一定。TUN 主要扩大 Clash 能够接管的流量范围，适合系统代理无法覆盖的程序。如果问题来自节点拥塞、DNS 错误、规则遗漏或 UDP 不稳定，TUN 反而可能增加路由复杂度。应先用系统代理完成基础验证，再根据日志决定是否需要 TUN。

浏览器无痕模式正常，普通窗口卡顿怎么办？

这通常与扩展程序、缓存、独立代理设置或浏览器实验功能有关。可以先停用代理扩展和广告拦截扩展，再清理 YouTube 站点数据，并检查浏览器是否启用了独立 DNS 或 QUIC 设置。若无痕模式始终正常，优先从浏览器配置入手，而不是立即修改 Clash 全局规则。

与只会切换全局代理的简单工具相比，Clash Verge、Clash Verge Rev 和 Mihomo 能通过连接日志、规则命中、DNS 模式与 TUN 开关定位 YouTube 的具体故障；一些轻量代理客户端缺少分流可视化，遇到页面能开而视频卡顿时往往只能盲目换节点。若你希望把本文的节点测试、视频域名分流和 TUN 对比流程固定下来，Clash V.CORE 提供了更清晰的策略管理与运行状态查看方式，可以前往下载页完成安装并开始排查。