2026 年 5 月の GPT-Realtime-2 と OpenAI Realtime API：WebSocket 長接続が「普通の API タイムアウト」と違う理由

2026 年 5 月、OpenAI は GPT-Realtime 系列（本稿では代表として GPT-Realtime-2 を扱います）を公開し、低遅延の音声対話と双方向ストリーミングを OpenAI Realtime API 経由で提供し始めました。開発者が最初に触るエンドポイントは、ほぼ例外なく wss://api.openai.com/v1/realtime 上の Realtime WebSocket です。REST の短い POST とは違い、セッション開始後は数秒から数分単位で TCP/TLS 接続を維持し、音声チャンクを双方向に流し続けます。

検索クエリでも「GPT-Realtime-2」「OpenAI Realtime API」「Clash 分流」「WebSocket 握手失敗」が一緒に並びやすくなっています。一方、現場では次のような断片的だが開発を止める症状が報告されています。(1)WebSocket 握手（101 Switching Protocols）の前にタイムアウト、(2)接続直後は音声が流れるが 20〜60 秒で突然切断、(3)片方向だけ遅延が跳ね上がり会話が途切れる、(4)同じ API キーで curl は通るのに SDK の WebSocket だけ失敗——といったパターンです。

ここでの誤読は「ChatGPT Web 版の分流と同じだからノードを替えれば直るはず」と短い HTTP 向けの感覚だけで判断することです。GPT-5.5 Instant × ChatGPT の分流記事やチャットサービス総合ガイドで整えた openai.com ルールは土台になりますが、Realtime WebSocket は長接続・低ジッター・プロセスごとのプロキシ継承という別次元の要件が乗ります。Codex MCP や IDE プラグイン寄りの話はCodex MCP 分流記事へ、動画 CDN 側はSora／OpenAI 動画 CDN 分流と役割分担してください。本稿の焦点はapi.openai.com 上の Realtime WebSocket を Clash で安定させることです。

免責：OpenAI の API 名称・エンドポイント・モデル提供条件は変更され得ます。本稿はネットワーク構成の検証フレームです。アカウント規約、課金、データ取り扱いは各自の契約に従って判断してください。技術的文脈でのプロキシ設計のみを対象とし、規制や雇用契約上の許諾がある環境でのみ適用してください。

Realtime WebSocketが止まって見える四つのパターン

OpenAI Realtime API の失敗は、ログ上では似たエラーコードでもネットワーク層では型が分かれます。型ごとに Clash が効く位置が違うため、最初のラベリングだけ丁寧にしてください。

握手前のタイムアウト（101 以前）：CONNECT api.openai.com:443 は見えるが Upgrade: websocket まで到達しない、または TLS ハンドシェイクで止まるパターン。広い GEOIP ルールに飲まれて不安定な自動選択ノードへ出ている、DNS が Clash 外で解決されている、システムプロキシを継がない SDK プロセスが直行している——のいずれかが多いです。
握手成功後 30 秒以内の切断：中間プロキシや一部ノードのアイドルタイムアウト、NAT セッションの早期破棄、url-test によるノード自動切り替えが長接続中に走るケース。接続一覧で切断直前に別ノードへ切り替わっていないか確認します。
音声は聞こえるが応答が 1〜2 秒遅れる：帯域ではなく往復遅延（RTT）とジッターの問題。Realtime 向けに選んだノードが HTTP ダウンロード向けの「数字だけ速い」出口だった可能性があります。地域としては OpenAI 側 PoP に近い北米西海岸系を優先し、過度に遠回りする経路を避けます。
ブラウザデモは動くがサーバー側 SDK だけ失敗：ブラウザはシステムプロキシを継ぐ一方、Node.js／Python の SDK プロセスは環境変数 HTTPS_PROXY 未設定で直行している典型例。ブラウザだけ通る問題の切り分けとセットで読むと理解が早いです。

共通の一次作業は、失敗タイミングと同じクロックで Clash／Clash Verge の接続タブから api.openai.com の行と選ばれたプロキシグループ名をコピーすることです。そのスナップショットが YAML を触る順序そのものになります。

