ERR_EMPTY_RESPONSE: qué significa y cómo solucionarlo

¿Qué es ERR_EMPTY_RESPONSE?

ERR_EMPTY_RESPONSE es la página de error de Chrome y Edge que dice "Esta página no funciona. example.com no ha enviado ningún dato." (This page isn't working. example.com didn't send any data.) En Chromium es el error de red -324, definido así: "The server closed the connection without sending any data" (el servidor cerró la conexión sin enviar ningún dato).

El navegador llegó más lejos que con la mayoría de los errores de conexión. La dirección se resolvió, la conexión se abrió y el navegador envió su petición. Después, el servidor, o algo que tiene delante, cerró la conexión con una respuesta vacía: sin código de estado, sin cabeceras, sin página. El código de Chromium solo usa este error para una conexión nueva que se cierra con cero bytes. Cuando se cierra una conexión antigua reutilizada, Chrome reintenta sin avisar.

Como la petición sí llegó a entregarse, ERR_EMPTY_RESPONSE suele apuntar al lado del servidor: una aplicación que se bloqueó mientras atendía la petición, una regla que descarta conexiones a propósito o un servicio que aceptó la conexión pero no tenía nada detrás. Unas pocas causas en tu propio equipo también pueden provocarlo.

¿Qué causa ERR_EMPTY_RESPONSE?

Solución 1: recarga y prueba en modo incógnito

Si el servidor se reinició en mal momento, basta con recargar unos segundos después. Si el error se repite, abre la página en una ventana de incógnito (Ctrl + Shift + N; en Mac, Cmd + Shift + N). El modo incógnito empieza sin cookies y sin extensiones, así que te dice rápidamente si hay algo guardado en tu navegador implicado.

Después comprueba si el sitio está caído para todo el mundo. La herramienta Cabeceras HTTP de DNS Robot solicita la página desde nuestros servidores: si nosotros obtenemos una respuesta normal, el problema está entre tú y el sitio. Si nosotros tampoco recibimos nada, el que falla es el propio sitio.

Solución 2: desactiva la VPN, el proxy y el análisis HTTPS

Cualquier cosa que se sitúe en medio de tus conexiones puede aceptar la petición y luego cerrarla sin devolverte la respuesta:

• VPN: desconéctala por completo y recarga.

• Proxy: en Windows 11, Configuración → Red e Internet → Proxy → desactiva Usar un servidor proxy. En un Mac, Ajustes del Sistema → Red → tu conexión → Detalles… → Proxies.

• Análisis HTTPS del antivirus: desactiva solo la función de análisis web o HTTPS (suele llamarse análisis HTTPS, escudo web (Web Shield) o filtrado de protocolos SSL/TLS) y recarga. Si eso lo soluciona, añade una exclusión para el sitio y vuelve a activar el análisis.

Solución 3: borra los datos del sitio y desactiva las extensiones

Las cookies muy grandes o dañadas pueden hacer que un servidor descarte la petición en lugar de responder, lo que a menudo aparece como un error solo después de iniciar sesión. Borra las cookies de ese sitio: haz clic en el icono a la izquierda de la barra de direcciones → Cookies y datos de sitios (o Configuración del sitio) → elimina los datos y vuelve a iniciar sesión.

Después, desactiva todas las extensiones en chrome://extensions y recarga. Vuelve a activarlas de una en una para encontrar la que interfiere, que suele ser un bloqueador de anuncios, una herramienta de privacidad o cualquier cosa que edite las peticiones.

Solución 4: vacía la caché DNS y restablece la pila de red

Si todos los sitios dan respuestas vacías en un mismo equipo, restablece su configuración de red. En Windows, ejecuta los comandos de abajo en un Símbolo del sistema como administrador y reinicia. En un Mac, vacía la caché DNS y elimina la red Wi-Fi para volver a añadirla.

ipconfig /flushdns
netsh winsock reset
netsh int ip reset
ipconfig /release
ipconfig /renew

