まず押さえる：Codexの不調は「モデルバージョン」より先に経路を疑う
Codex CLI や統合ランナーは、短い対話だけでなく長めの HTTPS セッションやストリーミング応答、ツール呼び出しに伴う追加ホストへの往復を含みます。体感では「モデルが弱い」「レート制限だ」と決めつけがちですが、ログを見ると TCP 再送や途中の切断、証明書検証より手前の名前解決失敗が混ざっているケースは少なくありません。特に 端末プロキシ がブラウザと非対称な環境では、速度テストが良好でも実アプリだけ失敗するパターンが起きます。コードやプロンプトを疑う前に、接続ログで当該操作直後の FQDN とポリシー名の対応を書き留めると、以降の対処が一気に速くなります。
また Codex 周辺では npm や pip、コンテナレジストリへのダウンロードが同じセッションに絡むこともあり、単一ドメインだけ直せば終わりではない場面があります。依存取得が固まって見えるときは、推論 API とパッケージ取得を切り分け、ログ上のホストが別系列かどうかを確認してください。Git やパッケージマネージャの細部は他稿に譲りますが、「Codex の画面ではなくトラフィックの辞書」として接続ログを読む姿勢が重要です。
なぜブラウザの ChatGPT は通るのに Codex CLI だけ失敗するのか
多くのブラウザは システムプロキシ を尊重しますが、ターミナルの言語ランタイムや一部の HTTP クライアントは既定で直結します。OpenAI Codex 自体の内部実装はアップデートで変わり得るため、ここでは一般論として「ターミナル発のトラフィックは取りこぼしやすい」と捉えてください。結果として、ブラウザだけ希望ノードに流れ、CLI が不安定回線や迂回不可経路へ出る、という 経路の非対称 が起きます。OAuth やデバイスフローの途中で別ホストへリダイレクトされるケースでは、メインの api.openai.com だけ規則化しても不足することがあります。症状を再現する 最小コマンド を一つ決め、その瞬間にログへ並ぶ名前を列挙するのが近道です。
第1の一手：TUN でターミナルも同じ分流に載せる
HTTP や SOCKS の手動指定に頼らず、OS のルーティングテーブルから仮想 NIC へ流すのが TUN の役割です。Clash Verge Rev などの GUI クライアントでは TUN を有効化するだけで、ブラウザと ターミナル が同一个ルールエンジンへ乗りやすくなります。初回は管理者権限や ネットワーク拡張、ヘルパーの承認を求められるため、画面が止まったように見えて実際は権限待ち、という誤解に注意してください。Windows と macOS のクリック順の詳細は Clash Verge Rev の TUN モード完全ガイド に譲りますが、「CLI を捕捉する目的では TUN を最優先」という方針だけは共通です。Global と Rule の使い分けは購読ポリシーに依存するため、常にログで最終的な出口グループを確認してください。
実務のコツ：TUN とシステムプロキシを同時に強く掛け合わせると、どこで詰まったか読みにくくなることがあります。まず TUN 単体で再現操作を試し、残差だけを環境変数で補うと切り分けが早いです。
分流ルール：ログで見た名前を DOMAIN-SUFFIX に落とす
OpenAI 周辺では api.openai.com、platform.openai.com、chatgpt.com、認証まわりの openai.com サブドメイン、静的アセットや計測系の別ホストなどが混線しがちです。公式が公開するエンドポイント集合は時代で増減するため、ブログ上ではログ優先を推します。接続ログに出た FQDN を DOMAIN-SUFFIX で拾い、現場で実際に選んでいる プロキシグループ名 へマッピングしてください。GEOIP だけへ寄せると CDN エッジの所在地で期待と違うノードに着地し、断続的なタイムアウトを誘発することがあります。困っているホストを個別指定する方が、Codex CLI の再現性確保には効きやすいです。
# Example sketch: point observed OpenAI-related hosts to your policy group
rules:
- DOMAIN-SUFFIX,openai.com,YOUR_PROXY_GROUP
- DOMAIN-SUFFIX,chatgpt.com,YOUR_PROXY_GROUP
YOUR_PROXY_GROUP は購読プロファイル内の実名へ置き換えてください。広いルールセットをすでに読み込んでいる場合でも、そのルールが本当に意図したポリシー階層へ流れているかはログで再検証が必要です。名前のtypoや古いグループ名の取り違えは、典型として「原因不明のタイムアウトだけが続く」症状を生みます。MATCH 行の直前で意図どおりにヒットしているか、順序による取りこぼしもあわせて確認しましょう。
DNS と FakeIP：ルール評価と名前解決のズレを潰す
分流が「設定したのに効かない」ように見えるとき、実際にはアプリが OS リゾルバ 経由で別経路の DNS を使い、得られた 実 IP がルール評価の想定と食い違っていることがよくあります。Clash Meta（Mihomo）系で fake-ip を使う場合は、返る仮アドレスと評価順を正しく理解しないと、一見ランダムな失敗が出ます。細部は Meta コア DNS リーク防止ガイド に譲りますが、Codex のタイムアウト調査では「DNS が一瞬だけ別値を返したのか」「チェーン途中で詰まったのか」を切り分けることが肝になります。TUN と DNS ハイジャックを併用するときは、セキュリティ製品や社内エージェントのフィルタと競合していないかも同時に疑ってください。
環境変数とツールチェーンの補助：TUN の隙間を埋める
TUN が有効でも、特定バイナリ alone が独自のネットワークスタックを持ち、想定外の経路へ出ることがあります。シェルでは HTTPS_PROXY や ALL_PROXY を混合ポートや SOCKS に合わせて指定し、必要に応じて NO_PROXY で社内サフィックスを直結させます。OpenAI 向けの API キーやベース URL を環境変数で切り替える運用をしているチームでは、プロキシ経由の検証環境と直結環境で値が食い違っていないかも確認してください。Windows と WSL を跨ぐ場合は WSL2 と Clash のポート連携 も参照し、ホスト側 TUN とゲスト側設定の二重化でループや誤ルーティングが出ていないかを見ます。
エージェント実行時に増えがちな「隠れホスト」とタイムアウト
エージェント モードではファイル検索やドキュメント取得、追加の計測エンドポイント、サンドボックス通信が挟まり、短い会話テストでは顕在化しないホストがログに現れることがあります。ここでいちいち憶測でルールを増やすより、失敗するワークフローを一つに絞り、増分でルールを足す方が事故が少ないです。長めのジョブほど TCP アイドル や中間装置のセッション切断が効いて見かけのタイムアウトになるため、別途サーバ側のタイムアウト設定やクライアント側の再試行ポリシーも併記されているドキュメントを参照してください。いずれにせよ、可視化された 接続ログ が全体の羅針盤になります。
最短ワークフロー：ログ起点で迷わない順序
- Clash を Rule モードにし、購読とポリシー階層が読み込めているか確認する。
- 症状が出る Codex CLI 操作を一つに絞り、実行直後の 接続ログ から FQDN を控える。
- TUN を有効化し、同じ操作を繰り返してログの変化を比較する。
- 不足している
DOMAIN-SUFFIXや順序を整え、MATCH に吸い込まれる前へ流す。 - DNS と FakeIP を見直し、他製品のリゾルバ干渉を切り分ける。
- 必要なら環境変数でプロキシ透過を補強し、認証と API を再試行する。
注意：利用契約・学校規程・企業方針によってはプロキシや経路変更が禁止されることがあります。関係法令と社内ガイドラインの範囲内でのみ設定を変更してください。
よくある質問
ブラウザの ChatGPT は速いのに CLI だけタイムアウトするのはなぜ？
ブラウザは OS のプロキシ設定を尊重しやすい一方、CLI はデフォルトで直結しやすい実装が多いです。TUN で経路の非対称をまず潰してください。
ルールを足しても改善しない
DNS が期待と違う値を返し、ルール評価が実際の転送経路とズレている可能性があります。FakeIP や DoH の競合をログで再確認してください。
職場の管理端末でも試せる？
MDM やゼロトラストでブロックされている場合は手順どおりに進みません。情報システムの許可範囲内で検証してください。
まとめ
OpenAI Codex CLI と エージェント 運用では、ブラウザと違ってプロキシを無視する経路が残りやすく、結果としてモデル取得や推論 API がタイムアウトしたように見えます。Clash の TUN でターミナルも同じ分流に載せ、ログを見ながら OpenAI 系ホストを DOMAIN-SUFFIX で拾い、DNS と FakeIP の整合を取れば、再現性の高い安定運用に近づきます。一方、手作業で巨大な設定ファイルを編集し続ける汎用ツールは、一行の綴り間違いが全体の可観測性を落としがちです。GUI でプロファイルとルールを視覚化でき、ノード切替や更新導線も揃ったクライアントの方が、詰まりどころの発見が早い場面も多いです。多くの代替実装は高機能な反面、起動手順や権限要求が環境依存で曲がり角が増え、結果として「設定は合っているはずなのに CLI だけ落ちる」時間が長引きます。ルールと DNS を一体として扱え、接続ログからすぐ試行錯誤へ戻れる製品設計は、コーディング エージェント と相性が良いです。まだ試していない方は 無料で Clash をダウンロード し、本文の順序どおりにログを取りながら TUN と DNS を整えてください。