OpenAI Codex CLIをClashで使う設定方法と接続トラブル対策

Codex CLIとClashを組み合わせる前に知っておきたいこと

OpenAI Codex CLIは、ターミナルからコードの読解、修正、テスト実行、リポジトリ内の調査などを行うための開発者向けツールです。ブラウザだけで利用するサービスとは異なり、CLIは端末上の認証処理、APIまたは関連サービスへのHTTPS通信、Gitやパッケージマネージャーの通信を個別に発生させます。そのため、ブラウザでウェブページを開ける状態でも、Codex CLIだけがログインに失敗したり、リクエストの途中でタイムアウトしたりすることがあります。

Clashを組み合わせる場合の基本方針は、端末全体を無条件にグローバルプロキシへ切り替えることではありません。Codex CLIの認証とAPI通信に必要なドメインだけをプロキシグループへ送り、国内のパッケージレジストリや社内ネットワーク、ローカルホストは直接接続に残す構成のほうが、速度と再現性を保ちやすくなります。特に開発環境では、Git、npm、pip、Docker、SSHなどが同時に動くため、すべてを同じ出口へ送ると別の問題を作る可能性があります。

なお、Clashは認証情報を発行するツールではありません。OpenAIアカウントのログイン状態やAPIキー、利用権限、組織設定は別途正しく準備する必要があります。Clashはあくまで通信経路を制御する役割を担い、認証エラーをネットワーク設定だけで解決することはできません。

事前準備:クライアント、カーネル、環境変数を確認する

デスクトップでClash Verge、Clash Verge Rev、Clash for Windows、ClashXなどを使う場合は、まずクライアントのバージョン情報を開き、実際に動作しているカーネルを確認します。TUN、fake-ip、rulesの拡張構文を利用するなら、mihomoまたはClash Meta系カーネルを採用したクライアントが扱いやすいです。画面上で「Clash」と表示されていても、内部のカーネルによって利用できる設定項目が異なるため、名称だけで判断しないでください。

• ノードを確認する。ClashのProxies画面で、利用するノードを選択し、テスト機能で遅延と接続状態を確認します。ノード名が表示されていても、実際のHTTPS接続が成功するとは限りません。
• 混合ポートを確認する。代表的なローカルポートは 7890 ですが、クライアントによって異なります。SettingsやGeneralに表示されているHTTPまたはMixed Portを実際に確認してください。
• APIキーを環境変数へ保存する。APIキーをコマンドラインの引数、設定ファイル、シェル履歴に直接書かないでください。認証方式がブラウザログインの場合も、ブラウザとCLIの通信経路が一致しているかを確認します。
• 既存のプロキシを整理する。VPN、別のローカルプロキシ、開発用のHTTP_PROXY設定が同時に有効だと、通信が二重化されます。検証中はClash以外の経路を一度停止します。

環境変数を使う方式では、Codex CLIを起動するシェルにプロキシを明示します。Windows PowerShellの例は次の通りです。値は実際の環境に合わせて置き換え、キーはサンプルのまま使用しないでください。

$env:HTTPS_PROXY="http://127.0.0.1:7890"
$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:ALL_PROXY="socks5://127.0.0.1:7891"
$env:NO_PROXY="localhost,127.0.0.1,::1"
codex

macOSやLinuxでは、ターミナルで次のように設定できます。HTTPプロキシしか用意していない場合は、HTTPS_PROXYとHTTP_PROXYの両方を同じMixed Portへ向けます。SOCKSポートが実際に有効か分からない場合、まずMixed Portだけを使うほうが確認しやすいでしょう。

export HTTPS_PROXY="http://127.0.0.1:7890"
export HTTP_PROXY="http://127.0.0.1:7890"
export ALL_PROXY="socks5://127.0.0.1:7891"
export NO_PROXY="localhost,127.0.0.1,::1"
codex

Clashの基本設定:Codex関連通信を専用グループへ振り分ける

Codex CLIだけを安定したノードへ送るには、専用のプロキシグループを作り、認証やAPI通信に関係するドメインを明示的に割り当てます。実際のエンドポイントはCLIのバージョン、ログイン方式、提供される機能によって変わる可能性があるため、下記は構成の考え方を示す例です。利用していないサービスのドメインを無制限に追加するのではなく、Clashのログで実際に発生した接続先を確認してから増やしてください。

mixed-port: 7890
allow-lan: false
mode: rule
log-level: info

proxy-groups:
  - name: CODEX
    type: select
    proxies:
      - "安定ノード"
      - DIRECT

rules:
  - DOMAIN-SUFFIX,openai.com,CODEX
  - DOMAIN-SUFFIX,auth.openai.com,CODEX
  - DOMAIN-SUFFIX,api.openai.com,CODEX
  - DOMAIN,localhost,DIRECT
  - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve
  - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve
  - MATCH,DIRECT

この例では、OpenAI関連のドメインを CODEX グループへ送ります。DOMAIN-SUFFIX,openai.com はサブドメインを広く対象にするため分かりやすい一方、必要以上の通信までプロキシへ送ることがあります。より厳密にしたい場合は、Clashの接続ログに表示された認証・API・更新用のドメインを個別の DOMAIN ルールへ置き換えます。

ルールは上から下へ評価され、最初に一致した行で処理が終了します。LAN用のアドレス帯やlocalhostを先にDIRECTへ送るのは、開発サーバー、Docker、社内APIへのアクセスを誤って外部ノードへ送らないためです。最後の MATCH,DIRECT は、未確認の通信までプロキシに送らない保守的な例です。海外のパッケージレジストリなどもCLIから利用する場合は、必要なドメインだけ別途ルールを追加してください。

