Codex está lento, mas o ChatGPT web funciona? Diagnóstico de proxy, reconexões e TLS

O ChatGPT funciona normalmente no navegador e o Google responde rápido, mas o Codex demora a responder ou mostra Reconnecting repetidamente. Nesse caso, comece pelos erros de conexão do Codex e só então decida se deve trocar de nó, ajustar o proxy ou aguardar o modelo.

O funcionamento do site só comprova que o caminho de acesso usado pelo navegador está disponível; não comprova que as solicitações do Codex passam pelo mesmo proxy nem que a conexão persistente dele funciona. Se os registros já mostram tls handshake eof, uma conexão redefinida ou reconexões seguidas, não atribua todo o tempo de espera à inferência do modelo.

Este artigo trata da lentidão do Codex acompanhada de anomalias de conexão. Siga esta ordem: verifique se há reconexões → confirme o caminho real do proxy → confira TLS e HTTPS comum → depois valide WebSocket ou a conexão em streaming.

As conclusões a seguir vêm de um teste real em um Mac: três chamadas reais do Codex foram concluídas com Tailscale; o nó AnyTLS salvo apresentou TLS EOF durante uma reconstrução isolada, e até o HTTPS do Google falhou. O teste não reproduziu completamente a condição anterior de “a web está rápida, só o Codex está lento”, portanto não comprova uma causa raiz única para o problema histórico. Ele ajuda a decidir qual camada investigar primeiro diante de cada evidência.

O Codex está pensando ou se reconectando sem parar?

Procure primeiro o erro da solicitação atual, em vez de considerar apenas há quanto tempo a interface está parada.

Sintoma ou erro observado	O que verificar primeiro
Reconnecting... junto com tls handshake eof	Caminho do proxy, estabelecimento TLS e encaminhamento ao destino
stream disconnected before completion	Veja o erro específico que aparece depois; essa frase, por si só, não determina a causa
WebSocket estabelecido e depois interrompido, código de fechamento 1006	Horário e duração do encerramento dessa conexão e os pontos intermediários
HTTP 400 informando claramente que o modelo precisa de atualização	Versão do cliente; não classifique primeiro como falha de rede
Nenhum erro de conexão, apenas longa espera pelo resultado	Mantenha a conclusão em aberto: lentidão, por si só, não prova desconexão

Nesta rodada, usamos o mesmo modelo e o mesmo nível de raciocínio; a única solicitação ao Codex foi devolver o texto fixo NETWORK_PROBE_OK:

Caminho	Resultado da chamada real
Tailscale, três sessões curtas independentes	Todas concluídas; o processo CLI completo levou 11.551, 13.945 e 14.877 segundos, respectivamente
HTTP CONNECT local, com saída pelo Tailscale	Concluído; duração total do processo de 11.634 segundos
HTTP CONNECT local usando o nó AnyTLS salvo	Reconexões repetidas; não concluiu durante a janela de observação de 45 segundos

A chamada que falhou gerou estes registros:

Reconnecting... 2/5 (... tls handshake eof)
Reconnecting... 3/5 (... tls handshake eof)
Reconnecting... 4/5 (... tls handshake eof)
Reconnecting... 5/5 (... tls handshake eof)
Reconnecting... waiting for network

Nesse caso, continuar esperando não significa que o modelo esteja gerando uma resposta continuamente. A solicitação está passando por falhas de conexão e novas tentativas; investigue primeiro a conexão.

Os tempos da tabela incluem inicialização do processo, autenticação, inferência e transferência; não representam a latência até o primeiro token nem apenas o tempo de rede. Os 45 segundos são o limite de encerramento do programa de teste, não o tempo médio de resposta do proxy.

Por que o Codex ainda pode não se conectar quando o ChatGPT web funciona?

Verifique separadamente a conexão real do navegador, do aplicativo para computador e da CLI. Extensões de proxy do navegador, proxy do sistema, TUN, roteamento por processo e variáveis de proxy no terminal podem cobrir escopos diferentes. O funcionamento de um programa não permite concluir que outro usa a mesma rota.

No Clash Verge, confira primeiro estes três pontos:

1. Veja se o registro de conexões do Clash mostra o tráfego correspondente quando o Codex faz a solicitação. Definir uma variável no terminal não comprova que a solicitação passou pelo proxy.
2. Confirme se a regra aplicada e a saída correspondem ao esperado. Verifique a solicitação atual, não apenas a tela de seleção do nó.
3. Compare o mesmo contexto de uso. O sucesso da CLI não comprova que todas as conexões em segundo plano do aplicativo para computador funcionam; uma conversa na web também não substitui um teste de conexão do aplicativo.

