ClashでYouTubeが遅い・再生できない時の設定と対処法

まず確認したい症状と切り分けの順番

Clash を使うと YouTube だけ遅い、動画のサムネイルは表示されるのに再生開始まで長い、再生中に何度もバッファリングする、といった症状は、単純な回線速度だけでは説明できないことがあります。特に同じ Wi-Fi で通常のウェブサイトや速度測定は快適なのに、YouTube の動画だけが止まる場合は、選択中のノード、ルールの判定、DNS の応答、動画 CDN への経路を順番に確認する必要があります。

最初から YAML を大きく書き換えるのではなく、Clash を停止した状態、Clash を起動して DIRECT にした状態、プロキシ経由の状態を比較してください。停止時にも遅いなら、家庭内ネットワーク、ISP、端末の Wi-Fi、YouTube 側の一時障害などが候補になります。DIRECT では再生でき、特定のプロキシグループだけ遅いなら、そのグループのノード品質や出口地域を疑うのが自然です。

YouTube はページ本体、画像、広告、字幕、動画マニフェスト、実際の映像チャンクを複数のホストから取得します。そのためページが表示されたことは、動画データの経路が正常であることを意味しません。ホーム画面だけ速く、再生時だけ止まる場合は、後段の動画 CDN が別のルールへ落ちている可能性があります。

ノードとプロキシグループを見直す

動画再生では、単純な最高速度だけでなく、遅延の安定性、パケットロス、長時間接続の維持、出口地域が重要です。速度テストで一瞬だけ高い数値が出るノードでも、数分間の動画通信で輻輳するとバッファが枯れます。逆に測定値が目立たないノードでも、混雑が少なく応答が安定していれば、実際の再生は滑らかなことがあります。

Clash のプロキシグループが select なら、まず別のノードへ手動で切り替えます。url-test を使っている場合は、測定 URL の応答速度だけで選ばれていないか確認してください。測定 URL が短い HTTP 応答を返すだけなら、YouTube の長時間ストリーミングに必要な品質を十分に表せないことがあります。fallback は障害時の切り替えには便利ですが、現在の再生が止まった瞬間に切り替わるため、再生中の体感が完全に途切れないとは限りません。

自動選択グループを使う場合も、検証時だけは手動選択に切り替えると差分を取りやすくなります。ノードを変えるたびに動画、画質、再生時間をそろえ、感覚だけで「こちらが速い」と判断しないことが大切です。複数端末で同じノードを使っているなら、他端末の大容量ダウンロードやゲーム更新が帯域を圧迫していないかも確認します。

ルール設定と動画 CDN の経路を確認する

YouTube の通信をすべて同じポリシーへ送る構成は分かりやすい一方、サービス周辺のドメインが多いため、広いルールやルールプロバイダの更新によって意図しない出口になることがあります。Clash は上から順番にルールを評価し、最初に一致したルールで処理します。最後の MATCH まで落ちている接続がないか、ライブ接続画面で確認してください。

たとえば YouTube のページ本体はプロキシ経由なのに、動画配信に使われる CDN だけが DIRECT になっていると、ページは開いても映像チャンクの取得で待ち時間が増えることがあります。反対に、地域内で直結したほうが安定するホストまで遠いノードへ送ると、余計な遅延や混雑が発生します。重要なのは「YouTube という名前の行を一つ追加すること」ではなく、実際の接続ログでどのホストがどのポリシーに割り当てられたかを確認することです。

rules:
  - DOMAIN-SUFFIX,youtube.com,YOUTUBE_POLICY
  - DOMAIN-SUFFIX,youtu.be,YOUTUBE_POLICY
  - DOMAIN-SUFFIX,googlevideo.com,YOUTUBE_POLICY
  - DOMAIN-SUFFIX,ytimg.com,YOUTUBE_POLICY
  - MATCH,FINAL_POLICY

上の断片は考え方を示す例であり、そのまま全環境へ貼り付ける設定ではありません。購読設定にすでに同等のルールがある場合、同じドメインを別のルールプロバイダで重複登録すると、更新順や優先順位が読みにくくなります。まず現在のルールをバックアップし、追加するなら最小限のドメインから始めてください。googlevideo.com を広く扱う変更は他の Google サービスにも影響する場合があるため、接続ログと他サービスの挙動を確認しながら調整します。

DNS と IPv4・IPv6 の不一致を直す

DNS の問題では、動画データそのものではなく、最初の接続先を決める段階で時間がかかります。Clash の DNS を使う構成と、OS やルーターの DNS を使う構成が混在すると、同じドメインでも異なる IP アドレスが返り、ノードの出口地域と CDN の割り当てが噛み合わなくなることがあります。特に「最初の数秒だけ長く待つ」「再読み込みすると急に再生できる」という場合は、名前解決と接続確立を分けて考えてください。

Mihomo 系クライアントでは、DNS の拡張モード、Fake-IP、Redir-Host などの表示がクライアントによって異なります。設定名だけを別の記事からコピーするのではなく、自分のコアが対応している項目かを確認します。DNS を変更した後は、ブラウザの DNS キャッシュ、OS のキャッシュ、Clash のキャッシュが残ることもあるため、変更直後の一回だけで結論を出さないようにします。

IPv6 が有効な環境では、IPv6 経路だけ品質が悪く、ブラウザが IPv6 接続を優先して動画が不安定になることがあります。Clash のログに IPv6 アドレスへの接続失敗や再試行が目立つなら、端末、ルーター、クライアントの IPv6 処理を一つずつ比較してください。IPv6 を無条件に無効化するのではなく、Clash を停止した場合と起動した場合で挙動が変わるかを確認するのが安全です。

