Codex CLIはブラウザ版ChatGPTと同じドメインだけ見ればよいですか？

限りません。CLIはAPI本体に加え、モデルやバイナリの取得、認可まわりで細かいホストへ散らばりやすいです。DOMAIN-SUFFIX,openai.com 一行に全部寄せると、軽いWeb向け自動選択と重いAPIストリーミングが同じ出口に縛られ、タイムアウトや途中切断の原因が隠れます。ログに出た実名から、DOMAIN行で核を先へ、余白は広いサフィックスで吸う二層が安全です。

TLS handshake failed と 403 は同じ対処でよいですか？

別物です。TLS失敗はSNI不一致、中間機器、ノードの互換、ローカルCA、DNSの取り違えを疑います。403は出口IPやリージョン、Enterpriseポリシー、アプリケーション側の認可トークンが優勢です。まずClashログで当たったポリシーが意図通りかを確認し、TLSなら別ノード or DIRECT試行、403ならトークンとAPIキー、組織設定を先に切り分けます。

環境変数のプロキシとClash TUNが両方あるとCLIはどちらを使いますか？

実装次第です。HTTPS_PROXY が残っていると、ターミナルからのHTTPリクエストが想定外の親プロキシへ跳び、二重CONNECTで落ちることがあります。GUIだけTUN、ターミナルだけ手動export、のズレも典型です。シェル設定ファイルとIDE統合ターミナルの起動元を含め、実プロセスが参照している変数と、システムプロキシ／TUNの有効範囲を揃えてからルールを詰めます。

GPT系API記事と何が違いますか？

HTTPクライアントの切り分けは共通ですが、Codex CLIは端末シェルでの実行、グローバルプロキシ環境、IDE埋め込みターミナル、バックグラウンドの依存取得が絡みやすい点が違います。ブラウザ分離の話だけでは足りないため、CDN的ホストとAPI核のDOMAIN順序、プロセスごとの出口確認を強調します。

Codex CLI端末×Clash API／CDN分流

なぜ「ターミナルのCodex CLI」だけ切り口を変えるのか

ブラウザでChatGPTを開くときと、Codex CLI をシェルから動かすときでは、見えている失誘因が違います。前者は同一オリジンに近い読み込みが多く、後者は 細かいホスト名 への逐次アクセス、長めのストリーミング、エディタ統合ターミナル由来の 環境変数 が重なります。加えて、開発者はnpmやgit、社内レジストリも同じシェルから触るため、どのプロセスがどの出口を見るか がブラウザよりブレやすいのが現実です。

2026年時点でも、ルール分流 の骨格は変わりません。rules は上から最初の一致だけが有効で、広い DOMAIN-SUFFIX を先に置くと細かい例外を書けません。OpenAI周りの記事では DOMAIN-SUFFIX,openai.com を例に出しがちですが、CLIでは API本体 と 静的配信・補助サービス を分けたい場面が増えます。分流の共通形は YAMLルール分流ガイドを前提にし、ここでは 端末の実接続ログ を軸に戻ります。

購読YAMLが更新されるたびに手書き行が下へ押し出される、という事故は購読の自動更新トラブルシュートと同系です。APIとCDNを分けても、順序が崩れれば意味がありません。まず「どのホストが、どの行に当たったか」をログで固定する癖を優先してください。

典型症状：総タイムアウト、TLS、403、取得失敗の重なり方

Codex CLIのユーザー視点では、すべて「止まった」に見えます。切り分けでは、次のレイヤを分けます。第一に DNS で名前が引けていない、または意図しないIPへ引いている。第二に TCP/TLS でハンドシェイクが通らない。第三に HTTP で403や401などアプリケーションエラー。第四に 長いストリーミング の途中でプロキシや中間機器がアイドル切断する。これらは単一の設定変更では直らず、症状ごとの当たり所 が違います。