No teste real de proxy da CLI nesta rodada, o registro do proxy isolado mostrou chatgpt.com, confirmando que a solicitação chegou a essa entrada. O teste de controle HTTP CONNECT também concluiu uma solicitação real, mostrando que, nesta rodada, o cliente podia funcionar por essa entrada.

Ainda assim, o canal durable/app-server com erro nos registros do aplicativo para computador precisa ser analisado separadamente. A documentação da OpenAI também lista solicitações e eventos SSE e WebSocket em categorias de monitoramento distintas; não combine o sucesso e a falha de canais diferentes em uma conclusão de que “a rede do Codex está normal”.Categorias de eventos de telemetria de conexão do Codex

Se o navegador funciona, mas o tráfego correspondente do Codex não aparece no proxy esperado, corrija primeiro o caminho dessa solicitação. Trocar de nó repetidamente pode não alterar em nada a conexão que está falhando.

O que verificar primeiro quando o Codex informa tls handshake eof?

tls handshake eof indica que a conexão terminou prematuramente durante o handshake TLS. Isso não é sinônimo de “o WebSocket foi estabelecido normalmente e depois expirou por inatividade”. Primeiro confirme se o HTTPS comum funciona pelo mesmo proxy; depois investigue a conexão persistente do aplicativo.

Verifique o HTTPS comum pelo mesmo proxy

Teste um endereço HTTPS simples pela rede atual do sistema e por um proxy local especificado explicitamente. Use a porta do cliente que está realmente em execução; testar o mesmo endereço no navegador ainda não confirma o caminho usado pelo Codex.

Os comandos abaixo usam uma porta substituível. 7897 é apenas um exemplo: troque pela porta HTTP ou mixed atual do Clash. Neste experimento, usamos uma porta temporária atribuída pelo script.

# 不显式使用 HTTP 代理，沿当前系统路由访问。
# 如果开着 TUN 或 Tailscale，这不等于绕过它们。
curl --noproxy '*' --connect-timeout 10 --max-time 25 \
  -o /dev/null -sS -w 'HTTP=%{http_code} total=%{time_total}s\n' \
  https://www.google.com/generate_204

# 明确经过本地 HTTP/mixed 代理入口。
curl --proxy http://127.0.0.1:7897 --noproxy '' \
  --connect-timeout 10 --max-time 25 \
  -o /dev/null -sS -w 'HTTP=%{http_code} total=%{time_total}s\n' \
  https://www.google.com/generate_204

Se primeiro aparecer um erro de conexão com a porta local, confirme que o Clash está em execução e que a porta está correta; isso ainda não testou o nó remoto. Se falhar somente ao chegar à etapa TLS, verifique o nó e o encaminhamento ao destino. Mesmo que os dois comandos funcionem, isso comprova apenas HTTPS de curta duração; ainda será preciso testar o Codex.

Nesta rodada, cada destino e caminho foi testado três vezes:

Destino do teste	Caminho Tailscale	Caminho do proxy isolado com nó salvo
Google generate_204	HTTP 204 nas três tentativas	curl 35 nas três, sem resposta HTTP
Página inicial do ChatGPT	HTTP 403 nas três tentativas	curl 35 nas três, sem resposta HTTP
GET sem autenticação ao endereço responses do Codex	HTTP 405 nas três tentativas	curl 35 nas três, sem resposta HTTP

curl 35 é um erro de conexão SSL/TLS; nesta rodada, a mensagem foi SSL_ERROR_SYSCALL.Descrição dos códigos de erro do curl

As respostas 403 e 405 não comprovam que as funções do ChatGPT ou do Codex estão operacionais; apenas mostram que a sonda recebeu uma resposta HTTP. Um GET sem autenticação também não substitui uma chamada legítima ao modelo. A validação real do aplicativo é a solicitação da seção anterior que retornou a marca fixa.

Mesmo assim, o fato de o caminho do proxy também falhar no HTTPS do Google é suficiente para mudar a ordem do diagnóstico: primeiro restaure o encaminhamento HTTPS geral, em vez de atribuir o problema diretamente ao WebSocket do Codex.

