動画 UI がスピナーのままに見えるときの典型
OpenAI が提供する動画まわりのウェブ UIは、テキストチャットより帯域と持続時間の長い TCP セッションを要求します。初期表示用のバンドル、計測・認証、REST/SSE 相当の API、そしてプレビューや成果物のメディア断片が、それぞれ別サブドメインや CDN に分散しているのが普通です。外枠だけ描画され、 Canvas や video 要素が期待どおり初期化されない、プログレスバーだけ動いて完了しない——こうした挙動は、しばしば経路の不整合として現れます。
具体例として、API 用ホストだけプロキシに乗り、メディア取得先だけ遅い直結やフィルタ済み出口に残ると、ブラウザは一つの体験として成立させられません。DNS の答えがローカルで合成された fake-ip なのに、ドメインルールが追従していない行へ流れている場合も同様です。症状の本体は魔法ではなく、Clash のログでポリシー命中と失敗段階を突き合わせられる種類の問題です。禁止された利用形態を開く手順ではない点に留意してください。
.mp4 やセグメント URL だけ pending のまま、というパターンはメディア CDN の出口ずれを強く疑います。
チャット向けルールだけでは足りない理由
すでに ChatGPT/OpenAI 向けのドメイン分流を整えていても、動画生成 UIは触れる名前空間が一段広がります。チャットで十分だった openai.com や oaistatic.com 周辺に加え、プレビュー配信や署名付き URL、第三者 CDN 名義のホストが追加されると、既存ルールの隙間に落ちます。
対処は「全部グローバルプロキシ」ではなく、動画体験に関わるホストを明示的に同じポリシーグループへ集約することです。ストリーミング全般の考え方は Netflix 向けのノード・ドメイン分流 や YouTube の動画 CDN 分流 に近く、メタデータ用とメディア用を別ストラテジに割らないという発想がそのまま効きます。
ルールの書き方と並べ順の原則は ルール分流のベストプラクティス に倣うのが安全です。広すぎる捕捉行を細かな OpenAI 行より上に置くと、意図せず DIRECT へ落ちたり別グループへ抜けたりします。
分流の核:OPENAI_MEDIA を一つに束ねる
推奨パターンは、例として OPENAI_MEDIA のような dedicated ポリシーグループを用意し、チャット専用の AI_PROXY と分けても同じ実体のノード集合に繋いでも一緒でも構いません。重要なのは、動画 UI に関わるホスト名がすべて同じ論理出口に収束することで、実トラフィックの観察結果とプロファイルを一致させることです。
普段の閲覧や国内向けは DIRECT に残し、OpenAI 動画束だけを HTTPS が安定しやすいチェーンへ送る——この構図はチャット版と同型です。違いは帯域と長命接続なので、同一ポリシーでも url-test の間隔やフォールバック閾値が厳しすぎると、動画途中でノードが切り替わり タイムアウト に見えることがあります。挙動の読み方は timeout と TLS のログ記事 が参考になります。
ログが読みやすいクライアント選定は クライアントの選び方 も参照してください。動画は失敗が視覚に直結するため、接続ビューアの有無はチャット以上に効きます。
DOMAIN-SUFFIX とメディア CDN の取りこぼし
まず観測から入ります。失敗時に出たホスト名をメモし、プロファイルの行き先と突き合わせます。静的資産に強い openai.com/chatgpt.com/oaistatic.com など代表的な接尾辞に加え、プレビュー配信に使われる新しいサブドメインや 署名付きドメインが増えたら、同じ OPENAI_MEDIA 行へ足していきます。DOMAIN-KEYWORD は早い反面誤爆しやすいので、実トラフィックを見てからにします。
第三者ルールの ルールプロバイダ/RULE-SET に OpenAI 分類がある場合、それを信頼して取り込んでも構いません。ただし分類更新の遅れや 動画専用ホストの欠落は常に起こり得ます。巨大なブロックリストが細かな接尾辞行を隠してしまわないよう、ローカルの追補行を残す運用が長期では楽です。
Illustrative YAML fragment
rules:
- DOMAIN-SUFFIX,openai.com,OPENAI_MEDIA
- DOMAIN-SUFFIX,chatgpt.com,OPENAI_MEDIA
- DOMAIN-SUFFIX,oaistatic.com,OPENAI_MEDIA
- DOMAIN-SUFFIX,oaiusercontent.com,OPENAI_MEDIA
- GEOIP,CN,DIRECT
- MATCH,DIRECT
oaiusercontent.com などの例は、利用製品の版や地域によって実際に出るかは検証次第です。行の意味は「この接尾辞にマッチした通信をすべて同じ出口へ」という一点に尽き、存在しないホストを書いても害は少ない一方、観測されていない重要ホストの欠落が問題です。新エンドポイントは開発者ツールの HAR や接続ログで追いかけます。
ルールセットと「大容量に強い」ノード選び
動画はレイテンシだけでなく損失と途中帯域が効きます。細い空港リンクや過剰な輻輳ノードでは、テキスト API は通ってもメディアだけ TCP タイムアウト に見えることがあります。OPENAI_MEDIA に渡すチェーンは、可能なら同一リージョンに固定し、自動選択の振れ幅を抑えます。
ルールセット運用では、更新間隔と失敗時のロールバック手順を決めておきます。ルール更新そのものがプロキシループに飲まれると、新しいホストが永遠に追加されません。購読 URL の直結や専用更新ポリシーは 購読とノード保守 の考え方と同じです。
DNS/fake-ip と TLS タイムアウトの切り分け
fake-ip モードでは、ブラウザに返すアドレスと実際の出口側の名前解決が分離されます。ドメインルールが追従していないホストだけズレると、「名前解決は一瞬で終わったのに接続が進まない」という典型的な壊れ方をします。OpenAI 動画で増えたサブドメインは、まさにこの穴に落ちやすいです。
Clash Meta の DNS 設定では、nameserver と fallback、fake-ip-filter の関係を先に揃えます。ブラウザだけ別経路の DoH を使うと、見えている挙動と Clash の内部状態が食い違います。FAQ の DNS/接続性 も併読し、「悪い答え」と「良い答えだが出口が違う」を分けてください。
ルール順・TUN・ブラウザの取り違え
ルールは上から最初の一致が勝ちます。広い GEOIP や巨大 RULE-SET が、OpenAI 向けの具体行より上にあると、メディアだけ想定外の経路へ流れます。逆に広告ブロック系が誤って CDN を止め、プレビューだけ欠損することもあります。並べ替えたらログで命中を再確認します。
ブラウザ拡張や別プロキシが OS 設定を迂回している場合、テキストは通ってもメディアだけ別口——という分割も起きます。確実に揃えるなら TUN でルーティング表に落とす選択肢があります。導入時は TUN の詳解 で他 VPN/仮想アダプタとの干渉を先に確認してください。
コンプライアンスを踏まえた自己チェック
上から順に潰すと、設定迷走を減らせます。
- この環境で OpenAI 動画とプロキシ利用が許可されているか確認する。
- 開発者ツールで遅延/失敗しているホスト名を列挙する。
- そのホストがすべて
OPENAI_MEDIA(相当)へ揃っているか Clash のログで確認する。 - ルールプロバイダと手書き接尾辞を更新し、欠けを埋める。
- DNS・fake-ip・ブラウザ DoH の優先順位が食い違っていないか確認する。
- 帯域の細いノードではなく、動画に耐えるチェーンへ切り替え比較する。
- TUN とシステムプロキシのどちらで挙動が一致するか A/B する。
まとめ:動画は「束ねてから」詰める
Sora を含む OpenAI 系の動画 UI は、チャットよりメディア CDN と API の両輪がはっきり分かれます。Clash ではその両方を同じポリシーに載せ、DNS をルールと同一の設計として扱えば、スピナーや途中黒画面の多くは「経路のバグ」として説明できます。神秘化せず、ログとホスト一覧で追いかけるのが最短です。
グローバルスイッチに逃げる代わりに、束の明示化とルールセットの保守に時間を使うほうが、後から楽です。透明なモデルと更新可能なプロファイルが、動画のような重いワークロードほど効きます。
→ 無料で Clash をダウンロードし、プレビューが回り続ける本当の理由を当てずっぽうで嫌わず、生成そのものに集中してください。