注意本稿のホスト例は構造説明用です。実サービスはCDNや認可のホストを更新します。必ずログと開発者向けトレースのServer Nameを一次情報にし、コピペ運用は避けてください。

CLIはブラウザより プロキシ自動検出 の恩恵を受けにくく、HTTPS_PROXY が残存していたり、逆にTUNだけ有効で変数が空だったりすると、見かけ上同じコマンドでも挙動が変わります。ここを揃えないまま DOMAIN-SUFFIX を増やしても迷走します。

ステップ1：実ホスト名をログで確定し「束ねすぎ」を解く

最初にやるのは推測ではなく観測です。Clash系クライアントのログに出る接続先、あるいはアプリ側の詳細ログから Server Name を列挙し、API呼び出し、モデルやバイナリ取得、OAuthメタデータ取得などに分類します。分類がつくと、「広いサフィックス一行」に載せるべきでない核が見えます。

特に問題になりやすいのは、API用の低遅延ノード と CDN向けの高帯域ノード を同一ポリシーで扱うパターンです。APIは遅いが安定、CDNは速いが不安定、のように要求が逆向きになることがあり、CLIは両方を短時間で要求するため、設定の妥協点がブラウザより厳しく見えます。

ヒント手書きルールは購読の大きなRULE-SETやMATCHより上に置くのが原則です。「OpenAI関連」カテゴリの_PROVIDERだけ信じる運用は、CLIの新しいホストに遅れて追従しがちです。

ステップ2：API核をDOMAINで先に固定し、CDNは別行へ

実務で効くのは二段構えです。第一行目に DOMAIN,api.openai.com,AI-API のような 狭い一致 を置き、第二段で DOMAIN-SUFFIX,openai.com,AI-WEB のように 広い吸収 を置く、という順序です。これにより、長い推論ストリームだけ安定出口に寄せ、Web向けの自動選択と混ぜない選択肢が生まれます。

# Example: narrow API first, broader suffix for remaining hosts (names are placeholders)
rules:
  - DOMAIN,api.openai.com,AI-API
  - DOMAIN-SUFFIX,openai.com,AI-WEB
  # ... keep your manual lines above GEOIP / MATCH / bulky RULE-SET ...

CDNと思われるホストが別トップレベルや別サフィックスに増える場合は、ログに出た名前先に DOMAIN 行を足し、十分に観測できてから DOMAIN-SUFFIX 化する段階を踏むと安全です。一気にサフィックス化すると、また束ねすぎに戻ります。

Azure系やEnterpriseゲートウェイを併用する場合はホスト空間が分かれるため、GPT系タイムアウト記事の「混ぜない」原則がそのまま効きます。CLIでも例外ではありません。

ステップ3：ポリシーグループ設計で「途中のノード切替」を止める

url-test は便利ですが、間隔が短い、または許容差が狭いと、長いセッションの途中で別ノードへ移り、CLI側は突然の切断として観測します。対策は大きく二つ、API専用グループをselectで手動固定するか、url-test のパラメータをAPI向けに緩めるか、です。

GUIブラウジング用に最適化した自動選択を、APIと共用しない価値は毎年説明されますが、2026年も変わりません。CLIは「体感速さ」より「落ちないこと」が優先されるケースが多く、固定ノードの方が結果的に速く感じることもあります。全体設計の整合は使い方ヘルプのルールモード説明とも整合的です。

ステップ4：HTTP(S)_PROXY、TUN、システムプロキシの三点照合

端末での典型ハマりは、GUIクライアントがTUN済みなのに、ターミナルだけ古い HTTP_PROXY を見ているパターンです。逆もあり、変数は空だがIDEが別経路でプロキシを注入しているケースもあります。Cursor／npm向け分流が触れているのと同じく、どのプロセスがどの変数を継承したか を疑います。

TUNとシステムプロキシの挙動差は TUNとシステムプロキシの記事に沿って切り分けます。特にWSLやリモートコンテナを交えると、見えているネットワーク名前空間がホストとズレ、Clashは正常でもCLIだけ別ルートへ抜けることがあります。ルール以前の問題として先に潰します。