Um nó acessível não significa que ele consiga conectar você à OpenAI

Se a entrada do proxy está acessível, verifique em seguida a autenticação, a compatibilidade do protocolo e o encaminhamento ao destino.

Nesta rodada, contornamos o cliente proxy e vinculamos um socket nativo à placa de rede física para conectar às quatro entradas IPv4 resolvidas do nó. As quatro conexões TCP foram estabelecidas em cerca de 4–7 ms; os handshakes TLS com validação de certificado também foram concluídos, com duração total de aproximadamente 248–553 ms.

Isso comprova apenas que a entrada está acessível. O caminho do proxy ainda inclui etapas posteriores:

本机 → 代理入口 TCP/TLS → 认证、协议处理与转发 → 目标服务

O sucesso do TLS na entrada e o sucesso do TLS ao acessar o site de destino pelo proxy são verificações diferentes. O primeiro não comprova que a autenticação AnyTLS funciona nem que o nó consegue acessar o Google ou a OpenAI.

Nesta rodada, fixar o domínio do nó em um dos IPs resolvidos não fez o HTTPS do Google funcionar. Em contrapartida, a mesma implementação da entrada HTTP CONNECT local conseguiu obter Google 204 quando foi alterada para DIRECT e saiu pelo Tailscale. Essas comparações direcionam a investigação para compatibilidade entre o protocolo do nó e o cliente, autenticação e estado do encaminhamento, além dos registros de saída do servidor; ainda não são suficientes para escolher uma única causa raiz.

Se você obtiver o mesmo resultado, o próximo passo é coletar os erros dessas etapas, não encerrar o diagnóstico porque “o ping está baixo” ou “a porta do servidor conecta”.

É preciso desativar WebSocket quando o Codex não para de reconectar?

Separe duas coisas: o WebSocket usado pelo aplicativo Codex e o protocolo de transporte usado pelo nó proxy.

O nó selecionado e salvo nesta rodada era AnyTLS, e não um nó VLESS/WS da configuração. Portanto, a hipótese “este nó usa WS e por isso o Codex está lento” não corresponde ao tipo de nó salvo. Mesmo assim, o próprio WebSocket do Codex ainda pode falhar ao passar por ele.

A necessidade de investigar WebSocket depende da etapa alcançada pela conexão:

Evidência disponível	Prioridade do diagnóstico
HTTPS comum também não completa o handshake TLS	Primeiro corrija o estabelecimento e o encaminhamento do proxy
HTTPS comum funciona, mas o handshake WS falha	Verifique o handshake dessa conexão, o caminho do proxy e a política de acesso
WS foi estabelecido e cai durante o uso ou após ficar ocioso	Registre o momento da queda e verifique a manutenção da conexão e os pontos intermediários

Nesta rodada, uma conexão persistente foi validada usando o serviço público WSS Echo do Postman: pelo Tailscale, trocamos cinco mensagens, desativamos o ping periódico iniciado pelo cliente de teste, deixamos a conexão ociosa por 90 segundos e então trocamos mais cinco mensagens. Os dez ecos corresponderam. Desativar o ping do cliente não significa eliminar o keepalive TCP nem possíveis frames enviados pelo servidor.Informações sobre o Postman Echo

Outro teste de controle HTTP CONNECT/DIRECT também completou o handshake WSS e o eco. Ele mostra que essa entrada local do proxy conseguia transportar WSS, mas não permite generalizar para todos os nós proxy; o Echo público também não substitui o endpoint específico do Codex.

Nos registros históricos do aplicativo para computador, foram encontrados explicitamente 10 eventos websocket_error e 15 eventos reconnect_started, relacionados ao canal durable. São registros de eventos, não 25 falhas independentes; o mesmo erro pode aparecer em várias linhas de estado.

O código de fechamento 1006 também indica apenas um fechamento anormal; sozinho, não permite identificar quem interrompeu a conexão.Definição do código de fechamento anormal no RFC do WebSocket

Por isso, quando aparecer Reconnecting, não aplique diretamente uma configuração para “desativar WS”. Nesta rodada, a falha já acontecia durante TLS, e não há evidência de que alterar o tempo limite de inatividade do WebSocket seja a correção correspondente.

O Tailscale pode resolver a lentidão do Codex?

