OpenAI CodexをClashで使う方法｜接続設定と安定化のコツ

OpenAI Codexを使ったAIコーディングでは、認証画面が開かない、APIリクエストが途中で止まる、ストリーミング出力が頻繁に切断されるといった問題が起きることがあります。原因はCodexそのものではなく、DNSの名前解決、プロキシのルーティング、ノードの混雑、TLS接続、あるいは環境変数の設定にある場合も少なくありません。Clashを正しく構成すれば、Codex関連の通信だけを適切なプロキシへ振り分け、通常の開発ツールや社内サービスは直接接続する構成を作れます。この記事では、OpenAI CodexをClashで使うための準備から、サブスクリプションの追加、ルール設定、ノード選び、接続テスト、トラブル対策までを順番に解説します。

CodexとClashの接続構成を理解する

Codexは、ターミナルやエディターからコード生成、コードレビュー、テスト作成、リファクタリングなどを実行するAIコーディングツールです。利用形態によって通信先や認証方法は異なります。ChatGPTアカウントによるブラウザ認証を使う場合もあれば、APIキーを環境変数に設定してAPIエンドポイントへ接続する場合もあります。そのため、Clash側では「特定のアプリ名」を指定するのではなく、Codexがアクセスするドメインと通信方式を正しく処理することが重要です。

基本的な通信経路は、次のようになります。

1. Codex CLIまたはエディター拡張機能が認証・APIリクエストを開始する
2. OSのDNSまたはClashのDNS機能が接続先ドメインを解決する
3. Clashがルールに従ってプロキシ接続または直接接続を選択する
4. 選択されたノードを経由して認証情報の送信やモデルAPIとの通信を行う
5. レスポンスがClashを通り、Codexの画面やターミナルへ返される

この流れのどこか一つでも不安定になると、ログインページの読み込み失敗、401 Unauthorized、403 Forbidden、429 Too Many Requests、接続タイムアウト、ストリーム切断などが発生します。特に、ブラウザではログインできるのにCLIだけ失敗する場合は、ブラウザとCLIで異なるプロキシ環境変数が使われている可能性があります。

Clashクライアントとサブスクリプションを準備する

WindowsではClash VergeまたはClash Verge Rev、macOSではClashX系クライアントやMihomo対応クライアント、AndroidではClash for Android系のアプリを利用できます。クライアントによってボタン名や設定画面の位置は異なりますが、必要な機能はほぼ共通しています。確認すべきなのは、サブスクリプションの読み込み、プロファイルの選択、システムプロキシ、TUNモード、DNS、外部コントローラーの状態です。

まず、契約しているサービスからサブスクリプションURLを取得します。Clash Verge系ではProfilesまたはプロファイル画面を開き、URL入力欄へサブスクリプションを貼り付けてダウンロードします。取得後は、新しく追加されたプロファイルを選択して有効化してください。URLが正しくても、形式がClash向けでない場合は読み込みに失敗するため、サービス側で「Clash」「Clash Meta」「Mihomo」などと表示された形式を選ぶ必要があります。

1. Clashクライアントを最新版へ更新する
2. サブスクリプションURLをプロファイル一覧へ追加する
3. 読み込んだプロファイルをアクティブにする
4. Proxy画面で利用可能なノードが表示されることを確認する
5. システムプロキシ、またはTUNモードを必要に応じて有効化する
6. ブラウザで一般的なHTTPSサイトを開き、Clashの接続数が増えることを確認する

通常のデスクトップアプリだけを対象にするなら、まずはシステムプロキシから始めると切り分けが簡単です。一方、CLI、Git、エディター拡張機能、サンドボックス化されたアプリなど、システムプロキシを参照しない通信もまとめて処理したい場合はTUNモードが便利です。ただしTUNモードはDNSや仮想ネットワークインターフェースにも影響するため、導入直後はすべての通信を無条件にプロキシする設定を避け、ルールを確認しながら使うことをおすすめします。

OpenAI関連ドメインをルールで振り分ける

Codexの通信を安定させるには、OpenAI関連のドメインを一つのルールグループへまとめます。利用しているサービスや認証方式によって実際の接続先は変わるため、下記のドメインをすべて固定的に登録するのではなく、Clashの接続ログで実際に使われているホスト名を確認してください。特に認証フローでは、API通信とは別のログイン、認可、ブラウザリダイレクト用ドメインが使われる場合があります。

