Codex Keeps Reconnecting? Check DNS and Clash Routing

Codex errors such as Reconnecting..., stream disconnected before completion, and error sending request can involve DNS interference or incorrect Clash routing. This guide explains how to investigate that possibility, apply a targeted Clash Verge Rev enhancement, and verify the result.

What community reports actually show

Reddit users have reported interrupted tasks targeting chatgpt.com/backend-api/codex/responses, repeated reconnect attempts, and response-body errors. These reports establish symptoms, not a DNS diagnosis. Interrupted request, reconnection loop

A separate discussion describes failures during remote context compaction. A commenter suggests investigating the proxy, but the discussion does not establish a verified cause. Compaction discussion

Reports on X show similar questions: a September 9 post describes persistent stream failures, while a September 6 post reports an SSE idle timeout during remote compaction. Neither provides a DNS comparison. These are useful examples of user problems, but they do not establish a shared cause. X stream report, X compaction report

Symptom	What to investigate
Immediate timeout with a resolver error	DNS, node reachability, and whether traffic enters Clash
ChatGPT works in a browser but Codex fails	Differences in proxy, DNS, certificates, and egress
Output starts, then the stream disconnects	Long-lived connections, network changes, and service errors
Only long conversations or compaction fail	Compare with a small new task; investigate session and server errors
HTTP 401, 403, 429, or 5xx	Inspect the response origin and body for authentication, policy, limits, or service failures

Check OpenAI service status and record the time and client version. For stuck chats, OpenAI also recommends checking for pending approvals and trying a smaller, focused new chat. Desktop and CLI versions may differ. Official troubleshooting

A local case: an unexpected DNS answer triggered DIRECT

In one recorded macOS investigation using Clash Verge Rev and Mihomo, proxy nodes were reachable, but chatgpt.com matched a GeoIP/CN rule and attempted a direct connection that timed out. A comparison with encrypted DNS reached through the proxy showed an anomalous answer on the local resolution path.

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

There are two configuration issues to address: the resolution path and the routing decision. This recorded case is not a benchmark or proof that other Codex failures have the same cause. An anomalous answer alone also cannot identify the responsible intermediary or establish DNS cache poisoning specifically.

Diagnose before changing configuration

Check the connection log

Search for the actual hostname in the error, including chatgpt.com or openai.com. Record the matched rule, connection chain, and error at the failure time. A connection that should use a proxy but selects DIRECT warrants a rule-order review. Mihomo evaluates routing rules from top to bottom. Routing documentation

If no matching connection appears, first establish whether that client uses Clash. Browser success does not establish the path used by a separate process.

Compare resolution paths

On macOS, inspect the system resolver and its current answer:

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

For an encrypted comparison, replace 7890 with your Clash HTTP/mixed port:

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'

The request uses Cloudflare’s DNS JSON interface. Check the connection panel: an explicit local proxy guarantees entry into Clash, but Clash rules still determine the final egress.

Different IP addresses alone are not proof of interference. CDN selection, caching, address families, and Fake-IP can explain differences. A synthetic address from Clash’s Fake-IP range is not inherently suspicious. Correlate an anomalous answer with the incorrect route and failure, then compare against another verified network path. With TUN enabled, even dig @resolver may be intercepted; it is not automatically an independent upstream test.

Apply a targeted Clash Verge Rev enhancement

This template requires Clash Verge Rev with Mihomo, an existing subscription, and a working proxy node. It is a subscription Script, not a complete standalone profile. Back up the current configuration first. If you already use a script, integrate the change into its existing main(config) function. Inspect the final runtime configuration after all enhancement steps. Clash Verge Rev Script documentation

Set CODEX_PROXY_GROUP to an existing group and select a working proxy node in that group. Set NODE_DNS to a DoH resolver that works before the proxy connects and correctly resolves node hostnames. The AliDNS example is intended for validation on a mainland-China network; replace it when inappropriate. It is not used to resolve the AI domains below.

// 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;
}

The script adds domain-specific DNS policy and prepends proxy rules while retaining other rules and domain policies. It changes node-hostname resolution. The four domain suffixes are a starting scope, not an exhaustive list of every Codex feature, custom provider, MCP service, or task download.

Mihomo supports a domain-specific nameserver-policy and an explicit proxy suffix on a DNS server address. Node resolution needs an independent path to avoid a circular dependency. DNS configuration reference

The targeted script retains existing fallback settings. Review broader DNS dependencies separately before replacing them. Also check for stale hosts mappings or conflicting, more-specific policies.

Check TUN separately

For processes that do not use the system proxy, enable TUN in Clash Verge Rev and verify that it is running. Merge the following fields into your existing TUN object, preserving its other settings:

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

These cover UDP and TCP DNS on port 53. Mihomo documents limitations for LAN-directed DNS on macOS and Windows; application-managed encrypted DNS is also outside these port-53 rules. Verify resolver and interface behavior instead of assuming the toggle covers every request. TUN reference

Verify configuration, routing, and Codex separately

First check the final configuration for errors, group references, and rule order. If the Mihomo CLI is available, mihomo -t -f <final-config-path> checks whether the configuration parses. It does not prove connectivity.

Next inspect actual connection routing and run a certificate-verified HTTPS probe through your real local port:

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/

A response from the intended service after successful certificate verification establishes an HTTP exchange for this probe. A 401 or 403 can still block access. It does not prove that an authenticated Codex request works, and disabling certificate verification would invalidate this check.

Finally, complete a small task in the client that originally failed. An installed, authenticated CLI can run the following optional check, which makes a real model request and uses account quota:

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

A CLI success only verifies that CLI request; test the desktop app separately if that is where the failure occurred. Recheck after a subscription update, network change, and sleep/wake. Later configuration layers or renamed groups can still break an enhancement.

Frequently asked questions

Is changing system DNS to 8.8.8.8 enough?

Not necessarily. A resolver address alone does not establish encryption, proxy routing, or reachability. Verify resolver, transport, and egress together.

Why does Codex fail while Clash is running?

The process might bypass the proxy, match a direct rule, or depend on unavailable node DNS. The problem might also be unrelated to DNS. Find the actual connection before changing several settings at once.

What if it still disconnects?

If DNS, TLS, and routing are working, investigate service status, conversation size, client version, node connection stability, and the exact error body. OpenAI documents feedback and log locations; review logs for secrets before sharing. Troubleshooting and logs

How do I undo the change?

Disable the added Script and restore the backed-up profile, TUN settings, and any system DNS settings you changed. A separate proxy-providers architecture can later isolate node subscriptions from local DNS and rules, but is not required for this targeted fix.

For installation and import steps, see Clash Verge setup. For other failures, see Clash troubleshooting. You can use this diagnostic process with an existing compatible subscription; buying another service is not a prerequisite for testing DNS.