Prueba también con otra red, como los datos móviles de tu teléfono. Si el sitio funciona ahí, puede que un filtro de tu red habitual (la del centro de estudios, la del trabajo o la de tu proveedor de internet) esté cortando la conexión.

ERR_EMPTY_RESPONSE en localhost y Docker

Los desarrolladores ven este error sobre todo en su propia máquina. Estas son las causas habituales:

• La aplicación del contenedor Docker escucha en 127.0.0.1. Dentro de un contenedor, 127.0.0.1 significa "solo este contenedor", así que la redirección de puertos de Docker no tiene a qué conectarse y tu navegador recibe una respuesta vacía (o, según la configuración, un reset de la conexión). Haz que la aplicación escuche en 0.0.0.0 dentro del contenedor, por ejemplo con next dev -H 0.0.0.0, vite --host 0.0.0.0, flask run --host=0.0.0.0 o uvicorn main:app --host 0.0.0.0.

• El mapeo de puertos del contenedor no coincide. -p 8080:3000 redirige tu puerto 8080 al puerto 3000 dentro del contenedor. Si la aplicación escucha en realidad en el 5000, todas las peticiones vuelven vacías.

• http:// en un puerto que solo admite HTTPS. Algunos servidores esperan TLS en un puerto y simplemente cuelgan cuando llega HTTP sin cifrar. Prueba https://localhost:8443 en lugar de http://.

• El servidor de desarrollo se bloqueó mientras atendía la petición. Revisa la terminal en la que se ejecuta. Una excepción o un error de falta de memoria en ese momento es tu respuesta.

# Reprodúcelo sin el navegador
curl -v http://localhost:8080/
# "Empty reply from server" = conexión aceptada, no se devolvió nada

# ¿Qué puertos publica el contenedor y qué escucha dentro de él?
docker ps --format "table {{.Names}}\t{{.Ports}}"
docker exec -it <container> sh -c "netstat -tlnp 2>/dev/null || ss -tlnp"

Para propietarios de sitios web: por qué tu servidor envía respuestas vacías

• Bloqueos y procesos terminados por falta de memoria. Si el proceso que atiende la petición muere, la conexión se cierra sin enviar nada. Revisa los logs de la aplicación y dmesg -T | grep -i "killed process" para ver si ha actuado el OOM killer de Linux (el mecanismo que mata procesos cuando falta memoria), sobre todo en páginas pesadas y en subidas de archivos.

• Descartes deliberados. El return 444; especial de nginx cierra la conexión sin ninguna respuesta, y se usa a menudo para bloquear bots maliciosos o nombres de host desconocidos. Si una regla así coincide con visitantes reales (una regla de user agent o de GeoIP demasiado amplia), verán ERR_EMPTY_RESPONSE, o ERR_HTTP2_PROTOCOL_ERROR en las conexiones HTTP/2, donde nginx restablece el stream en su lugar. Los WAF, los limitadores de peticiones y los servicios antibots pueden hacer lo mismo.

• Redirecciones de puertos y balanceadores de carga sin backend. Un listener que acepta la conexión pero no tiene ningún servidor sano detrás puede cerrarla vacía. Comprueba el estado de salud de los destinos y que el puerto del backend coincida.

• Tiempos de espera que cierran en lugar de responder. Haz que las peticiones de larga duración devuelvan un error adecuado (como un 504) en lugar de cerrar el socket en silencio, para que los visitantes y la monitorización vean lo que pasó.

• Peticiones demasiado grandes. Las cabeceras o las cookies muy grandes pueden hacer que algunos servidores descarten la petición. Mantén las cookies pequeñas.

# ¿Hay reglas que descartan conexiones?
sudo grep -rn "return 444" /etc/nginx/

# Prueba desde fuera, como se conectan los visitantes
curl -sv https://yourdomain.com/ -o /dev/null

ERR_EMPTY_RESPONSE frente a errores similares

Guías relacionadas: ERR_CONNECTION_CLOSED, ERR_CONNECTION_RESET, 502 Bad Gateway y 500 Internal Server Error. Para comprobar si el puerto de un servidor acepta conexiones desde fuera, usa el Verificador de Puertos.