O Codex continua reconectando? Verifique o DNS e o roteamento do Clash

Erros do Codex como Reconnecting..., stream disconnected before completion e error sending request podem envolver interferência de DNS ou roteamento incorreto do Clash. Este guia explica como investigar essa possibilidade, aplicar um aprimoramento direcionado no Clash Verge Rev e verificar o resultado.

O que os relatos da comunidade realmente mostram

Usuários do Reddit relataram tarefas interrompidas direcionadas a chatgpt.com/backend-api/codex/responses, tentativas repetidas de reconexão e erros no corpo da resposta. Esses relatos estabelecem sintomas, não um diagnóstico de DNS. Requisição interrompida, loop de reconexão

Uma discussão separada descreve falhas durante a compactação de contexto remoto. Um comentarista sugere investigar o proxy, mas a discussão não estabelece uma causa verificada. Discussão sobre compactação

Relatos no X mostram perguntas semelhantes: uma publicação de 9 de setembro descreve falhas persistentes de stream, enquanto uma publicação de 6 de setembro relata um tempo limite ocioso de SSE durante a compactação remota. Nenhuma fornece uma comparação de DNS. Esses são exemplos úteis de problemas de usuários, mas não estabelecem uma causa compartilhada. Relato de stream no X, Relato de compactação no X

Sintoma	O que investigar
Tempo limite imediato com um erro de resolvedor	DNS, alcançabilidade do nó e se o tráfego entra no Clash
O ChatGPT funciona no navegador, mas o Codex falha	Diferenças em proxy, DNS, certificados e saída
A saída começa, depois o stream desconecta	Conexões de longa duração, mudanças de rede e erros de serviço
Apenas conversas longas ou a compactação falham	Compare com uma nova tarefa pequena; investigue erros de sessão e de servidor
HTTP 401, 403, 429 ou 5xx	Inspecione a origem e o corpo da resposta em busca de falhas de autenticação, política, limites ou serviço

Verifique o status do serviço OpenAI e registre o horário e a versão do cliente. Para chats travados, a OpenAI também recomenda verificar aprovações pendentes e tentar um novo chat menor e focado. As versões Desktop e CLI podem diferir. Solução de problemas oficial

Um caso local: uma resposta DNS inesperada acionou DIRECT

Em uma investigação registrada no macOS usando Clash Verge Rev e Mihomo, os nós de proxy eram alcançáveis, mas chatgpt.com correspondia a uma regra GeoIP/CN e tentou uma conexão direta que expirou. Uma comparação com DNS criptografado acessado pelo proxy mostrou uma resposta anômala no caminho de resolução local.

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

Há duas questões de configuração a serem tratadas: o caminho de resolução e a decisão de roteamento. Este caso registrado não é um benchmark nem prova de que outras falhas do Codex tenham a mesma causa. Uma resposta anômala por si só também não pode identificar o intermediário responsável nem estabelecer especificamente envenenamento de cache DNS.

Diagnostique antes de alterar a configuração

Verifique o log de conexão

Procure o hostname real no erro, incluindo chatgpt.com ou openai.com. Registre a regra correspondente, a cadeia de conexão e o erro no momento da falha. Uma conexão que deveria usar um proxy, mas seleciona DIRECT, justifica uma revisão da ordem das regras. O Mihomo avalia as regras de roteamento de cima para baixo. Documentação de roteamento

Se nenhuma conexão correspondente aparecer, primeiro determine se esse cliente usa o Clash. O sucesso no navegador não estabelece o caminho usado por um processo separado.

Compare os caminhos de resolução

No macOS, inspecione o resolvedor do sistema e sua resposta atual:

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

Para uma comparação criptografada, substitua 7890 pela sua porta HTTP/mista do Clash:

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'

A requisição usa a interface DNS JSON da Cloudflare. Verifique o painel de conexão: um proxy local explícito garante a entrada no Clash, mas as regras do Clash ainda determinam a saída final.

Endereços IP diferentes, por si só, não são prova de interferência. Seleção de CDN, cache, famílias de endereços e Fake-IP podem explicar diferenças. Um endereço sintético da faixa Fake-IP do Clash não é inerentemente suspeito. Correlacione uma resposta anômala com a rota incorreta e a falha, depois compare com outro caminho de rede verificado. Com TUN ativado, até mesmo dig @resolver pode ser interceptado; ele não é automaticamente um teste upstream independente.

Aplique um aprimoramento direcionado no Clash Verge Rev

Este modelo requer Clash Verge Rev com Mihomo, uma assinatura existente e um nó de proxy funcional. É um Script de assinatura, não um perfil autônomo completo. Faça backup da configuração atual primeiro. Se você já usa um script, integre a mudança à função main(config) existente dele. Inspecione a configuração final em tempo de execução após todas as etapas de aprimoramento. Documentação de Script do Clash Verge Rev