TUN とシステムプロキシ：Realtime SDK はどちらを選ぶか

Realtime WebSocket を扱うアプリは、Electron デモ、Python スクリプト、バックエンドサービスなどプロセス形態がバラバラです。システムプロキシ（混合ポート）だけに頼ると「ブラウザ検証は成功、本番 SDK は失敗」という二重世界が起きやすくなります。

実務的な選び方は次のとおりです。(1)単一の Node.js／Python サービスだけが Realtime に接続するなら、HTTPS_PROXY と NO_PROXY を明示し、Clash の混合ポートへ寄せる方法でも十分なことが多いです。(2)複数プロセス・GUI アプリ・Docker コンテナが混在するなら、TUN モードで全 TCP を同じ mihomo インスタンスへ通す方が、WebSocket 長接続の経路一貫性を保ちやすいです。(3) WSL2 や Docker Desktop 併用時はDocker Desktop × ClashやWSL2 ルーティングも同時に確認してください。

ヒント：TUN を有効にしたら、Realtime 検証中はurl-test による自動ノード切り替えを一時停止するか、Realtime 専用グループを select 固定にしてください。長接続中の出口変更は WebSocket 切断の直接原因になりやすいです。

TUN の詳細はTUN モード完全ガイドを参照しながら、バイパスリストに Realtime を走らせるプロセスが入っていないか段階的に確認します。

api.openai.com 周辺で先に並べやすいドメインブロック

以下はログで実在を確認したあとでの加算が前提になる DOMAIN-SUFFIX の出発セットです。DESTINATION には後述の Realtime_OpenAI グループ名に置き換えてください。

Realtime API の背骨（必須）：api.openai.com — wss://api.openai.com/v1/realtime の SNI はここに載ります。可能なら DOMAIN,api.openai.com,Realtime_OpenAI を DOMAIN-SUFFIX,openai.com より上に置き、他の *.openai.com サブドメインと混線しないようにします。
共通ツリー（補助）：openai.com — 認証や管理系 API、将来の Realtime 関連サブドメイン追加に備えた広めのカバー。ただし広すぎる DOMAIN-KEYWORD は避け、ログに出た名前だけ足す運用が安全です。
アカウント・コンソール共有（ログ検証）：chatgpt.com — Realtime セッション確立前のトークン検証やアカウント状態読み込みで参照される構成があります。ワークフローに含まれれば同じグループへ寄せます。
添付・コンテンツ（ログ検証）：oaiusercontent.com など、音声ファイルのアップロードやプレビューで参照される場合のみ追加します。

注意：Realtime WebSocket は UDP ではありません。Discord 音声のような UDP 分流（Discord CDN × UDP 分流）を Realtime にそのまま当てはめる必要はなく、api.openai.com:443 の TCP/TLS 長接続を安定させることが中心です。

Clash Verge で「Realtime 専用」出口を切るグループ設計

生活用ブラウザ向けの url-test 自動選択グループとは別に、GPT-Realtime-2／OpenAI Realtime API 向けの Realtime_OpenAI という select 型グループを切る構成が読みやすいです。並べるノードの選び方は次の基準を推奨します。

長接続切断が少ない：Ping だけでなく、60 秒以上 WebSocket を維持できるかを実測で確認したノードだけを載せる。
RTT が安定：音声対話では平均 RTT よりジッター（遅延のばらつき）が体感品質を左右する。数字だけ最低のノードより、ばらつきが小さいノードを優先する。
地域：OpenAI API PoP との地理的近さを意識し、過度に遠回りするトランジットを避ける。同一サブスク内で「HTTP 向け」「Realtime 向け」を分けて選べると運用が楽です。

mihomo では名前付きグループ単位でのログ検索だけで「どのワークフローがどの経路だったか」を再現説明できるため、チーム開発でも説明コストが下がります。

YAML の骨格サンプル（概念・mihomo 互換）

キー名とインデントは実際のコアと GUI に合わせてください。ここでは読み順のイメージだけを示します。

