Codex fortsetter å koble til på nytt? Sjekk DNS og Clash-ruting

Sist oppdatert: 2026-09-10

Codex-feil som Reconnecting..., stream disconnected before completion og error sending request kan involvere DNS-forstyrrelser eller feil Clash-ruting. Denne veiledningen forklarer hvordan du kan undersøke den muligheten, bruke en målrettet forbedring i Clash Verge Rev og bekrefte resultatet.

Hva rapporter fra fellesskapet faktisk viser

Brukere på Reddit har rapportert avbrutte oppgaver rettet mot chatgpt.com/backend-api/codex/responses, gjentatte forsøk på å koble til på nytt og feil i responskroppen. Disse rapportene fastslår symptomer, ikke en DNS-diagnose. Avbrutt forespørsel, gjenoppkoblingssløyfe

En separat diskusjon beskriver feil under komprimering av ekstern kontekst. En kommentator foreslår å undersøke proxyen, men diskusjonen fastslår ikke en verifisert årsak. Diskusjon om komprimering

Rapporter på X viser lignende spørsmål: et innlegg fra 9. september beskriver vedvarende strømfeil, mens et innlegg fra 6. september rapporterer en SSE inaktivitetstidsavbrudd under ekstern komprimering. Ingen av dem gir en DNS-sammenligning. Dette er nyttige eksempler på brukerproblemer, men de fastslår ikke en felles årsak. X-rapport om strømfeil, X-rapport om komprimering

Symptom Hva som bør undersøkes
Umiddelbar tidsavbrudd med en resolver-feil DNS, om noden er nåbar, og om trafikken går inn i Clash
ChatGPT fungerer i en nettleser, men Codex feiler Forskjeller i proxy, DNS, sertifikater og utgående trafikk
Utdata starter, så kobles strømmen fra Langvarige forbindelser, nettverksendringer og tjenestefeil
Bare lange samtaler eller komprimering feiler Sammenlign med en liten ny oppgave; undersøk økt- og serverfeil
HTTP 401, 403, 429 eller 5xx Undersøk responsens opprinnelse og innhold for autentisering, policy, begrensninger eller tjenestefeil

Sjekk OpenAI service status og noter tidspunktet og klientversjonen. For fastlåste samtaler anbefaler OpenAI også å sjekke om det finnes ventende godkjenninger og å prøve en mindre, fokusert ny samtale. Desktop- og CLI-versjoner kan oppføre seg forskjellig. Offisiell feilsøking

En lokal sak: et uventet DNS-svar utløste DIRECT

I én dokumentert macOS-undersøkelse med Clash Verge Rev og Mihomo var proxynoder tilgjengelige, men chatgpt.com traff en GeoIP/CN-regel og forsøkte en direkte tilkobling som fikk tidsavbrudd. En sammenligning med kryptert DNS nådd gjennom proxyen viste et avvikende svar i den lokale oppløsningsbanen.

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

Det er to konfigurasjonsproblemer som må håndteres: oppløsningsbanen og rutingsavgjørelsen. Denne dokumenterte saken er ikke en benchmark eller et bevis på at andre Codex-feil har samme årsak. Et avvikende svar alene kan heller ikke identifisere det ansvarlige mellomleddet eller spesifikt fastslå DNS-cacheforgiftning.

Diagnostiser før du endrer konfigurasjonen

Sjekk tilkoblingsloggen

Søk etter det faktiske vertsnavnet i feilen, inkludert chatgpt.com eller openai.com. Noter hvilken regel som ble matchet, tilkoblingskjeden og feilen på tidspunktet da problemet oppstod. En tilkobling som burde bruke en proxy, men velger DIRECT, tilsier at rekkefølgen på reglene bør gjennomgås. Mihomo evaluerer rutingsregler ovenfra og ned. Dokumentasjon om ruting

Hvis ingen samsvarende tilkobling vises, må du først fastslå om den klienten bruker Clash. At det fungerer i nettleseren, fastslår ikke hvilken bane som brukes av en separat prosess.

Sammenlign oppløsningsbaner

På macOS kan du undersøke systemets resolver og det gjeldende svaret:

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

For en kryptert sammenligning erstatter du 7890 med Clash sin 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'

Forespørselen bruker Cloudflare’s DNS JSON interface. Sjekk tilkoblingspanelet: en eksplisitt lokal proxy garanterer at trafikken går inn i Clash, men Clash-reglene avgjør fortsatt den endelige utgående ruten.

Ulike IP-adresser alene er ikke bevis på forstyrrelser. CDN-valg, caching, adressefamilier og Fake-IP kan forklare forskjeller. En syntetisk adresse fra Clash sitt Fake-IP-område er ikke i seg selv mistenkelig. Knytt et avvikende svar til feil rute og feilen, og sammenlign deretter med en annen verifisert nettverksbane. Med TUN aktivert kan selv dig @resolver bli avskåret; det er ikke automatisk en uavhengig test mot oppstrømsserveren.

Bruk en målrettet forbedring i Clash Verge Rev

