Errores HTTP y del servidor

Acerca de esta categoría de errores

# Errores HTTP y del servidor

Los errores HTTP y del servidor ocurren cuando una solicitud no puede completarse con normalidad. Algunos fallos devuelven un código de estado HTTP, como 500, 502, 503 o 504. Otros ocurren antes de que el navegador reciba una respuesta HTTP y producen mensajes como ERR_CONNECTION_REFUSED o ERR_CONNECTION_TIMED_OUT.

El mensaje del navegador identifica el síntoma, pero no siempre el componente que requiere atención. Empieza por localizar el límite en el que se produce el fallo: del navegador a la red, de la red al servicio que está escuchando, del proxy al backend o de la aplicación a una dependencia.

Identifica primero el tipo de fallo

Se devolvió un código de estado HTTP

Un estado numérico significa que un componente compatible con HTTP respondió. Ese componente puede ser el servidor web de origen, un reverse proxy, un balanceador de carga o una CDN, y no necesariamente la aplicación.

• 500 Internal Server Error: El servidor encontró una condición inesperada al procesar la solicitud. Empieza por los logs de la aplicación y del servidor web. Consulta la [guía de 500 Internal Server Error](/http-500-internal-server-error).
• 502 Bad Gateway: Un proxy recibió del backend una respuesta no válida, vacía o inutilizable. Comprueba el proceso del backend, el host y el puerto upstream, y la conexión entre el proxy y el origen. Consulta la [guía de 502 Bad Gateway](/http-502-bad-gateway).
• 503 Service Unavailable: El servicio no puede gestionar la solicitud en ese momento. Algunas posibilidades son el modo de mantenimiento, una capacidad agotada, un proceso no disponible o una dependencia que ha fallado. Consulta la [guía de 503 Service Unavailable](/http-503-service-unavailable).
• 504 Gateway Timeout: Un gateway reenvió la solicitud, pero no recibió una respuesta antes de que expirara su tiempo de espera. El backend puede seguir funcionando, pero estar lento, sobrecargado o esperando a otro servicio. Consulta la [guía de 504 Gateway Timeout](/http-504-gateway-timeout).

Un código de estado, por sí solo, no demuestra qué capa falló. Inspecciona la identificación de la respuesta, los encabezados, la marca de tiempo y los logs para determinar si la respuesta provino del origen o de un intermediario.

El navegador informa de un fallo de conexión

Un error a nivel de conexión significa que el navegador no recibió una respuesta HTTP normal del endpoint esperado.

• ERR_CONNECTION_REFUSED: Se llegó al destino, pero la conexión fue rechazada. Comprueba si hay un servicio escuchando en el puerto esperado y si las reglas de seguridad locales o de red afectan al acceso. Para entornos de desarrollo, consulta [ERR_CONNECTION_REFUSED en localhost](/err-connection-refused-localhost).
• ERR_CONNECTION_TIMED_OUT: El navegador esperó sin recibir una respuesta utilizable. Investiga la ruta de red, el enrutamiento, el filtrado, DNS, la accesibilidad del servidor y la disponibilidad de recursos antes de buscar un error HTTP generado por la aplicación. Consulta la [guía de ERR_CONNECTION_TIMED_OUT](/err-connection-timed-out).

Secuencia práctica de diagnóstico

1. Reproduce y registra el fallo

Recarga una vez y prueba después la misma URL en una ventana privada o desde otro dispositivo. Registra la URL exacta, el texto del error, el código de estado, la hora aproximada y la página de respuesta visible. Una página de CDN o proxy con su propia marca sugiere que la solicitud llegó a un intermediario; un mensaje genérico del navegador puede significar que no llegó ninguna respuesta HTTP utilizable.

Si solo falla un navegador o dispositivo, inspecciona su proxy, VPN, caché DNS, extensiones y software de seguridad local. Si la misma URL falla en distintos dispositivos y redes, es más probable que el problema esté en el servidor, el proxy, el origen o una ruta de red compartida.

2. Define el alcance afectado

Determina si el problema afecta a una ruta, un host, una aplicación completa o todo el servicio.

