一、先分清：页面能开≠视频能流畅拖进度
在浏览器里访问 YouTube，地址栏往往是 youtube.com 或其国家子域；但点击播放后，大量字节实际从 *.googlevideo.com 等主机名拉取。若 Clash 规则只覆盖了「看起来相关」的关键字，或策略顺序导致一半直连、一半走代理，就会出现典型症状：页面骨架与评论能加载，播放器却长时间转圈；或能播几秒后卡住，拖动进度条时重新缓冲。
点播与直播对链路质量的要求也不完全相同：点播更强调突发下载与缓冲窗口，直播更强调持续低抖动与 UDP / QUIC 路径（具体协议栈随客户端与地区策略变化，以你本机抓包为准）。因此排查时不要只盯着「能不能 ping 通某个节点」，而要看日志里实际命中的主机名是否与预期策略组一致。
二、与 Gemini / Google API 专文差在哪
站内 《Google Gemini 与 Clash 规则》侧重 gemini.google.com、googleapis.com 等与对话与 API相关的端点；而YouTube 网页播放的主要吞吐在视频 CDN与媒体分片请求上，主机名形态与「写 YAML 解锁 AI」类教程里常见的泛 Google 列表并不等价。把整站所有 Google 流量一股脑塞进同一组，有时能「碰巧好用」，但一旦节点对媒体路径拥塞，你会看到只有视频卡、其它 Google 产品尚可的分裂现象。
本文刻意从播放链路切入：优先保证 youtube.com 与 googlevideo.com（以及缩略图、统计等强相关域）在规则顺序与策略组上的一致性，再讨论是否需要把其它 Google 服务拆到不同组。这样与「Gemini/API」专文检索意图区分开，也避免写成泛泛的「解锁 YouTube」口号文。
| 对比项 | Gemini / Google API（#11 类专文） | YouTube 网页播放（本文） |
|---|---|---|
| 主要痛点 | 对话页白屏、API 握手失败、OAuth 中断 | 缓冲、转圈、清晰度骤降、直播断续 |
| 关键主机名侧重 | googleapis.com、产品子域、账号域 |
googlevideo.com、youtube.com、图片与静态域 |
| 节点选择侧重点 | 长连接稳定、TLS 与账号会话 | 高吞吐、低丢包、路径与 CDN 区域相对一致 |
三、播放链路里常见主机名与点播 / 直播差异
Google 会调整边缘节点与主机名，请勿盲信过期清单。实用做法是：打开开发者工具，筛选 Media 或按 Domain 排序，记录播放开始后流量最大的几个后缀。下面为常见形态示例，实际以你环境为准。
- 站点与嵌入页：
youtube.com、youtu.be；嵌入第三方页面时还要注意父页面是否同源策略拦截。 - 视频媒体 CDN：大量请求落在
*.googlevideo.com；这是许多「只代理首页、不代理 CDN」规则的盲区。 - 缩略图与静态资源：
ytimg.com、ggpht.com等；若图片与脚本加载慢，会拖慢首帧与界面响应。 - 账号与个性化：若登录态异常，可能反复跳转
accounts.google.com；这与纯匿名观看路径略有不同。
点播与直播在排查上的提示
点播通常允许较大缓冲；若节点带宽不足，播放器会降码率而不是立刻断流。直播更怕抖动：同一节点若对 UDP 或 QUIC 路径处理不佳，可能表现为声音先行、画面冻结。若你使用 TUN 模式接管全流量，需确认客户端对相应协议的处理策略与防火墙放行，详见你所用内核与 GUI 的文档。
四、Clash 分流：把 YouTube 与 googlevideo 绑到同一策略组
分流规则的核心仍是顺序：更具体的业务规则在前，国内直连与私有地址在后，最后 MATCH 兜底。针对 YouTube，建议把页面域与媒体域放入同一自定义策略组（例如 YOUTUBE），避免一半命中 PROXY、另一半落入 DIRECT。下面是一段示意配置，代理组名与域名须替换为你自己的抓包结果与订阅结构。
# Example only — replace proxy group names after your capture
rules:
- DOMAIN-SUFFIX,youtube.com,YOUTUBE
- DOMAIN-SUFFIX,googlevideo.com,YOUTUBE
- DOMAIN-SUFFIX,ytimg.com,YOUTUBE
- DOMAIN-SUFFIX,ggpht.com,YOUTUBE
- DOMAIN-SUFFIX,googleusercontent.com,YOUTUBE
- GEOIP,CN,DIRECT
- MATCH,PROXY收窄与维护
上例对 googleusercontent.com 等较宽后缀可能会覆盖非 YouTube 业务；若你希望只影响视频场景，应结合抓包逐步收窄，或在 rule-providers 中为媒体单独维护一小段本地规则。避免使用过于粗暴的 DOMAIN-KEYWORD,google 抢在精细规则之前，导致无关流量全部涌入同一节点。
若你同时使用在线规则集，建议为 YouTube 保留可覆写的本地片段：当订阅提供方更新整库时，不至于冲掉你对 googlevideo.com 的固定策略。
五、节点选择：吞吐、丢包与出口一致性
规则命中正确后，节点选择决定体验上限。对 YouTube 而言，相比「延迟个位数毫秒」的噱头，更重要的是到媒体 CDN 路径上的稳定吞吐与低丢包。可操作的优先级如下。
- 优先高带宽、低丢包：视频分片下载对 TCP 窗口与重传敏感，高延迟但稳定的线路往往比抖动大的「低延迟」更可观看。
- 减少同一会话内频繁换出口：自动测速组若过于敏感，可能在播放中途切换节点，触发重新协商与缓冲；可为
YOUTUBE单独建fallback或手动 pinned 节点。 - 区域与解析一致性：若 DNS 解析与出口地域长期不一致，可能选到对你当前链路次优的边缘节点；在合规前提下，尽量保持解析与出口相对稳定。
- 直播场景关注 UDP / QUIC：若客户端大量走 QUIC，而节点或本地防火墙对 UDP 处理不佳，会出现「进度条不走、声音断续」；必要时对照关闭 QUIC 的实验性设置做 A/B（以浏览器允许项为准）。
若「同节点访问其它海外站流畅，仅 YouTube 卡顿」，更像对特定 CDN 路径或 ASN 的限制，可尝试更换节点池或联系订阅提供方；反复本地改规则却从不看连接日志，往往难以定位根因。与 TLS 相关报错可交叉阅读 《TLS Handshake Timeout 排查》。
六、DNS、Fake-IP、嗅探与 TUN / 系统代理
许多「规则显示代理却仍缓冲」的现象来自 DNS 与解析模式不一致。Clash 系常见配置会启用 Fake-IP：若嗅探与规则匹配链路未覆盖媒体域名，可能出现命中策略但连接仍异常。建议按顺序自查：
- Clash DNS 与系统 DNS是否互相打架；路由器或上级网络是否劫持解析。
- sniff 与 TLS SNI 相关选项是否与当前运行模式一致；媒体请求的主机名是否出现在日志中。
- IPv6：若本机 IPv6 与代理路径不一致，可能出现偶发直连失败；可在排除其它因素后对比开关。
- TUN 与系统代理：仅浏览器走系统代理时，部分组件或扩展仍可能绕开；需要统一接管时考虑 TUN，并对照 《TUN 与 Windows 路由排查》。
若曾遇到「开 fake-ip 后少数站异常」，可按 《fake-ip 与 DNS 排查》 中的对照实验逐步收敛 fake-ip-filter，再回到 YouTube 场景复测。
七、现象与检查项对照表
| 现象 | 建议优先检查 |
|---|---|
| 页面正常，播放器一直转圈 | googlevideo.com 是否命中与 youtube.com 同一策略组；日志是否出现直连或错组 |
| 能播放但频繁降清晰度 | 节点带宽与丢包；是否中途自动切换节点；是否 IPv6 路径异常 |
| 直播声音正常、画面卡住 | UDP / QUIC 路径；TUN 与防火墙；浏览器硬件解码与实验特性 |
| 规则显示走代理，仍握手失败 | DNS 与 Fake-IP；节点对目标地域是否受限；TLS 日志与 SNI |
与 局域网共享代理同时使用时，请确认旁路设备上的播放流量同样命中 YouTube 相关规则，否则会出现「电脑流畅、电视浏览器卡顿」的误判。
八、小结
要让 YouTube 网页播放在 Clash 下尽量少遇到缓冲与转圈，关键三件事：用抓包确认主机名，把 youtube.com 与 googlevideo.com 等播放强相关域纳入同一策略组并注意规则顺序；优先选择高吞吐、低丢包、出口相对稳定的节点，避免播放中途频繁切换；结合 DNS、Fake-IP 与 TUN/系统代理做分层自检，区分页面层与媒体层问题。与站内 Gemini / Google API 专文相比，本文聚焦视频 CDN 与网页播放链路，便于检索「YouTube + Clash」场景时直接落地。
相比功能单一的轻量代理工具，Clash 生态在规则、内核与客户端选择上更统一，适合需要同时照顾浏览器、系统代理与可选 TUN 的用户。若你希望从规则层面把媒体路径与页面路径对齐，再为策略组挑选更匹配长视频吞吐的节点，可从本站获取安装包后导入订阅，按本文思路微调 分流规则与节点选择。