この記事で分かること

OpenAI Codex アプリを起動できても、サインインが終わらない、タスクの実行中に接続が切れる、応答が途中で止まるといった症状が出ることがあります。ブラウザーで OpenAI のページを開ける場合でも、アプリが使う認証先や API への通信が同じ経路を通るとは限りません。原因を「Codex の障害」と決めつける前に、Clash のプロファイル、プロキシモード、ルール、DNS、実際の接続ログを順番に確認しましょう。

この記事では Clash Verge Rev と Mihomo 系クライアントを例に、OpenAI Codex アプリがつながらないときの切り分け方を解説します。特定のドメイン一覧をそのまま登録すれば必ず直る、という説明ではありません。アプリの更新や機能によって接続先は変わる可能性があるため、まず Clash のログに記録された接続先を確認し、必要な通信だけを適切な経路へ流す方針で進めます。

設定を一度に何か所も変更すると、改善した場合も原因が分からなくなります。変更前の状態を記録し、プロファイルとモード、ルール、DNS の順に一項目ずつ試してください。Clash Verge Rev の基本操作を先に確認したい場合は、Clash Verge Rev のチュートリアルも参考になります。

症状から接続レイヤーを切り分ける

最初に確認したいのは、Codex アプリのどの段階で失敗するかです。「アプリが起動しない」「ログイン画面から進めない」「ログインできるがタスクだけ失敗する」では、調べる場所が異なります。エラーが出た時刻、表示された文言、直前に行った操作をメモしておくと、Clash のログと照合しやすくなります。

  • サインイン画面が読み込めない、認証後に戻される:認証ページへの通信やブラウザーとのアプリ連携が関係している可能性があります。Codex 本体の API だけをルールに追加しても、認証関連の接続が別経路なら解決しません。
  • ログインは成功するが、タスク開始時に失敗する:アプリ本体の API、ストリーミング接続、タスクで利用する補助サービスなどが候補です。失敗した直後に Clash の接続ログを見て、Codex に関係する新しい接続先が DIRECT になっていないか確認します。
  • 応答が始まってから途中で止まる:単純な名前解決だけでなく、選択中のノードの混雑、長時間接続の切断、ネットワークの切り替わりも考えられます。短い操作と長い操作で結果が異なるかを比べてください。
  • ブラウザーは使えるのに Codex だけ失敗する:ブラウザーとデスクトップアプリではプロキシ設定の参照方法が異なることがあります。ブラウザーの表示だけで、Codex の通信も Clash を通っていると判断しないことが大切です。

接続エラーは、プロキシ経路以外が原因で起きる場合もあります。サービス側の稼働状況、アカウントの認証状態、アプリのバージョン、OS の時刻が正しいかも確認してください。Clash のログに Codex の接続が一件も現れないなら、ルールを追加する前に、アプリの再起動やモード変更で通信が捕捉されるかを調べます。

プロファイルとプロキシモードを確認する

まず Clash で使用中のプロファイルが読み込まれ、意図したプロキシグループとノードが利用できることを確認します。プロファイルを切り替えた直後や更新後に、ルールやグループ名が変わっていることがあります。画面上で選択されている名前だけでなく、グループに有効なノードがあり、遅延テストや一般的な HTTPS 通信が成功するかも確認してください。

次に、現在のモードを見ます。Rule モードではルールの一致結果に応じて通信先が決まり、Global モードでは通常、外向きの通信を選択したプロキシグループへまとめて送ります。切り分け中に短時間だけ Global へ切り替えると、Codex の通信がプロキシ経由で通るかを比較できます。ただし、Global では本来 DIRECT にしたい通信までプロキシに入るため、恒久的な解決策として使うのではなく、比較後は元のモードに戻してください。

システムプロキシを有効にしている場合も、それだけで全アプリの通信が必ず捕捉されるわけではありません。アプリが独自のネットワーク処理を使う、OS のプロキシ設定を参照しない、別の VPN やセキュリティソフトが経路を変更するといった状況があります。システムプロキシを使った状態でログに接続が出ない場合は、まず他の VPN やプロキシを一時停止して比較します。

TUN モードは、システムプロキシを参照しないアプリの通信を捕捉する助けになる場合があります。一方で、ネットワーク権限や仮想インターフェースの設定が関係し、企業 VPN や他のネットワーク拡張と競合する可能性もあります。通常のプロキシ経由を先に試し、Codex の通信がログに現れない場合に限って TUN を検討してください。切り替えた後は Codex を完全終了して起動し直し、ログに変化があるかを確認します。

TIP:モードを切り替える前に現在の設定をメモしておきましょう。検証は「Rule で失敗」「短時間だけ Global で比較」「元に戻してログを確認」のように、変更点を一つずつにすると原因を追いやすくなります。

接続ログを見てルールを調整する

Rule モードで接続できない場合は、ドメインを推測して大量に追加するより、失敗を再現した直後のログを確認するほうが確実です。Clash の接続画面やログ画面を開き、Codex で問題の操作をもう一度実行します。時刻を手掛かりに、接続先のホスト名、適用されたルール、選択されたポリシー、結果を確認してください。画面の項目名はクライアントやバージョンによって異なります。

