ERR_EMPTY_RESPONSE

Qué significa este error y cómo reconocerlo

• El navegador muestra ERR_EMPTY_RESPONSE en lugar de un estado HTTP como 200, 404 o 500.
• La solicitud falla antes de que el navegador reciba los encabezados de respuesta, HTML o una página de error de la aplicación.
• La recarga puede tener éxito ocasionalmente si se recupera un worker, un pool de conexiones o un servicio upstream.
• Puede fallar un hostname o una ruta mientras otros sitios siguen siendo accesibles.
• Una solicitud detallada desde la línea de comandos puede mostrar que la conexión TCP se abre y después se cierra sin encabezados de respuesta.
• La URL pública puede fallar a través de un reverse proxy, mientras que una solicitud autorizada al servicio upstream se comporta de otra manera.
• El error puede afectar únicamente a un navegador, dispositivo, red de origen, VPN o ruta a través de un proxy.

Causas principales, ordenadas por probabilidad

1. La aplicación o el worker de PHP-FPM terminó antes de enviar una respuesta. Los errores de aplicación fatales, los bloqueos de workers, los límites de procesos, la presión de memoria o las dependencias fallidas pueden finalizar la solicitud antes de que se genere una respuesta HTTP normal.
2. Nginx o el host han alcanzado la capacidad de conexiones o de descriptores de archivo. worker_connections efectivo, los límites de archivos abiertos, las conexiones activas y la memoria disponible influyen en que las solicitudes y las conexiones con el upstream puedan completarse.
3. Un reverse proxy no puede mantener una conexión upstream válida. Un comportamiento de keepalive incompatible, la reutilización de conexiones, los valores de timeout o la configuración del proxy pueden provocar que la conexión del cliente se cierre antes de que lleguen los encabezados del upstream.
4. El servicio upstream no está disponible o restablece las conexiones. Es posible que un servicio esté en ejecución, pero no pueda aceptar, procesar o completar la solicitud.
5. Un firewall, VPN, WAF, balanceador de carga u otro dispositivo de red cierra la conexión. Esto es más probable cuando el error depende de la red del cliente, la dirección de origen o la ruta.
6. Una condición local del navegador interfiere con la solicitud. Las extensiones, el estado almacenado de las conexiones, un proxy local, una VPN o el software de seguridad pueden producir un síntoma similar cuando otros clientes funcionan normalmente.

Cómo solucionarlo

1. Determina el alcance del fallo

Registra el hostname, la ruta exacta, la hora aproximada con zona horaria, el cliente, la red y si el fallo es constante. Prueba la misma ruta en una ventana privada, otro navegador, otro dispositivo y —si está permitido— otra red.

Si solo falla un navegador o dispositivo, investiga primero las extensiones, la configuración del proxy local, el software VPN, el estado almacenado de las conexiones y los controles de seguridad del endpoint. No des por hecho que la página de inicio es representativa; prueba la ruta específica que falla.

2. Comprueba si el cliente recibe encabezados de respuesta

Desde un cliente afectado o cercano, realiza una solicitud de solo lectura al destino autorizado. Sustituye los valores entre corchetes por el hostname y la ruta reales:

curl -v https://[your hostname]/[path]

Si la conexión se cierra sin encabezados de respuesta, esto respalda el diagnóstico de respuesta vacía. Si se devuelve un estado HTTP, investiga ese estado, la redirección, el comportamiento de TLS o la representación del navegador. Cuando sea posible, compara la salida detallada de un cliente que funciona con la de uno que falla.

3. Correlaciona la solicitud con los registros del servidor

Usa la hora y la ruta exactas para revisar:

1. Los registros de acceso y errores de Nginx o del servidor web correspondiente.
2. Los registros de PHP-FPM si la ruta ejecuta PHP.
3. Los registros de la aplicación en busca de errores fatales, excepciones no controladas y dependencias fallidas.
4. Los registros del sistema operativo en busca de eventos de falta de memoria, terminación de procesos, agotamiento de descriptores de archivo y fallos de servicios.

Una entrada en el registro de acceso sin una respuesta upstream completada, un restablecimiento del upstream o un mensaje de terminación de un worker ayudan a identificar qué capa cerró la conexión. El error del navegador por sí solo no permite identificar el componente responsable.

