カクつきや Premium 表示のズレが「経路の割れ」に見える理由

YouTube のクライアントは、ホーム・検索・視聴ページの HTML／JSON、そして実際の動画セグメント取得のための googlevideo.com 配下、サムネイルや UI アセットの ytimg.com、内部 API の youtubei.googleapis.com など、ブラウザやアプリの種類によって多数のホストへ順番に HTTPS を張ります。Clash は接続ごとに DIRECT か特定の proxy-groups かを決めるため、同じ画面の中でもホスト単位で出口が混ざると、一覧は描画されるのにセグメント取得だけ遅延し、ユーザーにはカクつきや終わらないバッファリングとして見えます。ログを開くと、youtube.com だけプロキシに乗り、googlevideo.com が DIRECT のまま、といった表の割れが典型です。神秘的な「Google の障害」より先に、ルール欠け・順序の誤り・DNS の答えと出口の不一致を疑うと早いことが多いです。

Premium や請求まわりは、アカウントの登録国・決済手段・実際の出口 IP から見える地域の整合が絡みます。Clash でできるのは、判定に使われそうなホスト群がすべて同じポリシーグループに乗り、かつそのグループで選ばれているノードの所在地が一貫しているかをログで確認することです。UI だけ別地域のノード、動画 CDN だけ別地域のノード、といった地区のちぐはぐは、エラーコードが出ないまま体験が不安定になるパターンを生みやすくなります。分流の目的は「規約違反の裏口を作る」ことではなく、許容された単一の視聴・契約コンテキストに経路を揃えるための衛生です。

すべてを同じ海外出口へ流す説明は簡単ですが、OS 更新・クラウド同期・別タブの大容量転送と細かく連続する動画チャンクが同じトンネルを奪い合い、遅延のジッターが増えます。分流は、YouTube 関連の名前空間だけを意図したストリーミング出口へ固定し、それ以外は直結や別ポリシーに残すことで、競合と未知のホスト漏れを減らします。長尺ストリーミングは AI の短い API 往復とは負荷パターンが違うため、帯域とセッション継続を同じ目線で見る必要があります。

ℹ 観測ファースト：再生直前に Clash のライブ接続で、youtube.com だけプロキシに乗り、googlevideo.com や ytimg.com 相当のホストが DIRECT のまま、といった割れがないか確認してください。ここが割れていると、画面は出ても再生がカクつく説明がつきやすくなります。

分流の核：YouTube 名前空間をひとつのストリーミングポリシーへ

実務では STREAMING や YOUTUBE_GRP のようなストリーミング専用ポリシーグループを用意し、YouTube に関わるサフィックスをそこへ集約します。日常の国内サイトや社内イントラは DIRECT、別サービスは別グループ、というように責務を分けると、ルールプロバイダを更新したときの影響範囲が読みやすくなります。設計の骨格は ルール分流のベストプラクティス に沿っておくと、数か月後の自分が助かります。

ポリシーグループの中身は、遅延テスト付きの url-test、手動選択、フォールバックなど環境に合わせてよいのですが、動画向けに帯域と安定性のバランスが取れたノードを選ぶのが要点です。細かい接続ログが読めるクライアントを選ぶことは、ストリーミング切り分けでも同様で、クライアントの選び方 も参照してください。

ドメインの束：本体・CDN・画像・API・広告

運用上は次のような束に分けてメモすると整理しやすいです。（1）ブランド／アカウント UI：youtube.com、youtu.be、関連する Google アカウント連携。（2）動画 CDN：googlevideo.com を中心としたセグメント取得。（3）画像・フォント・静的：ytimg.com、ggpht.com など環境によって増える別名。（4）内部 API：youtubei.googleapis.com など googleapis.com 配下——ここが別出口だと、おすすめや再生開始の挙動が不安定に見えることがあります。（5）広告・計測：リストやブロッカー設定によっては、意図せず再生関連ホストまで巻き込むことがあります。フォーラムのコピペ一覧は出発点にすぎず、自分の端末のログで見えたラベルを正とします。

サードパーティの geosite:youtube 型カテゴリを購読に含める場合も、版と供給元を確認し、意図せず広告ブロックが CDN を潰していないか、広い捕捉行が具体行より上に来ていないかを見ます。ルールは上から順にマッチするため、ここが崩れると「ルールは書いたのに効いていない」状態になります。

