Causas y soluciones del error «Se produjo un error durante la transmisión de mensajes» de ChatGPT

Prueba estos tres pasos durante los primeros 90 segundos

Regenera la respuesta → actualiza la página (si usas la aplicación, ciérrala por completo y vuelve a abrirla) → cierra sesión y vuelve a iniciarla. Una interrupción puntual suele resolverse con uno de estos tres pasos, y las interrupciones puntuales son lo normal. En cambio, si siempre se detiene en el mismo punto, es señal de una causa concreta de las descritas abajo, no de un fallo aleatorio.

Determina primero si el problema está de tu lado

Este es el paso que otros tutoriales suelen omitir, aunque es el que más tiempo ahorra. Abre status.openai.com. Si aparece una incidencia en curso, ninguna configuración local cambiará nada: esperar es la única solución. Si no hay ninguna incidencia, la causa está en el entorno local y el siguiente paso reducirá el alcance. Haz esta comprobación antes de cambiar la configuración para no pasar veinte minutos borrando la caché durante una incidencia oficial.

Reduce las causas locales capa por capa, desde fuera hacia dentro

Sigue este orden, porque cada capa descarta todas las posibilidades anteriores: ① desactiva la VPN y el proxy ② abre una ventana de incógnito (elimina de una vez extensiones y caché) ③ cambia de navegador o de dispositivo ④ cambia de red. La capa tras la cual se normalice el funcionamiento es la causa. Si el error solo aparece con conversaciones largas, ninguna de las cuatro capas es el problema: la solución es trasladar los puntos importantes a una conversación nueva.

Para desarrolladores: cómo se ve la misma interrupción en la API

Al llamar a la API con stream: true, el mismo fallo aparece como una conexión de Server-Sent Events que termina sin finish_reason. El código de estado HTTP es 200 — todo parece correcto cuando se envían los encabezados —, por lo que comprobar solo el código de estado no basta; con mucha carga también pueden aparecer 429 y 529 overloaded_error. Tres medidas lo hacen tolerable: (1) tratar una transmisión que termina sin finish_reason como reintentable, no como una respuesta completada; (2) aplicar reintentos con retroceso exponencial y jitter para 429, 500 y 529; (3) si hay un proxy intermedio, comprobar su idle timeout y desactivar el almacenamiento en búfer de respuestas: un proxy que almacena en búfer puede convertir una transmisión normal en una conexión que parece bloqueada durante mucho tiempo. Para aislar el problema, transmite primero sin pasar por el proxy:

# 直接串流、路徑上不放 Proxy，觀察它停在哪裡。
curl -N https://api.kunavo.com/v1/chat/completions \
  -H "Authorization: Bearer $KUNAVO_API_KEY" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","stream":true,
       "max_tokens":300,
       "messages":[{"role":"user","content":"請慢慢從 1 數到 20"}]}'

¿El «error de transmisión de mensajes» es culpa mía?

Casi nunca. Este mensaje indica que la conexión que transportaba la respuesta se interrumpió antes de completarse. El contenido que escribiste no lo provoca. Las causas son la carga de OpenAI, una red inestable, extensiones del navegador o una sesión no válida, o una conversación tan larga que provoca un tiempo de espera.

¿Qué hago si regenerar tampoco funciona?

Consulta primero status.openai.com: durante una incidencia oficial no servirá ningún ajuste local. Si no hay ninguna incidencia, abre una ventana de incógnito usando otra red: esta prueba descarta simultáneamente las extensiones, la caché y tu conexión habitual. Si funciona en incógnito, vuelve a añadir los elementos uno por uno hasta encontrar cuál provoca el fallo. Si falla en todas partes y solo ocurre en una conversación larga, traslada los puntos importantes a una conversación nueva.

¿Otros sistemas de IA también presentan el mismo error?

Esta expresión es propia de ChatGPT, pero cualquier asistente que responda mediante streaming puede interrumpirse de la misma manera. Claude muestra un mensaje que indica que no pudo generar completamente la respuesta; al llamar directamente a la API, se manifiesta como una transmisión SSE que termina sin finish_reason o, con mucha carga, como 529 overloaded_error.

¿Por qué ocurre más a menudo en conversaciones largas?

Cada turno vuelve a enviar toda la conversación, por lo que cuanto más larga es, más tiempo se genera contenido en la misma conexión abierta. Cuanto más tiempo permanece abierta la conexión, más oportunidades hay de que un tiempo de espera del proxy, un cambio de red o un fallo momentáneo del upstream la interrumpa. Normalmente es más eficaz iniciar una conversación nueva con un resumen que cambiar cualquier configuración del navegador.