AIREITEREncontrou a mensagem upstream connect error or disconnect/reset before headers no ChatGPT ou na API da OpenAI? O problema está do lado da OpenAI. O aviso vem do Envoy, o proxy na borda da infraestrutura da empresa, e indica que ele não conseguiu obter uma resposta utilizável do backend da OpenAI. No site do ChatGPT, esse caso costuma aparecer como Error Code 111. O trecho após reset reason: traz o diagnóstico de fato; já before headers quer dizer que o proxy desistiu antes de receber sequer um cabeçalho de resposta. Ou seja: não há uma resposta real por trás desse 503, apenas a resposta gerada pelo próprio Envoy. Você não tem como corrigir a infraestrutura da OpenAI, mas a próxima ação depende do motivo do reset e de onde o erro aconteceu: navegador ou código.
Veja qual é o seu caso:
- ChatGPT na web ou no app: consulte status.openai.com e, em seguida, recarregue a página ou inicie uma nova sessão.
- API da OpenAI no código: identifique o motivo do reset, registre o ID da requisição e aplique uma política de retry.
O que esse erro quer dizer na prática
O Envoy fica entre você e o backend da OpenAI. Quando sua requisição chega, ele abre uma conexão com o backend, encaminha a solicitação e aguarda os cabeçalhos da resposta. Se essa conexão falhar, for resetada, expirar ou atingir um limite de capacidade antes de qualquer cabeçalho retornar, o Envoy exibe essa mensagem com HTTP 503 — em alguns casos, 502. Ela pode aparecer nas telas de indisponibilidade do ChatGPT, em rastreamentos de pilha de openai.InternalServerError e em logs de agentes.
A redação pode mudar: quando aparece retried and the latest reset reason, significa que o Envoy já tentou novamente e que a falha mostrada ocorreu na última tentativa. Em qualquer cenário, é o proxy da OpenAI informando que o próprio backend não respondeu — não é um problema no seu prompt nem no corpo da requisição.
Como interpretar o motivo do reset
O motivo do reset mostra o que o proxy da OpenAI encontrou e ajuda a decidir se vale tentar de novo.
| motivo do reset | O que o proxy da OpenAI encontrou | O que fazer |
|---|---|---|
connection timeout | O backend demorou demais para aceitar a conexão | Tente novamente com backoff e consulte o status |
overflow | Foi atingido um limite de capacidade ou taxa, com o backend sobrecarregado | Reduza a concorrência, aplique backoff e tente novamente |
connection failure / remote connection failure | O backend estava inacessível ou recusou a conexão | Tente novamente; se persistir, consulte o status e reporte o problema |
connection termination / connection reset | O backend encerrou a conexão durante a requisição | Tente novamente; em geral, isso coincide com um incidente |
protocol error | Houve um problema de protocolo do lado da OpenAI | Tente novamente; se persistir, reporte incluindo o ID da requisição |
overflow e connection timeout são os dois casos mais recorrentes nos relatos da comunidade da OpenAI, algo compatível com um backend chegando ao limite de capacidade sob carga irregular. Nenhum deles é resolvido por alguma configuração na sua máquina: as medidas úteis são verificar o status, usar backoff e recorrer a failover.
No site ou app do ChatGPT: Error Code 111
Comece por status.openai.com. Se houver um incidente publicado, esperar a normalização é a principal solução, embora uma falha persistente e exclusiva da sua conta mereça ser reportada ao suporte. Se o status estiver normal, recarregue a página, abra uma nova aba ou saia e entre novamente — uma sessão desatualizada pode manter uma conexão morta. Trocar de rede ou desativar uma VPN ou proxy corporativo só ajuda quando essa camada é a responsável por resetar a conexão; portanto, vale testar antes de concluir que a origem é a OpenAI.
Como tratar o erro na API da OpenAI
Nesse contexto, trata-se de uma falha intermitente e dependente de carga. Um desenvolvedor no rastreador de issues do openai-python relatou que cerca de 5% das chamadas falhavam com openai.InternalServerError: upstream connect error or disconnect/reset before headers ao fazer centenas de requisições por hora — os outros 95% eram bem-sucedidos. Uma taxa parcial de falhas assim aponta para saturação do backend, e tarefas intensivas em lote, como embeddings em massa e ingestão de documentos grandes, tendem a esbarrar nisso mais facilmente porque elevam a concorrência. Em geral, a solução é uma política de retry, não uma alteração no payload; ainda assim, controlar a concorrência e enfileirar trabalhos em lote é igualmente importante sob carga alta.
Antes de escalar o problema, registre informações suficientes para demonstrar que a falha está no provedor: data e hora, endpoint e modelo, status e corpo HTTP, x-request-id, versão do SDK, número de requisições em andamento e se as falhas coincidem com um incidente publicado. Depois, implemente uma política de retry adequada para produção:
import random, time
from openai import OpenAI, APIStatusError, APIConnectionError
client = OpenAI()
def with_retry(fn, max_attempts=5, cap=30.0):
for attempt in range(max_attempts):
try:
return fn()
except (APIConnectionError, APIStatusError) as e:
status = getattr(e, "status_code", None)
# retry connection drops and 5xx (incl. this 503); never blindly retry 4xx
if isinstance(e, APIStatusError) and status and status < 500 and status != 429:
raise
if attempt == max_attempts - 1:
raise
retry_after = float(getattr(e, "response", None).headers.get("retry-after", 0)) if getattr(e, "response", None) else 0
backoff = retry_after or min(cap, 0.5 * 2 ** attempt) * (0.5 + random.random())
time.sleep(backoff)Os SDKs da OpenAI já fazem retry automático para erros transitórios, usando max_retries com padrão 2. Por isso, defina esse comportamento deliberadamente — por exemplo, OpenAI(max_retries=0) — antes de envolver as chamadas na sua própria camada, ou os retries do SDK e os seus serão acumulados. Limite o total de tentativas, entre 3 e 5, e a concorrência geral para que os retries não ampliem o pico que causou o overflow. Trate 429 conforme o Retry-After; repita 408/409 apenas quando a operação puder ser executada novamente com segurança. Tenha cuidado com chamadas não idempotentes ou de streaming: um retry cego pode duplicar trabalho ou reproduzir um stream parcialmente consumido.
Como o problema aparece para o cliente
Muitas vezes, você nem chega a ver o corpo 503 do Envoy — a conexão morre antes. Um curl -v para um endpoint indisponível retorna curl: (52) Empty reply from server após Request completely sent off: a requisição saiu, mas nada voltou. Na versão exposta pelo próprio Envoy, o erro vem como um 503 cujo corpo contém o texto upstream connect error.... Os relatos públicos batem com isso: no subreddit da OpenAI, um usuário publicou a string exata retried and the latest reset reason: connection timeout junto de "Network connection lost", enquanto o rastreador do openai-python registra a mesma mensagem como um InternalServerError sob alto volume de requisições.
Quando faz sentido usar uma rota alternativa
Como a falha ocorre entre o gateway da OpenAI e o backend, retry e backoff são tudo o que você pode fazer ao usar um único endpoint. A outra opção é redundância: passar por uma camada que faça failover para outro backend quando um upstream expirar ou sofrer overflow. Gateways multiprovedor como OpenRouter e AIReiter ficam à frente de vários provedores de modelos e desviam de um provedor lento, seguindo o mesmo modelo de roteamento multiprovedor no qual o OpenRouter se baseia. Assim, a lentidão de um único upstream pode virar um redirecionamento em vez de um 503 exposto ao cliente. A contrapartida é real: há um salto adicional, dependência da disponibilidade do próprio roteador e diferenças de preço, tratamento de dados e observabilidade a considerar. Ainda assim, isso reduz a exposição à instabilidade de um único provedor.
Perguntas frequentes
O que é o ChatGPT Error Code 111?
Alguns usuários do ChatGPT relatam ver essa mensagem acompanhada do rótulo "Error Code 111". Ela indica que o proxy da OpenAI não conseguiu obter uma resposta do backend, ou seja, é uma falha no servidor. Consulte status.openai.com e recarregue a página.
Por que o erro só aparece sob carga ou de forma aleatória?
Falhas dependentes de carga geralmente indicam overflow, um limite de capacidade ou taxa, ou saturação do backend elevando o tempo de conexão além do timeout. Ambos aparecem quando a concorrência aumenta, por isso o mesmo código funciona na maior parte do tempo.
Uma VPN ou firewall pode causar isso?
Somente se essa camada estiver resetando a conexão entre você e a OpenAI. Vale eliminar essa possibilidade trocando de rede, mas isso não resolve uma indisponibilidade real da OpenAI nem um 503 do lado da API.
Isso é o mesmo que um erro 429 de limite de taxa?
Não. Um 429 é uma resposta explícita de limite de taxa que você recebeu. Este 503 indica que nenhuma resposta utilizável retornou. Respeite o Retry-After em um 429; no 503, aplique backoff e tente novamente.
O que significa "retried and the latest reset reason"?
O Envoy já tentou repetir a requisição, e esse é o motivo da falha na tentativa final. Isso aponta para um problema persistente no backend da OpenAI, não para uma oscilação pontual.