一、先把现象拆开：缓冲、清晰度锁与「账号半通」不是一回事

遇到YouTube 缓冲时，建议先分清三类表状：纯卡顿（码流经常中断、缓冲环常驻）、清晰度锁定（手动可选档位灰掉或只剩低清）、以及账号与会员异常（登录循环、Premium 徽章消失、家长许可或家庭组反复要求验证）。第一类更像线路质量与 TCP 长会话问题；第二类除了带宽，还常与自适应码率判断「网络不稳」因而拒绝升档有关，背后往往是播放 CDN 与元数据接口出口分裂；第三类则明显偏向 accounts 与 OAuth/Consent 链路，和 googlevideo 无直接替换关系。

若三类现象同时出现，不要假设只有一个根因：同一套错误规则可以同时让鉴权 cookie 写在对的出口、却让实际片源走错线路。先在纸面或备忘录里分别记录复现步骤与大致时间点，再去连接日志里按时间戳对齐主机名，会比盲目堆规则更有效。

二、为什么要单独谈 googlevideo：它通常不是「www 的一个子路径」

YouTube 播放时，浏览器或 App 除请求 youtube.com 页面壳层外，会向大量形如 *.googlevideo.com 的主机拉取分片与清单。这类主机名往往对应不同地区的边缘节点，与实际 Google 账号会话所在的法域、以及客户端认为的「网络质量」共同作用。若 googlevideo 相关连接被前置规则打成 DIRECT，而页面或 API 走代理，播放器可能仍能「勉强开画」，却会在升档与切分辨率时频繁重协商，于是你看到的是长时间缓冲与清晰度被锁叠加。

反过来，若只有主站与账号走直连、而播放域名被迫走了高丢包或频繁切换的代理组，也可能在低码率下勉强播放，但一旦尝试 1080p 或更高就会雪崩式卡顿。工程目标是让与一次完整播放会话强相关的若干主机名在策略意图上收敛到同一稳定出口，而不是把「所有 google 域名」一锅炖进一个组里了事。

三、账号与会员：accounts、googleapis 与 gstatic 为什么要对齐

登录、会话刷新、YouTube Premium 权益校验、通知与部分内容许可，会经过 accounts.google.com、apis.google.com、oauth2.googleapis.com、www.googleapis.com 等方向，以及用于静态脚本与样式的 gstatic.com。其中任一线路若被宽泛的「国内直连」或错误的地区节点截断，就会出现能播广告不能跳片头、会员功能间歇失效或设置页与主站状态不一致的假随机感。

与Spotify 音频 CDN 与账号域那类拆分逻辑相似：不能把「账号一定跟主站」当成默认真命题。请以连接面板中失败或长时间 pending的具体主机名为准，再决定是把这些后缀与 youtube.com 放在同一策略组，还是拆成「账户专用」与「播放专用」两个组。若你尚未跑通基础配置，建议先完成《Clash 订阅链接怎么用？机场配置文件一键导入完整教程》，确保当前编辑的是已生效的那份 YAML。

四、推荐排查顺序：先证据，再换节点

刻意把「换一个更快的节点」放在中后段，是为了避免策略未命中时，在错误的主机名上反复测速。

  1. 确认当前是系统代理还是TUN，以及电视、机顶盒或独立 App 是否绕开了本机代理；必要时以连接日志为准。
  2. 复现缓冲时，在 Mihomo / Clash 连接面板过滤 googlevideo、youtube、ggpht、gvt 等关键字，观察每条连接策略是否为同一组，有无 DIRECT 与代理混用。
  3. 单独复现清晰度锁定：关注是否存在大量短时间失败的 TLS或同一主机名在不同策略间跳动，往往伴随 ABR 拒绝升档。
  4. 复现登录与会员异常：过滤 accounts、googleapis、oauth，看是否有被拦、RST、或 DNS 解析到意外段。
  5. 检查DNS：fake-ip 是否与真实连接目标一致；海外域名的上游是否被污染；必要时收紧 nameserver-policy（以所用内核文档为准）。
  6. 在规则顺序与 DNS 合理后，再挑选抖动小、长时吞吐稳定的节点，并关闭对同一播放主机名过于激进的自动故障转移。

通用端口、内核崩溃或订阅拉取失败等问题，请对照《Clash 常见报错解决方案》；本文只覆盖 YouTube Clash 播放与账号链路的域名级半通。

五、系统代理与 TUN：谁覆盖网页、谁覆盖独立 App

仅开系统代理时，尊重系统代理的浏览器会走 Mihomo 的 mixed 端口；但部分 TV App、嵌入式 WebView 或旧版播放器可能不遵循系统代理，于是出现「电脑浏览器 4K 正常、电视只能 480p 且狂缓冲」的分裂。若你核对过规则仍如此，可评估TUN 模式在网卡层统一 TCP 路径，使googlevideo 连接也进入内核分流。

启用 TUN 前建议阅读《Clash TUN 模式开启方法》，并在启用后回到连接日志确认YouTube App 对应进程没有仍显示为 DIRECT 绕过。多设备共享网关的场景，可与《Clash 开启局域网代理》对照，保证网关与 DNS 指向同一台运行 Mihomo 的机器。