proxy-groups:
  - name: Realtime_OpenAI
    type: select
    proxies:
      - 北米西海岸A
      - 北米西海岸B
      - 手動固定用

rules:
  - DOMAIN,api.openai.com,Realtime_OpenAI
  - DOMAIN-SUFFIX,openai.com,Realtime_OpenAI
  - DOMAIN-SUFFIX,chatgpt.com,Realtime_OpenAI
  - DOMAIN-SUFFIX,oaiusercontent.com,Realtime_OpenAI

このあと巨大な RULE-PROVIDER が上から先にマッチしていないかを確認し、社内直行や最終 MATCH まで繋ぎます。ノード比較実験では同一 YAML のまま出口だけを差し替え、同じ Realtime セッションを二度繰り返すと再現性の有無がはっきりします。

評価順の落とし穴：DOMAIN より上の IP ルールと ASN

分流ルールは上から打ち切られます。GEOIP や ASN、巨大 RULE-SET が先にあると、あなたの DOMAIN,api.openai.com に到達する前に締められている——という現場は珍しくありません。対策は、(1) Realtime 向けの具体的 DOMAIN 行を抽象的なセットより上へ移動、(2) IP 側の先勝ちを避けるためプロバイダ同期の末尾肥大化を定期レビュー、(3) mixin で Realtime 用フラグメントだけを単体適用して検証、の三本です。ルール分岐総論の読み順トレーニングを、この記事で挙げたホストだけ抜き出して練習すると自分の構成に落とし込みやすくなります。

DNS・Fake IP・WebSocket：名前解決が「別出口」問題に見える理由

名前解決がClash 外で完結していると、mihomo ダッシュボードの Fake IP 一覧は期待どおりでも、実送信は直行している——という見かけだけの一致が発生します。WebSocket SDK が接続先 IP をキャッシュしたあと DNS が切り替わると、握手は成功するが数秒後に経路不一致で切断という症状も起き得ます。

DNS／Fake IP の実務セットアップ記事にある前提とも齟齬がないか、ブラウザの Secure DNS と OS／ルータの名前解決を二重適用しないように整理してください。設定変更のたびに Realtime クライアントを一回終了させ、DNS キャッシュをまっさらにしてから単一ワークフローだけ再実行すると、ログの相関が取りやすくなります。

ノード地域選定：GPT-Realtime-2 音声向けの実測観点

Realtime 音声は帯域より低遅延・低ジッターが重要です。以下は同一サブスク内で複数地域を試すときの観点です。

西海岸（LA／San Jose 系）：OpenAI API との RTT が短くなりやすい。まず Realtime 専用グループの第一候補に。
東海岸：HTTP ダウンロードでは速く見えても Realtime では西海岸より RTT が伸びることがある。用途で分ける。
アジア経由トランジット：国内から見て Ping が低くても、国際バックホールでジッターが増えるノードは Realtime に向かない場合がある。
長接続テスト：wscat や SDK のサンプルで 60 秒以上維持し、途中切断がないかを確認してから本番ワークロードへ載せる。

すべてのノードが赤表示になる場合はノード全赤の切り分けも参照してください。UDP テスト結果だけで Realtime 向き否向きを決めないことがポイントです。

実測ステップ（`step-list`）

OpenAI Realtime API で外向き問題を疑うときの手順です。番号順の意味は変えないでください。

WebSocket 握手失敗または途中切断を二度だけ再現させ、終了直後に Clash／Clash Verge の接続一覧へ移り api.openai.com と Upgrade: websocket 行、マッチしたルール種別とグループ名をコピーする。
Realtime_OpenAI グループを作り、長接続テストで安定したノードだけを並べる。url-test 自動切り替えが Realtime 中に走らないよう select 固定または間隔を延ばす。
YAML で DOMAIN,api.openai.com がRULE-SET より上位にあるか一覧化し、プロバイダ同期で増殖した末尾セットが見落とされていないか確認する。
TUN または HTTPS_PROXY のどちらか一方の経路に統一し、SDK プロセスがプロキシを継いでいるか確認する。ブラウザだけ成功する場合は TUN 側へ寄せる。
DNS の二重適用を解消したうえで、同一ノード・同一 API キーで 60 秒以上の Realtime セッションを維持できるか再テストする。切断が続く場合は別地域ノードへ差し替えて比較する。

