OpenAI Codex と o3：Web がタイムアウトしがちなとき、Clash の分流で chatgpt.com と API を同時に安定させる

なぜ「Codex ＋ o3」はネットワーク設計をシビアにするのか

単発のチャットと違い、Codex はエディタやシェルから複数ホストへ連続アクセスし、認証・レート制限・中間 CDN をまたぎます。o3 のような推論モデルはサーバー側処理とクライアント側の待機が長く、途中で出口 IP が変わったり、DNS だけ別経路になったりすると、画面上は「タイムアウト」や「再試行」として現れやすいです。Clash はルールベースなので、ホスト名の種類ごとに意図したポリシーグループへ寄せるほど、体感は安定しやすくなります。

• HTML／アセット：短い GET が多く、キャッシュや CDN の振る舞いが支配的。
• API（REST／互換エンドポイント）：TLS セッションと認証ヘッダが絡み、経路の一貫性が効く。
• ストリーミング応答：ジッターや中間プロキシのバッファに敏感。
• CLI／IDE プラグイン：システムプロキシを読まないことがあり、ブラウザだけ「直結」に見える錯覚を生む。

トラフィックの四層：chatgpt.com・API・CDN・長接続

設定を書く前に、ログでどの層が詰まっているかを分けます。四層に分けると、あとからルールを足し減りしやすいです。

実際のホスト名はプロダクト更新で増減します。リモートの巨大リストを無検証で足すより、Connections ログで自分のクライアントが触っている名前を基準にするほうが、2026 年以降も保守しやすいです。

症状で見分ける：Web だけ・API だけ・両方

切り分けの順序を固定しておくと迷いません。

見え方	疑う順
ブラウザは快適、Codex CLI だけタイムアウト	システムプロキシ非追従、環境変数 HTTPS_PROXY、TUN の要否
API は通るが chatgpt.com の UI が白い	CDN ホストのルール欠落、広告ブロック系リストの過剰一致
o3 の長い応答ほど切れる	長接続向きでないノード、グループのフラップ、アイドルタイムアウト
ログイン直後だけ不安定	認証ドメインと本番 API で出口が分裂、DNS の食い違い

DNS：fake-ip と「名前は合っているのに国が違う」問題

ブラウザだけ DoH、Clash 内だけ別リゾルバ、ターミナルは OS 既定——という三重分裂は典型です。fake-ip を使う場合は、アプリごとに見え方が変わるので、DNS／fake-ip の整理を先に合わせてください。

• 解決経路を揃える：デバッグ中はブラウザ単体 DoH を一時オフにしてベースラインを取る。
• LAN とキャプティブは DIRECT：誤ってプロキシに乗ると「全体がおかしい」に見える。
• CLI の解決：Codex がコンテナや WSL 内なら、そのスタックの DNS も別世界になり得ます。

分流ルール：粗い GEOIP の前に OpenAI 用の束を置く

Rule モードでは、細かい行ほど上が基本です。openai.com や chatgpt.com、実測で出た API ホストを同じ安定グループに寄せ、ログイン中は出口を跳ばせないことが重要です。

コミュニティの広告ブロック用途リストは、SaaS のテレメトリや A/B 用ホストまで止めがちです。「ChatGPT が重い」ではなく「特定ホストが黙って失敗」になるので、新しいリストを入れた直後から壊れた場合は真っ先に疑ってください。

Codex CLI／IDE：プロセスとプロキシ環境変数

エディタ統合の Codex は、親プロセスがシステムプロキシを継承しないことがあります。ブラウザで chatgpt.com が動いても、ターミナルだけ別出口になるパターンです。

1. まず Rule で OpenAI 系ドメインを意図したグループへ（ブラウザで確認）。
2. CLI だけ遅いなら HTTPS_PROXY などを一時的に明示するか、TUN で取りこぼしを減らす。
3. 企業 VPN や ZTNA と TUN を無秩序に重ねない（二重捕捉で逆に不安定になることがあります）。

Windows の土台は Clash for Windows セットアップ、macOS は Verge Rev で権限と購読を先に固めると、あとの分流調整が楽です。

o3 推論と長接続：ノードは「速い」より「途切れない」

推論時間が伸びるほど、中間の TCP セッションはアイドルに近い状態が続きます。ping が良くても、バッファや輻輳でストリームだけ落ちるノードがあります。

• ポリシーグループのフラップを避ける：数秒ごとに出口が変わると、クライアント側が静かに再接続を繰り返す。
• 多段チェーンは TLS ラウンドトリップを増やし、長文ほど不利になりやすい。
• 混雑時間帯は帯域争奪：大容量ダウンロードと同じ自動選択グループを使わない。

ここは「ChatGPT がカクつく」というより開発ワークフロー全体の信頼性の話です。長いジョブのあいだ手動でノードを固定するのも、再現調査では有効な手段です。

ノード選択：API 用プールを別ける意味

動画向けに選んだ「帯域は広いが遅延が不安定」な出口と、API 向けに欲しい「一貫した低損失」は必ずしも一致しません。分流ルールで OpenAI 系をひとつのポリシーグループに寄せたうえで、そのグループの中身を会話・API 向けにチューニングすると管理がしやすいです。

• 健康チェックの間隔と URL は、実際の API 疎通と相関するものを選ぶ。
• データセンター出口は普通：急に認証が厳しくなったら、別のクリーンなノードを試す。
• ログで「応答中に outbound が変わった」タイムスタンプがないか確認する。

ルール順の例（あくまで雛形）

グループ名 AI-STABLE は実際の名前に置き換え、自機のログで足りないホストを足してください。

# Illustrative only — verify hostnames from your client logs
rules:
  - DOMAIN-SUFFIX,chatgpt.com,AI-STABLE
  - DOMAIN-SUFFIX,openai.com,AI-STABLE
  - DOMAIN-SUFFIX,oaistatic.com,AI-STABLE
  - DOMAIN,api.openai.com,AI-STABLE
  # Add CDN hostnames seen stalled in Connections
  - MATCH,DIRECT

MATCH の行は環境に合わせて調整します。リモート rule-providers をマージする場合、ローカルの OpenAI 行が最終 MATCH に負けていないかを必ず確認してください。

IPv6・MTU・分割トンネル

IPv4 と IPv6 で別出口になっていると、一部のホストだけ奇妙に遅くなることがあります。MTU 問題は短文では成功し長い推論ストリームで切れる、というパターンもあります。ノード総入れ替えの前に、プロトコルとパケットサイズの相関を一度見てください。

FAQ

ブラウザは OK、Codex だけ失敗する

プロキシ継承と DNS を疑う。TUN で捕捉できるか、環境変数で明示できるかを試す。

API は通るのに UI だけおかしい

CDN 系ホストのルール欠落やブロックリストを疑う。ログのホスト差分を取る。

o3 にした途端タイムアウトが増えた

処理時間と長接続の相性。同一セッション中のノード固定と、フラップしていないかを確認。

Cursor の記事と何が違う？

Cursor 稿はエディタ周辺の汎用開発トラフィックが主役。本稿は OpenAI Codex と chatgpt.com／API の一体運用に寄せています。

チェックリスト（2026）

まずはメンテされたクライアントから

ルールとログが読みやすいクライアントほど、OpenAI まわりの調整は速くなります。

Clash を無料ダウンロードし、Codex・o3 向けの分流と DNS の土台にする