六、播放侧：manifest、分片与缩略图 CDN

除 googlevideo 外，缩略图与静态资源常涉及 ytimg.com、ggpht.com 或 Google 静态资源域。若界面图全裂而视频仍隐约能动，多半不是播放主干坏了，而是图片 CDN 被错误直连或走了另一条高延迟线路；这会加重客户端重试，让你主观感觉「整体都卡」。连接日志里请单独看待这些主机名，不要盲目把它们与 googlevideo.com 混写进同一条过宽规则，以免波及其他业务。

站内 《NBA League Pass 直播分流》同样讨论长视频下的边缘与鉴权拆分，但体育赛事拉流与 YouTube 点播的主机名集合不同，可借鉴排查顺序而非照搬条目。

七、DNS、fake-ip 与双栈：半通常从解析开始

启用 fake-ip 后，解析与建连的一致性更依赖内核实现与规则顺序。YouTube 缓冲若集中在某条 manifest 或首分片请求失败之后，往往要先核对DNS 答案与最终 SNI是否匹配，而不是先加十条 DOMAIN-SUFFIX。

在双栈网络下，若客户端优先 IPv6 外出，而你的代理策略主要覆盖 IPv4，也可能出现「偶发能播、多数失败」的假象。请在出问题的设备上确认同一播放会话内的地址族是否一致，必要时在路由器侧临时关闭不完整的 IPv6 出口，避免与 Clash 分流规则打架。

八、清晰度锁定：不全是「会员」与「版权」

播放器把清晰度灰掉，有时是区域与版权限制，但在代理半通场景里，更常见的是自适应算法认为链路质量不足：TLS 握手慢、分片下载超时、或 CDN 边缘与账号会话看到的出口地理不一致，都会让客户端拒绝升档。把googlevideo 与账号域名的策略对齐之后，若灰掉的选项恢复，多半说明瓶颈在路由而非账号本身；若仍灰掉，再回头查证Premium 状态与客户端版本，避免无效折腾节点。

九、Clash 分流规则：示例片段（请替换策略组名）

下列 YAML 演示如何把常见 Google / YouTube 相关后缀显式指向同一代理组。将 PROXY 换成你的策略组名，并把片段放在过于宽泛的 GEOIP 或 MATCH 之前；若与订阅自带「国内直连」冲突，需提高本条优先级或收窄匹配。实际生产环境以连接日志为准，勿把示例当作永久完整清单。

# Example only — replace PROXY with your policy group name
rules:
  - DOMAIN-SUFFIX,youtube.com,PROXY
  - DOMAIN-SUFFIX,googlevideo.com,PROXY
  - DOMAIN-SUFFIX,ytimg.com,PROXY
  - DOMAIN-SUFFIX,googleapis.com,PROXY
  - DOMAIN-SUFFIX,gstatic.com,PROXY
  - DOMAIN,accounts.google.com,PROXY

对日志中出现的具体 CDN 主机名，按需追加 DOMAIN 规则。若某后缀与其它服务共用且你不想整条代理，可改用更窄的匹配或进程级规则（视内核与客户端能力而定）。部分条目在日志里以 IP 出现，此时除域名规则外还需结合 TUN 与路由文档中的高级选项，本文不展开具体开关，以免与版本差异冲突。

十、与订阅规则冲突时怎么收敛

许多订阅自带大块「国内直连、海外代理」规则。googlevideo 与 googleapis 有时会被误判到错误的组，或accounts 被错误直连导致 OAuth 半通。处理方式是：把与 YouTube 强相关、且你在日志里反复看到的主机名写成靠前、更具体的规则，修改后观察「同一分钟内」连接策略是否整体统一。

若合并多份配置，注意后加载文件是否覆盖策略组或清空自定义规则；长视频用户常在不重启客户端的情况下长时间停留在同一 App，更容易遇到「偶发失效」的合并顺序问题。

使用代理访问 YouTube 或改变出口地区可能违反平台用户协议或当地法律。本文仅讨论网络路径、DNS 与 Clash 分流规则等工程话题，不构成任何违法用途指引。请读者在合法合规前提下阅读与实践，并自行承担相应责任。

十二、小结：把缓冲与清晰度锁拆成可验证的主机名清单

YouTube 缓冲、清晰度锁定与账号验证异常，多数是模式、DNS、规则顺序、节点稳定性与youtube.com / googlevideo / 账号 API路径不一致叠加的结果，而非单一「坏节点」。按本文顺序，你可以在连接日志里得到明确命中记录，再决定是否需要为图片 CDN 与播放 CDN 分设策略组。

当你希望少手写 YAML、用图形界面统一管理连接记录与策略切换时，成熟客户端在 Mihomo 内核上的整合度较高，长视频场景下也比零散工具组合更省心。相比单纯追求测速榜第一名，稳定、可预期的策略命中对降低 YouTube 缓冲往往更有效。→ 立即免费下载 Clash，开启流畅上网新体验