• api.openai.com：APIキーを使う場合の代表的なAPIエンドポイント
• openai.com：OpenAIのWebサービスや関連ページ
• auth.openai.com：認証フローで使用される可能性があるホスト
• chatgpt.com：ChatGPTアカウントを利用する認証やWeb画面
• platform.openai.com：開発者向け管理画面やAPI設定ページ

一般的には、ドメインルールを先に記述し、最後に地域ルールやMATCHルールを置きます。Clashのルールは上から順番に評価されるため、広い範囲を対象にするルールを先に書くと、OpenAI向けの指定が無視されることがあります。

proxy-groups:
  - name: AI-Service
    type: select
    proxies:
      - Auto-Select
      - node-us
      - node-singapore
      - DIRECT

rules:
  - DOMAIN-SUFFIX,openai.com,AI-Service
  - DOMAIN-SUFFIX,chatgpt.com,AI-Service
  - DOMAIN,platform.openai.com,AI-Service
  - DOMAIN,api.openai.com,AI-Service
  - MATCH,DIRECT

上の例では、OpenAIとChatGPT関連の通信だけをAI-Serviceへ送り、それ以外は直接接続しています。認証ページが表示されない場合は、Clashの接続ログを開き、失敗したドメインを確認してからルールへ追加します。逆に、すでに直接接続で正常に動作しているドメインまで無理にプロキシへ送る必要はありません。不要な経路を増やすと、遅延や認証判定の変化につながることがあります。

Codexに適したノードを選ぶ

AIコーディングでは、単純な速度測定の数値だけでなく、長時間接続の安定性が重要です。Codexのレスポンスは短いリクエストだけでなく、コード生成結果をストリーミングで受信することがあります。そのため、pingが低いノードでも、数十秒後に接続が切れるなら実用性は低くなります。

自動選択を使う場合は、url-testグループが便利です。ただし、テストURLへの遅延が低いノードが、OpenAI APIへの経路でも最速とは限りません。最初は自動選択で候補を絞り、Codexで実際にログイン、短いコード生成、長めの出力を順番に試してください。安定したノードが見つかったら、重要な作業中は手動選択へ切り替えると、テスト結果による頻繁なノード変更を防げます。

proxy-groups:
  - name: AI-Auto
    type: url-test
    proxies:
      - node-us-01
      - node-us-02
      - node-jp-01
    url: https://www.gstatic.com/generate_204
    interval: 300
    tolerance: 80

  - name: AI-Service
    type: select
    proxies:
      - AI-Auto
      - node-us-01
      - DIRECT

DNSと環境変数を整える

OpenAI関連の接続だけ失敗する場合、プロキシノードよりもDNSが原因になっていることがあります。ローカルDNSが誤ったアドレスを返す、DNSリクエストだけが直接接続になる、IPv6経路だけが不安定になるといったケースです。Mihomoでは、DNSをClash内で処理し、ドメインルールと実際の接続経路を一致させる構成が取りやすくなっています。

dns:
  enable: true
  enhanced-mode: fake-ip
  fake-ip-range: 198.18.0.1/16
  nameserver:
    - 1.1.1.1
    - 8.8.8.8
  fallback:
    - tls://1.1.1.1:853
    - tls://8.8.8.8:853
  respect-rules: true

fake-ipはドメインベースのルールと相性がよく、Clashが接続先ドメインを保持したままルールを適用しやすい方式です。ただし、利用しているOS、TUN実装、他のVPNソフトとの組み合わせによっては、特定のアプリで問題が起きることがあります。その場合は一時的にredir-hostへ変更して挙動を比較し、DNS設定だけが原因かどうかを切り分けてください。

APIキーを使う場合は、キーをYAMLファイルへ直接書き込むより、OSの環境変数で管理する方が安全です。macOSやLinuxのシェルでは、たとえば次のように設定できます。

# macOS / Linux
export OPENAI_API_KEY="your-api-key"
export HTTPS_PROXY="http://127.0.0.1:7890"

