YouTube の画質上限・Premium まわりと Clash：2026 年、分流ルールと DNS で経路を段階的に整える
YouTube を Clash と併用していると、画質メニューが期待より低い、背景再生や Premium 機能の案内が地域と噛み合わない、同じアカウントなのにブラウザとアプリで挙動が違う——といった違和感に直面することがあります。原因の多くは単一のドメインではなく、動画本体の取得（googlevideo.com 系）、アプリ内部 API（youtubei.googleapis.com など）、表層の youtube.com が、それぞれ別の DNS 結果と別の出口に流れてしまうことに集約されがちです。本記事では 2026 年時点で実務的な 分流ルールの置き方、ストリーミング向けノードの選び方、fake-ip を含む DNS 設計を整理し、既存の Netflix 向けストリーミング記事とはドメインと症状の切り口が異なる「動画プラットフォームの第二の主戦場」として読めるようにします。各サービスの利用規約と法令を遵守し、契約上許された範囲でのネットワーク整理を前提とします。
Netflix 記事では足りない、YouTube 特有のレイヤー
メインストリーム動画全般の話は Netflix の記事で扱いましたが、YouTube はGoogle の縦割りサービス群の一部として、次のようなホストが同時に絡みます。
- 視聴ページとサムネ・メタデータ：
youtube.com、ytimg.com、ggpht.comなど。 - 実際のメディアセグメント：多くが
googlevideo.com配下のエッジへ。ここが帯域とキャッシュの主戦場です。 - モバイルアプリ・TV の内部 RPC：
youtubei.googleapis.comを中心とした API 群。画質候補の提示や会員まわりの判定にも関わることがあり、表層の Web ページだけ整えても不十分なケースがあります。
つまり「youtube.com だけプロキシに乗せれば十分」という発想だと、動画バイナリだけ別国のエッジへ直行し、メタ情報と実体の国が食い違う状態を作りやすいです。Clash の Rule モードでは、これらを意図したポリシーグループへ揃える順序が成果を分けます。
切り口の整理
Netflix が nflxvideo.net など自前 CDN 族に寄りがちなのに対し、YouTube は googlevideo + Google API の二段が目立ちます。ルールセットのカテゴリ名はクライアント依存なので、ログに出た実ホスト名で追従する姿勢が安全です。
症状の読み分け：画質・バッファ・Premium 表示
ネットワーク側で疑うべきパターンを、画面の見え方に寄せて整理します（すべてが接続起因とは限りません）。
- 解像度が勝手に落ちる：実出口の帯域不足、輻輳、TLS 遅延に加え、エッジの選択と QUIC／TCP の取り合いも絡みます。
- 高ビットレートが選べない：端末性能やコーデックの前に、取得経路の安定性を疑い、同じ動画で別ノード・別プロトコル（試験的に HTTP/3 を切る等）を比較します。
- Premium の文言や機能がアカウント認識と矛盾：クライアントが参照する API 応答と、実際の課金リージョンの組み合わせが複雑です。技術的には API 系ドメインをページと同じ出口へ揃えると切り分けやすくなりますが、最終的には契約と Google アカウント設定が正です。
分流ルール：広い MATCH の前に「動画三種」を置く
原則は Netflix 記事と同じで、ローカルで明示したい行は GEOIP や最終 MATCH より上です。購読ルールをマージしたあとは、自分の上書きが結果の先頭側に残っているかを必ず確認してください。
以下は概念例です。YOUTUBE-GROUP は実際のポリシーグループ名に置き換え、環境のログでホスト名を検証してください。
# Illustrative — replace YOUTUBE-GROUP; verify hostnames in your logs
rules:
- DOMAIN-SUFFIX,googlevideo.com,YOUTUBE-GROUP
- DOMAIN-SUFFIX,youtubei.googleapis.com,YOUTUBE-GROUP
- DOMAIN-SUFFIX,youtube.com,YOUTUBE-GROUP
- DOMAIN-SUFFIX,ytimg.com,YOUTUBE-GROUP
- DOMAIN-SUFFIX,ggpht.com,YOUTUBE-GROUP
- MATCH,DIRECT
リモートの RULE-SET に「YouTube」カテゴリが含まれる場合でも、上記のような狭い直書きをローカル先頭に置いて上書き優先にするか、マージ順を調整します。広告ブロック系の広域ルールが googlevideo.com へ伸びていると、静かにサムネやセグメント取得が欠けることもあるため、不具合時は一時的にカテゴリを狭めるのが現実的です。
ルール順のミニチェック
- プロセスルールを使う構成では、意図せずブラウザ以外のトラフィックが先にマッチしていないか。
- 競合する DOMAIN 行が、意図より広いサフィックスで YouTube 以外を巻き込んでいないか。
- リモートセット更新後、急に画質が落ちた場合は差分を疑い、バックアップ設定へ一度戻す。
DNS と fake-ip：名前解決と実経路の「二重の真実」を防ぐ
Clash 系でよく使われる fake-ip は、ドメインを早い段階で仮アドレスへマップし、接続フェーズで本解決へ寄せる流れです。ルールマッチの一貫性には効きますが、OS やアプリが自分で握った DNS 結果だけを信じると、Clash 内の解決と食い違います。
YouTube では次を揃えるとトラブルが減りやすいです。
- Clash の DNS：
nameserverとfallback、タイムアウト、fake-ip-filter（ローカル・メッシュ・STUN など）を整理する。 - OS の DNS：TUN 利用時は、端末がどの DNS を権威として見ているかを一点に寄せる。ブラウザ拡張の Secure DNS との二重化にも注意。
- 全屋・ルータ経由：LAN クライアントが ISP DNS へ直行していると、PC だけ Clash でも TV やスマホが別解決になります。OpenWrt / OpenClash のように DNS を束ねる構成のほうが再現性が高い場面があります。
接続はあるのに特定アプリだけ真っ白、という場合は DNS と fake-ip の詳細記事を先に当たり、変数を一つずつ戻してください。
ストリーミング向けノード選び（2026 年の現実）
YouTube も長時間・高スループットのセッションが多く、ping が良くても帯域が細いノードは 1440p や 4K でバッファが伸びやすいです。url-test の間隔が短すぎると、再生中に出口が切り替わって一瞬だけセグメント取得が失敗する症状も起きがちです。
実務的には、一般ブラウジング用と、動画・大容量向けでポリシーグループを分け、後者は fallback や長め間隔の url-test を検討します。データセンター由来の IP は事業者側のリスク評価に引っかかることがあり、画面上は技術的には「つながる」のに品質だけ抑えられることもあります。ここは利用規約と実態の両方を踏まえ、合法的な範囲での最適化に留めてください。
遵守事項
本稿は接続の一貫性とトラブルシュートのための技術整理です。地域を偽って課金・視聴する行為を推奨するものではありません。契約上許されたリージョンとプランの範囲で運用してください。
TUN・モバイル・TV：見えない経路をそろえる
システムプロキシ非対応のアプリでは、TUN モードで捕捉するか、ゲートウェイ側で透過的に載せる必要があります。Windows の土台は Clash for Windows のセットアップ、macOS は Clash Verge Rev を参照し、権限と拡張機能を終えてから YouTube アプリ側を検証すると手戻りが減ります。
Android の「プライベート DNS」、iOS のプロファイルや他社 VPN との併用では、見かけ上 Clash はオンでも実パケットが別スタックに抜けることがあります。症状が端末限定なら、まずその競合を疑うのが早いです。
IPv6 とリークの見落とし
2026 年も、IPv4 だけをトンネルに載せて IPv6 は ISP 直出しのままだと、名前解決と実通信のプロトコルが分断し、CDN のエッジ選択が意図とズレることがあります。ルータ設定、OS の優先度、Clash の IPv6 関連スイッチを含め、一度スナップショットを取る価値は高いです。
症状別チェックリスト
| 症状 | まず見る場所 |
|---|---|
| 画質が急に落ちた | googlevideo.com の実経路、ノード帯域、ルール更新差分、広告ブロックの過剰マッチ |
| アプリだけおかしい | youtubei.googleapis.com が意図したグループへ流れているか、TUN の範囲、プライベート DNS |
| ブラウザと TV で差 | 各端末の DNS・ゲートウェイ、全屋プロキシの有無 |
| 途中でだけ止まる | ポリシーグループの自動切替間隔、TLS 遅延、輻輳時間帯の出口品質 |
よくある質問
Global モードなら画質が上がるのでは？
切り分けとして一時的に試す価値はありますが、日常運用では不要なトラフィックまで同じ出口に乗り、遅延・ログノイズ・検知リスクが増えます。Rule で YouTube 用グループを切ったほうが長期的に安定しやすいです。
Sniffer を有効にすべきか
HTTPS の実ドメイン推定には役立つ一方、環境によっては握手や証明書まわりで副作用が出ます。必要なら Sniffer と除外ドメインを参照し、段階的に入れてください。
QUIC（HTTP/3）を切ると直ることがあるって本当？
一部環境でUDP の扱いとエッジの組み合わせが不安定になる事例はあります。クライアント側で試験的に無効化し、TCP フォールバック時の挙動を比較するのは合理的な切り分けです。
まとめ
YouTube の品質や Premium まわりの違和感は、単一スイッチでは直らないことが多いですが、googlevideo.com と youtubei.googleapis.com を含めた分流、ストリーミングに耐えるノード選び、fake-ip を含む DNS の一貫性を揃えると、体感はかなり安定しやすくなります。Netflix 向けに既にルールを敷いている場合も、YouTube 用にドメイン集合を明示したローカル行を足すだけで運用が明快になります。