1. バッファと画質ロックは「経路のきしみ」のサインになりやすい
YouTube は初期表示から、ページ本体・推奨一覧・広告挿入、そして連続的な動画チャンク（セグメント）の取得、さらにサインインや課金状態の照会へと、並列で多数のホストへアクセスします。ユーザーから見えるのは「どんどん先読みされない」「画質を上げようとしても UI が戻る」といった症状ですが、Clash（Mihomo）の接続一覧に現れるホスト名と実際に選ばれた策略（ポリシーグループ）を並べると、典型として「youtube.com 系は意図どおりプロキシに乗っている一方、googlevideo.com だけ想定外の DIRECT や遅い出口に落ちてレイテンシが跳ねている」「accounts 系だけ例外ルールに捕まりログイン周りだけ別経路」といった部分的成功がすぐに判別できます。まずは一枚岩のドメイン想定でルールを書かない前提を共有します。
設定ファイルの流れをまだ把握していない場合は、先にサブスクリプション取り込みの記事で全体像を押さえておくと、以降の手順が読みやすくなります。
2. Netflix（動画 CDN）や Gemini（Google 一般）との違い
当サイトの Netflix 向け分流の記事は、Open Connect 系の配信エッジと API の束ね方が中心です。Gemini 向けの記事は gemini.google.com と Generative Language API など、生成 AI 周辺に焦点を当てています。一方 YouTube は、インターフェイス（youtube.com）と、実データの大部分を運ぶ googlevideo.com 系、サムネイルや静的（ytimg.com 等）、埋め込みプレーヤーや TV アプリ固有のエンドポイントへホストが分岐します。Netflix のルールをそのまま流用しても、YouTube のバッファは直らないのが普通ですし、Gemini 用に書いた Google 一般ルールだけでは、再生 CDN の取りこぼしが残ることもあります。題材としては同じ「動画」でも、YouTube 専用のルール表を別に持つと長期的に安全です。
3. YouTube 周辺通信を「層」に分けて考える
実際のホスト名はクライアント（ブラウザ／アプリ／TV）や地域で変わり得るため、開発者ツールや Clash のログに出た名前を正とします。設計メモとして、次のような役割分けを頭に置くとルールが書きやすくなります。
| 層 | 代表例（ログで要確認） | 切り分けのポイント |
|---|---|---|
| ページ・ナビ | www.youtube.com、m.youtube.com | 一覧は出るが再生だけ遅いとき、UI 層とメディア層の分裂を疑う。 |
| 短リンク・リダイレクト | youtu.be | 共有リンクから開いた場合にのみ現れるリクエストを取りこぼさない。 |
| 動画セグメント（本命） | *.googlevideo.com など | ここが低速や誤 DIRECT だとバッファと画質制限に直結しやすい。 |
| 静的・プレビュー | ytimg.com、i.ytimg.com | サムネだけ欠ける／プレーヤーは動くなど、見え方で分岐が起きる。 |
| アカウント・OAuth | accounts.google.com、oauth 系 | ログインは通るのにチャンネル登録や会員表示が崩れるときに要確認。 |
| API／内部呼び出し | googleapis.com 配下（YouTube Data API 等） | サードパーティ連携や拡張機能と併用している場合に表面化しやすい。 |
重要なのは、トップページが開けたから全部通っているではないという点です。再生ボタンを押したあとも高レートなストリーム接続が続くため、一枚岩のドメイン想定でルールを書くとすぐ破綻します。
4. Web 版と公式アプリ・TV：プロキシの効き方が違う
ブラウザ版は OS のプロキシ設定や拡張、HTTP/3（QUIC）の有無の影響を受けやすく、公式モバイルアプリは内部で別スタックを使うことがあります。スマート TV やゲーム機はシステムにプロキシ概念が薄い事例も多く、LAN 側で旁ルータへ集約する構成だと、PC の Clash とは別の経路になっている可能性があります。Clash 側でシステムプロキシかTUNのどちらでトラフィックを握っているかを先に固定し、同じ操作（トップ表示→再生→画質変更→ログイン確認）を繰り返しながら、出てくるホスト集合がクライアント間でどう違うかを比較してください。片方だけ直るなら、もう片方の取りこぼしを疑います。
5. ドメイン収集：再生操作と Clash ログの両方で拾う
収集の基本は次の流れです。ログの出方はクライアントや地域で差があるため、再現手順は自分の環境に合わせてください。
- YouTube を開き、問題の動画を実際に再生し、可能なら画質を手動で切り替える（自動に戻す操作でも可）。
- Clash（Mihomo 対応 GUI なら接続ビュー）で、同じ操作直後に現れた接続行を時系列で並べ、
youtube・googlevideo・googleを含むホストをメモする。 DIRECTや想定外のポリシーに落ちている行に印をつけ、購読ルールのどの行より上に自作ルールを置くべきかを検討する。- Google アカウントのサインイン／サインアウト、Premium メニュー表示を挟んだあともう一度ログを眺め、accounts 系が増えていないか確認する。
ポート競合やコア起動失敗など汎用トラブルはトラブルシュート記事へ。本稿は YouTube 特有のマルチドメイン構成に焦点を当てます。
6. 推奨する切り分け順序
- Clash が起動していること、システムプロキシかTUNのどちらでトラフィックを握っているかを確認する。
- 接続ログで
googlevideo.comやyoutube.com関連ホストが意図したポリシーグループに入っているか、誤ったDIRECTがないかを見る。 fake-ipを含む DNS 設定を確認し、必要なら特定サフィックスへnameserver-policy等を当てて名前解決のブレを減らす。- ページ層・メディア層・アカウント層をホスト／サフィックス単位でルール化し、購読ルール内の広い
DIRECTより上側に矛盾なく配置する。 - ルールが意図どおりになったあとで、遅延の揺れが少ないノードを選び、過剰な自動切替を避ける。
7. システムプロキシと TUN：取りこぼしを減らす
システムプロキシは手軽ですが、プロキシ設定を読まないコンポーネントや、別ドライバの VPN と併用すると見かけ上の経路が分裂します。TUN はルーティング層で取り込むため一貫性は上がりますが、他 VPN との競合や権限まわりのトレードオフがあります。有効化するならTUN モードの解説を参照し、有効化後に再接続ログで googlevideo 系がすべて期待どおりの経路になったか検証してください。
8. DNS／fake-ip：名前解決とルール判定のズレ
fake-ip は体感速度を上げる一方、設定次第では「ルールに渡る前の名前」と「実接続の宛先」の整合が崩れやすくなります。YouTube のようにサブドメインと CDN が多いサービスでは、軽いズレでもプレーヤーが適応画質を下げ、ユーザーには画質のロックや間欠的なバッファとして見えます。対策の基本は、上流 DNS を信頼できるものにそろえ、ログで頻出する主要サフィックスへ専用の名前解決ポリシーを当てることです。フィールド名はコアのバージョンで差があるため、利用中の Mihomo／Clash Meta のドキュメントと照合してください。疑わしいときは一時的に、クライアントの DNS ログや dig で解決結果が実際の転送出口と一致するかを確認します。
9. 分流ルールの考え方（記述例は置き換え前提）
購読ルールに「広い DIRECT」が先に入っていると、意図せず国内直結へ落ちるホストが紛れ込みます。より具体的な DOMAIN／DOMAIN-SUFFIX を、矛盾なく上側に置くのが実務的です。以下は例示であり、実際のホスト名は必ずログで確認して置き換えてください。googlevideo.com を丸ごと別グループに載せると、他サービスへ副作用が出る可能性があるため、ログに現れたパターンに限って表を更新するのが安全です。
# Example only — verify hostnames in your Clash logs before use
rules:
- DOMAIN-SUFFIX,youtube.com,PROXY
- DOMAIN-SUFFIX,youtu.be,PROXY
- DOMAIN-SUFFIX,googlevideo.com,PROXY
- DOMAIN-SUFFIX,ytimg.com,PROXY
- DOMAIN-SUFFIX,accounts.google.com,PROXYストリーム帯域だけ別グループ（例：PROXY_MEDIA）に分け、アカウント用（PROXY_ACCOUNT）と切り離すと、障害時の切り分けが容易になります。グループ名は proxy-groups に定義済みである必要があります。
10. Premium と地域・広告：ログイン整合を崩さない
月額課金の確認や広告除去の挙動は、セッションと地域判定に依存します。accounts.google.com と再生レイヤーが別経路になると、ブラウザ上ではログイン済みに見えても API 応答が食い違い、設定画面だけエラーになることがあります。同一の意図した出口にそろえることを優先し、ログで矛盾がなくなったうえでノードの国を変えて比較すると、原因がノード側かルール側かが切り分けやすくなります。ここは検索意図としても「Clash × YouTube」の核心なので、一度シークレットウィンドウで再ログインして症状が変わるかも併せて確認するとよいでしょう。
11. ノード選定：帯域テストより「揺れの少なさ」
スピードテストで一位でも、短時間で往復遅延が跳ねるノードは、適応ビットレート制御のあるストリーミングには不向きです。TLS の再ハンドシェイクが増え、プレーヤー側は低画質固定や間欠バッファとして現れます。手動選択で様子を見たり、動画用に安定路線を固定するのが実用的です。プロトコル特性の比較はプロトコル比較記事も参考になります。
12. 追加の落とし穴：QUIC、複数 VPN、IPv6、hosts
ブラウザが HTTP/3（QUIC）を優先する環境では、見かけ上UDP だけ別経路になることがあります。Clash 側の転送モードや、OS のファイアウォールと併せてログを確認してください。Clash 以外の常駐 VPN と TUN を同時に有効にしている場合、ルートの奪い合いで「ときどきだけ直結」が紛れ込みます。IPv6 が有効な回線では、IPv4 側だけプロキシに乗っているといったデュアルスタックの偏りも起きます。また hosts を手で弄っていると、特定 CDN だけ別 IP に解決されルールと食い違うこともあります。まずは単一路径に戻してからログで確認するのが早道です。
13. まとめ：証拠ベースで YouTube 用ホストを束ねる
YouTube のバッファや画質ロック、ログインまわりの違和感は、単一設定ミスよりもモード・DNS・ルール順・ノードの揺れの積み重ねで起きがちです。本稿の順序どおりにログで確認していけば、「とりあえず別ノード」より再現性の高い改善が期待できます。2026 年も配信基盤は変化が早いので、購読ルールに頼り切らず、自分の環境で一度 googlevideo 周りの表を更新する習慣を持つと安心です。
接続ログとルール編集を GUI でまとめられるクライアントを使うと、YAML を毎回手で触る負担も下がります。同種ツールのなかでも、策略表示とコアの整合が取りやすい製品ほど長く運用しやすい印象です。YouTube の再生とアカウントをまとめて安定させたい方は、→ Clash を無料ダウンロードして、快適な接続体験を始める