1. なぜ UI と再生でホストが分かれるか
YouTube のブラウザ体験は、一覧や検索、コメント、サムネイルといったアプリ UI用のホストと、実際の映像・音声を届けるメディア配信用のホストが分かれているのが普通です。後者は地域やキャッシュ状況に応じて *.googlevideo.com など長いサブドメインが並び、ここが別ルールに落ちると「ページは開くがバッファだけが続く」ように見えます。
Clash のルール分流は、接続ログに出た実名の Server Nameを正として、意図したプロキシグループへ載せる作業です。推測で DOMAIN-KEYWORD,youtube だけを増やすより、開発者ツールの Network とクライアントのログを突き合わせた方が安全です。クライアントの入手は ダウンロードページ、用語の整理は ドキュメントを参照してください。
googlevideo.com や ytimg.com などが並ぶ場面があります。ここが DIRECT のまま残っているか、期待するポリシーに乗っているかを Clash のログと照合してください。
2. Gemini 記事との違い（再生専用の視点）
当サイトでは Google Gemini／Google API向けに、googleapis.com や gemini.google.com 周辺をルール分流する考え方をまとめています。本稿の主眼はそこではなく、動画再生の帯域とバッファリングです。API の JSON エラーや OAuth よりも、TCP／TLS 越しのスループットとCDN の出口が結果に効きやすい領域です。
したがって「Google 全部を同じノードに寄せれば万事解決」という単純化は避け、再生に使われているホストをログで確認し、youtube.com 系と googlevideo.com 系が同じ安定ノードに乗るかを見るのが現実的です。動画生成サービスとの比較は OpenAI／Sora 向け記事も参考になりますが、ドメイン集合は別物です。
3. 症状：VOD・ライブ・広告まわりの差
典型的には次のようなパターンがあります。オンデマンド（VOD）ではシークや画質切り替えのたびに新しい接続が張られ、ライブでは低遅延向けの経路やチャンク取得の挙動が変わります。広告やトラッキング用のホストが別出口だと、体感では「一瞬止まってから再生が戻る」ように見えることもあります。
いずれもネットワークだけが原因とは限りません。ブラウザ拡張、ハードウェアデコード、GPU ドライバ、省電力設定など端末側の要因も並びます。本稿は Clash を前提にプロキシ経路の一貫性を疑う手順です。改善しない場合は、別ブラウザやシークレットウィンドウで再現するか、有線 LAN へ切り替えるなど、比較実験を挟むと切り分けが早いです。
4. 関係しやすいドメインとログの見方
Google のサービス構成は更新されます。以下は設定時の思考のための例であり、正は常に接続ログと公式の挙動です。
- サイト UI：
youtube.com、youtu.beのリダイレクト、accounts.google.comなど。サインインや設定画面で増えるホストがあります。 - サムネイル・静的資産：
ytimg.com、ggpht.comなど。読み込みの一部だけ別経路だと、画面が「半分だけ遅い」ことがあります。 - 再生本体（代表）：
*.googlevideo.com。ここがバッファ体感に直結しやすいです。 - 埋め込みや周辺：
googleusercontent.comなど。コミュニティやチャンネル周りで現れることがあります。
ルールの順序
rules: は上から評価されます。巨大な RULE-SET や GEOIP が先に当たり、意図しない DIRECT／別グループに落ちていないかを確認してください。ルール分流は「地図」です。地図が食い違うと、表示は速いのに再生だけ遅い、という形に現れます。
5. Clash のルール分流の例
Clash（Mihomo 系コア）では、DOMAIN-SUFFIX や DOMAIN-KEYWORD、外部 RULE-SET を並べ、最後に MATCH で全体のデフォルトへ落とします。以下は例です。実運用ではログに合わせて追記・修正してください。
# Example only — verify hostnames in your client logs
rules:
- DOMAIN-SUFFIX,youtube.com,PROXY
- DOMAIN-SUFFIX,googlevideo.com,PROXY
- DOMAIN-SUFFIX,ytimg.com,PROXY
- DOMAIN-SUFFIX,ggpht.com,PROXY
- DOMAIN-SUFFIX,googleusercontent.com,PROXY
- MATCH,DIRECTDOMAIN-KEYWORD,googlevideo は短く書けますが、意図しないホストへマッチするリスクもあるため、可能なら DOMAIN-SUFFIX,googlevideo.com を優先し、不足分だけキーワードで補う運用が無難です。購読ルールセットに依存する場合は、更新で順序が変わることがあるため、トラブル時は一時的に明示ルールを上に持ってくると切り分けが早いです。
6. ノード選択：帯域と安定性
ノード選択は、表示遅延（ping）だけで決め切れないことがあります。動画再生はスループットと途中切断の少なさが効き、混雑したサーバでは ping が良くてもバッファが増えることがあります。実務的には、同一プロファイル内で複数ノードを試し、同じ画質・同じ動画で再現性を見ます。
フォールバックと手動固定
自動フェイルオーバー系のグループは設定次第でノードが泳ぎ、再生が細かく止まって聞こえることがあります。まずは手動で一つの安定ノードに固定し、問題が再現しないことを確認してから自動化を検討するのが無難です。ライブ配信ではUDPや低遅延プロトコルが絡む場合もあり、クライアントの TUN 設定や UDP の扱いも併せて確認してください（環境により挙動が異なります）。
7. DNS・Fake-IP・モード（TUN／システムプロキシ）
Clash 利用者がつまずきやすいのが DNS です。Fake-IP を使う構成では、名前解決とルール評価のタイミングが絡み、「ブラウザの Network ではこの IP なのに、コアのログでは別挙動」という混乱が起きます。YouTube のように同一ブランドでもホストが複数あるサービスほど、名前解決の一貫性が重要です。詳細は fake-ip／DNS の切り分け記事も参照してください。
また、システムプロキシだけ有効にしているのか、TUN でアプリ全体を載せているのかによって、ブラウザ以外のプロセスがプロキシ外に落ちるケースがあります。どちらのモードで試しているかを統一し、例外リストに YouTube 関連が紛れ込んでいないかも確認します。
IPv6 だけが別経路に出ている場合も稀にあります。OS やルータで IPv4 を優先し、挙動が変わるかを見るのも手早い切り分けです。
8. セルフチェックリスト
短いチェックリストです。上から順に試すと手戻りが減ります。
- クライアントの更新：コアと GUI のバージョン差が出やすいです。ダウンロードページから入手できる最新系へ。
- モードの統一：システムプロキシと TUN、どちらで試すかを固定。
- ログのヒット：
googlevideo.comやytimg.comが期待のポリシーに乗っているか。 - ノードの健全性：別ノードへ切り替えて再現性を確認。
- DNS：Fake-IP／
fake-ip-filterの漏れがないか。 - 端末側：別ブラウザ・シークレット・ハードウェア加速のオンオフで再現が変わるか。
これでも改善しない場合は、ISP 側の輻輳や、特定地域のピーク時間帯といったプロバイダ要因も考えられます。時間を置いて再試行するのも現実的です。
9. Gemini API との対照
Google Gemini 向けに googleapis.com を整えたからといって、YouTube のgooglevideo 側が自動的に最適化されるとは限りません。逆に、動画向けに広く PROXY へ寄せたからといって、API のクォータや認証エラーが消えるわけでもありません。
| 観点 | Gemini／Google API（参考） | YouTube 再生（本稿） |
|---|---|---|
| 主な焦点 | API、OAuth、SDK 先のホスト | バッファ、CDN、スループット |
| 典型ホスト例 | generativelanguage.googleapis.com など |
*.googlevideo.com、ytimg.com など |
| 失敗の見え方 | HTTP ステータス、JSON エラー | 再生停止、画質固定の遅延、ライブのカクつき |
| まず見るログ | API ホストと認証まわり | googlevideo が期待ポリシーか |
10. まとめ
YouTube のブラウザ体験は、UI と再生 CDNが分かれており、Clash のルール分流が一部だけ空振りすると、バッファやぐるぐるに見えやすいです。googlevideo.com を含むメディア系ホストをログで確認し、youtube.com 周辺と同じ安定ノードに載せ、DNS と Fake-IP、TUN／システムプロキシのモードを揃えると、試行錯誤の幅がはっきりします。
同種のツールと比べて、Clash 系は接続とルールの対応を追いやすい場合があり、長尺やライブ視聴のような帯域敏感な用途でも、改善サイクルを回しやすいです。2026 年時点でも、推測よりログの実名を正にルールを育てる運用がいちばん再現性が高いです。