ERR_EMPTY_RESPONSE: causas y soluciones

Qué significa ERR_EMPTY_RESPONSE

Este error ocurre más tarde en el ciclo de vida de la petición que una conexión rechazada o con el tiempo agotado. El navegador se conecta correctamente al servidor, y en una petición HTTPS el handshake TLS normalmente también se completa, pero después de enviar la petición, la conexión se cierra sin ninguna línea de estado HTTP, sin cabeceras, y sin cuerpo alguno. Eso es distinto de una página de error 500 o 502, que sigue siendo una respuesta HTTP completa; aquí no hay nada que interpretar porque no volvió nada.

Esto hace que ERR_EMPTY_RESPONSE sea más difícil de diagnosticar desde el lado del cliente que la mayoría de los errores de conexión, ya que cada capa hasta la conexión de transporte, inclusive, funcionó correctamente. El fallo está específicamente en lo que sea que genera la respuesta HTTP: el proceso de la aplicación, el framework que gestiona la petición, o un proxy delante de él que cerró el socket en lugar de retransmitir, o generar, una página de error correcta.

Cómo aparece el error

Chrome muestra "This site can't be reached ... ERR_EMPTY_RESPONSE" en cuanto la conexión se cierra sin datos. curl reporta la misma condición en términos claros:

curl -v https://example.com/api/generate
* Connected to example.com (203.0.113.10) port 443
> GET /api/generate HTTP/1.1
> Host: example.com
*
* Empty reply from server
curl: (52) Empty reply from server

"Empty reply from server" es el texto exacto de curl para esta condición, y es la señal más clara de que la propia conexión funcionó mientras que lo que debía generar una respuesta no lo hizo.

Qué causa ERR_EMPTY_RESPONSE

• Un proceso worker se cayó mientras gestionaba la petición. Una excepción sin gestionar, un cierre por falta de memoria, o un fallo de segmentación pueden cerrar la conexión antes de que se escriba ninguna respuesta.
• La aplicación agotó su tiempo de espera detrás de un proxy que cierra en silencio. Algunas configuraciones de proxy inverso cierran la conexión del cliente sin enviar una página de error cuando el backend tarda demasiado, en lugar de devolver un 502 o un 504 correctos.
• Se sirve HTTP plano en el puerto HTTPS, o al revés. Un cliente que habla TLS con un puerto que sirve HTTP plano, o al revés, no obtiene ninguna respuesta válida que la capa de protocolo del cliente pueda interpretar, y a menudo se manifiesta como una respuesta vacía en lugar de un error de protocolo claro.
• Una extensión del navegador o un proxy local interfieren con la respuesta. Los bloqueadores de anuncios, las extensiones de privacidad, o un proxy corporativo que inspecciona y ocasionalmente gestiona mal una respuesta pueden dejarla reducida a nada.
• Una comprobación de salud de un balanceador de carga marca el backend como no sano a mitad de la petición, cerrando la conexión con ese backend antes de que termine la respuesta.

Cómo saber de quién es la culpa

Desactiva las extensiones del navegador o prueba primero una ventana de incógnito; una extensión del lado del cliente es una de las causas más habituales y fáciles de descartar. Si la respuesta vacía persiste con las extensiones desactivadas, prueba desde un segundo dispositivo o red para descartar un proxy local. Si ocurre de forma constante desde varias ubicaciones externas, la causa es el servidor o una caída de la aplicación. Ejecutar una comprobación HTTP desde varios puntos de control a la vez confirma si la respuesta vacía es general o está ligada a un cliente, una extensión, o una red concretos.

Cómo corregir ERR_EMPTY_RESPONSE

Si eres el visitante

1. Prueba una ventana de incógnito o privada con las extensiones desactivadas para descartar un bloqueador de anuncios o una extensión de privacidad interfiriendo con la respuesta.
2. Desactiva cualquier proxy o VPN local y vuelve a intentarlo, ya que algunos interceptan y ocasionalmente gestionan mal las respuestas en lugar de dejarlas pasar.
3. Borra la caché del navegador para el sitio; un estado de conexión en caché y corrupto puede reaparecer ocasionalmente como este error al reintentar.
4. Espera y recarga. Si la causa es un proceso worker caído en el servidor, un supervisor de procesos normalmente lo reinicia en cuestión de segundos.