社内の親プロキシを二重に挟む構成では、CONNECTネストでタイムアウトが伸びるだけでなく、ヘッダ検査で403になることもあります。「Clashだけ直せばCodexも直る」と決めつけないでください。

ステップ5：DNSと証明書検証、403を混同しない

症状がTLSだけ怪しいときは、DNS fake-ipとredir-hostの記事の手順で名前解決を確定します。fake-ip のままローカル開発向け例外を誤ると、ブラウザよりCLIの方が先に破綻することがあります。逆に403中心なら、出口IPのレピュテーションや組織ポリシーを疑い、プロキシを変える前にトークンと権限を見直します。

切り分けの実測順を一文でまとめると、第一に実ホスト名、第二にrulesの命中行、第三にポリシーグループとノード、第四にプロキシ注入の経路、第五にDNS、第六にアプリの認可、です。順序を飛ばすと、設定を増やすほどログが読めなくなります。

発展：ストリーミング切断と再試行の扱い

ネットワークが一瞬揺れただけでCLIは全体を失敗扱いにすることがあります。アプリ側の指数バックオフや429／503の扱いはSDK任せの部分も多いですが、プロキシ側でできるのは 誤った出口への再試行を減らす ことです。ルール順が崩れて遅いノードに固定されている状態でリトライを叩くと、逆にレート制限だけが早まります。

長文のストリーミングでは、途中フレームが止まってもサーバはまだ生成継続、という時間帯があります。中間機器のアイドルタイムアウトが短いと、CLIだけ切断されます。ここはノード変更とアイドル上限の両面から見ます。

よくある質問

ブラウザは速いのにCLIだけ遅いのはなぜですか

ホスト集合、HTTP/2やTLSの扱い、Keep-Aliveの長さ、プロキシ経路が違うためです。まずログでCLIが触っているホストを列挙し、ブラウザのNetworkと突き合わせます。ホストが違うのに同一DOMAIN-SUFFIXへ丸めていると、意図しないノード品質に引っ張られます。

公式のCodex以外のCLIツールにも使えますか

構造は共通です。重要なのは、そのツールが叩く実名の列挙と、ルール順の維持です。ホストがOpenAI以外に広がるなら、別カテゴリのDOMAIN行を増やし、OpenAI系と混ぜないようコメントと順序で区切ってください。

まとめ

2026年の Codex CLI 利用では、API 本体と CDN 的ドメイン、認可補助を DOMAIN-SUFFIX 一行に押し込めない設計が効きます。DOMAIN で核を先に固定し、ポリシーグループ でAPIの途中切替を避け、ターミナルの プロキシ環境 とGUI側の TUN を照合し、最後に DNS とアプリの 403 を分離して読む。この順序を守ると、「総タイムアウト」という言葉が指す層がブレにくくなります。

購読YAMLの更新で手書きが沈むのを防ぐため、エクスポートしてルール位置を定期的に確認し、必要ならCIやローカルスクリプトで差分検知を載せると運用が楽になります。

似た題材でも、ブラウザ特化の拡張機能や単機能プロキシだと、ルールの優先順位やDNSモード、カーネル側のトラフィック取りこぼしに弱く、長いCLIセッションでは設定が散らばりがちです。ClashNote が案内する Clash Meta／mihomo 系のクライアントは、YAML中心でルール順を明示しやすく、TUNやプロセス単位の整理とも相性がよいのが強みです。ターミナルからの実測ログと矛盾しない形に揃えやすい点は、コマンドライン開発の保守性にも直結します。

→ Clashを無料ダウンロード — Metaコア対応クライアントを選べば、OpenAI Codex CLI向けのAPI／CDN離れをYAMLで再現しやすくなります。

ほかのチュートリアルは技術コラムからどうぞ。