ライブ配信が「別問題」になる理由（Netflix記事との違い）

オンデマンドはカタログ取得と再生セッションの関係が比較的安定しやすい一方、スポーツライブ は視聴者集中でエッジ負荷が跳ね上がり、セグメント単位 の取得失敗がすぐ画面に出ます。さらにアプリによっては、ログインや権利確認、おすすめ情報、計測ビーコンが 動画CDNとは別ドメイン に分かれ、ルールを広い GEOIP や MATCH だけに任せると、片方だけ別ノードへ流れることがあります。

本サイトの Netflix向け記事 が扱うのは主にリージョンとカタログ整合です。対して本稿は 低遅延のライブ視聴 を想定し、複数ホストにまたがる経路 を ポリシーグループ で束ねることに焦点を当てます。題材は異なり、検索意図も「映画」ではなく「中継・スポーツアプリ・CDN」に寄ります。

最初に決めること 「どの公式アプリ／ブラウザで見るか」を一つに絞り、再生中にログへ出るホスト名の一覧をメモしてから DOMAIN 行を足すと安全です。キーワードが短い DOMAIN-KEYWORD は誤爆しやすいので、ライブ用途では後回しにします。

2026年大会のスケジュール感と日本から見る時間帯

開催地が北米であることから、日本在住の視聴では 早朝から午前 に試合が集中しやすい時間帯が想定されます（現地の夏時間やグループステージの組み合わせによって前後します）。ライブ視聴では「その時間帯だけWi‑Fiが混む」「モバイル回線の基地局が混雑する」など、プロキシ以前の要因も重なります。切り分けでは、まず同じ端末で 別アプリの短時間動画 を試し、次にClashのログで policy名が一定か を見ると迷いにくいです。

追っかけ再生やハイライトのオンデマンドに切り替わると、接続パターンがライブとは変わります。症状報告を自分で再利用するには、「ライブ中／録画再生／ハイライト」のどれで再現したかをメモし、同じ手順でログを取り直すのが実務的です。

ポリシーグループ設計：ライブ用に出口を固定する

ライブでカクつく典型は、url-test や自動選択が短い間隔でノードを切り替え、セッション途中に 出口の国やASNが変わる ことです。視聴体験を優先するなら、ライブ専用に select で国を固定できるグループを用意し、手動で遅延の少ないノードを選ぶ構成が扱いやすいです。自動選択を使う場合も、テストURLと間隔によっては別地域へ寄ることがあるため、ログで実際の出口を確認します。

ゲームのストアCDNとコミュニティを分けた Steam／Epic向け記事 と同様、スポーツでも 大容量のセグメント取得 と 軽いAPI・認証 を分けて考えると、ルールの意図が説明しやすくなります。前者を SPORT-CDN、後者を SPORT-APP のように分けると、購読YAMLの可読性が上がります。

proxy-groups:
  - name: "SPORT-LIVE"
    type: select
    proxies:
      - "low-latency-node-A"
      - "low-latency-node-B"
      - "DIRECT"
  - name: "PROXY"
    type: url-test
    # ...
rules:
  - DOMAIN-SUFFIX,example-sports-cdn.net,SPORT-LIVE
  - DOMAIN-SUFFIX,example-league.app,SPORT-LIVE
  # Place GEOIP / MATCH below your sport rules

上記ホスト名は 説明用の仮名 です。実運用では開発者ツールやClashの接続ログに出た 実ホスト に置き換えてください。コア差を抑えたい場合は Clash Meta（mihomo）の更新 も検討します。

DOMAIN／DOMAIN-SUFFIXで拾う：アプリ・サイト・ライブCDN

スポーツ配信は、公式アプリが OSのネットワークスタック を直接使う例が多く、ブラウザの拡張機能やシステムプロキシの見え方とずれることがあります。TUNモードを使う場合は、OS全体のトラフィックが仮想NIC側に乗るため、UWPや一部アプリでは別の切り分けが必要になることがあります（Windowsの例は UWPとTUNの記事 を参照）。

