まず押さえること：YouTube 公式の品質レビューではない
配信側のエンコード品質、地域キャッシュ、広告挿入、端末のデコーダ負荷など、プロキシ以前で体感が決まる要素は多いです。ここでは「同じ動画を別回線・別端末では滑らかなのに、Clash 経由のこの PC だけがループする」といった、経路と名前解決が疑わしいケースを想定します。全動画が常に止まるなら帯域やノードの物理上限を先に疑い、特定の解像度だけ、夜間だけ、ブラウザだけ／アプリだけなど条件付きで悪化するなら、ルール命中と DNS のズレを疑う価値があります。
高ビットレートと「経路が合っていない」の切り分け
4K は秒間のデータ量が大きく、遅延やパケットロスに敏感です。一方で、画面は出るがしばらくして急に止まる、画質を一段下げると安定するのに上げると即ループ、といったパターンは、単純な「遅い回線」だけでは説明しきれないことがあります。切り分けのコツは、(1) プロキシをオフにしたときや テザリング に切り替えたときにだけ改善するか、(2) Clash の接続ログで googlevideo.com や youtube.com が意図したポリシーに載っているか、を見ることです。ノードの帯域が足りない場合は、解像度を下げても同じノードに流れ続ける限り改善が頭打ちになるため、別ポリシー（別グループ）への振り分けも検討します。
分流の骨格：動画・CDN だけプロキシ、他は直結
すべてのトラフィックを同じ出口に押し込むと、DNS 問い合わせや軽い API、静的アセットまで遠回りし、結果としてプレイヘッド（先読みバッファ）が育ちにくいことがあります。実務では、再生に直結するホスト（多くの環境で *.googlevideo.com や関連する動画配信 FQDN）を先に拾い、検索・サムネイル・設定画面などは地域直結や別ポリシーへ分ける、という最小代理の考え方が扱いやすいです。購読ルールが「Google 丸ごとプロキシ」になっている場合、意図せず不要なホストまで遠路に乗り、逆に遅くなることもあるため、ログに出た名前を正にして細かく整えます。
よく出るドメイン：固定表よりログ優先
代表的には youtube.com、youtu.be、画像や UI 周りの ytimg.com、ggpht.com、googleusercontent.com、そしてストリーム本体で googlevideo.com などが挙がります。実際の FQDN は地域・ISP・クライアント実装で増減するため、DOMAIN-KEYWORD,google のように広げすぎると無関係な Google 系まで誤爆しやすいです。HTTPS が IP 表示のまま でドメインルールに届かないときは、Sniffer と HTTPS のドメイン分流 で TLS SNI や QUIC からホストを復元する手順を併読してください。
ルール順：細かい一致と動画系を先に
Clash 系は上から順に評価します。GEOIP や巨大な Rule Provider に先に吸われると、YouTube 向けの個別行が到達しないことがあります。逆に「国内だけ直結」の広い DIRECT が、海外 CDN のエッジ IP にまで効いてしまい、帯域はあるのにレイテンシだけ悪化するパターンもあります。対策は、(1) 接続ログで実際に出た DOMAIN-SUFFIX を先頭付近へ、(2) 購読ルールを触れない場合はクライアントのルール上書き／プリペンドで例外を足す、の二点が実務的です。国コードとドメイン集合をまとめて使う場合は GEOIP／GEOSITE 分流の記事 も参照し、no-resolve や geodata 更新との関係を整理してください。
YAML スケッチ：動画系をポリシーへ（説明用）
以下は説明用です。YOUR_PROXY_GROUP は利用中のポリシー名に置き換え、実ホストは必ずログで検証してください。自宅回線が十分速いなら、動画以外を DIRECT に寄せるほど出口の一貫性が上がる場合もあります。
# Example: YouTube playback + related hosts (verify FQDNs from your logs)
rules:
- DOMAIN-SUFFIX,googlevideo.com,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,youtube.com,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,ytimg.com,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,ggpht.com,DIRECT
# Add only suffixes you see; avoid overly broad KEYWORD rules
ggpht.com を直結に残すか同じ出口に乗せるかは、サムネイル取得の遅延とルール単純化のトレードオフです。HDR や高フレームでは帯域の頭打ちが出やすいので、ポリシーは「遅延重視」「帯域重視」で別グループに分け、自動選択の条件も見直すと改善することがあります。
DNS・FakeIP・DoH：ルールと解決経路を一致させる
分流は多くの場合、名前解決のあとに効く前提で設計されます。OS が Clash を経由せず ISP の DNS へ向いていると、得られた IP がルールの想定と合わず、画面は出るが再生だけループといった不整合が起きます。FakeIP を使うときは、仮想アドレスとルール評価順が意図どおりか接続ログで確認してください。ブラウザのセキュア DNS をオンにしたまま Clash 側とも別々に DoH を向けていると二重解決が起きやすいので、切り分け時は一時的にブラウザ側をオフにして比較するのも有効です。詳細は Meta コア DNS リーク防止ガイド を参照ください。
アプリとブラウザ：捕捉漏れを減らす
ブラウザは OS のプロキシ設定を尊重しやすい一方、デスクトップの YouTube アプリや Electron 系は独自スタックになりがちです。TUN モードはルーティング層で捕捉するため、複数クライアントを同じ分流設計に乗せやすくなります。プロセス単位で出口を切り替えたい場合は PROCESS-NAME ルールの記事 を参照し、Windows の exe 名・macOS のバイナリ名をログと突き合わせてください。初めて PC 側に Clash を入れる場合は Windows での Clash Verge Rev セットアップ（2026） と合わせると、プロファイル読み込みからシステム連携までの流れが掴みやすいです。
実務のコツ：同じノードでも時間帯で混雑が変わります。4K だけ不安定なら、まずは別ノード／別プロトコルを試しつつ、ログで googlevideo が本当にそのポリシーに載っているかを確認してください。帯域は十分なのに SNI が取れずルールがズレているケースは Sniffer が効きやすいです。
Steam 記事との棲み分け
Steam 向けの稿 は store.steampowered.com や steamcommunity.com など、ランチャーと CDN が分かれやすいホストを例にしています。YouTube は googlevideo を中心にストリームが伸び、サムネイルやメタデータが別ホストに分散するため、どの FQDN がバッファ中に増えるかをログで見る作業がより重要になります。いずれも「広い KEYWORD よりログで足す」という運用は共通です。
おすすめの作業順（最小）
- Clash を Rule モードで動かし、プロファイルが意図どおり読み込まれているか確認する。
- 4K 再生で症状が出る操作に絞り、接続ログのドメイン（特に
googlevideo）を控える。 DOMAIN-SUFFIXで動画系を意図したポリシーへ流し、ルール順序で他ルールに負けていないか確認する。- DNS が Clash と矛盾していないか、FakeIP・DoH・ブラウザのセキュア DNS を含めて比較する（DNS ガイド）。
- HTTPS が IP 表示のままなら Sniffer を検討。アプリだけおかしい場合は TUN や PROCESS-NAME を疑う。
注意：職場・学校・地域の契約によっては、プロキシや迂回ツールの利用が禁止されている場合があります。YouTube の利用規約・ローカル法規も確認のうえ、許可された環境でのみ設定してください。
まとめ
YouTube の 4K や高ビットレートで バッファが続く症状は、ノードの物理上限だけでなく、Clash の分流 と DNS の不整合でも起こり得ます。googlevideo.com など再生に直結するホストを接続ログで特定し、ルールの優先順位 で誤命中を防ぎ、FakeIP・DoH・ブラウザのセキュア DNS まで含めて名前解決の経路を揃えると、再生の安定性を高めやすくなります。ホスト構成は変わり得るため、広すぎる DOMAIN-KEYWORD よりログで事実を取り、必要なサフィックスだけを足す運用が 2026 年現在もっとも再現性が高いです。クライアントの入手と更新は 公式ダウンロードページ から行うと、インストーラ取得とソース閲覧の目的が混ざりにくくなります。