DNS を変更した後の確認方法

DNS 設定を変更したら、同じ動画ページを新しいプライベートウィンドウで開き、最初の再生開始時間とライブ接続ログを比較します。広告ブロックやブラウザ拡張を一時的に無効にすると、動画本体と別リクエストの影響を分離できます。DNS だけ変えてノードを固定し、次にノードだけ変えて DNS を固定するという一度に一要素だけ変える実験が、最も再現性の高い方法です。

TUN・システムプロキシ・ブラウザ設定の確認

Clash のモードが Rule、Global、Direct のどれかによって、同じブラウザでも通信経路が変わります。システムプロキシをオンにしていても、ブラウザや拡張機能が独自のプロキシ設定を持っていれば、期待したポリシーを通らないことがあります。逆に TUN を有効にすると、ブラウザ以外の通信も捕捉され、DNS や QUIC の扱いまで変化します。

まずは TUN を使わず、システムプロキシだけで YouTube を開きます。この状態で安定するなら、TUN のルーティング、仮想インターフェース、他の VPN との競合が候補になります。TUN でだけ遅い場合は、Clash のログにブラウザのプロセスが現れているか、DNS の hijack が有効か、除外ルートが意図せず広くないかを確認してください。

YouTube で再生ボタンを押しても始まらない場合、ブラウザが HTTP/3 や QUIC を利用しようとして UDP 通信を選んでいることがあります。環境によっては TCP の HTTPS より UDP 経路が不安定になるため、ブラウザ側の実験的な設定、Clash の UDP 対応、ノード側の UDP 転送可否を確認します。安易に複数の設定を同時変更すると原因が見えなくなるので、まず同じブラウザで別プロファイルを使い、差分を小さくしてください。

切り分けの基本：「Clash のオン・オフ」「ノードの変更」「DNS の変更」「TUN のオン・オフ」「ブラウザの変更」を一度に実行しないことです。各テストの動画、画質、時間帯、選択ノードを記録すると、偶然の混雑と設定変更の効果を区別できます。

改善しない時の復旧チェックリスト

ここまで確認しても改善しない場合は、設定を増やすより一度構成を簡素化します。購読プロファイルをバックアップし、カスタムルール、ルールプロバイダ、DNS の追加設定を一時的に外して、最小構成で再生します。最小構成で安定するなら、外した要素を一つずつ戻せば、原因となった設定を特定できます。

1. Clash のコアとクライアントを再起動し、接続ログを空にする。
2. 同じ動画を使い、DIRECT とプロキシ経由を比較する。
3. 手動選択で複数ノードを試し、再生開始時間と停止回数を記録する。
4. youtube.com、googlevideo.com、ytimg.com の判定先を確認する。
5. DNS、IPv6、TUN、QUIC を一項目ずつ検証する。
6. 改善後の設定を保存し、購読更新で上書きされない場所へ分離する。

ノード自体が原因なら、同じプロバイダ内の別地域や別回線のノードを試します。どのノードでも同じ時間帯に遅いなら、プロバイダ側の帯域制限や YouTube 側の一時的な混雑も考えられます。特定のブラウザだけで起きる場合は、拡張機能、キャッシュ、ハードウェアアクセラレーション、ブラウザ独自の DNS 設定を確認してください。問題を「Clash の設定ミス」と決めつけず、端末・回線・ノード・サービスの四層に分けると、不要な変更を減らせます。

よくある質問

DIRECT なら再生できるのに、プロキシだと遅いのはなぜですか？

プロキシ経由では自宅からノードまで、ノードから YouTube や動画 CDN までの経路が追加されます。ノードの混雑、出口地域、DNS の地域判定、長時間接続の品質が原因になりやすいため、別ノードを手動選択して比較してください。

DNS を変えれば必ず速くなりますか？

DNS は接続先を決める初期段階を改善する可能性がありますが、ノードの帯域不足やパケットロスを解決するものではありません。再生開始だけ遅いのか、再生中も止まるのかを分けて判断する必要があります。

TUN を有効にしたほうが YouTube は安定しますか？

ブラウザ以外の通信も同じ経路へそろえたい場合には有効ですが、仮想インターフェース、IPv6、UDP、他の VPN と競合することもあります。まずシステムプロキシだけで正常動作を確認し、その後 TUN を追加する順番が安全です。

画質を下げてもバッファリングします。何を見ればよいですか？

低画質でも止まる場合は、帯域の絶対量より接続の安定性、DNS、ルールの誤判定、ノードの長時間接続品質が疑わしくなります。Clash のライブ接続で動画関連ホストのルールとノードを確認し、別ノードで同じ動画を試してください。

YouTube のバッファリング対策では、古い GUI の手順をそのまま使うとメニュー名や DNS の挙動が合わず、設定だけが複雑になることがあります。一般的な VPN アプリはノードの切り替えが簡単でも、ルールの優先順位や接続ログを細かく追いにくい場合があります。一方、Clash V.CORE ならプロキシグループ、ドメインルール、DNS、TUN の状態を同じ運用画面で確認し、今回のような「ページは開くのに動画だけ止まる」問題を段階的に切り分けられます。設定を自分で検証しながら安定した再生環境を作りたい方は、対応環境を確認してダウンロードしてください。