• El fallo de una sola ruta puede indicar código de la aplicación, una dependencia específica de esa ruta o una consulta lenta.
• Que todas las rutas devuelvan 500 sugiere un problema más amplio de la aplicación o de la configuración del servidor.
• Un 502 o 504 en todo un proxy dirige la atención al proceso de origen, la conexión upstream o la configuración del proxy.
• Una conexión rechazada en un puerto puede significar que el servicio esperado no está escuchando, mientras otros servicios siguen disponibles.

Cuando sea posible, compara un endpoint que funciona con el que falla. Las diferencias en el enrutamiento, la autenticación, las dependencias y el estado del despliegue pueden ser más informativas que cambiar configuraciones no relacionadas del cliente.

3. Comprueba el componente que generó la respuesta

Para un 500, correlaciona los logs de la aplicación y del servidor web con la hora del fallo. Para las respuestas 502, 503 y 504, inspecciona tanto los logs del proxy o gateway como los del backend. Busca un proceso detenido, un despliegue fallido, un fallo de conexión con una dependencia, agotamiento de recursos o una solicitud que supere un tiempo de espera relevante.

Para un ERR_CONNECTION_REFUSED local, verifica que Apache o Nginx estén ejecutándose y que el puerto configurado esté disponible. XAMPP, Laragon y MAMP pueden mostrar este síntoma cuando su servidor web no se ha iniciado o cuando otro programa impide que se vincule al puerto esperado.

4. Prueba el origen y las dependencias por separado

Si administras el servicio, comprueba si el backend acepta conexiones y responde a un endpoint sencillo, sin asumir que una conexión correcta a través del proxy demuestra que la aplicación está sana. Después, comprueba los servicios necesarios, como la base de datos u otras dependencias configuradas.

Un backend activo pero constantemente lento es más coherente con un 504 que un backend detenido o que devuelve una respuesta inutilizable, lo que puede producir un 502. Un 503 puede producirse antes de procesar una solicitud de la aplicación si el servicio no está disponible deliberadamente o si no se puede utilizar una dependencia necesaria.

Evita las recargas repetidas como método de diagnóstico. Pueden añadir carga mientras se investiga el problema subyacente del proceso, la dependencia o el tiempo de espera.

Usa los detalles del error para localizar la capa

El cuerpo de la respuesta, los encabezados y la marca de tiempo pueden revelar qué componente gestionó el fallo:

• Un mensaje genérico del navegador suele indicar que no se recibió ninguna respuesta HTTP utilizable.
• Una página de proxy o CDN con su propia marca indica que un intermediario generó o presentó el error.
• Una página de error específica de la aplicación puede apuntar más directamente a la aplicación de origen.

En fallos intermitentes, correlaciona la hora con despliegues, aumentos de tráfico, reinicios de procesos y latencia de las dependencias. En fallos constantes, compara una solicitud que funciona con la que falla e inspecciona las diferencias de configuración antes de cambiar los ajustes del servidor.

En sitios que usan Cloudflare, un 504 con la marca de Cloudflare generalmente significa que su edge no pudo obtener una respuesta del origen dentro de la ventana de tiempo de espera aplicable. La [guía 504 Gateway Timeout detrás de Cloudflare](/504-gateway-timeout-cloudflare) explica cómo separar un problema del origen de un tiempo de espera producido por otro gateway o por el propio origen.

Qué incluir al solicitar ayuda

Un informe útil incluye:

• El texto exacto del error y el código de estado
• La ruta de la URL y la hora aproximada del fallo
• Si el problema afecta a otros usuarios, dispositivos o redes
• Si intervienen un proxy, una CDN o un balanceador de carga
• Las entradas relevantes de los logs del servidor web, el proxy y la aplicación, con las contraseñas, tokens y otros secretos eliminados

El objetivo es identificar el límite en el que se produce el fallo. Una vez localizado, la guía de errores correspondiente puede proporcionar comprobaciones más específicas, sin tratar como intercambiables las causas relacionadas con el navegador, la red, el proxy y el backend.