Codex が再接続を繰り返す場合: DNS と Clash のルーティングを確認

Reconnecting...、stream disconnected before completion、error sending request などの Codex エラーには、DNS 干渉や不正な Clash ルーティングが関係している可能性があります。このガイドでは、その可能性を調査する方法、対象を絞った Clash Verge Rev の拡張を適用する方法、そして結果を確認する方法を説明します。

コミュニティ報告が実際に示していること

Reddit のユーザーは、chatgpt.com/backend-api/codex/responses を対象とした中断されたタスク、繰り返される再接続の試行、レスポンス本文のエラーを報告しています。これらの報告が示しているのは症状であり、DNS 診断ではありません。中断されたリクエスト、再接続ループ

別の議論では、リモートのコンテキスト圧縮中の失敗が説明されています。コメント投稿者の 1 人はプロキシの調査を提案していますが、その議論だけでは検証済みの原因は確立されていません。圧縮に関する議論

X 上の報告でも同様の疑問が見られます。9 月 9 日の投稿では継続的なストリーム障害が説明され、9 月 6 日の投稿ではリモート圧縮中の SSE アイドルタイムアウトが報告されています。どちらも DNS 比較は示していません。これらはユーザーの問題の有用な例ですが、共通の原因を確立するものではありません。X のストリーム報告、X の圧縮報告

症状	調査する内容
リゾルバーエラーを伴う即時タイムアウト	DNS、ノード到達性、トラフィックが Clash に入っているか
ブラウザでは ChatGPT が動作するが Codex は失敗する	プロキシ、DNS、証明書、外向き通信の違い
出力は始まるが、その後ストリームが切断される	長時間接続、ネットワーク変化、サービスエラー
長い会話または圧縮だけが失敗する	小さな新規タスクと比較し、セッションエラーとサーバーエラーを調査する
HTTP 401、403、429、または 5xx	レスポンスの発信元と本文を調べ、認証、ポリシー、制限、またはサービス障害を確認する

OpenAI のサービスステータスを確認し、時刻とクライアントのバージョンを記録してください。チャットが停止している場合、OpenAI は保留中の承認を確認し、より小さく焦点を絞った新しいチャットを試すことも推奨しています。デスクトップ版と CLI 版では状況が異なる場合があります。公式トラブルシューティング

ローカルでの事例: 予期しない DNS 応答が DIRECT を引き起こした

Clash Verge Rev と Mihomo を使用した、ある記録された macOS の調査では、プロキシノードには到達可能でしたが、chatgpt.com が GeoIP/CN ルールに一致し、タイムアウトする直接接続を試みていました。プロキシ経由で到達した暗号化 DNS との比較では、ローカルの名前解決経路で異常な応答が示されました。

Request to chatgpt.com
  → anomalous DNS answer
  → no earlier matching OpenAI domain rule
  → GeoIP selects DIRECT
  → connection times out and Codex retries

対処すべき設定上の問題は 2 つあります。名前解決経路とルーティング判断です。この記録された事例は、ベンチマークでも、他の Codex 障害にも同じ原因があることの証明でもありません。異常な応答だけでは、関与した中継者を特定することも、特に DNS キャッシュポイズニングを立証することもできません。

設定を変更する前に診断する

接続ログを確認する

エラー内の実際のホスト名を検索してください。chatgpt.com や openai.com も含みます。一致したルール、接続チェーン、障害発生時刻のエラーを記録してください。プロキシを使うべき接続が DIRECT を選択している場合は、ルール順序の見直しが必要です。Mihomo はルーティングルールを上から下へ評価します。ルーティングのドキュメント

一致する接続が表示されない場合は、まずそのクライアントが Clash を使っているかどうかを確認してください。ブラウザで成功していても、別のプロセスで使われている経路が同じであることは示されません。

名前解決経路を比較する

macOS では、システムリゾルバーとその現在の応答を確認してください:

scutil --dns
dscacheutil -q host -a name chatgpt.com

暗号化された比較を行うには、7890 をあなたの Clash の HTTP/mixed ポートに置き換えてください:

curl --noproxy '' --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  -H 'accept: application/dns-json' \
  'https://1.1.1.1/dns-query?name=chatgpt.com&type=A'

