この記事で分かること

2026 年時点では、エディタ内のチャットとは別軸として、ターミナルでコードリポジトリを直接走査する OpenAI Codex CLI や、その背後で GPT-5.3-Codex のようなモデル名が露出するワークフローが検索クエリにも現れやすくなっています。現場では「OpenAI Codex」「GPT-5.3-Codex」「タイムアウト」「ChatGPT API」「HTTPS_PROXY」といった語が並び、症状としてはブラウザで ChatGPT は開けるが、CLI だけが数十秒単位で止まるというパターンが目立ちます。

本稿ではデスクトップ向け Mihomo／Clash Meta フロントエンドの一つである Clash Verge Rev を前提に、(1) ルール分流（Rule）で API 分流を明示し、ログに現れたホストを意図したノードへ送る、(2) ブラウザとターミナルの間でズレがあるときにシステムプロキシと TUNをどう足すか、(3) HTTPS_PROXY／HTTP_PROXY／ALL_PROXY と NO_PROXY をどのファイルに書くか—を一続きで整理します。環境によりエンドポイントは変わりうるため、Verge のログと curl で実際の接続先を確かめる前提です。Anthropic の CLI 向けの整理は別稿のClaude Code × Clash Verge Rev の記事、Electron 系開発ツールにはCursor 向けの分流ガイドと役割分担が近いので併読してください。

タイムアウト・握手失敗として現れる検索クエリと症状の対応

OpenAI Codex と GPT 系モデルをターミナルから直呼びするケースでは、画面やログには次のような言い回しが出やすく、ユーザーが入力する検索語と対応させて整理できます。

  • 総長時間タイムアウト：プロキシに載るべき OpenAI API が DIRECT のまま国境付近で詰まる、または SNI と証明書の検査が別製品によって割り込まれる例です。開発者環境だけで再現するときは、家庭用ルーターの IPv6 と IPv4 が分裂していないかも疑います。
  • TLS ハンドシェイクまで進まない：途中のキャリア NAT またはキャンパス網でのフィルタ、あるいはノード側のポート閉塞により、モデル側以前に接続が止まっている場合があります。OpenAI Codex と書かれたエラーログでも根本原因はモデルより手前にあることがあります。
  • 成功とタイムアウトが交代する（フラッピング）：環境変数とシステムプロキシ設定が競合している、複数ウィンドウの Shell が別の .zshrc を読んでいる、Keep-Alive が古い経路に残っている、といった状態の二重化が典型です。

いずれも「インターネットが完全に落ちた」というより、ターミナル上の HTTPS クライアントが期待したプロキシチェーンに乗っていない比率が高いです。ここで Clash Verge Rev のログを一行ずつ追えることは、ブラックボックスな VPN 単体製品と比べたときの大きな実務メリットになります。

API 分流の中心：Rule と補助としての TUN

Rule（ルール分流）は、国内の決済・社内 Git・大学のイントラを DIRECT に残しつつ、api.openai.com などを PROXY へ送るための第一選択です。YAML の順序とログの突き合わせで「どのホストがどのポリシーに落ちたか」を説明できるため、チーム内で設定差分をテキスト共有しやすいのも利点です。

TUN はカーネル近傍でトラフィックをキャプチャし、プロセスがプロキシを無視していても一度 Mihomo に引き込める強力な手段です。一方で社内ゼロトラストクライアントや別 VPN の仮想 NIC とスタック競合しやすく、切り分けコストも上がります。実務的には、(1) Rule とシステムプロキシで十分か試す、(2) 特定バイナリだけ直結するなら限定的に TUN、(3) 常時フル TUN は最後の手段、の順が安全です。

Clash Verge Rev では「システムプロキシをセット」「TUN を開始」が別トグルになっているため、ブラウザは整っているがターミナルだけ裸というズレが起きやすい点に注意してください。Shell を開き直したあと env | grep -i proxy を見ると早いです。