ログに接続先が表示されたら、まずその接続が DIRECT、プロキシグループ、または拒否のどれに分類されているかを見ます。ルールが一致しているのに失敗する場合は、ルール不足とは限りません。選択ノードが不安定、上流側で接続が拒否されている、DNS が意図しない IP アドレスを返しているなど、別の原因を調べます。反対に、Codex に関係するホストが DIRECT に流れているなら、プロファイルのルール順序やルールセットを確認します。

独自ルールを追加する場合は、プロファイルの管理方法に合わせてください。購読プロファイルを直接編集すると、更新時に変更が上書きされることがあります。クライアントがルールの追加機能やオーバーライド機能を提供している場合は、そちらを優先し、既存ルールの構成と順序を確認してから、ログで確認できたホストだけを追加します。具体的なルール形式やグループ名はプロファイルによって異なるため、未確認の設定例をそのまま貼り付けないでください。

認証とタスク実行で異なるホストが記録されることもあります。そのため、ログインが成功した接続先だけを通して終わりにせず、サインイン、タスク開始、応答受信という各段階を個別に再現します。ログから一つの接続先を特定したら、その通信だけをルールに反映し、もう一度試すという手順にすると、不要なドメインを広くプロキシへ送らずに済みます。

ログには接続先やネットワーク情報が含まれることがあります。画面を共有したり、公開の場所へ貼り付けたりする前に、アカウント情報、トークン、購読 URL、端末固有の情報が写っていないか確認してください。原因調査に必要なのは通常、時刻、対象ホスト、ルール名、結果であり、秘密情報を公開する必要はありません。

DNS とネットワークを段階的に確認する

接続先が DIRECT になっていないのに失敗する場合は、DNS とネットワークの状態を調べます。Clash では DNS の処理方法、プロファイルの設定、システム側の名前解決が組み合わさることがあります。DNS 設定を変更した後は、同じ操作を繰り返すだけでなく、Codex と Clash を再起動してから結果を比べます。クライアントに DNS キャッシュの消去機能がある場合は、利用前に現在の設定を記録してください。

ブラウザーで対象サービスのページが開くことは、Codex の API 接続が正常である証拠にはなりません。逆に、ブラウザーが開かない場合も、Codex 固有の問題と一般的なネットワーク障害が混ざっています。別のネットワーク、たとえば Wi-Fi とスマートフォンのテザリングで同じ操作を試すと、端末の設定とルーター側の問題を切り分ける助けになります。会社や学校のネットワークでは、管理者のポリシーを確認し、制限を回避する目的で設定を変更しないでください。

ノードを切り替えて接続が改善するか試すときは、地域や遅延だけで決めず、同じ条件で数回比較します。一度成功しただけでは、DNS キャッシュや一時的な混雑の影響を排除できません。短いタスクと時間のかかるタスクを分けて試し、開始までの時間、応答が途切れるタイミング、Clash のログを一緒に記録すると、ノード側の不安定さとルールの誤りを区別しやすくなります。

ファイアウォールやセキュリティ製品が Codex の通信を制御していないかも確認します。特に TUN を有効にした後だけ接続が失敗する場合は、ネットワーク拡張、仮想アダプター、他の VPN クライアントとの競合が考えられます。複数のネットワークツールを同時に有効にせず、変更前の状態へ戻せることを確認しながら一つずつ比較してください。

よくある質問

ブラウザーは使えるのに Codex アプリだけ失敗するのはなぜですか?

ブラウザーと Codex アプリが、同じプロキシ設定や同じ接続先を使うとは限らないためです。ブラウザーの成功だけで判断せず、Codex の操作を再現した時刻に Clash のログを確認してください。ログに接続が現れない場合は、システムプロキシの参照状況や TUN の必要性を調べます。

Global モードなら接続できる場合、ずっと使ってもよいですか?

Global モードで改善するなら、Rule モードで適用されているルールやポリシーに差がある可能性を調べる手掛かりになります。ただし、無関係な通信までプロキシに流れるため、まずログで Codex の接続先を特定し、必要なルールを整えてから Rule モードに戻す運用が扱いやすいです。

OpenAI のドメインをすべてプロキシへ送れば解決しますか?

必ずしも解決するとは限りません。アプリの機能やバージョンによって接続先が変わる可能性があり、広い範囲のドメインをまとめて設定すると、不要な通信まで経路が変わることがあります。実際のログで確認できたホストと適用ルールを基準に、必要な範囲だけを調整してください。

購読プロファイルを更新したら、追加したルールが消えました。どうすればよいですか?

購読元が配布するプロファイルは、更新時に内容が置き換わることがあります。追加ルールを直接書き込んでいた場合は、クライアントが提供するオーバーライド機能やルール追加機能を確認し、更新後にも設定が維持される方法を選びます。変更前の設定を保存しておけば、必要なルールだけを再適用できます。

他のプロキシアプリでは、アプリごとに設定方法が違ったり、接続先を広く一括指定する必要があったりして、Codex のように認証とタスク実行を分けて調べる場面では原因を追いにくいことがあります。Clash はプロファイル、ルール、接続ログを組み合わせ、どのホストがどの経路を通ったかを確認しながら調整できるのが利点です。まずは普段使う端末に合ったクライアントを選び、変更を戻せる状態で一項目ずつ検証してみてください。

ダウンロード →