YouTube の地域がずれる？googlevideo と DNS を Clash で揃える実測ステップ（2026）

この記事が扱う「YouTube がおかしい」症状

YouTube をClash／Mihomo で見ていると、トップは開けるが画面上のコンテンツの地域イメージだけ違う、YouTube Premium の案内文言と自分のノード出口イメージが一致しない、「This video isn’t available in your country」のような文言が別の理由で見えるなど、単純な「通信不可」とは質の違う不整合が出ることがあります。再生そのものが googlevideo.com 向けなどCDN の別ホストに乗っているため、youtube.com だけ分流ルールに載せても説明できないギャップが発生します。

本稿では、当サイトのストリーミング向け事例であるNetflix と Clash の実測手順や Disney+／Max とホスト構成が異なることを前提に、YouTube 特有の複数ホストとDNS リークや Fake-IP、ルール評価の順番を並べました。サービス規約および利用可能地域の取り決めは各プラットフォームに従い、ユーザーの側で切り分け可能なネットワーク層に話を限定しています。

なぜ YouTube は「youtube と googlevideo」に分岐するか

ブラウザやアプリでは、サイトの UI とメタデータが youtube.com（および youtubei.googleapis.com に代表される API／RPC 経路など）側に載りやすく、実映像チャンクの多くは googlevideo.com 系ホストへの接続になります。そのため、(1) 片方だけ広い GEOIP で直結させている、(2)DNS が片系統だけ OS 側のリゾルバにフォールバックしている、といった条件が重なると、メタ情報と視聴エッジのノード選択が食い違い、画面上のサービス地域だけが浮く、といった体感になります。Clash の分流では両者をDOMAIN-SUFFIX またはキーワードで同じグループ側に寄せるのが原点です。

参考として、広告や計測、埋め込みプレーヤーの周辺だけが別経路にあるケースでは ytimg.com／ggpht.com などもログに並びます。まずログで「どのホスト名が想定グループへ入っているか」を眺めてから増やすと、過剰なルール膨張より再現調査が速くなります。

ステップ 1：DNS と Fake-IP・nameserver を揃える

Enhanced Mode が fake-ip の構成では、分流ルール評価用の名前解決と、映像転送側の復元結果が一時的にも食い違うと、アプリ側の地域ヒントだけがぶれることがあります。DoH を使うときは、そのエンドポイント側のホスト名がノード選択済みとは限らず、初回の名前解決や TLS だけがプロキシ外で失敗しやすく、体感では「サイトは開いたが視聴だけ苦しい」にも見えます。Windows の指定された DNS の暗号化、Android の Private DNS、ルータ側の自動 DNS が、実効のクエリ競合になっていないかも順に確認します。

• IPv6：AAAA と IPv4 のどちらで実接続されているか。YouTube の環境によっては経路だけ片側になると自動で画質が落ちやすくなります。
• fallback の条件：nameserver と fallback の切り替えトリガーを雑に設定すると、「国内向けの答え」を取りこぼすケースがあります。
• ログで確認：Clash／Mihomo の接続ログで .googlevideo.com 向けクエリや実送信先が見えるクライアントでは、名前と実転送の両方を並べられると調べやすくなります。

購読の取り込みや共通の DNS レイヤーの整理は、サブスクリプション URL 追加ガイドとも整合を取れる話題です。YouTube の地域トラブルでは「名前解決の出口」と「転送ノード選択出口」の二者が両方とも意図通りになるまで待ってから再試行すると、体感のブレが減ります。

ステップ 2：分流ルールと googlevideo・youtube を同じ評価帯へ

実務では、広い GEOIP でまとめるより、(1)youtube.com と googlevideo.com と主要 API 経路への DOMAIN-SUFFIX、必要なら (2)youtubei.googleapis.com と ytimg.com を並べ、(3)広い GEOIP や MATCH を下にする、という積み上げが読みやすいです。RULE-SET と rule-providers を使うときは評価順序が最重要で、基本概念はルール分岐の詳解にある通り、上にあるほど先に適用されます。