このリクエストは Cloudflare の DNS JSON インターフェースを使用します。接続パネルを確認してください。明示的なローカルプロキシは Clash への流入を保証しますが、最終的な外向き通信は依然として Clash のルールによって決まります。

IP アドレスが異なること自体は、干渉の証拠ではありません。CDN の選択、キャッシュ、アドレスファミリー、Fake-IP が違いを説明できる場合があります。Clash の Fake-IP 範囲からの合成アドレスは、それ自体で不審というわけではありません。異常な応答を不正な経路と障害に関連付け、そのうえで別の検証済みネットワーク経路と比較してください。TUN が有効な場合、dig @resolver でさえ捕捉されることがあり、自動的に独立した上流テストになるわけではありません。

対象を絞った Clash Verge Rev の拡張を適用する

このテンプレートには、Mihomo を備えた Clash Verge Rev、既存のサブスクリプション、および動作するプロキシノードが必要です。これはサブスクリプション Script であり、完全なスタンドアロンプロファイルではありません。最初に現在の設定をバックアップしてください。すでにスクリプトを使用している場合は、変更を既存の main(config) 関数に統合してください。すべての拡張手順の後で、最終的な実行時設定を確認してください。Clash Verge Rev Script のドキュメント

CODEX_PROXY_GROUP を既存のグループに設定し、そのグループ内で動作するプロキシノードを選択してください。NODE_DNS は、プロキシ接続前に動作し、ノードのホスト名を正しく解決できる DoH リゾルバーに設定してください。AliDNS の例は中国本土のネットワークでの検証を想定したものです。不適切な場合は置き換えてください。これは以下の AI ドメインの解決には使用されません。

// Clash Verge Rev subscription Script. Use with an existing Mihomo profile.
// Replace this with the exact name of a working proxy group in that profile.
const CODEX_PROXY_GROUP = "REPLACE_WITH_EXISTING_PROXY_GROUP";

// Example bootstrap resolver for a mainland-China network. Verify reachability
// and node-hostname answers on your network, or replace with your trusted DoH.
// It must work BEFORE the proxy is established. It does not resolve AI domains.
const NODE_DNS = ["https://223.5.5.5/dns-query#DIRECT"];

