Códigos de error
Errores 502, 503 y 504: lo que realmente significa cada uno
Publicado October 24, 2026
502, 503 y 504 significan aproximadamente “el servidor no pudo darle una respuesta real en este momento”, razón por la cual a menudo se confunden entre sí. Pero cada código reduce el problema de manera diferente y leer el número correctamente ahorra tiempo al solucionar problemas en la capa incorrecta.
La distinción rápida
- 502 Bad Gateway: un servidor que actúa como puerta de enlace o proxy recibió una respuesta no válida del servidor detrás de él.
- Servicio 503 no disponible: el servidor está activo pero se niega deliberadamente a manejar la solicitud en este momento (sobrecargado o en mantenimiento).
- 504 Gateway Timeout: un servidor que actúa como puerta de enlace o proxy no obtuvo respuesta del servidor detrás de él dentro de su límite de tiempo.
El patrón: 502 y 504 involucran dos servidores: un proxy/equilibrador de carga/CDN al frente y un servidor de aplicaciones detrás. 503 suele ser solo un servidor que le dice directamente que no está listo.
502 Puerta de enlace no válida
Qué está pasando: Un proxy inverso, un equilibrador de carga o una CDN (como Cloudflare o Nginx que actúan como puerta de enlace) reenvió su solicitud al servidor de aplicaciones real y obtuvo una respuesta que no pudo entender o que tenía un formato incorrecto: no silencio, sino una respuesta entrecortada.
Causas comunes:
- El servidor de aplicaciones (Node, PHP-FPM, un proceso backend) falló o se reinició a mitad de la solicitud.
- Un proxy inverso mal configurado que apunta al puerto o dirección incorrectos.
- El servidor devolvió una respuesta que viola el formato HTTP básico.
- Un CDN o WAF frente al sitio está mal configurado y rechaza una respuesta de backend legítima.
Qué verificar si es su sitio: Mire los registros de su servidor de aplicaciones para detectar fallas o reinicios alrededor del momento del error. Confirme que su configuración de proxy inverso (nginx proxy_pass, destino del balanceador de carga, etc.) apunte a un backend que realmente se esté ejecutando en el puerto esperado.
503 Servicio no disponible
Qué está pasando: El servidor recibió su solicitud correctamente, pero le dice explícitamente que no puede manejarla en este momento. A diferencia de 502/504, esto suele ser intencional: un servidor declara su propia condición en lugar de un proxy quejándose de lo que hay detrás.
Causas comunes:
- Mantenimiento planificado: muchas plataformas devuelven 503 a propósito durante la implementación o actualización, a menudo con un encabezado
Retry-After. - Sobrecarga: demasiadas solicitudes simultáneas para la capacidad del servidor, algo común durante picos de tráfico (una venta, una publicación viral, un DDoS).
- Agotamiento de recursos: el servidor se quedó sin memoria, conexiones de base de datos o procesos de trabajo para manejar nuevas solicitudes.
- Limitación de velocidad: algunas configuraciones devuelven 503 en lugar de 429 cuando un cliente (o un servicio ascendente) envía solicitudes demasiado rápido.
Qué comprobar si es su sitio: Si esto apareció durante una implementación, puede resolverse solo en cuestión de segundos o minutos. Si persiste, verifique el uso de recursos del servidor (CPU, memoria, límites del grupo de conexiones) y los registros de su administrador de procesos para ver si los trabajadores no se inician o mueren.
504 Tiempo de espera de puerta de enlace
Qué está pasando: La misma configuración de dos servidores que 502, pero en lugar de recibir una respuesta interrumpida del backend, el proxy no obtuvo nada dentro del tiempo de espera asignado. Es el hermano “puerta de enlace” de un tiempo de espera de conexión simple.
Causas comunes:
- El backend está tardando demasiado en procesar la solicitud: una consulta lenta a la base de datos, un script no optimizado o una dependencia (API, servicio de terceros) que en sí misma es lenta o está inactiva.
- El backend está sobrecargado y demasiado ocupado para responder a tiempo, aunque no haya fallado.
- Una configuración de tiempo de espera de proxy que es demasiado agresiva para una operación legítimamente lenta (pero funcional), como una carga de archivos de gran tamaño o una generación de informes intensa.
Qué comprobar si es su sitio: Perfile el punto final lento directamente, sin pasar por el proxy, para ver si el backend en sí es lento o si el problema está exclusivamente en la capa del proxy. Compruebe si una dependencia específica (base de datos, API externa) está degradada, ya que esa es la causa raíz más común de que un backend funcione lento en lugar de fallar por completo.
¿Eres tú o son ellos?
Los tres son errores del lado del servidor por definición; no son causados por su navegador, su DNS o su red local, lo que los separa claramente de problemas como ERR_CONNECTION_TIMED_OUT o DNS_PROBE_FINISHED_NXDOMAIN. Si ve un 502, 503 o 504, la solución (si hay alguna que pueda hacer) casi nunca depende de usted; la actualización ocasionalmente funciona para un 503 transitorio, pero uno persistente solo significa esperar a que el sitio lo resuelva.
Para confirmar que no es solo usted (algunos CDN o nodos de borde regionales ocasionalmente muestran un error de puerta de enlace incorrecto, mientras que otros están bien), ejecute el sitio a través de una verificación de estado independiente para ver el código de estado HTTP en vivo desde un servidor fuera de su propia red, junto con el tiempo de respuesta y el estado de SSL en la misma vista.
Verifícalo tú mismo
Ejecuta una verificación en vivo de HTTP, SSL y DNS en cualquier sitio en un par de segundos — sin registro.