Si administras el sitio

1. Revisa los registros de la aplicación en busca de una caída en la misma marca de tiempo que la petición fallida; una excepción sin gestionar o un cierre por falta de memoria es la causa más habitual y normalmente deja un rastro claro.
2. Confirma que el protocolo correcto está enlazado a cada puerto. Verifica que el puerto 443 realmente sirve TLS y el puerto 80 sirve HTTP plano, no al revés, con una comprobación directa:

   curl -v https://example.com:443/
   curl -v http://example.com:80/

3. Revisa el comportamiento de tiempo de espera del proxy inverso. En nginx, un backend que supera proxy_read_timeout debería devolver igualmente un 504, así que una respuesta vacía en lugar de una página de error correcta suele significar que algo está cerrando la conexión más abajo en la pila.
4. Revisa los registros del balanceador de carga y de las comprobaciones de salud en busca de un backend marcado como no sano en el momento del fallo, lo que puede cerrar conexiones en curso hacia esa instancia.
5. Reinicia el worker o servicio afectado si se confirma una caída, y vigila de cerca los registros después del reinicio por si se repite el mismo error.

Cómo prevenir ERR_EMPTY_RESPONSE

Una caída de un worker bajo condiciones concretas, como un cuerpo de petición particular o un pico de memoria, puede ser lo bastante intermitente como para pasar una prueba manual mientras sigue fallando de forma periódica para visitantes reales. La monitorización continua de HTTP que comprueba el código de estado y el cuerpo de la respuesta a intervalos regulares desde más de 300 puntos de control en 158 ciudades detecta un patrón de respuestas vacías que una única comprobación manual probablemente pasaría por alto, con alertas por correo, SMS, llamada de voz, Slack, Telegram y más.

Errores relacionados

• ERR_CONNECTION_RESET también termina antes de tiempo una conexión que funcionaba, pero con un reset explícito en lugar de un cierre silencioso.
• 502 Bad Gateway es una respuesta de error HTTP correcta de un proxy, a diferencia de la respuesta vacía que describe este error.
• This site can't be reached cubre todo el conjunto de errores de conexión que Chrome agrupa bajo un único título.

Preguntas frecuentes

¿ERR_EMPTY_RESPONSE es lo mismo que un error 502?

No. Un 502 es una respuesta HTTP completa con línea de estado, cabeceras, y normalmente un cuerpo, enviada deliberadamente por un proxy. ERR_EMPTY_RESPONSE significa que no se envió ninguna respuesta HTTP en absoluto, solo una conexión cerrada.

¿Por qué ocurre esto solo en una página concreta?

Una página que dispara este error de forma constante, mientras otras cargan bien, suele apuntar a una caída en la ruta de código que usa esa página o endpoint de API concretos, en lugar de a un problema general de servidor o de red.

¿Puede un bloqueador de anuncios causar de verdad este error?

Sí. Algunos bloqueadores de anuncios y extensiones de privacidad interceptan y reescriben respuestas, y un fallo o una regla agresiva pueden ocasionalmente dejar una respuesta legítima reducida a nada en lugar de bloquearla limpiamente.

¿ERR_EMPTY_RESPONSE significa que se perdieron mis datos?

No necesariamente para una petición GET, pero para el envío de un formulario o una llamada a una API que cambia datos, comprueba si la acción realmente se completó en el servidor antes de reintentar, ya que el cliente no puede saber por una respuesta vacía si la petición se procesó.

¿Por qué curl dice "Empty reply from server" en lugar de un código de error?

Porque no hay ninguna respuesta HTTP de la que leer un código de estado. El propio texto de curl describe el evento a nivel de transporte, una conexión cerrada sin datos, que está una capa por debajo del propio protocolo HTTP.

¿Podría estar cerrando la conexión mi propia red en lugar del servidor?

Es menos habitual que una causa del lado del servidor, pero ocurre. Un proxy corporativo o un firewall que termina conexiones de larga duración tras un periodo de inactividad fijo puede producir el mismo síntoma; probar la misma petición desde otra red lo descarta rápidamente.