ChatGPT の OpenAI Codex（クラウド Coding Agent）が総タイムアウトするとき｜Clash で分流・DNS を段階実測する（2026）
ブラウザ上のChatGPTでOpenAI Codex（クラウド Coding Agent）を動かすと、通常のテキスト会話より長いHTTPSセッションや追加ドメインが絡みやすく、検索では「総タイムアウト」「エージェントだけ繋がらない」といった部分的成功に着地しがちです。本稿は一般的なChatGPT 閲覧向けのまとめ（ChatGPT／OpenAI のドメイン分流記事）と切り口を分離し、Codex／コーディングエージェント本体を軸にClash（多くの場合 Mihomo コア）の分流ルールとDNSを、接続ログ優先で合わせる手順を日本語で整理します。記載のホストはサービス側アップデートで増減し得るため、YAML は叩き台とし、必ず自分のログを正としてください。
検索意図の整理：なぜ Codex だけ「途中で沈む」のか
OpenAI CodexのようなCoding Agentは、チャット欄の応答表示に加えてリポジトリ操作やターミナル／ツール呼び出し、ストリーミングされた実行ログが絡みます。結果としてブラウザから見える通信は、短い REST だけの会話よりホスト幅が広がり、同時セッション数も増えがちです。ここにClash のルール順（巨大な RULE-SET や GEOIP が先にマッチして DIRECT や低速グループへ落とす）や、DNS の fake-ip と実経路のねじれが重なると、「トップや履歴は開けるのに、エージェント起動直後や実行中だけタイムアウト」という見え方になります。
CLI や SDK 前提の切り分けはClaude Code CLI と DNS の実測稿やCursor Agent SDK×CI の稿と手順が近い一方、本稿の舞台はChatGPT Webです。用語の共通解説はチュートリアルとカスタムルールも併読すると早いです。
ステップ 1：症状を「表示」と「エージェント処理」に分ける
まずユーザーから見える壊れ方を分類します。(A) チャットバブルは進むが、Codex の実行パネルやツール結果だけ止まる、(B) ログインやサイドバーは正常なのに、コードブロックのプレビューや静的アセットだけ欠ける、(C) ページ全体が証明書エラーや真っ白になる、の三つに大別できます。(A) は API やワーカー系ホストが意図しない policy に載っている、(B) は CDN・オブジェクト配信の FQDN が別出口、(C) はプロキシ二重・システム DNS・キャプティブ系のより手前の問題、が多いです。ブラウザの開発者ツールで失敗リクエストのホスト名とステータスをメモし、Clash の connections と突き合わせると、当てずっぽうの DOMAIN 列挙が減ります。
ステップ 2：ログファーストで FQDN と policy をそろえる
分流を書く前に、Mihomo 系 GUI のコネクション一覧や、external-controller 経由の観測、あるいは Verge 系のログで実際に張られた宛先を拾います。タイムアウトの直前に伸びているsniやhostを DOMAIN ルールの材料にしてください。chatgpt.comやopenai.comなどのサフィックス一括は運用は速い反面、不要な範囲まで同じ出口に乗るため、社内ポリシーや課金用ホストを分けたい場合はログで狭める運用が向きます。
並行して、ブラウザ拡張・別 VPN クライアント・社内 PAC が同じマシンで別ポートを指していないか確認します。HTTP(S)_PROXYと Clash のシステムプロキシ注入が二重だと、「Clash のルールは正しいのにブラウザだけ別穴」が起きやすいです。NO_PROXY に広域ドメインを詰め込むと意図せず直叩きに逸れるので、広げたら必ずログで副作用を見ます。
ステップ 3：狭い DOMAIN を上へ（コピペ用の叩き台）
購読テンプレに大きな RULE-SET がある場合、上から先にマッチした行が勝つため、エージェント関連ホストをリスト上位へ寄せます。以下は出発点の例です。OpenAI_Codexは安定した proxy-groups 名に置き換え、ログに出ていない行は削る／足す前提で使ってください。
rules:
# Replace OpenAI_Codex with your stable outbound group — extend from YOUR logs only
- DOMAIN-SUFFIX,chatgpt.com,OpenAI_Codex
- DOMAIN-SUFFIX,openai.com,OpenAI_Codex
- DOMAIN-SUFFIX,oaistatic.com,OpenAI_Codex
- DOMAIN-SUFFIX,oaiusercontent.com,OpenAI_Codex
- DOMAIN,platform.openai.com,OpenAI_Codex
- DOMAIN,api.openai.com,OpenAI_Codex
# Add hosts that appear only when Codex runs — verify in connections panelコード実行や外部連携を強く使うビルドでは、上記以外の一時ホストが現れることがあります。PROCESS-NAME でブラウザだけ寄せる手もありますが、表記は OS ごとに異なるため、テンプレのコピペより実ログとの一致を優先してください。GitHub 等の別タブを同時に開いていると、別ホストが同じ遅い出口に乗り、エージェントだけが遅いように錯覚することもあるため、切り分け時はタブを減らすのも有効です。
ステップ 4：DNS（fake-ip／nameserver-policy）を単一変数で振る
DNSは「短い GET は成功するのに、長いストリームだけ失敗」タイプを生みやすい層です。enhanced-mode の fake-ip と OS の /etc/resolv.conf や macOS のネーム解決順が噛み合わないと、表示と実コネクションの宛先が食い違います。検証は一度に一つの項目だけ変えるのが安全で、(1) fake-ip と redir-host の切替、(2) nameserver-policy で openai.com 系だけ別 resolver、(3) IPv6 優先のON/OFF、の順に踏むと原因が追いやすくなります。
Public DNS と DoH を同時に二系統足すと、どちらが効いたかログから読みにくくなるため、まずは nameserver を単純化してから policy を足す構成を推奨します。詳細なノブの意味はChatGPT 向け分流稿の DNS 節とも整合を取りつつ、本稿ではCodex 実行中のログ差分を正にすることを最優先にしてください。
ステップ 5：一般利用向けホスト表だけに依存しない
ChatGPTの通常チャット向けに整理済みのドメイン一覧は出発点として有用ですが、Coding Agentは製品アップデートや A/B テストで追加サブドメインが現れやすい立ち位置にあります。検索流入の固定表より、週次でルール断片をログに合わせてバージョン管理する運用が長続きします。また、同一アカウントで別リージョンや別ブラウザプロファイルを切り替えると、CDN の向き先が変わりルール最適点もずれるため、検証環境を揃えることも再現性向上に効きます。
よくある質問
通常のチャットは速いのに Codex だけ遅いように見えるのはなぜ？
エージェント経路ではコード実行や外部ツール、長めのストリームが絡み、別ホストへ伸びるぶんpolicy 分裂やDNS ねじれが表面化しやすいです。タイムアウト行の FQDN をメモし、proxy-groups 名までログで揃えてください。
chatgpt.com だけ通せば足りる？
単一行だけで済む環境もありますが、静的配信・認証まわり・課金 UI・API 系が別 FQDNとして現れるビルドは普通です。接続ログを正にしてからサフィックスを足し引きしてください。
ブラウザのプロキシと Clash を併用してよい？
二重適用や PAC 残滓でポートが分岐すると、ルールが正しくてもブラウザが別経路へ抜けることがあります。まず一本化し、NO_PROXY の過剰指定を疑ってください。
まとめ
ChatGPT上のOpenAI Codex／Coding Agentは、通常対話より通信の幅と長さが増えやすく、Clash 分流とDNSの設計ミスが「エージェントだけタイムアウト」として顕在化しがちです。症状の分類→ログで FQDN と policy を取得→狭い DOMAIN をリスト上位へ→DNS を単一変数で検証→一般 ChatGPT 向け表との差分を継続追補の順に進めると、切り分けの再現性が上がります。
従来型の単機能プロキシでは、用途ごとに細かなホスト例外を YAML で積み上げつつ、長いストリームと短い REST を同一ログ画面で追いかける運用までを一気通貫で持ち上げにくいものもあります。一方 Clash／Mihomo 系はルール順と接続ビューを軸に微調整できるため、ホストが増え続けるクラウドコーディングエージェントとも相性がよいです。入手経路を一本化したい場合はダウンロードページから確認し、VPN との設計差はClash と VPN の比較も参考にしてください。