ノード地区と地域検出（Premium を含む）

YouTube はコンテンツのライセンスや決済と、実際の出口 IP から見える地域の整合を扱う場面があります。Clash でできるのは、判定に使われそうなホスト群がすべて同じポリシーグループに乗り、かつそのグループで選ばれているノードの所在地が一貫しているかをログで確認することです。Premium の表示や請求国が期待と違うときは、まず経路のちぐはぐを疑い、次にアカウント設定と公式の説明を照らします。

「表示国を変える」ためのプロキシ運用は、サービス規約と法令の両方で問題になり得ます。本稿は許可されたネットワークで、意図した単一の契約・視聴コンテキストに経路を揃えるための話に限ります。出口の地理情報はノード提供者のラベルより、実測ログと公式のネットワーク診断を優先し、期待とズレたらルールと DNS を先に直してください。

ストリーミングノードの選び方

「ストリーミング用ノード」というラベルはプロバイダ任せのマーケ語であり、技術的にはその出口が動画 CDN との経路・混雑状況に適しているかの問題です。極端に CPU 負荷の高い多重暗号化や、過剰なユーザー数の共有出口は、長時間の TCP セッションに不向きなことがあります。一方で、帯域だけ広く RTT が不安定な経路も適応ストリーミングには不利です。Clash では url-test や fallback で「今このネットワークで一番マシな出口」を選べますが、まずドメインが正しいグループに揃っているかを確認してからノードを総入れ替えした方が早いことがほとんどです。

4K や高ビットレートを狙う場合でも、端末・ディスプレイ・作品ごとの提供フォーマットは配信側と受信側の条件が揃わないと上がりません。プロキシは「届かない帯域を届ける」装置ではなく、すでに提供されているレンジの選択が正しく機能するための経路衛生だと捉えると期待値が適切です。timeout と TLS の読み方 は、接続が張る前に落ちているのか、途中で切れているのかを分けるのに役立ちます。

DOMAIN-SUFFIX・ルールプロバイダ・YAML 例

DOMAIN-SUFFIX,youtube.com,STREAMING のようにサフィックスで束ねるのが基本です。動画本体が googlevideo.com にあるなら、そのサフィックスも同じ STREAMING に入れる必要があります。ytimg.com、必要に応じて googleapis.com の一部（ログで実名が見えた範囲）も同様です。単一ホストだけ切りたい場合は DOMAIN。DOMAIN-KEYWORD は手早い反面、無関係ホストを巻き込みやすいので、ログで実名が見えてから限定利用するのが安全です。

下の YAML は教育用のイメージです。実際のグループ名・国内判定（GEOIP の国コードなど）は環境に合わせて置き換え、観測したホストに合わせて行を増減してください。

Illustrative YAML fragment

rules:
  - DOMAIN-SUFFIX,youtube.com,STREAMING
  - DOMAIN-SUFFIX,youtu.be,STREAMING
  - DOMAIN-SUFFIX,googlevideo.com,STREAMING
  - DOMAIN-SUFFIX,ytimg.com,STREAMING
  - DOMAIN-SUFFIX,ggpht.com,STREAMING
  - GEOIP,JP,DIRECT
  - MATCH,DIRECT

googleapis.com は他サービスも同居するため、広く丸ごとプロキシに入れると副作用が出やすいです。ログに出た API ホストだけを DOMAIN で足すか、ルールプロバイダの細かいカテゴリを検討してください。新しい CDN 名が観測されたら行を足し、ルールプロバイダ更新後に壊れたら差分を戻す——ソフトウェアの依存更新と同じ運用が長く効きます。

DNS／fake-ip をルールと揃える

fake-ip モードではアプリに合成アドレスが返り、実解決はプロキシ側で進むことがあります。DOMAIN 系ルールと DNS の見え方がズレると、「名前解決は一瞬なのに再生が始まらない」パターンが出ます。ブラウザの Secure DNS、OS のリゾルバ、Clash の dns ブロックを同時に有効にすると優先が衝突するため、よくある質問の DNS の項 を手掛かりに、層を分けて切り分けてください。

