Si estás viendo upstream connect error or disconnect/reset before headers en ChatGPT o desde la API de OpenAI, es del lado de OpenAI. El mensaje proviene de Envoy, el proxy en el borde de OpenAI, y significa que Envoy no pudo obtener una respuesta utilizable del backend de OpenAI. En el sitio web de ChatGPT esto suele etiquetarse como *Error Code 111*. El texto después de reset reason: es el diagnóstico real, y before headers significa que el proxy se rindió antes de que llegara un solo encabezado de respuesta, así que no hay una respuesta real detrás de ese 503, solo la de Envoy. No puedes arreglar la infraestructura de OpenAI, pero lo que hagas a continuación depende del motivo del reinicio y de si te ocurrió en el navegador o en código.
¿Qué camino estás siguiendo?
- ChatGPT web/app: consulta status.openai.com, luego recarga o inicia una nueva sesión.
- OpenAI API in code: lee el motivo del reinicio, captura el ID de la solicitud y luego aplica una política de reintento.
Lo que realmente significa el error
Envoy se sitúa entre usted y el backend de OpenAI. Cuando su solicitud llega, Envoy abre una conexión con el backend, reenvía la solicitud y espera los encabezados de respuesta. Si esa conexión falla, se reinicia, expira o supera un límite de capacidad antes de que se devuelvan los encabezados, Envoy devuelve este mensaje con un HTTP 503 (a veces 502). Aparece en las pantallas de caída de ChatGPT, en las trazas de pila de openai.InternalServerError y en los registros de agentes.
La redacción varía: la frase retried and the latest reset reason significa que Envoy ya reintentó y que este fue el fallo del último intento. En cualquier caso, es el proxy de OpenAI informando que su propio backend no respondió, no un problema con tu prompt ni con el cuerpo de tu solicitud.
Decodificar la razón del reinicio
La razón de reinicio te dice con qué se encontró el proxy de OpenAI y, por lo tanto, si vale la pena reintentar.
| motivo del reinicio | Lo que golpeó el proxy de OpenAI | Lo que puedes hacer |
|---|---|---|
connection timeout | El backend fue demasiado lento para aceptar la conexión a tiempo | Reintenta con backoff; revisa el estado |
overflow | Se alcanzó una capacidad o límite de tasa (backend sobrecargado) | Reduce la concurrencia, haz backoff y luego reintenta |
connection failure / remote connection failure | El backend no era accesible o rechazó la conexión | Reintenta; si persiste, revisa el estado e informa |
connection termination / connection reset | El backend cerró la conexión en mitad de la solicitud | Reintenta; normalmente coincide con un incidente |
protocol error | Un problema de protocolo del lado de OpenAI | Reintenta; informa con tu ID de solicitud si persiste |
overflow y connection timeout son los dos que aparecen con más frecuencia en los informes de la comunidad de OpenAI, lo que encaja con un backend que alcanza su capacidad bajo carga intermitente. Ninguno de estos se soluciona con nada en tu máquina — las respuestas útiles son comprobaciones de estado, retroceso y conmutación por error.
En el sitio web o la aplicación de ChatGPT (código de error 111)
Consulta primero status.openai.com. Si hay un incidente publicado, esperar a que se resuelva es la principal solución, aunque un fallo persistente específico de la cuenta merece informarse al soporte. Si el estado está en verde, recarga la página, abre una nueva pestaña o cierra sesión y vuelve a iniciarla; una sesión obsoleta puede mantener una conexión muerta. Cambiar de red o desactivar una VPN o un proxy corporativo solo ayuda si esa capa es la que está restableciendo la conexión, así que pruébalo antes de asumir que se trata de OpenAI.
Desde la API de OpenAI en código
Aquí el error es intermitente y depende de la carga. Un desarrollador en el openai-python issue tracker informó que aproximadamente el 5% de las llamadas fallaban con openai.InternalServerError: upstream connect error or disconnect/reset before headers al realizar cientos de solicitudes por hora — el otro 95% tuvo éxito. Una tasa de fallo parcial como esa apunta a saturación del backend, y los trabajos con mucha carga por lotes (embeddings masivos, ingesta de grandes documentos) lo encuentran con más frecuencia porque aumentan la concurrencia. La solución suele ser una política de reintento en lugar de un cambio en la carga útil, aunque dar forma a la concurrencia y poner en cola los trabajos por lotes importa tanto como eso bajo alta carga.
Antes de escalar, recopila suficiente información para demostrar que es un problema del lado del proveedor: la marca de tiempo, el endpoint y el modelo, el estado y el cuerpo HTTP, el x-request-id, tu versión de SDK, el recuento de solicitudes en curso y si los fallos coinciden con un incidente publicado. Luego aplica una política de reintentos que se mantenga en producción:
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)
# reintenta caídas de conexión y 5xx (incluido este 503); nunca reintentes ciegamente 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)Los SDK de OpenAI ya reintentan por sí mismos los errores transitorios (max_retries, valor predeterminado 2), así que configúralo deliberadamente — por ejemplo OpenAI(max_retries=0) — antes de envolver llamadas, o tu capa y la del SDK se acumularán. Limita el total de intentos (3–5) y la concurrencia global para que los reintentos no amplifiquen la ráfaga que causó el overflow. Maneja 429 según su Retry-After; reintenta 408/409 solo cuando la operación sea segura de repetir. Ten cuidado con llamadas no idempotentes o en streaming: un reintento ciego puede duplicar trabajo o reproducir un flujo consumido a medias.
Cómo se ve desde el lado del cliente
A menudo ni siquiera ves el cuerpo del 503 de Envoy — la conexión muere primero. Un curl -v contra un endpoint caído devuelve curl: (52) Empty reply from server después de Request completely sent off: la solicitud salió, no volvió nada. La propia versión del error en Envoy es un 503 que lleva el texto upstream connect error... como cuerpo. Los informes públicos coinciden: en el subreddit de OpenAI un usuario publicó la cadena exacta retried and the latest reset reason: connection timeout junto con "Network connection lost," y el rastreador de openai-python lleva el mismo mensaje como un InternalServerError bajo un alto volumen de solicitudes.
Cuándo evitarlo
Como el salto que falla es entre la pasarela de OpenAI y su backend, reintentar y hacer backoff es todo lo que puedes hacer contra un único endpoint. La otra palanca es la redundancia: enruta a través de una capa que haga failover a un backend diferente cuando un upstream agota el tiempo de espera o se sobrecarga. Las pasarelas mult proveedor, como OpenRouter y AIReiter, ponen delante varios proveedores de modelos y rodean a uno lento, el mismo modelo de enrutamiento mult proveedor sobre el que está construido OpenRouter, así que un upstream único que se ralentiza puede convertirse en un reroute en lugar de un 503 expuesto. La compensación es real: un salto adicional, una dependencia del propio uptime del enrutador, y diferencias en precios, manejo de datos y observabilidad que hay que sopesar; pero reduce la exposición a la inestabilidad de un solo proveedor.
Preguntas frecuentes
¿Qué es el código de error 111 de ChatGPT?
Algunos usuarios de ChatGPT informan que ven este mensaje junto con la etiqueta "Error Code 111". Esto significa que el proxy de OpenAI no pudo obtener una respuesta de su backend — un problema del lado del servidor. Consulta status.openai.com y vuelve a cargar la página.
¿Por qué solo lo recibo bajo carga o al azar?
Los fallos dependientes de la carga suelen significar overflow (un límite de capacidad o de velocidad) o la saturación del backend, que hace que los tiempos de conexión superen el timeout. Ambos aparecen solo cuando aumenta la concurrencia, por eso el mismo código funciona la mayor parte del tiempo.
¿Lo causa una VPN o un firewall?
Solo si esa capa es la que está restableciendo la conexión entre tú y OpenAI. Vale la pena descartarlo cambiando de red, pero no solucionará una caída real de OpenAI ni un 503 del lado de la API.
¿Es esto lo mismo que un error de límite de tasa 429?
No. Un 429 es una respuesta explícita de límite de velocidad que recibió. Este 503 significa que no se recibió ninguna respuesta utilizable en absoluto. Respete Retry-After en un 429; reduzca la frecuencia e intente de nuevo en el 503.
¿Qué significa "reintentado y el motivo de restablecimiento más reciente"?
Envoy ya reintentó la solicitud, y por eso falló el intento final. Esto apunta a un problema persistente en el backend del lado de OpenAI, no a un fallo aislado.