YouTube 卡顿或首页打不开？Clash 分流 Google 与视频 CDN 域名实测（2026）

1. 与 Netflix/Disney 专文差在哪里：YouTube 是 Google 生态 + 视频 CDN

Netflix、Disney+ 类文章里常见的「片库与订阅地区是否一致」「平台地区提示」在 YouTube 上当然也存在（尤其是 Premium 与付款资料），但用户大量搜索的「首页白屏」「能刷推荐却点播放就卡」「画面能出、进度条永远加载」往往更像规则漏配或 CDN 主机名未纳入同一策略组，而不是单纯「换一个国家的节点」就能解释。YouTube 的前端强依赖 Google 通用脚本与 gRPC 式接口（例如页面里常见的 youtubei.googleapis.com 路径），而真正吃带宽的往往是 *.googlevideo.com 一类视频 CDN主机名；二者若被拆到不同出口或一半直连一半代理，就会表现为「界面像能用，缓冲却起不来」的假阳性。

因此本文的实测顺序是：先把 YouTube 相关 Google 域名与视频 CDN 用成组规则钉进同一策略组，再核对 DNS 是否经内核、Fake-IP 是否与规则匹配一致，最后才用「关闭 QUIC」做传输层对照。若你需要对比「另一路长视频平台的地区检测话术」，可并行阅读 Netflix 专文；若关心生成式视频/API场景的 CDN 写法，可参 Sora 与视频 CDN，三篇主场景与核心词均不重叠，可交叉索引而不重复堆砌。

2. 按链路分域：首页/鉴权、播放与分片、缩略图与静态

把一次「从首页点进视频并播满数十秒」拆成四段，分别看连接日志里的 Host / SNI，比一次性堆关键字更不容易误伤：① 首页与壳层——youtube.com、m.youtube.com、相关跳转与脚本；② 鉴权与 InnerTube API——常见落在 googleapis.com、youtube.googleapis.com 或日志中的 youtubei 路径；③ 播放与视频 CDN——大量请求指向 googlevideo.com 及区域性格式；④ 缩略图与封面——多见于 ytimg.com、ggpht.com、或 googleusercontent.com 一类承载。四段里任意一段仍落在 DIRECT 或意外策略组，都可能造成「首页能进、起播失败」或「海报全灰」等割裂表现。

实务上建议你在图形客户端里开连接记录，从无痕窗口打开首页、点一部视频，把新出现而规则集未覆盖的主机名补进本地覆写并放在过于宽泛的直连或超大 GEOIP 规则之前。规则顺序与兜底的写法请先对照 高级规则分流指南，避免一条后置规则把前面为 YouTube 准备的命中全冲掉。

3. 建议覆盖的 Google 与视频 CDN 主机名骨架

Google 会调整边缘与主机名前缀，下列条目是 2026 年仍常被引用的骨架，用于建立你的首版覆写；上线后请以自己日志为准增删。原则仍是：与 YouTube 强相关的条目要靠前，订阅里若已有 GEOSITE:google 或流媒体大类，可与本地段组合，但勿用超大分类代替排错。

• youtube.com、youtube-nocookie.com、yt.be（站点、短链与部分嵌入场景）
• googlevideo.com、googleusercontent.com（核心视频 CDN与部分静态/重定向）
• ytimg.com、ggpht.com（缩略图、头像与封面资源）
• googleapis.com 中与播放器相关的子域（例如日志里出现的 youtubei、youtube.googleapis.com）；建议先用具体子域再考虑放宽，避免误伤其它 Google API 客户端
• gstatic.com、google.com 中与页面脚本、账号体系相关的路径（若仅登录阶段失败，请把 accounts.google.com 等一并纳入同一策略意图或按你安全策略单独列出）

不建议长期依赖过于模糊的 DOMAIN-KEYWORD,google 做唯一兜底：审计困难且易与其它 Google 产品抢规则。更稳妥是后缀 + 日志补全，与站内 Hugging Face CDN、Steam 下载等文章同一套维护方法。

4. 专用策略组与 mihomo 规则示例

为 YouTube 单独建一个 select 或 url-test 策略组（示例名：▶ YouTube），只放入你确认带宽与稳定性适合视频、且延迟可接受的节点。将上节后缀显式指向该组；名称请与你本地 proxy-groups 对齐。若尚未导入订阅，可先完成 订阅导入与连通，再叠加覆写。

proxy-groups:
  - name: "▶ YouTube"
    type: select
    proxies:
      - NODE-US-01
      - NODE-SG-01
      - DIRECT

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
  - DOMAIN-SUFFIX,youtube.googleapis.com,▶ YouTube
  # Tighten googleapis.com if other clients need different groups
  # ... GEOIP / MATCH below

电视、盒子或移动端 App 若未走系统代理，请评估 TUN 是否已覆盖对应进程；仅浏览器插件或 PAC 往往盖不住独立解析的视频流。此时应先确认终端网络栈是否已被内核接管，再回头微调域名表。

5. DNS、Fake-IP 与规则顺序：避免解析与连接各走各路

Fake-IP 模式下，若浏览器或系统仍启用绕过 Clash 的 DoH，容易出现「解析与连接策略不一致」：Google 域名在本地规则里看似命中，真实连接却以另一套解析结果走向直连或默认组，从而表现为缓冲或间歇失败。调整 DNS 段落后，请清理本机 DNS 缓存并重启内核再测。规则顺序上，务必让本节为 YouTube 准备的条目位于过于宽泛的直连、广告屏蔽或超大 GEOIP 之前。

对 HTTPS 连接，mihomo Sniffer 可在早期缺少域名信息时借 TLS SNI 补全匹配，排错时特别有用；具体日志对照可与 Sniffer 与 SNI 专文 同步阅读。大流量场景不必长期全开嗅探，可先在域名规则写全后仍出现异常再短期开启对照。

6. QUIC/HTTP3 关闭对照：缩小缓冲与间歇失败范围

与 Gemini 篇一致：HTTP/3 基于 QUIC（UDP），与常见以 TCP 为主的代理路径、日志观测方式不完全重合。若你已确认 Clash 分流 覆盖无误，仍遇到「同一节点下时好时坏」的缓冲或失败，可用浏览器侧关闭 QUIC做一次对照实验：仅切换 QUIC 开闭，其它变量不变。

• Chromium 系：地址栏打开 chrome://flags（Edge 为 edge://flags），搜索 QUIC，将 Experimental QUIC protocol 设为 Disabled，重启浏览器后重试播放。
• 结论用法：若关闭 QUIC 后明显稳定，应把「UDP / HTTP3 路径」记入长期清单，并与换节点、改 DNS 的结论区分，避免混谈。
• 恢复：排错结束可改回 Default，以免长期错过浏览器对 HTTP/3 的修复与性能优化。

移动端 App 或电视客户端若无法关 QUIC，应回到 TUN、UDP 与 DNS 是否一致的老问题；与 Gemini 专文 中的「对话/API」场景相比，本文更强调长时间、大流量的视频拉流对弱网与 UDP 路径更敏感。

7. 排查清单（2026 实测向）