HTTPS_PROXY を中心にしたターミナル向け環境変数

ターミナル代理では、GUI アプリよりも環境変数の比重が高くなります。OpenAI Codex や API スクリプトが内部で読む名前は実装依存ですが、実務では次のセットで取りこぼしが減ります。

  • HTTPS_PROXY：HTTPS への接続が多く、優先されます。
  • HTTP_PROXY：リダイレクトや証明書取得の先行 GET で参照されます。
  • ALL_PROXY：単一変数のみを読むツールへの保険として併記できます（無視されることもあります）。
  • NO_PROXY：localhost、127.0.0.1、社内ドメインを除外し、アーティファクトサーバや社内 SSO のループを防ぎます。

書き場所の典型例は以下のとおりです。

  • 常時：~/.zshrc または ~/.bashrc。ログインシェルだけなら ~/.zprofile。
  • リポジトリ単位：direnv の .envrc に export HTTPS_PROXY=http://127.0.0.1:<mixed-port> と書く。
  • 一発検証：HTTPS_PROXY=http://127.0.0.1:7890 codex … のように前置きのみで汚さない（ポートは各自の構成に読み替え）。

値は通常 http://127.0.0.1:<mixed-port> でよく、CONNECT で TLS をトンネルします。GPT-5.3-Codex と銘打った処理でも、このプロキシ形式はモデルとは独立して共通です。

ルールへ載せるべきホストの「型」：ログでの実測を優先

エンドポイントはサービス側の更新で変わりうるため固定一覧は避け、検索ログで繰り返し見かける型として押さえるのが無難です。

  • REST と互換レイヤー：api.openai.com を中心とした名前が最も頻出しやすく、証明書名とホストが一致することが重要です。
  • 認証・アカウント連携：openai.com のサブドメインや、OAuth 関連のホストが混ざることがあります。ブラウザは既にログイン済みでも、CLI は別フローを踏むことがあります。
  • コンソールとドキュメント：platform.openai.com 付近や CDN がログに並ぶことがあり、誤って国内向けグループへ落としていると体感が安定しません。

OpenAI Codex 本体の名前がユーザー向けログに現れても、実際は上記の共通ホストに集約されていることがほとんどです。GPT-5.3-Codex のプレビューで追加経路がある場合でも、ログのホスト名列挙より早い順にルールを足す運用が堅実です。

TIP：一度だけGlobal に近いプリセットで Codex を動かして症状が消えるか確認してください。消えるならDIRECT に落ちるルール順が本命で、MATCH より上へ個別 DOMAIN を差し込めば改善しやすいです。

ルール記述例（ポリシー名と順序は各プロファイルに合わせる）

以下は Mihomo／Clash Meta 互換の説明用スニペットです。PROXY はお使いのポリシーグループ名に読み替え、既存の MATCH より上に置いてください。

# Example rules snippet — replace PROXY with your policy group name
rules:
  - DOMAIN-SUFFIX,openai.com,PROXY
  # Add hosts you see in Verge Rev logs above MATCH

DOMAIN-SUFFIX,openai.com で多くのサブドメインをまとめられますが、ログに別ゾーンのホストが出たらその行を追記してください。広すぎる DOMAIN-KEYWORD は誤爆しやすいので、実測名を DOMAIN で足す運用が安全です。

ステップ：OpenAI Codex／GPT 系ワークフローで安定させるまで

  1. Clash Verge Rev がアクティブなプロファイルで起動済みであり、mihomo が期待どおり待ち受けていることを確認します（プロファイル差し替え忘れが多いです）。
  2. ブラウザで同一ノードを使って海外サイトへ到達できるかを確認し、問題がターミナル特有かを切り分けます。
  3. ログに出たホストへ API 分流ルールを足し、fake-ip とルール種別の組み合わせでマッチがズレないか確認します。
  4. システムプロキシをオンにしても改善しない場合、Shell に HTTPS_PROXY と HTTP_PROXY を並べて OpenAI Codex プロセスを新しいウィンドウから起動します。
  5. curl -vI https://api.openai.com などで応答頭が返るか、Clash 側で PROXY チェーンに乗ったかを見ます。
  6. 個別バイナリが依然として直結するなら TUN を試す前に、ウイルス対策の HTTPS インスペクションと社内 VPN の経路競合を疑います。