Denne malen krever Clash Verge Rev med Mihomo, et eksisterende abonnement og en fungerende proxynode. Det er et abonnementsskript, ikke en fullstendig frittstående profil. Ta sikkerhetskopi av den nåværende konfigurasjonen først. Hvis du allerede bruker et script, integrerer du endringen i den eksisterende main(config)-funksjonen. Undersøk den endelige kjøretidskonfigurasjonen etter at alle forbedringstrinnene er brukt. Dokumentasjon for Clash Verge Rev Script

Sett CODEX_PROXY_GROUP til en eksisterende gruppe, og velg en fungerende proxy-node i den gruppen. Sett NODE_DNS til en DoH-oppløser som fungerer før proxyen kobler til, og som løser node-vertsnavn korrekt. AliDNS-eksemplet er ment for validering på et fastlands-Kina-nettverk; bytt det ut når det ikke er passende. Det brukes ikke til å løse AI-domenene nedenfor.

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

Skriptet legger til domenespesifikk DNS-policy og setter proxyregler først, samtidig som andre regler og domenepolicyer beholdes. Det endrer oppløsning av node-vertsnavn. De fire domenesuffiksene er et startomfang, ikke en uttømmende liste over alle Codex-funksjoner, egendefinerte leverandører, MCP-tjenester eller oppgavenedlastinger.

Mihomo støtter en domenespesifikk nameserver-policy og et eksplisitt proxysuffiks på en DNS-serveradresse. Node-oppløsning trenger en uavhengig bane for å unngå en sirkulær avhengighet. DNS-konfigurasjonsreferanse

Det målrettede skriptet beholder eksisterende fallback-innstillinger. Gå gjennom bredere DNS-avhengigheter separat før du erstatter dem. Se også etter foreldede hosts-tilordninger eller konflikterende, mer spesifikke policyer.

Kontroller TUN separat

For prosesser som ikke bruker systemproxyen, aktiver TUN i Clash Verge Rev og bekreft at den kjører. Flett følgende felt inn i ditt eksisterende TUN-objekt, og bevar de andre innstillingene:

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

Disse dekker UDP- og TCP-DNS på port 53. Mihomo dokumenterer begrensninger for LAN-rettet DNS på macOS og Windows; applikasjonsstyrt kryptert DNS faller også utenfor disse port-53-reglene. Bekreft oppløser- og grensesnittatferd i stedet for å anta at bryteren dekker alle forespørsler. TUN-referanse

Verifiser konfigurasjon, ruting og Codex separat

Kontroller først den endelige konfigurasjonen for feil, gruppereferanser og regelrekkefølge. Hvis Mihomo CLI er tilgjengelig, kontrollerer mihomo -t -f <final-config-path> om konfigurasjonen kan parses. Det beviser ikke tilkobling.

Undersøk deretter faktisk tilkoblingsruting og kjør en sertifikatverifisert HTTPS-probe gjennom din faktiske lokale 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/

Et svar fra den tiltenkte tjenesten etter vellykket sertifikatverifisering etablerer en HTTP-utveksling for denne proben. En 401 eller 403 kan fortsatt blokkere tilgang. Det beviser ikke at en autentisert Codex-forespørsel fungerer, og deaktivering av sertifikatverifisering ville ugyldiggjøre denne kontrollen.

Fullfør til slutt en liten oppgave i klienten som opprinnelig mislyktes. En installert, autentisert CLI kan kjøre følgende valgfrie kontroll, som gjør en reell modellforespørsel og bruker kontokvote:

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

Suksess i CLI verifiserer bare den CLI-forespørselen; test skrivebordsappen separat hvis det var der feilen oppstod. Kontroller på nytt etter en abonnementsoppdatering, nettverksendring og dvale/oppvåkning. Senere konfigurasjonslag eller omdøpte grupper kan fortsatt ødelegge en forbedring.

Ofte stilte spørsmål

Er det nok å endre system-DNS til 8.8.8.8?

Ikke nødvendigvis. En oppløseradresse alene etablerer ikke kryptering, proxyruting eller tilgjengelighet. Verifiser oppløser, transport og utgående bane samlet.

Hvorfor mislykkes Codex mens Clash kjører?

Prosessen kan omgå proxyen, treffe en direkte regel eller være avhengig av utilgjengelig node-DNS. Problemet kan også være uten sammenheng med DNS. Finn den faktiske tilkoblingen før du endrer flere innstillinger samtidig.

Hva hvis den fortsatt kobler fra?

Hvis DNS, TLS og ruting fungerer, undersøk tjenestestatus, samtalestørrelse, klientversjon, stabiliteten i nodeforbindelsen og den nøyaktige feilteksten. OpenAI dokumenterer steder for tilbakemelding og logger; gå gjennom logger for hemmeligheter før deling. Feilsøking og logger

Hvordan angrer jeg endringen?

Deaktiver det tillagte Script og gjenopprett den sikkerhetskopierte profilen, TUN-innstillingene og eventuelle system-DNS-innstillinger du endret. En separat proxy-providers-arkitektur kan senere isolere nodeabonnementer fra lokal DNS og regler, men er ikke påkrevd for denne målrettede løsningen.

For installasjons- og importtrinn, se oppsett av Clash Verge. For andre feil, se feilsøking for Clash. Du kan bruke denne diagnoseprosessen med et eksisterende kompatibelt abonnement; å kjøpe en annen tjeneste er ikke en forutsetning for å teste DNS.