ストリーミング · · 読了まで約 18 分

YouTube が重い・ホームが開かない・再生だけ止まる?Google ドメインと動画 CDN を Clash(mihomo)で分流し、DNS・Fake-IP・QUIC まで含めて校準する実測メモ(2026)

YouTube(ユーチューブ)は 2026 年現在も高トラフィックの動画基盤であり、検索でも「開かない」「ずっとくるくる」「バッファが終わらない」といった語が根強く残ります。当サイトの Google 対話型 AI 向けの稿会話・API 製品線に軸足を置くのに対し、本稿は視聴クライアントの画面が進むまでの再生チェーン(ホーム表示、アカウントと権限、マニフェスト取得、メディアセグメント、サムネイル)に焦点を当てます。また、NetflixDisney+ の既稿が長尺ストリーミングのカタログと地域検知を前面に出すのに対し、ここではGoogle が共有する名前空間の広がり短文〜中尺の動画 CDNを片側から切り出して整理します。Clash 分流は専用策略に束ね、DNSFake-IP、必要に応じてQUIC / HTTP3の切り分けまでセットで扱います。

1. Netflix / Disney+ 稿との違い(再生チェーンと名前空間)

長尺向けの記事では、課金・ライセンス・リージョン検知がユーザー体験の前面に出やすい一方、YouTubeでは同じ「動画」でも、表側の youtube.com や埋め込み、モバイルアプリ、テレビ向けクライアントが同じブランドでも別の API と CDN の組み合わせに乗る場面が多く、症状の見え方が違います。検索ニーズも「地域が合わない」より読み込みが遅い・止まるが中心になりがちです。したがって本稿では、ルール設計のゴールをカタログ国の一致よりバッファと初回表示の安定に寄せて説明します。

購読の取り込みとルール評価順の基本は、サブスクリプション導入ルールルーティングの解説と共通します。以降は YouTube・Google 動画基盤特有の論点に絞ります。

2. 段階別の症状:ホーム/認証/再生/サムネ

トップや検索の一覧すら白画面・タイムアウトになる場合は、youtube.com やそれに付随する API 経路が意図しない出口に乗っているか、DNS が意図せず分流している可能性が高いです。端末側の「プライベート DNS」や VPN 併用、セキュリティ製品のフィルタが挟まっているケースも、同じ見え方になります。

一覧や詳細は表示できるのに再生だけ進まない、バッファが回復しない場合は、マニフェスト(メディアの取り決め)と実セグメントの取得googlevideo.com など動画 CDN 側のホストに分かれている典型です。UI は国内直線でも、メディアだけ別経路に残ると「表は通っているのに中身が進まない」になります。

タイトルは出るがサムネイルだけ空白・極端に遅い場合は、画像系の ytimg.comggpht.com など、表側 HTML とは異なる配信名が策略の外に出ていることがあります。検索窓のサジェストやコメント読み込みなど、周辺機能ごとにホストが増える点も押さえておくと切り分けが速くなります。

3. 押さえる Google と動画 CDN のドメイン型

インフラは変更され得るため、手元のログ・開発者ツールの Network に出たホスト名を正としてください。出発点として多くの環境で登場しやすいのは、youtube.com(サイトと製品全体の表側)、googlevideo.com(メディア取得で繰り返し登場)、ytimg.com(静的資産や縮小画像)、ggpht.com(プロフィールやサムネイル周辺で現れやすい)、googleapis.com 配下の youtubei.googleapis.com など(クライアントの内部 API)です。アプリやテレビでは追加のホストが出るため、同一ブラウザの成功例だけを一般化しないのが安全です。

ルールを広げすぎると、無関係な Google サービスまで同じ出口に乗り、遅延や別用途の不調を招くことがあります。購読ルールセットに既に含まれる「YouTube / Google 動画」カテゴリを先に確認し、ログに出て不足したサフィックスだけを足す運用が現実的です。Clash 分流では、広い MATCH より前に具体的な DOMAIN-SUFFIXを置くのが基本で、その順序は ルールルーティングの解説どおりです。

4. mihomo ルール例:YouTube 用策略の上へ DOMAIN を積む

実務では YouTube / 動画視聴向けの策略グループを一つ切り、そこにレイテンシの安定したノードを載せる形が扱いやすいです。自動切り替え系では、再生中に出口だけが頻繁に変わるとセッションが不安定になることがあるため、視聴中は手動ロックや遅延の小さい固定に近い出口を選ぶ運用も検討余地があります。

以下は構造の例です。プロキシ名と最終 MATCH は環境に合わせて置き換えてください。

# proxy-groups: dedicated group for YouTube / Google video stack
proxy-groups:
  - name: STREAM_YOUTUBE
    type: select
    proxies:
      - NODE-A
      - NODE-B
      - DIRECT