検証のコツ：環境変数が効いているか確認する

「設定したつもりの HTTPS_PROXY」が統合ターミナルに届かないときは、非ログイン Shell になっている、アプリ側が独自一覧で上書きしている、などがあります。

  • 同一ホストを curl と Codex が別結果にする場合：curl は変数が効いており Codex が無視しているなら、そのバージョン固有のフラグや設定ファイルがあるか読みます。
  • IPv6 と IPv4 の分裂：curl -4 でのみ通るときは経路または DNS が二系統化しています。
  • 社内 Split DNS：機密リポジトリは NO_PROXY に残し、外部モデルだけ PROXY へ——の二段にすると開発者環境での事故が減ります。
注意：コードやログを外部モデルへ送る操作は、契約書と会社の情報セキュリティポリシーに触れることがあります。ネットワークの安定化はできても、アップロードの可否は別判断です。
ダウンロードページへ

トラブルシューティング

症状：curl は成功するが OpenAI Codex だけタイムアウト

想定原因：バイナリが環境変数を読まず、設定ファイルまたはラッパーで直結している。

対処：公式ドキュメントでプロキシ関連のフラグ／環境名を確認し、スクリプトで明示的に export する。複数インストールのパス競合も疑う。

症状：PROXY に乗っているのに極端に遅い

想定原因：ノード輻輳、HTTP/3 フォールバック、DNS の迂回失敗。

対処：別リージョンへ切り替え、DNS をプロファイル内で固定、検査プロキシを一時無効にして差分確認する。

症状：TUN で社内サイトだけ繋がらない

想定原因：社内ネットワークがプロキシ側へ流れた、PRIVATE ネットワークの除外が不足。

対処：TUN を切り NO_PROXY と GEOIP／IP-CIDR を厚くした Rule に戻し、運用規程に沿って確認する。

よくある質問

ブラウザの ChatGPT は開けるのに、Codex CLI だけタイムアウトします。なぜですか？

ターミナル代理とブラウザ代理で参照する設定レイヤが違うためです。OpenAI Codex が内部で読む名前を合わせ、Clash で DIRECT 漏れを潰してください。

GPT-5.3-Codex と既存モデルではドメインが変わりますか？

多くは同じ OpenAI 経路へ集約されます。追加がある場合でもログでの実名追跡が最も確実です。

HTTPS_PROXY はどこに書けばいいですか？

常時利用なら Shell 設定ファイルや direnv、IDE のターミナル環境。短期検証はコマンド前置きのみに閉じて副作用を限定します。

単一製品 VPN との比較で見える Clash の利点

大手のワンタップ VPN は初期セットアップは楽でも、ドメイン単位の細かな例外や、ログでの逆引きには向きにすくないことがあります。開発者ワークステーションでは、Git だけ直結できない、アーティファクト URL だけが別経路で詰まる、といった摩擦が出やすいです。Clash 系は本文のとおりルール分流とログで説明可能な API 分流が書けるため、OpenAI Codex や GPT-5.3-Codex と社内サービスを同じマシン上で両立させるほうが現実的になります。

フロントエンドは嗜好で選べますが、Verge Rev はプロファイル編集とログ監視が近接しており、ターミナル中心のワークフローと相性がよいです。チーム運用でも差分 YAML を共有できる点は、アプリ単体のブラックボックス VPN に対して実務的な優位になります。

無料で Clash を入手し、ターミナル経由の分流と検証を試す →