実践手順:Clashを経由してCodex CLIを起動する

ここでは、既にCodex CLIがインストールされ、Clashに有効なサブスクリプションとノードが登録されている前提で確認します。OSやCLIのリリースによってログインコマンドの表示は異なるため、画面に提示された現在のコマンドを優先してください。

1. Clashを起動し、Profilesで使用する設定を選択します。Proxies画面で CODEX グループを開き、接続テストで正常なノードを選びます。
2. SettingsまたはGeneralでHTTP/Mixed Portを確認します。例として 127.0.0.1:7890 を使いますが、実際のポートが7890でない場合は読み替えてください。
3. ターミナルから curl -I -x http://127.0.0.1:7890 https://api.openai.com を実行し、Clashのログに接続が現れることを確認します。HTTPステータスが401や404でも、TLS接続自体が成立していれば経路確認としては役立ちます。
4. HTTPS_PROXY、HTTP_PROXY、必要ならALL_PROXYを設定し、NO_PROXYにはlocalhostと127.0.0.1を指定します。既存の環境変数があれば、古いポート番号が残っていないか確認します。
5. Codex CLIのログインまたは認証操作を実行します。ブラウザが開く方式では、認証ページを開いた時刻にClashのログを確認し、関連する接続がCODEXグループへ入っているかを見ます。
6. 認証後、短い読み取り専用の依頼を実行します。いきなり大規模な編集やテスト実行を行わず、応答、遅延、ログの3点を確認します。
7. 動作が安定したら、プロジェクト単位のシェル設定やターミナルプロファイルへ必要な環境変数だけを移します。共有端末ではAPIキーを平文で保存しないでください。

テスト中にClashのConnections画面を開いておくと、CLIがどのドメインへ接続しているかを把握できます。接続が一瞬で消える場合は名前解決またはTLS開始前の問題、接続が長時間残る場合はノードの遅延、サーバー応答、タイムアウト設定を疑います。CLIの表示だけで判断せず、Clashのログと端末側のエラー時刻を照合することが重要です。

接続エラーの原因と確認方法

Codex CLIのエラー文は、認証、ネットワーク、サーバー側の制限を完全には区別しないことがあります。次の表を使って、エラーが発生する位置を切り分けてください。

環境変数とシステムプロキシの優先関係

ブラウザが使えるのにCLIが使えない場合、最初に確認したいのは環境変数です。Clashのシステムプロキシをオンにしていても、CLIがその設定を自動利用するとは限りません。逆に、HTTPS_PROXYが設定されていると、システムプロキシをオフにしてもCLIだけがClashへ接続し続けることがあります。PowerShellでは Get-ChildItem Env: | Select-String PROXY、macOSやLinuxでは env | grep -i proxy を実行して、設定値を一覧表示できます。

不要な設定を一時的に解除する場合、PowerShellでは Remove-Item Env:HTTPS_PROXY、macOSやLinuxでは unset HTTPS_PROXY HTTP_PROXY ALL_PROXY を使います。大文字と小文字を別々に参照する実装もあるため、同名の小文字変数が残っていないかも確認してください。

DNS、TLS、TUNの確認

Clashのルールログにドメインが表示されない場合、CLIがプロキシ環境変数を読んでいないか、独自のネットワーク処理で直接接続している可能性があります。端末全体を確実に取り込みたい場合はmihomoのTUNモードを検討できます。TUNを有効にするときは管理者権限、仮想ネットワークアダプター、DNS hijack、IPv6の扱いを確認してください。システムプロキシとTUNを同時に使う構成では、同じ通信が二重に処理されることがあるため、まず片方だけで検証します。

TLS証明書エラーが出る場合は、端末の日時、Clashのシステムプロキシ、企業ネットワークのHTTPS検査、カスタムCA証明書の有無を確認します。証明書検証を無効化して回避する設定は安全性を下げるため、常用しないでください。正しい時刻へ戻し、必要な社内CAを適切なOSまたはCLIの信頼ストアへ登録する方法を優先します。

安全に運用するための設定とログ管理

Codex CLIはソースコード、環境変数、設定ファイル、テスト結果などを扱うため、通信が成功することだけでなく、何を送信するかも確認が必要です。プロジェクトに秘密鍵、アクセストークン、顧客データが含まれる場合は、CLIの利用ポリシーと対象ファイルを事前に確認してください。不要な秘密情報をワークスペースへ置かず、環境変数やOSの資格情報管理機能を利用します。

• APIキーをログに出さない。デバッグログやシェルの実行履歴にAuthorizationヘッダーが出ていないか確認します。キーをチャット、スクリーンショット、設定ファイルへ貼り付けないでください。
• Clashのログレベルを戻す。調査中だけdebugを使い、解決後はinfoまたはwarnへ戻します。長時間の詳細ログには接続先やエラー情報が残る場合があります。
• 開発用ポートを公開しない。allow-lan: false とloopbackバインドを基本にし、LAN内の他端末からClashのMixed Portや外部コントロールポートへ接続できる状態を避けます。
• プロジェクトごとに分離する。業務コードと個人の検証用ディレクトリを分け、不要なファイルを同じワークスペースへ置かないようにします。

Clashの接続ログで確認すべきなのは、接続先ドメイン、使用ルール、選択された策略グループ、接続の成否、発生時刻です。APIキーやCookieなどの秘密値をログへ書き出す必要はありません。障害を報告するときは、これらの秘密情報を伏せたうえで、CLIのバージョン、カーネル名、OS、ポート番号、再現手順を整理すると、原因を特定しやすくなります。

よくある質問