DOMAIN-SUFFIX でまとめるときは、配信事業者が使う ライブ用CDN のサフィックスをログから拾い上げます。大容量の取得だけを SPORT-CDN に寄せ、計測や広告、開発者向けAPIまで同じ出口に乗せる必要は必ずしもありません。ただし分割しすぎると逆に別ノードへ流れるため、まずは 再生に必須なホスト から束ね、様子を見ます。

RULE-SET を購読している場合、自前の追記行を より上 に置くか、セット内の優先度を理解したうえで競合がないかを確認します。Clashのルールは 上から最初の一致 だけが採用されるため、意図しない行に先にマッチしていないかが鍵です。

カクつきをログで切り分ける：CDN・UDP・帯域

バッファリングの体感は、実際には セグメント取得の遅延・再バッファ・解像度の切り替え が混ざって見えます。Clash側で見るべきは、対象ホストに対してどの policy が選ばれたか、タイムアウトや REJECT が出ていないか、です。ノードの帯域が細い・混雑している場合は、ルールが正しくても改善しません。まず別ノードへ切り替え、同じホストでログを比較すると切り分けが早いです。

UDPやQUICを扱うクライアントでは、プロキシの設定やコアのバージョンによって挙動が変わります。ライブで途切れるときは、ブラウザとアプリで プロトコルが違わないか も疑い、可能なら同一端末・同一アプリで再現手順を固定します。大容量CDNの分割の考え方は、モデル取得の Hugging FaceのCDN分流 とも通じますが、こちらはライブ視聴向けです。

DNS・fake-ip：名前解決がルールより先に崩れるケース

ライブでもオンデマンドでも、不具合の多くはルール以前の 名前解決 にあります。fake-ipモードでは、クライアントが受け取るIPと実接続の関係が直感とずれるため、ログで どのドメインがどのルールに当たったか を追う習慣が重要です。nameserver-policy で特定サフィックスだけ別DNSへ送っている場合、ポリシーが広すぎると想定外のドメインまで流れ、逆にリージョン判定が乱れることがあります。

詳細は DNS fake-ipとredir-hostの記事 を参照してください。モバイル視聴では省電力やOSの制限の影響も出やすく、PCと同じYAMLでも結果が変わる点に注意します。

権利・利用規約・「公式／海外ソース」への向き合い方

本稿はネットワーク設定の一般論にとどまります。各国・各サービスの 放映権 と 利用規約 は異なり、居住地域で認められない視聴方法を技術で補うことは推奨しません。Clashの設定は、正当な契約の範囲で利用できる 公式アプリや公式サイト を前提に説明しています。権利者の許可のない配信源へ誘導する内容は扱いません。

コンプライアンス 旅行や一時滞在先での利用など、サービス側が許容する範囲は規約で確認してください。迷うときは公式のFAQやサポートに従い、本稿のYAML例はあくまで技術的なたたき台として扱ってください。

実測のすすめ：ログを単一の真実にする

設定変更後は、短時間でよいので ログを開いたまま ライブまたは同アプリの短い再生を試し、出たホスト名とマッチしたルールをメモします。ブラウザなら開発者ツールのネットワークタブ、テレビやセットトップボックスではルーター直下にプロキシを置くなど、観測できる範囲 を決めてから調整すると迷走しにくいです。購読の取得失敗で別の問題が重なっている場合は 購読更新の切り分け と混同しないよう、症状を分けて確認してください。

まとめ

2026年 の FIFAワールドカップ をはじめとする スポーツライブ では、オンデマンドの映画・ドラマとは異なり、CDN とマルチビットレート、複数ホストへの分散が前提になります。Clash の 分流ルール と ポリシーグループ で出口を揃え、DNS や fake-ip と整合させ、ログでホストとpolicyを照合する流れが実務では再現性が高いです。北米開催に伴う時間帯の偏りも、切り分けメモに含めると後から読み返しやすくなります。

クライアントの入手は ダウンロードページ で各OS向けを比較できます。GUIの違いで迷ったときも、まずログで「どのルールに乗ったか」を確定させ、YAMLを少しずつ調整すると手戻りが減ります。

→ Clashを無料ダウンロード — 購読リンクを取り込み、自分の環境に合うクライアントから試せます。

関連：YAML ルール分流の全般、技術コラム一覧。