# 接続先と環境変数を確認
echo $OPENAI_API_KEY
echo $HTTPS_PROXY

APIキーを端末へ表示したままにしたり、シェル履歴へ残したりしないよう注意してください。Gitリポジトリ、共有ログ、スクリーンショットへキーを保存するのも危険です。認証方式によって必要な環境変数は異なるため、Codexの公式ドキュメントで現在の変数名と設定方法を確認し、不要な変数は削除してください。また、プロキシ環境変数の値に余分な引用符、誤ったポート番号、古いローカルプロキシアドレスがないかも確認します。

接続テストとトラブルシューティング

設定後はいきなり大規模なリポジトリで作業せず、小さなテストを実行します。まずClashの接続ログを開き、認証画面やAPIリクエストが想定したプロキシグループへ入っているか確認してください。次に、短いプロンプトでコード生成を行い、レスポンスが最後まで表示されるかを見ます。最後に、複数ファイルを対象にしたレビューやテスト生成を試し、長時間接続の安定性を確認します。

• 認証画面が開かない：ブラウザのシステムプロキシ、CLIの環境変数、ClashのOpenAI関連ルールをそれぞれ確認します。リダイレクト先のドメインがルールから漏れていることがあります。
• 401が表示される：APIキーの期限、コピー時の空白、利用中のアカウントや環境変数名を確認します。プロキシを変更しても401が続く場合は、ネットワークより認証情報の問題である可能性が高いです。
• 403が表示される：ノードの地域、IP評価、アカウント設定、アクセス権を確認します。異なるノードで比較し、特定のノードだけ失敗するかを調べます。
• 429が表示される：短時間のリクエスト数や利用上限を確認します。Clashのノードを変えても解決しない場合、単純な速度問題ではありません。
• 途中でストリームが切れる：混雑したノード、短いアイドルタイムアウト、TLSやHTTP/2の相性を疑います。別ノードで長めの出力を試し、TUNとシステムプロキシを切り替えて比較します。
• CLIだけ接続できない：シェルに残ったHTTP_PROXYやHTTPS_PROXYが、Clashのポートと一致しているか確認します。アプリ独自のプロキシ設定がある場合は、二重プロキシになっていないかも確認します。

Clashのログでは、接続先、使用ルール、選択された代理グループ、接続エラーを確認できます。まず「どのドメインが」「どのルールに一致し」「どのノードへ送られたか」を記録すると、設定変更の効果を比較しやすくなります。設定を一度に複数変更すると原因が分からなくなるため、ノード変更、DNS変更、ルール変更、プロキシ方式変更を一つずつ行ってください。

安全で安定した日常運用

Clashは通信経路を柔軟に変更できる便利なツールですが、APIキーやログインセッションを扱うCodexでは、速度だけでなく安全性も重視する必要があります。出所が不明な設定ファイルをそのまま使わず、プロファイルに含まれるDNS、リダイレクト、外部コントローラー、スクリプト設定を確認してください。特にexternal-controllerを外部公開する場合は、強力なシークレットを設定し、不要ならローカルホストに限定します。

証明書エラーを解決するために、skip-cert-verify: trueを常用するのは避けてください。これはTLS証明書の検証を無効にするため、認証情報やコードデータを扱う通信ではリスクが高まります。接続できない場合は、まずノードの証明書、システム時刻、SNI、クライアントのコアバージョンを確認し、検証無効化に頼らず原因を解決します。

実際の運用では、OpenAI関連通信を専用グループへ分け、通常のWeb閲覧や社内開発サービスとは経路を分離する構成が扱いやすいです。CodexのログインとAPI通信が成功し、短いコード生成と長時間のストリーミングも安定しているなら、その組み合わせを基準設定として保存します。Clashのプロファイル更新後は、ルール、DNS、ノードグループが意図せず変更されていないかを確認してから作業を再開してください。

OpenAI CodexをClashで使う際の要点は、サブスクリプションを読み込むことだけではありません。実際の接続先をログで確認し、必要なドメインだけをルール化し、長時間通信に強いノードを選び、DNSとCLIの環境変数を一貫させることが安定化への近道です。基本設定が整ったら、利用するOSやCodexの認証方式に合わせて少しずつ調整し、再現性のある開発環境を作っていきましょう。