モータースポーツライブが「別物」になる理由
オンデマンドの映画では、ある程度 バッファを深く取ってから再生 する設計が許容されやすい一方、F1 のようなライブ中継は遅延を抑えるため セグメント長が短く、欠損や遅延がすぐ画面に出ます。アプリやブラウザは マスター・マニフェスト から メディアセグメント を順に引き、状況に応じて解像度を上下させる ABR（適応的ビットレート）も動きます。このとき 認証トークン、ライブタイミング、データ可視化、広告・計測 が別FQDNに分かれていると、見た目は同じアプリでも 背後では複数系列のTCP／TLS が並走しています。
Clash で GEOIP や広い MATCH だけに任せると、たとえば APIと映像CDN が別ノードに流れ、片方だけ遅い・片方だけ遮断、といった 部分的成功 が起きやすいです。レースウィークは視聴者集中でCDN側の負荷も上がるため、プロキシ以前の要因と混ざります。切り分けの第一歩は、再生中にログへ出る ホスト名の一覧 をメモし、どの policy に乗ったかを揃えることです。
DOMAIN-KEYWORD は誤爆しやすいので、ログに出た実名から DOMAIN-SUFFIX を優先します。
ワールドカップ稿・Netflix稿との役割分担
本サイトの ワールドカップ向け記事 も スポーツライブ と CDN を扱いますが、想定する 放送エコシステムと典型ドメイン がサッカー大会寄りです。F1 は formula1.com 配下のサービス、各国の独占配信、タイムシフトやオンボード映像など周辺機能のホストが増えやすく、ログに現れる名前の集合が異なります。SEO と読者シーンの両面で記事を分けています。
Netflix向け記事 が扱うのは主に カタログとDRMのリージョン整合 です。対して本稿は レースセッション中の低遅延ストリーム を想定し、セグメント取得の連続性と ポリシーグループ による出口固定に焦点を当てます。題材が違えば検索意図も「映画」ではなく「F1 ライブ」「F1 TV」「カクつき」に寄るため、ルールの考え方は共通でも調整ポイントは別になります。
2026年シーズンの視聴パターン（時差と集中）
シーズン中は欧州・中東・アジア・アメリカと開催地が移り、日本から見ると 深夜から早朝 に集中する週と、比較的視聴しやすい時間帯が混在します。中国グランプリ のようなアジア戦では国内の話題と検索ボリュームが一気に伸び、配信CDNのエッジ負荷とDNSキャッシュの挙動が普段と違うこともあります。モバイル回線と宅内Wi‑Fiで症状が変わる場合、プロキシ以前に 基地局混雑 や ルーター負荷 を疑います。
タイムシフト再生やハイライトのオンデマンドに切り替わると、接続パターンはライブとは別物です。メモには「ライブ中／アーカイブ／ハイライト」の区別を残し、同じ手順でログを取り直すと再現性が上がります。
ポリシーグループ：ライブ用に出口を固定する
ライブでカクつく典型は、url-test や自動選択が短い間隔でノードを切り替え、セッション途中に 出口の国やASNが変わる ことです。視聴体験を優先するなら、F1向けに select で国やプロバイダを固定できる ポリシーグループ を用意し、遅延の少ないノードを手動選択する構成が扱いやすいです。自動選択を使う場合も、テストURLと間隔によっては想定外の地域へ寄るため、ログで実際の出口を確認します。
命名は運用チームで揃えるとよく、例として F1-LIVE に映像系、F1-API に認証・計測・ライブタイミング系を寄せる二段構成が説明しやすいです。ゲームのストアCDNとコミュニティを分けた Steam／Epic向け記事 と同様、大容量セグメント と 軽いAPI を分けて考えるとYAMLの意図が明確になります。
proxy-groups: - name: "F1-LIVE" type: select proxies: - "low-latency-A" - "low-latency-B" - "DIRECT" - name: "PROXY" type: url-test proxies: - "auto-node-1" - "auto-node-2"
rules: - DOMAIN-SUFFIX,formula1.com,F1-LIVE - DOMAIN-SUFFIX,example-live-cdn.net,F1-LIVE # Place GEOIP / MATCH below your F1 rules
example-live-cdn.net は 説明用の仮名 です。実運用では開発者ツールやClashの接続ログに出た 実ホスト のサフィックスへ置き換えてください。コア差を抑えたい場合は Clash Meta（mihomo）の更新 も検討します。
DOMAIN-SUFFIXで束ねる：F1 TV・計測・CDNの典型
公式アプリは OSのネットワークスタック を直接使うことが多く、ブラウザ拡張やシステムプロキシの見え方とずれる場合があります。TUNモードでは仮想NIC側にトラフィックが乗るため、WindowsのUWPなどは別途切り分けが必要になることがあります（UWPとTUNの記事）。
ドメイン設計の実務では、まず formula1.com 配下を広くカバーし、ログに出た サブドメイン を足し込みます。F1 TVのWebやアプリは年度やクライアント更新でホストが増えるため、静的な「完璧なリスト」より、ログ起点のメンテナンス が現実的です。映像本体を配る CDN のFQDNは、事業者や地域でブレるため、視聴環境ごとに一度ずつ確認するのが安全です。
RULE-SET を購読している場合、自前の追記行を より上 に置くか、セット内の優先度を理解したうえで競合がないかを確認します。Clashのルールは 上から最初の一致 だけが採用されるため、意図しない行に先にマッチしていないかが鍵です。
バッファをログで切り分ける：セグメント・QUIC・帯域
体感のカクつきは、セグメント遅延・再バッファ・解像度切替 が混ざって見えます。Clash側で見るべきは、対象ホストにどの policy が選ばれたか、タイムアウトや REJECT がないか、です。ノードの帯域が細い・混雑している場合はルールが正しくても改善しません。まず別ノードへ切り替え、同じホストでログを比較すると早いです。
QUIC やHTTP3を使うクライアントでは、プロキシ実装やコアのバージョンによって挙動が変わります。ブラウザとネイティブアプリでプロトコルが違わないかも疑い、可能なら同一端末・同一アプリで手順を固定します。大容量CDNの分割の考え方は Hugging FaceのCDN分流 にも通じますが、こちらはライブ視聴向けです。
DNS・fake-ip：名前解決が先に崩れるケース
不具合の多くはルール以前の 名前解決 にあります。fake-ipモードでは、クライアントが受け取るIPと実接続の関係が直感とずれるため、ログで どのドメインがどのルールに当たったか を追う習慣が重要です。nameserver-policy で特定サフィックスだけ別DNSへ送っている場合、ポリシーが広すぎると想定外のドメインまで流れ、逆にリージョン判定が乱れることがあります。
詳細は DNS fake-ipとredir-hostの記事 を参照してください。モバイル視聴では省電力やOS制限の影響も出やすく、PCと同じYAMLでも結果が変わる点に注意します。
権利・利用規約・コンプライアンス
本稿はネットワーク設定の一般論にとどまります。各国の 放映権 と各サービスの 利用規約 は異なり、居住地域で認められない視聴を技術で補うことは推奨しません。F1 TV や提携プラットフォームは契約プランと視聴可能地域が定められているため、迷うときは公式の案内に従ってください。
実測チェックリスト：ログを単一の真実にする
設定変更後は短時間でよいので ログを開いたまま セッション再生を試し、出たホスト名とマッチしたルールをメモします。ブラウザなら開発者ツールのネットワークタブ、テレビやセットトップボックスではルーター直下にプロキシを置くなど、観測できる範囲 を決めてから調整すると迷走しにくいです。購読の取得失敗が重なっている場合は 購読更新の切り分け と混同しないよう、症状を分けて確認してください。
手順の再現性を上げるには、(1) クライアントとコアのバージョンを固定、(2) TUN／システム代理のどちらで試しているか明記、(3) 選択中のノード名とpolicyをスクリーンショット、(4) 問題のセッション名（FP1／予選など）を記録、の四点をそろえると、後からYAMLを見返したときに迷いが減ります。
まとめ
2026年 の F1 シーズンでは、F1 TV や各国の スポーツライブ が CDN と低遅延設計の前面に出ます。Clash の 分流ルール と ポリシーグループ で DOMAIN-SUFFIX 単位に出口を揃え、DNS や fake-ip と整合させ、ログでホストとpolicyを照合する流れが実務では再現性が高いです。ワールドカップやNetflixの各稿と題材は異なりますが、「ログに出た実名からルールを足す」 という作業姿勢は共通です。
クライアントの入手は ダウンロードページ で各OS向けを比較できます。GUIの違いで迷ったときも、まずログで「どのルールに乗ったか」を確定させ、YAMLを少しずつ調整すると手戻りが減ります。
関連：YAML ルール分流の全般、技術コラム一覧。