4. Comprueba el estado de PHP-FPM y de la aplicación

Para una ruta dinámica, determina si PHP-FPM tiene workers disponibles y si estos terminan repetidamente, alcanzan los límites configurados o son eliminados por el sistema operativo. Comprueba los despliegues recientes, los errores fatales, la presión de memoria, las consultas lentas a la base de datos y otras dependencias bloqueadas.

Cambia los límites de PHP-FPM, el código de la aplicación o el estado del servicio únicamente después de confirmar las evidencias pertinentes y evaluar la capacidad y el impacto operativo. Un reinicio puede liberar temporalmente workers fallidos, pero no solucionará un bloqueo recurrente, el agotamiento de recursos ni un defecto de la aplicación. Si se autoriza un reinicio, recopila los registros y el estado de los procesos antes de realizarlo.

5. Comprueba la capacidad de conexiones y descriptores de archivo de Nginx

Revisa la configuración efectiva de Nginx y los límites del sistema operativo para el servicio afectado. Examina worker_connections, el comportamiento de los procesos worker, las conexiones activas, los límites de archivos abiertos, la memoria disponible y los mensajes de error que indiquen que se alcanzó un límite de recursos.

No aumentes simplemente worker_connections. El límite de descriptores de archivo del sistema operativo y la memoria disponible deben admitir el cambio. Registra los valores actuales y las condiciones de tráfico, sigue el procedimiento de cambio aprobado y valida el resultado después de una recarga o un reinicio controlado, si se autoriza.

6. Aísla un fallo del reverse proxy o del upstream

Si hay una CDN, un balanceador de carga, un ingress o un reverse proxy de Nginx delante de la aplicación, compara:

• La solicitud pública a través del proxy.
• Una solicitud autorizada al upstream desde el host del proxy o desde un punto de prueba interno equivalente.
• Los registros de errores del proxy y los registros de la aplicación upstream correspondientes a la misma hora.

Comprueba si el proxy está reutilizando una conexión que el upstream ya cerró, si la configuración de keepalive es compatible y si los timeouts del proxy y del upstream son adecuados para la ruta. Cambia una sola configuración relacionada cada vez, documenta el impacto previsto y repite la misma prueba.

7. Comprueba los controles de red y seguridad

Si no existe ninguna entrada en el registro del servidor web en el momento del fallo, inspecciona el firewall, la VPN, el WAF, el balanceador de carga, el enrutamiento y la ruta de seguridad del cliente. Compara una red de origen que funciona con la que falla y busca decisiones de políticas, restablecimientos de conexiones o gestión de conexiones inactivas que coincidan con la marca de tiempo.

Si la conexión desaparece antes de llegar al servidor web, escala el problema al equipo de red o de hosting en lugar de cambiar el código de la aplicación.

8. Valida la solución conservando las evidencias

Después de un cambio aprobado en la aplicación, la configuración o la red, repite las mismas pruebas de ruta y cliente. Confirma que la respuesta ahora incluye encabezados y un estado HTTP adecuado, no solo que el navegador dejó de mostrar el mensaje original. Revisa los registros del proxy, el servidor web, el upstream, la aplicación y el sistema, y conserva los valores de configuración anteriores y posteriores para compararlos o revertirlos.

Prevención y cómo verificar la solución

• Supervisa los errores del servidor web, los restablecimientos del upstream, la disponibilidad de workers de PHP-FPM, las salidas de procesos, la presión de memoria, el uso de archivos abiertos y las advertencias sobre límites de conexiones.
• Documenta las políticas de reverse proxy, keepalive del upstream y timeouts, y pruébalas después de cambios en la infraestructura.
• Incluye un identificador de solicitud o una marca de tiempo precisa con zona horaria en los informes de incidentes para poder correlacionar los registros del proxy, el servidor web y la aplicación.
• Prueba la capacidad de las conexiones y de los descriptores de archivo antes de aumentar el tráfico o cambiar el número de workers.
• Despliega los cambios de la aplicación con un plan de reversión y vigila inmediatamente después los errores fatales, los bloqueos de workers y los fallos de dependencias.
• Mantén un procedimiento autorizado para probar por separado tanto el endpoint público como el servicio upstream.
• Mantén los reinicios de servicios y los cambios de límites en producción dentro de un proceso de cambios aprobado.

Preguntas frecuentes