Nos pedidos curtos testados neste Mac, o Tailscale foi um caminho comprovadamente funcional; isso não garante que seja mais rápido em geral. Três chamadas reais do Codex e um teste de eco após 90 segundos ocioso sustentam melhor a decisão atual de continuar usando-o do que um teste de velocidade isolado.

O Tailscale usa WireGuard: quando consegue uma conexão direta, transmite por UDP; caso contrário, pode usar um relay. O WebSocket do Codex pode funcionar dentro do túnel; mudar para Tailscale não equivale a desativar WebSocket.Tipos de conexão do Tailscale

Nas 20 sondas de descoberta do Tailscale desta rodada, 17 tiveram sucesso e 3 expiraram; a mediana do RTT das amostras bem-sucedidas foi de 188 ms. Isso não representa diretamente a taxa de perda de pacotes do tráfego de produção em longo prazo, mas mostra que “funciona” não significa “sem latência ou anomalias”.

Da mesma forma, dig não comprova congestionamento na rede backbone 163. As três consultas A ao domínio do ChatGPT foram concluídas em 185–233 ms; elas medem consultas DNS e não substituem TCP, TLS ou solicitações reais do aplicativo. Nesta rodada, não obtivemos evidências de caminho suficientes para confirmar congestionamento na backbone 163.

Se o Codex voltar a funcionar após trocar a saída, é possível confirmar que “a mudança de caminho alterou o resultado”. Para atribuí-lo também a uma operadora específica, à carga de um nó compartilhado ou ao protocolo proxy, são necessárias evidências que sustentem essa conclusão.

Como confirmar que o Codex se recuperou, e não apenas que a página abriu?

Valide no cliente em que o problema aconteceu, em vez de apenas voltar ao navegador e atualizar a página inicial.

1. Envie uma solicitação curta sem ferramentas. Mantenha o mesmo modelo e nível de raciocínio e confirme que a resposta chega completa, para não misturar o tempo de execução das ferramentas ao teste de conexão.
2. Confira a regra do proxy, a saída e os registros de erro da solicitação correspondente. Verifique se ainda há reconexões; configurar um proxy não comprova que a solicitação passou por ele.
3. Depois teste o fluxo de trabalho que falhava originalmente. O sucesso de uma solicitação curta não substitui a validação de tarefas longas, retomada após inatividade ou canal de segundo plano do aplicativo. Nesta rodada, apenas uma solicitação curta ao modelo foi concluída; não foi comprovada a recuperação de fluxos longos.

No aplicativo para computador, envie: “Não leia arquivos nem use ferramentas; responda apenas NETWORK_PROBE_OK”. Usuários da CLI podem usar o exemplo abaixo; ele realmente chama o modelo e não é uma verificação offline:

codex exec --ephemeral --skip-git-repo-check --sandbox read-only \
  '不要读取文件或调用工具，只回复 NETWORK_PROBE_OK'

Valide com a versão e as configurações que apresentaram o problema e registre erros e conclusão. Não declare o aplicativo para computador recuperado só porque outra CLI respondeu.

Se o cliente informar claramente que o modelo precisa de uma versão mais recente, resolva primeiro a compatibilidade de versão. Isso aconteceu no primeiro teste desta rodada: a CLI independente 0.151.0 retornou HTTP 400; depois, repetimos o teste com 0.164.0-alpha.11.1, incluído no aplicativo. O primeiro resultado não foi contado como falha de rede.

Diante do resultado atual, a escolha prática é continuar usando o Tailscale, que concluiu chamadas reais; ao investigar este proxy, primeiro restaure o HTTPS comum e depois valide a conexão específica do Codex. Para explicar o problema anterior de “a web funciona, só o Codex fica lento”, ainda é necessário registrar conexão e saída simultaneamente quando as condições se repetirem.

Escopo dos testes: Os dados deste artigo vêm de testes locais em um Mac na madrugada de 27 de outubro de 2026. O experimento do proxy leu os parâmetros do nó AnyTLS salvo e o reconstruiu em um processo mihomo independente; não iniciou a interface/TUN original do Clash e não alterou o proxy do sistema nem a saída do Tailscale. Embora a vinculação à placa física estivesse configurada, o nettop não capturou uma interface upstream verificável para esse processo AnyTLS; portanto, não é possível afirmar que os dois caminhos físicos completos foram verificados de maneira totalmente independente. Os resultados da CLI, do canal durable do aplicativo e do Echo público foram registrados separadamente; os dados originais, scripts e condições detalhadas estão nos materiais do experimento associado.