Se você estiver vendo upstream connect error or disconnect/reset before headers no ChatGPT ou na OpenAI API, o problema é do lado da OpenAI. A mensagem vem do Envoy, o proxy na borda da OpenAI, e significa que o Envoy não conseguiu obter uma resposta utilizável do backend da OpenAI. No site do ChatGPT, isso geralmente é rotulado como *Error Code 111*. O texto após reset reason: é o diagnóstico real, e before headers significa que o proxy desistiu antes que chegasse um único cabeçalho de resposta — então não há uma resposta real por trás desse 503, apenas a do próprio Envoy. Você não pode consertar a infraestrutura da OpenAI, mas o que fazer a seguir depende do motivo do reset e de você ter encontrado isso no navegador ou no código.
Qual caminho você está seguindo:
- ChatGPT web/app: verifique status.openai.com, depois recarregue ou inicie uma nova sessão.
- OpenAI API in code: leia o motivo da redefinição, capture o ID da solicitação e, em seguida, aplique uma política de repetição.
O que o erro realmente significa
Envoy fica entre você e o backend da OpenAI. Quando sua solicitação chega, o Envoy abre uma conexão com o backend, encaminha a solicitação e aguarda os cabeçalhos da resposta. Se essa conexão falhar, for redefinida, expirar ou atingir um limite de capacidade antes que qualquer cabeçalho seja retornado, o Envoy devolve esta mensagem com um HTTP 503 (às vezes 502). Ela aparece nas telas de indisponibilidade do ChatGPT, em stack traces de openai.InternalServerError e nos logs de agentes.
A redação varia: a expressão retried and the latest reset reason significa que o Envoy já havia tentado novamente e este foi o erro da tentativa final. De qualquer forma, é o proxy da OpenAI informando que o próprio backend não respondeu — não é um problema com o seu prompt nem com o corpo da sua solicitação.
Decodifique o motivo da redefinição
O motivo da redefinição informa o que o proxy da OpenAI encontrou e, portanto, se vale a pena tentar novamente.
| motivo da redefinição | O que o proxy da OpenAI encontrou | O que você pode fazer |
|---|---|---|
connection timeout | O backend demorou demais para aceitar a conexão a tempo | Tente novamente com backoff; verifique o status |
overflow | Um limite de capacidade ou de taxa foi atingido (backend sobrecarregado) | Reduza a concorrência, faça backoff e tente novamente |
connection failure / remote connection failure | Backend inacessível ou recusou a conexão | Tente novamente; se persistir, verifique o status e relate |
connection termination / connection reset | O backend fechou a conexão no meio da solicitação | Tente novamente; geralmente isso coincide com um incidente |
protocol error | Um problema de protocolo do lado da OpenAI | Tente novamente; relate com o seu request ID se persistir |
overflow e connection timeout são os dois que aparecem com mais frequência nos relatos da comunidade OpenAI, o que é compatível com um backend atingindo a capacidade sob carga em picos. Nenhum deles é corrigido por algo na sua máquina — as respostas úteis são verificar o status, aplicar backoff e fazer failover.
No site ou aplicativo do ChatGPT (Código de erro 111)
Verifique primeiro status.openai.com. Se houver um incidente publicado, esperar é a principal solução, embora uma falha persistente específica da conta valha a pena ser relatada ao suporte. Se o status estiver verde, recarregue a página, abra uma nova aba ou saia e entre novamente — uma sessão desatualizada pode manter uma conexão inativa. Trocar de rede ou desativar uma VPN ou proxy corporativo só ajuda se essa camada for o que estiver redefinindo a conexão, então tente isso antes de assumir que o problema é da OpenAI.
A partir da API da OpenAI no código
Aqui o erro é intermitente e depende da carga. Um desenvolvedor no openai-python issue tracker relatou que cerca de 5% das chamadas falhavam com openai.InternalServerError: upstream connect error or disconnect/reset before headers ao fazer centenas de solicitações por hora — os outros 95% eram bem-sucedidos. Uma taxa de falha parcial como essa aponta para saturação do backend, e tarefas com muito volume em lote (embeddings em massa, ingestão de grandes documentos) sofrem mais com isso porque elevam a concorrência. A correção normalmente é uma política de retentativas, em vez de uma alteração na carga útil, embora ajustar a concorrência e enfileirar trabalhos em lote seja tão importante quanto em alta carga.
Antes de escalar, capture informações suficientes para provar que é do lado do provedor: o timestamp, o endpoint e o model, o status HTTP e o body, o x-request-id, a versão do seu SDK, a contagem de requisições em andamento e se as falhas coincidem com um incidente publicado. Em seguida, aplique uma política de retry que funcione bem em 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)
# tente novamente em quedas de conexão e 5xx (incluindo este 503); nunca tente novamente cegamente em 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á repetem automaticamente erros transitórios por conta própria (max_retries, padrão 2), então defina isso de forma deliberada — por exemplo OpenAI(max_retries=0) — antes de encapsular as chamadas, ou sua camada e a do SDK ficarão sobrepostas. Limite o total de tentativas (3–5) e a concorrência geral para que as tentativas não amplifiquem o pico que causou o overflow. Trate 429 pelo seu Retry-After; tente novamente 408/409 apenas quando a operação for segura para repetir. Tenha cuidado com chamadas não idempotentes ou de streaming — uma repetição cega pode duplicar trabalho ou reproduzir um stream consumido parcialmente.
Como isso parece do lado do cliente
Você muitas vezes nem chega a ver o corpo do 503 do Envoy — a conexão cai primeiro. Um curl -v em um endpoint inativo retorna curl: (52) Empty reply from server após Request completely sent off: a requisição saiu, nada voltou. A própria versão do erro no Envoy é um 503 que carrega o texto upstream connect error... como corpo. Os relatos públicos batem: no subreddit da OpenAI, um usuário publicou exatamente a string retried and the latest reset reason: connection timeout com "Network connection lost", e o rastreador do openai-python traz a mesma mensagem como um InternalServerError sob alto volume de requisições.
Quando contorná-lo
Como o salto com falha está entre o gateway da OpenAI e o backend dela, tentar novamente e fazer backoff é tudo o que você pode fazer contra um único endpoint. A outra alavanca é a redundância: roteie por uma camada que faça failover para um backend diferente quando um upstream expira por timeout ou transborda. Gateways multi-provider como OpenRouter e AIReiter ficam na frente de vários provedores de modelos e contornam um lento, usando o mesmo modelo de roteamento multi-provider sobre o qual o OpenRouter é construído, de modo que um único upstream ficando lento pode virar um redirecionamento em vez de um 503 exposto. A troca é real — um salto adicional, uma dependência da própria disponibilidade do roteador e diferenças em preços, tratamento de dados e observabilidade a considerar —, mas isso reduz a exposição à instabilidade de qualquer provedor específico.
Perguntas Frequentes
O que é o código de erro 111 do ChatGPT?
Alguns usuários do ChatGPT relatam ver esta mensagem junto com o rótulo "Error Code 111". Isso significa que o proxy da OpenAI não conseguiu obter uma resposta do seu backend — um problema do lado do servidor. Verifique status.openai.com e recarregue.
Por que eu só o recebo sob carga ou aleatoriamente?
Falhas dependentes de carga geralmente significam overflow (um limite de capacidade ou de taxa) ou saturação do backend empurrando os tempos de conexão além do timeout. Ambos aparecem apenas quando a concorrência aumenta, e é por isso que o mesmo código funciona na maior parte do tempo.
Uma VPN ou firewall causa isso?
Somente se essa camada for o que está redefinindo a conexão entre você e a OpenAI. Vale a pena descartar isso trocando de rede, mas isso não corrigirá uma indisponibilidade real da OpenAI nem um 503 do lado da API.
Isso é o mesmo que um erro de limite de taxa 429?
Não. Um 429 é uma resposta explícita de limite de taxa que você recebeu. Este 503 significa que nenhuma resposta utilizável retornou de todo. Respeite Retry-After em um 429; faça backoff e tente novamente no 503.
O que significa "retried and the latest reset reason"?
O Envoy já tentou novamente a solicitação, e é por isso que a tentativa final falhou. Isso aponta para um problema persistente no backend do lado da OpenAI, não para uma falha pontual.