WebSocket／TCP レイヤの追加確認（開発者向け）

アプリログだけでは原因が曖昧なとき、次の短い確認でレイヤを切り分けます（本番キーをログに残さないよう注意）。

TLS 到達性：curl -Iv https://api.openai.com/ を HTTPS_PROXY 付き／なしで比較し、効く側を特定する。
WebSocket 握手：wscat 等で wss://api.openai.com/v1/realtime へ接続し、101 応答まで到達するか確認する（認証ヘッダは SDK に任せ、手動テスト時のみ最小権限キーを使う）。
長接続維持：接続後に 60 秒間 ping／音声無送信で維持し、中間切断が起きるか見る。アイドルタイムアウト疑いの切り分けになる。
Clash ログ：切断直前に api.openai.com 以外のホストへ新規接続が走っていないか確認する。DNS 切り替えやルール再評価の痕跡を探す。

FAQ：よくある切り分け

Q. ChatGPT Web 版の分流ルールをそのまま使えば Realtime も通りますか？ — openai.com 系の DOMAIN 行は共通基盤として有効ですが、Realtime は長時間 WebSocket を維持するため、専用グループと固定ノードを分ける運用を推奨します。GPT-5.5 Instant 分流と併読してください。

Q. Realtime は UDP 分流が必要ですか？ — 不要です。TCP/TLS 上の WebSocket です。UDP 分流が必要なのは Discord 音声など別プロトコルです。

Q. 社内プロキシと二重プロキシになりますか？ — 社内 MITM が必須の環境では Clash の上流設計から見直しが必要です。本稿のサンプルはクライアント側に判断余地がある前提です。

まとめと次のアクション

GPT-Realtime-2 と OpenAI Realtime API は、REST API よりWebSocket 長接続の経路一貫性が成否を分けます。DOMAIN,api.openai.com を軸に Realtime_OpenAI 専用グループへ先に評価し、TUN または HTTPS_PROXY で SDK プロセスの出口を統一、DNS の二重適用を解消し、長接続に強い地域ノードを選べば、「ノードの Ping だけ悪い」という誤認から抜け、観測ログの束として説明可能になります。ChatGPT Web 版、Codex MCP、動画 CDN とは検索意図が異なるため、相互リンクで補完するのが長期運用では読みやすいです。

コマンド断片だけのチュートリアルや、WebSocket 長接続を想定していない汎用 VPN 型ツールでは、握手成功後の途中切断や SDK プロセスのプロキシ未継承まで追い切れないことがあります。Clash 公式サイトは接続一覧を起点にした再現手順を重視した記事設計にしており、本稿も Realtime 向けの DOMAIN 分流と TUN 選定を同じ画面で確認できるフローへ寄せました。複数クライアントで比較実験するときはClash クライアント無料ダウンロードから環境別ビルドを取り、同一ノードを短時間で切り替えて Realtime セッションの再現性を確かめられます。GUI だけの商用プロキシアプリは手軽な一方、api.openai.com 向けのルール評価順や WebSocket 長接続中のノード固定といった開発者向け要件が見えにくく、トラブル時に原因の線を引きづらい場面もあります。Clash 公式サイトはオープンな mihomo コアとローカル YAML の可搬性を前提にしており、チームで Realtime 用フラグメントをレビュアブルに保ちやすいことと、モデル更新のたびにネットワーク設定を掘り直さなくてよいことのバランスを意識しています。まだ Realtime 向けの出口を固めていない場合は、まず単一の安定ノードと api.openai.com の明示分流に寄せてから GPT-Realtime-2 の音声ワークロードを載せるほうが、因果の線が追いやすくなります。必要になったタイミングで無料ダウンロードからクライアントを入手し、本稿の順序で一度だけ通しで試してみてください。