構成によっては sniff／Sniffer とDNS の組み合わせが期待とズレやすく、視聴系で症状がぶれるときはSniffer とストリーミング分流の記事にある優先順位の整理と併せて確認すると効きやすくなります。Netflix と同じセットを「そのまま」流用してもホスト構成が異なるので、共通の考え方だけ借りYouTube 向けにはドメイン行を増やしてください。

ステップ 3：システムプロキシと TUN で「視聴クライアントの視界」を揃える

ブラウザだけがノード選択を見ている、ネイティブアプリだけが別ポートを読んでいる、テレビやゲーム機は別デバイスで LAN 側の DNS が異なるといった状態だと、アカウントとエッジの見え方がすれます。できる範囲で同一スタックへ寄せたいときはTUN の利用を検討すると視聴トラフィックごと経路が揃いやすいです。TUN モードの解説で触れたキャプチャ範囲の読みがそのまま当たります。モバイルでは VPN 権限つき GUI でアプリ全体を同じグループ側に載せるのが運用として素直です。

ステップ 4：ノード選択と体感の再生・「only in certain countries」系の整理

遅延テストだけが綺麗でも、視聴用スループットが足らず自動で地域や画質表示が読み換わる事例は別途あります。まず選択型で明示的な地域タグ付きノードに固定し、数分実視聴でバッファと画質読み値を確認するのが再現確認として堅実です。また UGC の地域制約メッセージはコンテンツ権利由来のほか、アップローダ側の設定や契約状態などユーザーがプロキシで直せる話ではないケースもある点を切り離して読むことも重要です。あわせて請求情報が紐づく国と画面上のコンテンツは同一ではない構成もあるので、問題の粒度を混線させないようにします。

全ノードの遅延が赤になるなど下位レイヤーを疑う場面では、先にDNS と UDP を含め全体を読むほうが効率がよいです。ノード一覧がすべて赤く見えるときの記事とも役割分担できます。

Premium／課金と IP の説明だけが複雑に見えるとき

課金やファミリー機能の適用地域や表示言語、アプリのストア課金口座はサービス側のポリシーと連動しており、アップローダが見えるメタ情報の地域と単純に一致するとは限りません。ユーザーが自分の環境で調整しやすいのは、(1)プロキシグループで出口を明示し、(2)DNS を通したときのクエリ競合がないか、(3)分流ルールが googlevideo を確実に同じグループへ送っているか、の三本です。そのうえで表示が読み換われば、残りはアカウント側の設定やプラットフォーム側のメッセージと切り分けられます。

短いチェックリスト

1. 視聴クライアントがブラウザ／ネイティブ／セットトップそれぞれでノード選択できるスタックか（必要なら TUN を検証）。
2. DNS：fake-ip と OS／ルータの競合がないか。IPv6 片側などの異常パス。
3. 分流：.googlevideo.com や youtube.com、必要な API を意図したプロキシグループより上に並べられているか（漏れと過マッチ両方）。
4. ログに出ている未登録ホスト（ytimg.com 等）への取りこぼし。
5. Sniffer／ルール評価の優先順位とDNS を重ねたときに矛盾がないか。

より詳しい資料

YAML の共通表現はサイト内のチュートリアル・ドキュメントにもまとめてあります。ビルドの入手経路については統一説明があるダウンロードページを参照してください：Clash の設定とチュートリアル一覧。

まとめ

YouTube が「読み込めるのに画面上のサービス地域や画質の見えだけがずれる」のは、単一ホスト問題ではなく、youtube.com とgooglevideo、必要な RPC／静的ドメインのどれかがDNS または分流ルールの前提と食い違っている可能性が定番です。Mihomo 系クライアントではルール順とログを手元で制御できるため、名前を増やしていく運用とも相性がよいです。

自分の環境でも揃えるには、ノード一覧から地域を選ぶ前に名前解決の出口も含め並べて観るだけで体感の誤検知がだいぶ減ります。各プラットフォーム向け実行ファイルや配布概要はサイトのダウンロード一覧側を第一の入口にしていただけると読み込み順も迷いにくいです。→ Clash クライアントを無料でダウンロードし、YouTube 向けにもルールと DNS を揃えた接続を試す