function main(config) {
  const groups = config["proxy-groups"] || [];
  if (!groups.some((group) => group.name === CODEX_PROXY_GROUP)) {
    throw new Error("Set CODEX_PROXY_GROUP to an existing working proxy group.");
  }
  if (/[#&,\r\n]/.test(CODEX_PROXY_GROUP)) {
    throw new Error("Use a proxy group name without #, &, commas or newlines.");
  }

  const domains = ["chatgpt.com", "openai.com", "oaistatic.com", "oaiusercontent.com"];
  const doh = [
    "https://1.1.1.1/dns-query#" + CODEX_PROXY_GROUP,
    "https://8.8.8.8/dns-query#" + CODEX_PROXY_GROUP,
  ];
  const dns = config.dns || {};
  const policy = Object.assign({}, dns["nameserver-policy"] || {});
  domains.forEach((domain) => { policy["+." + domain] = doh.slice(); });
  dns.enable = true;
  dns["nameserver-policy"] = policy;
  dns["proxy-server-nameserver"] = NODE_DNS.slice();
  if (!Array.isArray(dns.nameserver) || dns.nameserver.length === 0) {
    dns.nameserver = NODE_DNS.slice();
  }
  config.dns = dns;

  const oldRules = Array.isArray(config.rules) ? config.rules : [];
  const aiRules = domains.map((domain) =>
    "DOMAIN-SUFFIX," + domain + "," + CODEX_PROXY_GROUP
  );
  config.rules = aiRules.concat(oldRules.filter((rule) => !aiRules.includes(rule)));
  return config;
}

このスクリプトは、他のルールとドメインポリシーを保持したまま、ドメイン固有の DNS ポリシーを追加し、プロキシルールを先頭に挿入します。これにより、ノードのホスト名解決が変更されます。4 つのドメインサフィックスは出発点となる対象範囲であり、Codex のすべての機能、カスタムプロバイダー、MCP サービス、またはタスクのダウンロードを網羅した一覧ではありません。

Mihomo は、ドメイン固有の nameserver-policy と、DNS サーバーアドレス上の明示的なプロキシサフィックスをサポートしています。ノード解決では循環依存を避けるために独立した経路が必要です。DNS 設定リファレンス

対象のスクリプトは既存のフォールバック設定を保持します。これらを置き換える前に、より広範な DNS 依存関係を別途確認してください。古い hosts マッピングや、競合する、より具体的なポリシーも確認してください。

TUN を個別に確認する

システムプロキシを使用しないプロセスについては、Clash Verge Rev で TUN を有効にし、実行中であることを確認してください。以下のフィールドを既存の TUN オブジェクトにマージし、その他の設定は保持してください:

tun:
  enable: true
  auto-route: true
  auto-detect-interface: true
  dns-hijack:
    - any:53
    - tcp://any:53

これらはポート 53 の UDP と TCP DNS を対象としています。Mihomo では、macOS と Windows における LAN 宛て DNS の制限が文書化されています。また、アプリケーション管理の暗号化 DNS もこれらのポート 53 ルールの対象外です。トグルがすべてのリクエストをカバーすると決めつけるのではなく、リゾルバーとインターフェースの挙動を確認してください。TUN リファレンス

設定、ルーティング、Codex を個別に確認する

まず、最終設定にエラー、グループ参照、ルール順序の問題がないか確認してください。Mihomo CLI が利用可能であれば、mihomo -t -f <final-config-path> で設定が正しく解析されるか確認できます。これは接続性を証明するものではありません。

次に、実際の接続ルーティングを調べ、実際のローカルポート経由で証明書検証付きの HTTPS プローブを実行してください:

curl --noproxy '' --proxy http://127.0.0.1:7890 \
  --connect-timeout 10 --max-time 20 \
  -o /dev/null -sS \
  -w 'HTTP=%{http_code} TLS=%{time_appconnect}s TOTAL=%{time_total}s\n' \
  https://chatgpt.com/

証明書検証に成功した後、意図したサービスから応答が返れば、このプローブについては HTTP のやり取りが成立していることを示します。401 や 403 でもアクセスがブロックされる可能性はあります。これは認証済みの Codex リクエストが機能することを証明するものではなく、証明書検証を無効にするとこの確認は無効になります。

最後に、元々失敗していたクライアントで小さなタスクを完了してください。インストール済みで認証済みの CLI では、以下の任意の確認を実行できます。これは実際のモデルリクエストを行い、アカウントのクォータを消費します:

codex exec --skip-git-repo-check --sandbox read-only \
  'Reply with exactly: PONG. Do not use tools.'

CLI での成功が確認できるのはその CLI リクエストだけです。問題が発生したのがデスクトップアプリであれば、そちらは別途テストしてください。サブスクリプションの更新、ネットワーク変更、スリープ/復帰の後にも再確認してください。後から適用される設定レイヤーや名前変更されたグループによって、拡張が引き続き壊れる可能性があります。

よくある質問

システム DNS を 8.8.8.8 に変更するだけで十分ですか?

必ずしもそうではありません。リゾルバーのアドレスだけでは、暗号化、プロキシルーティング、到達性は確立されません。リゾルバー、トランスポート、エグレスをまとめて確認してください。

Clash が動作しているのに、なぜ Codex は失敗するのですか?

そのプロセスがプロキシをバイパスしているか、direct ルールに一致しているか、利用できないノード DNS に依存している可能性があります。問題が DNS と無関係である可能性もあります。複数の設定を一度に変更する前に、実際の接続を特定してください。

それでも切断される場合は?

DNS、TLS、ルーティングが機能している場合は、サービスの状態、会話サイズ、クライアントのバージョン、ノード接続の安定性、正確なエラー本文を調査してください。OpenAI はフィードバック方法とログの場所を文書化しています。共有前にログ内の秘密情報を確認してください。トラブルシューティングとログ

変更を元に戻すには?

追加した Script を無効にし、バックアップしたプロファイル、TUN 設定、および変更したシステム DNS 設定を復元してください。別個の proxy-providers アーキテクチャを使えば、後からノードのサブスクリプションをローカル DNS やルールから分離できますが、この対象を絞った修正には必須ではありません。

インストールとインポートの手順については、Clash Verge セットアップを参照してください。その他の障害については、Clash トラブルシューティングを参照してください。この診断手順は、既存の互換性のあるサブスクリプションで利用できます。DNS をテストするために別のサービスを購入することは前提条件ではありません。