Codexが遅いのにChatGPTのウェブ版は正常？プロキシ、再接続、TLSエラーの調べ方
ChatGPTのウェブ版では普通に会話でき、Googleも速いのに、Codexの応答が遅い、またはReconnectingが繰り返し表示されることがあります。その場合は、まずCodexの接続エラーを確認し、経路の変更、プロキシの調整、モデルの応答待ちのどれを行うか判断します。
ウェブ版が動くことから分かるのは、現在のブラウザーの経路が使えることだけです。Codexのリクエストが同じプロキシを通ることや、Codexの持続接続が正常であることは証明できません。 ログにtls handshake eof、接続リセット、連続した再接続がすでに記録されているなら、待ち時間のすべてをモデル推論の時間とはみなせません。
この記事は、接続異常を伴うCodexの遅延を扱います。確認する順序は、再接続中か確認 → 実際のプロキシ経路を特定 → TLSと通常のHTTPSを確認 → その後にWebSocketまたはストリーミング接続を検証、です。
以下の判断は、Mac上で行った1回の実験に基づいています。TailscaleではCodexの実リクエスト3回が完了し、保存済みAnyTLSノードを独立環境で再構築するとTLS EOFが発生し、Google HTTPSにも接続できませんでした。以前の「ウェブ版は速いのにCodexだけ遅い」という状態を完全に再現したわけではないため、過去の障害の唯一の根本原因とはいえません。 異なる証拠が得られたときに、どの層から確認すべきかを考える材料になります。
Codexは推論中？それとも再接続を繰り返している？
画面にどれだけ長く表示されているかだけで判断せず、現在のリクエストに対応するエラーを確認してください。
| 表示された現象やエラー | まず確認すること |
|---|---|
Reconnecting...とtls handshake eofが同時に出る |
プロキシ経路、TLS接続の確立、宛先への転送 |
stream disconnected before completion |
後続にある具体的なエラーを確認。この文だけでは原因を特定できない |
| WebSocket接続後に切断、終了コード1006 | 該当接続の切断時刻・継続時間・中間経路 |
| モデルの更新が必要と明記されたHTTP 400 | クライアントのバージョン。最初からネットワーク障害と決めつけない |
| 接続エラーはなく、結果が長時間返らない | 原因は保留する。遅いことだけではネットワーク切断を示さない |
今回の実験では、同じモデル、同じ推論レベルを使い、Codexに固定文字列NETWORK_PROBE_OKを返すよう求めました。
| 経路 | 実リクエストの結果 |
|---|---|
| Tailscale、独立した短いセッション3回 | すべて完了。CLIプロセス全体の所要時間は11.551、13.945、14.877秒 |
| ローカルHTTP CONNECT、Tailscale経由で外向き接続 | 完了。プロセス全体で11.634秒 |
| ローカルHTTP CONNECT、保存済みAnyTLSノードを使用 | 再接続を繰り返し、45秒の観察時間内に完了せず |
失敗したリクエストでは、次のログが出ました。
Reconnecting... 2/5 (... tls handshake eof)
Reconnecting... 3/5 (... tls handshake eof)
Reconnecting... 4/5 (... tls handshake eof)
Reconnecting... 5/5 (... tls handshake eof)
Reconnecting... waiting for network
この状況で待ち続けても、モデルが回答を生成し続けているとは限りません。接続に失敗して再試行しているため、まず接続を調べてください。
表の時間にはプロセス起動、認証、推論、転送が含まれます。初回トークンまでの時間でも、純粋なネットワーク時間でもありません。 45秒はテストプログラムの終了上限であり、プロキシの平均応答時間ではありません。
ChatGPTのウェブ版が正常でも、Codexが接続できないのはなぜ？
ブラウザー、デスクトップアプリ、CLIの実際の接続経路をそれぞれ確認してください。ブラウザーのプロキシ拡張機能、システムプロキシ、TUN、プロセスごとの振り分け、ターミナルのプロキシ環境変数は、異なる範囲に適用されることがあります。あるプログラムが動くからといって、別のプログラムも同じ経路を使うとは限りません。
Clash Vergeを使っている場合は、まず次の3点を確認します。
- Codexがリクエストを送ったとき、Clashの接続ログに対応する通信が出ていますか？ ターミナルに環境変数を設定しただけでは、リクエストがプロキシを通ったことの確認にはなりません。
- 想定したルールと出口に一致していますか？ ノード選択画面だけでなく、現在のリクエストを確認してください。
- 同じ利用環境同士を比べていますか？ CLIのテストに成功しても、デスクトップアプリのすべてのバックグラウンド接続が成功したとはいえません。ウェブ版で会話できても、デスクトップ側の接続テストの代わりにはなりません。
今回のCLI実プロキシテストでは、独立したプロキシの接続ログにchatgpt.comが記録され、リクエストがその入口に到達したことを確認できました。別途行ったHTTP CONNECTの対照テストでは実リクエストが完了し、この実験中にこのクライアントがその入口を通して動作できることが分かりました。
一方、デスクトップログでエラーが出たdurable/app-serverチャネルは別に分析する必要があります。OpenAIのドキュメントでも、SSE、WebSocketのリクエスト、イベントは別々の観測カテゴリとして列挙されています。異なるチャネルの成功と失敗をまとめて「Codexのネットワークは正常」と結論づけることはできません。Codex接続テレメトリーのイベント分類
ブラウザーは正常でも、該当するCodex通信が想定したプロキシに現れないなら、まずそのリクエストの経路を直してください。ノードを何度も変更しても、問題の接続経路が変わっていない可能性があります。
Codexがtls handshake eofを報告したら、まず何を確認する？
tls handshake eofはTLSハンドシェイク中に接続が早期終了したことを示します。「WebSocketは正常に確立したが、後でアイドルタイムアウトした」という意味ではありません。まず同じプロキシ経由で通常のHTTPSが使えるかを確認し、その後でアプリケーションの持続接続を調べます。
同じプロキシ経由で通常のHTTPSが使えるか確認する
簡単なHTTPSアドレスを、現在のシステムネットワーク経由と明示的に指定したローカルプロキシ経由の両方で試します。実際に動作中のクライアントのポートを使ってください。 ブラウザーで同じURLを試すだけでは、Codexが使う経路を確認できません。
以下はポートを置き換えて使うコマンド例です。7897は例にすぎず、現在のClashのHTTPポートまたはmixedポートに変更してください。今回の実験ではスクリプトが割り当てた一時ポートを使いました。
# 不显式使用 HTTP 代理，沿当前系统路由访问。
# 如果开着 TUN 或 Tailscale，这不等于绕过它们。
curl --noproxy '*' --connect-timeout 10 --max-time 25 \
-o /dev/null -sS -w 'HTTP=%{http_code} total=%{time_total}s\n' \
https://www.google.com/generate_204
# 明确经过本地 HTTP/mixed 代理入口。
curl --proxy http://127.0.0.1:7897 --noproxy '' \
--connect-timeout 10 --max-time 25 \
-o /dev/null -sS -w 'HTTP=%{http_code} total=%{time_total}s\n' \
https://www.google.com/generate_204
ローカルポートに接続できない場合は、Clashが動作していることとポートが正しいことを先に確認してください。まだリモートノードはテストできていません。TLS段階でのみ失敗するなら、ノードと宛先への転送を調べます。両方のコマンドが成功しても分かるのは短いHTTPS通信が可能なことだけなので、続けてCodexをテストしてください。
今回の実験では、宛先ごとに各経路を3回テストしました。
| テスト先 | Tailscale経路 | 保存ノード経由の独立プロキシ経路 |
|---|---|---|
Google generate_204 |
3回ともHTTP 204 | 3回ともcurl 35、HTTP応答なし |
| ChatGPTホームページ | 3回ともHTTP 403 | 3回ともcurl 35、HTTP応答なし |
| Codex responsesアドレスへの未認証GET | 3回ともHTTP 405 | 3回ともcurl 35、HTTP応答なし |
curl 35はSSL/TLS接続エラーで、この実験ではSSL_ERROR_SYSCALLでした。curlエラーコードの説明
403と405は、ChatGPTやCodexの機能が正常だという意味ではありません。 プローブがHTTP応答を受け取ったことだけを示します。未認証GETは、正規のモデルリクエストの代わりにはなりません。実際のアプリケーション確認は、前の節で固定マーカーを返したリクエストです。
ただし、プロキシ経路ではGoogle HTTPSにも接続できませんでした。この結果から確認の順序を変え、CodexのWebSocketを最初から原因とみなすのではなく、まず一般的なHTTPS転送を復旧させるべきです。
ノードに接続できても、OpenAIへの接続を代行できるとは限らない
プロキシ入口に到達できる場合でも、認証、プロトコルの互換性、宛先への転送を確認する必要があります。
今回の実験ではプロキシクライアントを介さず、ネイティブsocketを物理ネットワークインターフェイスにバインドして、ノードの名前解決で得た4つのIPv4入口に接続しました。4つすべてでTCP接続が成功し、所要時間は約4～7 msでした。証明書を検証するTLSハンドシェイクもすべて成功し、合計時間は約248～553 msでした。
これは入口に到達できることだけを示します。プロキシ経路にはさらに次の段階があります。
本机 → 代理入口 TCP/TLS → 认证、协议处理与转发 → 目标服务
入口へのTLS成功と、プロキシ経由で宛先へ接続するTLS成功は別の検証です。 前者だけではAnyTLS認証の成功も、ノードからGoogleやOpenAIに到達できることも証明できません。
今回、ノードのホスト名を名前解決したIPの1つに固定してもGoogle HTTPSは失敗しました。同じ実装のローカルHTTP CONNECT入口をDIRECTに切り替え、Tailscale経由で外向きに接続するとGoogle 204を返しました。この対照結果からノードのプロトコルとクライアントの互換性、認証と転送の状態、サーバー側の外向き接続ログに注目できますが、唯一の根本原因を特定するには不十分です。
同じ結果になった場合は、「pingが低い」「サーバーポートに接続できる」で調査を終えるのではなく、これらの段階のエラーログを取得してください。
Codexがずっと再接続中なら、WebSocketを無効にすべき？
まず、Codexアプリが使うWebSocketとプロキシノードが使う伝送プロトコルを区別してください。
今回保存されていた選択ノードはAnyTLSで、設定内のVLESS/WSノードではありません。そのため「このノードはWSでラップされているからCodexが遅い」という推測は、保存済みノードの種類と一致しません。ただし、Codex自身のWebSocketがそのノード経由で失敗する可能性はあります。
WebSocketを調べるかどうかは、接続がどの段階まで進んだかで判断します。
| 分かっている証拠 | 調べること |
|---|---|
| 通常のHTTPSでもTLSハンドシェイクを完了できない | まずプロキシ接続の確立と転送を直す |
| 通常のHTTPSは正常だが、WSハンドシェイクに失敗する | 該当接続のハンドシェイク、プロキシ経路、アクセス方針を確認 |
| WS確立後、使用中またはアイドル後に切れる | 切断のタイミングを記録し、接続維持と中間経路を調べる |
今回、Postmanの公開WSS Echoサービスで持続接続を検証しました。Tailscale経由でまず5件のメッセージを交換し、テストクライアントの能動的な定期pingを無効にして90秒アイドル状態にした後、さらに5件を交換しました。10件すべてのエコーが一致しました。能動pingを無効にしても、TCP keepaliveやサーバーが送る可能性のあるフレームがなくなるわけではありません。Postman Echoサービスの説明
別のHTTP CONNECT/DIRECT対照テストでもWSSハンドシェイクとエコーが成功しました。これはこのローカルプロキシ入口がWSSを通せることを示しますが、すべてのプロキシノードに一般化はできません。公開EchoサービスもCodex固有の宛先の代わりにはなりません。
過去のデスクトップログでは、durableチャネルに関係するwebsocket_errorが10件、reconnect_startedが15件見つかりました。これらはイベント記録であり、25件の独立した障害ではありません。1つのエラーが複数の状態ログに伝播することもあります。
終了コード1006は異常終了を示しますが、それだけでは誰が接続を中断したか判断できません。WebSocket異常終了コードに関するRFCの定義
したがって、Reconnectingが表示されたからといって、自動的に「WSを無効にする」設定を適用しないでください。今回の失敗はTLS段階ですでに起きており、WebSocketのアイドルタイムアウトを変更すれば解決するという証拠はありません。
Tailscaleに切り替えればCodexの遅延は解消する？
このMacで今回行った短いリクエストのテストでは、Tailscaleは実リクエストが完了した経路です。常に速くなるという保証ではありません。 実際のCodexリクエスト3回と90秒のアイドルエコーは、単独の速度テストより、今回どの経路を使い続けるかを判断する材料になります。
TailscaleはWireGuardを使用します。直接接続できるときはUDPで通信し、できないときは中継を使う場合があります。CodexのWebSocketはそのトンネル内で動作できます。Tailscaleへの切り替えはWebSocketを無効にすることではありません。Tailscaleの接続方式
今回のTailscale検出プローブ20回のうち、成功は17回、タイムアウトは3回でした。成功したサンプルのRTT中央値は188 msでした。これはアプリケーション通信の長期的なパケット損失率ではありませんが、「動く」ことが「遅延も異常もない」ことを意味しない点は示しています。
同様に、digだけでは163バックボーンの混雑を証明できません。今回ChatGPTドメインのAレコード問い合わせは3回すべて成功し、185～233 msかかりました。これはDNS問い合わせ時間の測定であり、TCP、TLS、実際のアプリケーションリクエストの代わりにはなりません。今回、163バックボーンの混雑を確認できるだけの経路証拠は得られませんでした。
出口経路を変えてCodexが復旧した場合、確認できるのは「経路の変更によって結果が変わった」ことです。特定の通信事業者、共有ノードの負荷、プロキシプロトコルに原因を帰するには、その判断を裏付ける証拠がさらに必要です。
ウェブページが開くだけでなく、Codexが復旧したと確認するには？
ブラウザーでホームページを更新するだけでなく、問題が発生したクライアント内でテストします。
- ツールを呼び出さない短いリクエストを送ります。 同じモデルと推論レベルを保ち、完全な結果が返ることを確認します。これでツール実行時間が接続テストに混ざるのを避けられます。
- 該当リクエストのプロキシルール、出口、エラーログを確認します。 再接続が続いていないか確認してください。プロキシを設定しただけでは、リクエストが通過した証拠にはなりません。
- 元々失敗していたワークフローを検証します。 短いリクエストの成功は、長いタスク、アイドル後の復帰、デスクトップのバックグラウンドチャネルの確認の代わりにはなりません。今回完了したのは短いモデルリクエストだけで、長いワークフローの復旧は証明していません。
デスクトップアプリでは「ファイルを読んだりツールを呼び出したりせず、NETWORK_PROBE_OKだけを返して」と送信します。CLIユーザーは次の短いリクエスト例を使えます。これは実際にモデルを呼び出すもので、オフライン検査ではありません。
codex exec --ephemeral --skip-git-repo-check --sandbox read-only \
'不要读取文件或调用工具，只回复 NETWORK_PROBE_OK'
問題が発生した実際のバージョンと設定で確認し、エラーと完了状況を記録してください。別のCLIが回答できたからといって、デスクトップアプリも復旧したと判断しないでください。
クライアントがモデルの更新に必要なバージョンを明示している場合は、まずバージョン互換性を解決します。今回の最初のテストでもこの状況があり、独立版CLI 0.151.0はHTTP 400を返しました。その後、アプリに同梱された0.164.0-alpha.11.1で再テストしました。最初のHTTP 400はネットワーク障害には数えていません。
今回の結果に基づく実用的な選択は、実リクエストが完了したTailscaleを使い続けることです。このプロキシを調べる場合は、Codex固有の接続を検証する前に通常のHTTPSを復旧させます。「ウェブ版は正常でCodexだけ遅い」という以前の障害を説明するには、その状態を再現したときに接続と出口のログを同時に記録する必要があります。
テスト範囲： この記事のデータは2026年10月27日未明にMacで行ったテストに基づいています。プロキシ実験では保存済みAnyTLSノードのパラメーターを読み取り、別のmihomoプロセスで再構築しました。元のClash GUI/TUNを起動せず、システムプロキシやTailscaleの出口も切り替えていません。物理インターフェイスへのバインドを設定しましたが、nettopではAnyTLSプロセスの上流インターフェイスを確認できませんでした。そのため、2つの完全な物理経路を独立して検証したとはいえません。CLI、デスクトップのdurableチャネル、公開Echoの結果は個別に記録しました。生データ、スクリプト、詳細条件は付属の実験資料に保存されています。