企業ネットワークで公開名が書き換えられる場合は、Clash だけいじっても直らないことがあります。簡単な回線で再現するか、IT と resolver トレースを共有できる形でエスカレーションします。

システムプロキシ・TUN・テレビ／アプリ視聴

PC ブラウザならシステムプロキシで十分なことが多いですが、Smart TV やゲーム機、一部のネイティブアプリは OS プロキシを無視します。YouTube のテレビアプリやコンソール版は googlevideo.com への接続が増えがちで、プロキシを見ない端末ほど TUN で経路を揃える必要が出ます。TUN でデフォルトルート側から捕まえると同じプロファイルに揃えやすい反面、他 VPN やゼロトラスト製品と競合します。詳細は TUN モードの詳解 を先に読み、除外インターフェースと DNS の取り扱いを決めてから有効化してください。

ルール順・ブロックリスト・購読更新ループ

広告／トラッカー系リストが動画 CDN を誤ってブロックすると、UI は生きているのに再生だけが始まらないことがあります。ルールプロバイダを更新した直後に壊れたら、一つ前の版へ戻して差分を見てください。また、購読 URL やルールセット取得が死んだプロキシチェーンへ入ると更新が止まり、新ホストに追従できなくなります。購読とノード保守 の型で、更新経路を DIRECT または低リスク専用に分離します。

⚠ コンプライアンス：YouTube／Google の利用規約、著作権、コンテンツの地域ポリシー、および所在地・職場の法令・ネットワーク規則を遵守してください。本稿は許可された環境での経路衛生の説明であり、不正な地域偽装やサービス回避を推奨するものではありません。

Netflix／Disney+ 記事との棲み分け

当サイトの Netflix 向けストリーミング分流 は、nflxvideo.net など Netflix 固有の CDN 束を軸にしています。Disney+ 向け は bamgrid.com 系や disneyplus.com を中心にした別の名前空間です。一方 YouTube は googlevideo.com・ytimg.com・youtube.com・googleapis.com などGoogle 名前空間が広いため、ルールセットをそのまま流用するとホスト漏れが出やすいです。手法はいずれも「ストリーミング関連サフィックスを同一ポリシーへ」「DNS とルール順を一致」「テレビアプリは TUN を検討」という三拍子で似ていますが、コピペ対象のドメイン行だけはプラットフォームごとに差し替える必要があります。ChatGPT や Copilot など AI 向け記事とは目的が異なり、長尺動画のセッション維持と CDN 走線が主眼です。

許可された利用の前提で押さえるチェック

  1. YouTube・プロキシ・職場ポリシーのすべてで許容されているか確認する。
  2. 再生直前のホスト名を列挙し、STREAMING（相当）へ揃っているかログで見る。
  3. youtube.com だけプロキシ、googlevideo.com だけ直結、といった表の割れを潰す。
  4. ノード地区が UI・CDN・API でちぐはぐになっていないか確認する。
  5. DNS／fake-ip・ブラウザ DoH・OS リゾルバの二重化を整理する。
  6. ルール順とブロックリストの誤爆を確認する。
  7. 購読・ルール更新がループせず成功しているか確認する。
  8. システムプロキシと TUN、テレビ／アプリの経路差を比較する。
  9. ローカル要因を切ったうえでノードと配信側ステータスを切り分ける。

各ステップでログ行を残すと、設定の全消しより早く収束します。

まとめ

YouTube の視聴体験は、単一ドメインではなく本体 UI・動画 CDN・画像・API・広告／計測など複数ホストの協奏です。Clash は ドメイン分流とストリーミング向けポリシーグループで、その協奏を同じ出口ストーリーに揃え、ノード地区と地域検出の前提も一貫させる道具です。ズレはカクつきや Premium まわりの違和感として現れがちですが、ログとサフィックスの不足を埋めることで多くは再現可能な経路バグに戻せます。

グローバルプロキシより、名前空間を分けた方が帯域競合を減らし、AI 向けルールとも責務がぶつかりにくくなります。不透明なプロファイルより、編集と検証ができるクライアントを選ぶ価値は 2026 年も変わりません。

→ 無料で Clash をダウンロードし、カクつく再生や表示のズレを「経路の設計」として扱えるようにしてください。