# rules: suffixes commonly involved in watch path (extend from your logs)
rules:
  - DOMAIN-SUFFIX,youtube.com,STREAM_YOUTUBE
  - DOMAIN-SUFFIX,googlevideo.com,STREAM_YOUTUBE
  - DOMAIN-SUFFIX,ytimg.com,STREAM_YOUTUBE
  - DOMAIN-SUFFIX,ggpht.com,STREAM_YOUTUBE
  - DOMAIN-SUFFIX,googleapis.com,STREAM_YOUTUBE
  - DOMAIN-KEYWORD,youtubei,STREAM_YOUTUBE
  - MATCH,PROXY

googleapis.com は用途が広いため、ログで実際に視聴と同時に出たホストだけに絞り込むと副作用が減ります。TUN を使う場合は TUN モードの解説も参照し、システムプロキシでは追い切れないプロセスが残っていないか確認してください。

5. DNS・Fake-IP・Sniffer:名前と実接続を一致させる

Fake-IPを有効にしている構成では、ブラウザが握っているアドレスと、ルールが参照するドメイン情報の間にズレが生じやすくなります。Clash 分流が効かないように見えるのは、出口ではなく名前解決の経路が混線しているケースが多いです。nameserverproxy-server の書き分け、.Fake-IP 用のフィルタが自分の購読テンプレートでどう定義されているかを、一度通読してください。

mihomo 系では Sniffer が TLS の SNI などから接続の実名を復元し、ルール再評価に使えるため、Fake-IP と併用する場面で「ドメインが取れず策略が空振りする」状況を減らせます。手順の詳細は Sniffer・SNI・ログの稿を参照し、実装差は手元のコアのドキュメントを正としてください。

Google 傘はドメインが多岐にわたるため、DNS だけ別出口に出ていると表側は開いてもメディアだけ別ルートという分断が起きやすい点に注意します。考え方の共通骨格は Claude 稿でも述べているDNS と出口の二正面と同型です。

6. QUIC / HTTP3 を切った実測と注意点

ブラウザが QUIC(HTTP/3)を優先すると、TCP と異なる経路特性が出たり、プロキシ側の対応状況と噛み合わず一部の接続だけレジリエンスが悪化したりすることがあります。切り分けとして、短時間だけブラウザ側で HTTP/3 を無効化し、同じノード・同じルールでも症状が変わるかを比較するのは有効です。論点の重なりは Gemini 向けの稿でも触れているため、合わせて読むと設定の意図が掴みやすくなります。

コアやクライアントによっては、QUIC に関する実験フラグや独自のトグルがある場合があります。環境ごとに表記が違うため、「無効化したら改善した」かどうかの二分比較をログとセットで残すと、次の改善がしやすくなります。恒久策として必ず無効化すべき、とは限らず、ノード品質やルールの見直しで戻る場合もあります。

7. ログでホストを拾い足す手順

推奨の手順は次のとおりです。(1)mihomo のログで問題サイトのホストがどの策略にマッチしたかを確認する。(2)マッチは正しいのに再生だけ失敗する場合、開発者ツールからマニフェストとセグメント URL のホストをメモし、未登録のサフィックスだけを追加する。(3)Fake-IP 利用時は Sniffer の有無と DNS の整合を確認する。(4)QUIC を切った比較で差が出るかを見る。フェイルオーバの挙動は url-test / fallback の稿も参照してください。

ルールを増やすほど無関係なトラフィックまで同じ出口に吸い上げるリスクが上がります。繰り返しログに現れた名前から必要最小限だけ足す運用が、長期的なメンテナンスに繋がります。

8. つまずきやすい点とコンプライアンス

第一に、youtube.com だけを足して満足することです。表側は通っても 動画 CDN と画像配信が別名のままだと、バッファとサムネの不調が残りやすいです。

第二に、googleapis.com を広く束ねすぎることです。別用途の API まで同一策略に乗り、想定外の遅延や認証まわりの不具合を誘発することがあります。ログで視聴と同時に出た実名に限定してください。

第三に、本稿はサービス利用規約や著作権、国や地域の法令を踏み越えた利用を助長するものではありません。ここで扱うのは、正当な契約の範囲内で自宅ネットワークの経路を整理する一般的な知識に限られます。

9. まとめ

YouTubeの不調は、ブランドは一つでもホーム・内部 API・動画 CDN・サムネイルが別ドメインに分かれやすいため、検索で多い「開かない・くるくる・バッファ」を段階別に切り分ける必要があります。mihomo のルールで Google 動画関連を専用策略に揃えDNS・Fake-IP・Sniffer で名前と実接続を一致させ、必要ならQUIC / HTTP3の影響を短時間だけ切り分ける、という三層は、Netflix / Disney+ 稿の長尺ストリーミングの地域検知とは役割を分けて使うと整理しやすいです。ホスト名は将来的にも変わり得るため、最終的には自分のログに出た名前を正としてルールを足し込むのがいちばん確実です。全体の手順のおさらいは チュートリアル総覧にまとまっています。

同じ Clash 系でも GUI とコアの世代で既定値が変わります。安定したクライアントから揃えるなら、 → 無料で Clash をダウンロードし、快適な接続体験を試す ところから始めるのがおすすめです。

トピックの近さで選んだ関連記事 — 同じカテゴリの Clash 実践ガイド。