Defina CODEX_PROXY_GROUP como um grupo existente e selecione um nó de proxy funcional nesse grupo. Defina NODE_DNS como um resolvedor DoH que funcione antes de o proxy se conectar e resolva corretamente os nomes de host dos nós. O exemplo do AliDNS destina-se à validação em uma rede da China continental; substitua-o quando não for apropriado. Ele não é usado para resolver os domínios de AI abaixo.

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

O script adiciona uma política de DNS específica por domínio e antepõe regras de proxy, mantendo as outras regras e políticas de domínio. Ele altera a resolução de nomes de host dos nós. Os quatro sufixos de domínio são um escopo inicial, não uma lista exaustiva de todos os recursos do Codex, provedores personalizados, serviços MCP ou downloads de tarefas.

O Mihomo oferece suporte a nameserver-policy específico por domínio e a um sufixo de proxy explícito em um endereço de servidor DNS. A resolução dos nós precisa de um caminho independente para evitar uma dependência circular. Referência de configuração de DNS

O script direcionado mantém as configurações de fallback existentes. Revise separadamente dependências de DNS mais amplas antes de substituí-las. Verifique também mapeamentos de hosts desatualizados ou políticas conflitantes e mais específicas.

Verifique o TUN separadamente

Para processos que não usam o proxy do sistema, habilite o TUN no Clash Verge Rev e verifique se ele está em execução. Mescle os campos a seguir ao seu objeto TUN existente, preservando as outras configurações dele:

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

Eles cobrem DNS UDP e TCP na porta 53. O Mihomo documenta limitações para DNS direcionado à LAN no macOS e no Windows; DNS criptografado gerenciado pelo aplicativo também fica fora dessas regras da porta 53. Verifique o comportamento do resolvedor e da interface em vez de presumir que a alternância cobre todas as solicitações. Referência de TUN

Verifique separadamente a configuração, o roteamento e o Codex

Primeiro, verifique se há erros na configuração final, referências de grupo e ordem das regras. Se a CLI do Mihomo estiver disponível, mihomo -t -f <final-config-path> verifica se a configuração pode ser analisada. Isso não comprova conectividade.

Em seguida, inspecione o roteamento real da conexão e execute uma sonda HTTPS com verificação de certificado por meio da sua porta local real:

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/

Uma resposta do serviço pretendido após a verificação bem-sucedida do certificado estabelece uma troca HTTP para esta sonda. Um 401 ou 403 ainda pode bloquear o acesso. Isso não prova que uma solicitação autenticada do Codex funcione, e desabilitar a verificação de certificado invalidaria esta verificação.

Por fim, conclua uma pequena tarefa no cliente que falhou originalmente. Uma CLI instalada e autenticada pode executar a seguinte verificação opcional, que faz uma solicitação real ao modelo e usa a cota da conta:

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

Um sucesso na CLI verifica apenas essa solicitação da CLI; teste separadamente o aplicativo de desktop se foi nele que a falha ocorreu. Verifique novamente após uma atualização de assinatura, mudança de rede e suspensão/reativação. Camadas de configuração posteriores ou grupos renomeados ainda podem quebrar uma melhoria.

Perguntas frequentes

Alterar o DNS do sistema para 8.8.8.8 é suficiente?

Não necessariamente. Um endereço de resolvedor, por si só, não estabelece criptografia, roteamento por proxy nem alcançabilidade. Verifique em conjunto o resolvedor, o transporte e a saída.

Por que o Codex falha enquanto o Clash está em execução?

O processo pode contornar o proxy, corresponder a uma regra direta ou depender de DNS de nó indisponível. O problema também pode não estar relacionado a DNS. Identifique a conexão real antes de alterar várias configurações ao mesmo tempo.

E se ele ainda se desconectar?

Se DNS, TLS e roteamento estiverem funcionando, investigue o status do serviço, o tamanho da conversa, a versão do cliente, a estabilidade da conexão do nó e o corpo exato do erro. A OpenAI documenta locais de feedback e logs; revise os logs em busca de segredos antes de compartilhá-los. Solução de problemas e logs

Como desfaço a alteração?

Desative o Script adicionado e restaure o perfil com backup, as configurações de TUN e quaisquer configurações de DNS do sistema que você tenha alterado. Uma arquitetura proxy-providers separada pode posteriormente isolar assinaturas de nós do DNS e das regras locais, mas não é necessária para esta correção direcionada.

Para etapas de instalação e importação, consulte Configuração do Clash Verge. Para outras falhas, consulte Solução de problemas do Clash. Você pode usar este processo de diagnóstico com uma assinatura compatível existente; comprar outro serviço não é um pré-requisito para testar DNS.