Error 502 Bad Gateway: qué significa y cómo solucionarlo

¿Qué es el error 502 Bad Gateway?

502 Bad Gateway es un código de estado HTTP que significa que el servidor que te responde actúa como puerta de enlace (gateway) o proxy, y recibió una respuesta no válida del servidor que tiene detrás. El estándar HTTP (RFC 9110, sección 15.6.3) lo define exactamente así: el servidor, "while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request" (mientras actuaba como puerta de enlace o proxy, recibió una respuesta no válida de un servidor interno al que accedió para atender la petición).

La mayoría de los sitios web modernos tienen al menos dos capas. Un servidor frontal, como nginx, Apache, Cloudflare o un balanceador de carga en la nube, acepta tu conexión y luego pasa la petición a una aplicación upstream (el servidor de detrás), como PHP-FPM, una app de Node.js, Gunicorn de Python o un contenedor. Cuando ese upstream está caído, falla o responde con algo que el proxy no puede usar, el proxy no tiene nada que darte, así que devuelve un 502.

Lo importante es que la puerta de enlace en sí funciona. Recibió tu petición y respondió. El fallo está un paso más atrás.

Las muchas caras de un error 502

El código de estado es el mismo en todas partes, pero la página que ves depende del proxy que la generó:

Veas la versión que veas, el nombre del proxy en el pie de la página es una pista útil: le dice al propietario del sitio qué capa debe investigar.

502 vs. 500 vs. 503 vs. 504: ¿cuál es la diferencia?

Todos los códigos 5xx significan "problema del servidor", pero cada uno apunta a una capa distinta:

Una regla rápida: 502 = el upstream rechazó la conexión, colgó o envió una respuesta mala, 504 = el upstream no respondió a tiempo. Nuestras guías sobre los errores vecinos los tratan a fondo: 500 Internal Server Error, 503 Service Unavailable y 504 Gateway Timeout.

¿Qué causa un error 502 Bad Gateway?

• La aplicación upstream no se está ejecutando. PHP-FPM, Node, Gunicorn o el contenedor se cayó, no arrancó después de un despliegue o se está reiniciando.
• El proxy apunta al lugar equivocado. proxy_pass o fastcgi_pass usa el puerto equivocado, una ruta de socket de PHP antigua tras una actualización, o localhost dentro de un contenedor Docker.
• La aplicación se cae con algunas peticiones. Una página hace que el sistema mate el proceso por falta de memoria o provoca una excepción no controlada, y la conexión se cierra antes de que haya respuesta.
• Todos los workers están ocupados. PHP-FPM alcanzó pm.max_children, así que las peticiones nuevas esperan en la cola del socket. La mayoría acaba en un 504 por tiempo de espera; cuando la cola se llena, nginx registra (11: Resource temporarily unavailable) y devuelve un 502.
• Las cabeceras de la respuesta son demasiado grandes. Las cookies grandes o las cabeceras de seguridad extensas desbordan el proxy_buffer_size de nginx.
• Desajuste de keep-alive detrás de un balanceador de carga. La aplicación cierra las conexiones inactivas antes de lo que espera el balanceador, así que este envía una petición por una conexión que se está cerrando.
• El proxy no puede llegar al upstream tras un cambio de red. Un firewall que rechaza al proxy, o un upstream que cambió a otra IP, da un 502 (Connection refused, No route to host). Un firewall que descarta los paquetes en silencio da un 504, y detrás de Cloudflare se ven como 521 o 522.

Cómo solucionar un error 502 como visitante

No puedes reparar el servidor de otra persona, pero estos pasos confirman que el problema está realmente de su lado y eliminan las raras causas locales:

• Espera entre 30 y 60 segundos y recarga (Ctrl + R, o Cmd + R en Mac). Muchos errores 502 duran solo lo que tarda un despliegue o un reinicio.
• Comprueba si está caído para todos. El Verificador de páginas caídas de DNS Robot abre la página desde 11 lugares, y el Verificador de Cabeceras HTTP muestra el código de estado exacto que recibe nuestro servidor. Si ellos también ven un 502, el problema es el sitio, no tú.
• Fuerza la recarga con Ctrl + Shift + R (Mac: Cmd + Shift + R), por si te están mostrando una página de error en caché.
• Vacía tu caché DNS si el sitio cambió de hosting hace poco, para llegar al servidor nuevo. Aquí tienes cómo vaciar la caché DNS en cada sistema.
• Desactiva las VPN y los proxies. Tu propio proxy puede ser la "puerta de enlace" que falla, sobre todo en redes de empresa.
• Prueba otro navegador o tu teléfono con datos móviles. Si funciona ahí, borra las cookies de ese sitio.

Cómo solucionar un 502 Bad Gateway en tu servidor

En el lado del servidor, un 502 es de los errores más fáciles de resolver, porque el proxy suele registrar qué falló (las excepciones son la condición de carrera de keep-alive de un balanceador y los 502 propios de Cloudflare). Haz estas tres comprobaciones en orden; la cuarta parte es un ejemplo real.

1. Lee el registro de errores del proxy

Reproduce el 502 y lee las últimas 50 líneas del registro de errores del proxy (los comandos están debajo de la tabla). Cada uno de estos mensajes de nginx apunta a su propia solución:

# nginx
sudo tail -n 50 /var/log/nginx/error.log

# Apache
sudo tail -n 50 /var/log/apache2/error.log    # Debian/Ubuntu
sudo tail -n 50 /var/log/httpd/error_log      # RHEL/Alma/Rocky

2. Comprueba que la aplicación upstream se está ejecutando

# PHP-FPM (ajusta la versión)
sudo systemctl status php8.3-fpm
sudo journalctl -u php8.3-fpm -n 50

# Node.js con PM2
pm2 status
pm2 logs --lines 50

# Docker
docker ps -a          # busca contenedores que se reinician una y otra vez
docker logs --tail 50 <container>

# ¿Se mató el proceso por usar demasiada memoria?
sudo dmesg -T | grep -i "killed process"

Si el servicio está detenido, inícialo y averigua por qué se detuvo: un despliegue fallido, un error de sintaxis en la nueva versión o el OOM killer, que mata procesos cuando falta memoria. En el registro de PHP-FPM, server reached pm.max_children setting significa que todos los workers estaban ocupados. Sube pm.max_children solo si el servidor tiene RAM suficiente; si no, busca las peticiones lentas que mantienen ocupados a los workers.

3. Asegúrate de que proxy_pass apunta al puerto o socket correcto

Compara el destino configurado en nginx con lo que realmente está escuchando:

# ¿A dónde reenvía nginx las peticiones?
sudo nginx -T 2>/dev/null | grep -n "proxy_pass\|fastcgi_pass"

# ¿Qué está escuchando realmente?
sudo ss -tlnp            # puertos TCP y sus procesos
ls -l /run/php/          # archivos de socket de PHP-FPM

Dos desajustes clásicos: después de actualizar PHP, el socket pasa a ser php8.3-fpm.sock mientras nginx sigue apuntando a php8.1-fpm.sock; y dentro de Docker, proxy_pass http://localhost:3000 apunta al propio contenedor de nginx en lugar de a la aplicación, así que usa el nombre del servicio de Compose (http://app:3000).

4. Un ejemplo real: cómo dnsrobot.net sirvió un 502

Nos pasó el 30 de septiembre de 2026. Después de publicar un lote de nuevas entradas del blog, exactamente una de ellas devolvía 502 Bad Gateway a través de nginx 1.24, mientras que todas las demás páginas funcionaban. La aplicación Next.js que hay detrás de nginx devolvía esa misma página con 200 OK cuando la pedíamos directamente en el puerto 3000. Es decir, la aplicación estaba bien y lo que fallaba era la puerta de enlace.

El registro de errores de nginx tenía la respuesta en una línea: upstream sent too big header while reading response header from upstream. Las cabeceras de respuesta de esa página sumaban 4087 bytes, sobre todo por una cabecera Content-Security-Policy larga y varias cabeceras Link de precarga. nginx lee la primera parte de la respuesta, incluidas todas las cabeceras, en un búfer definido por proxy_buffer_size, que por defecto ocupa una página de memoria: 4 KB en nuestro servidor. Eso dejaba solo 9 bytes libres, y el bloque completo de cabeceras, con la línea de estado incluida, lo desbordó.

La solución fueron tres líneas en el bloque location que hace de proxy hacia la aplicación; tras nginx -t y una recarga, la página devolvió 200:

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_buffer_size 16k;        # espacio para cabeceras grandes (antes, 4k por defecto)
    proxy_buffers 4 32k;
    proxy_busy_buffers_size 64k;
}

La lección: si solo algunas páginas devuelven 502 mientras el resto del sitio funciona, busca un límite de tamaño, como cabeceras grandes o valores de Set-Cookie en esas páginas, antes de sospechar de la aplicación.

Node.js detrás de un balanceador de carga: errores 502 aleatorios

Si ejecutas Node.js detrás de un AWS Application Load Balancer o un balanceador similar y ves errores 502 ocasionales sin nada en los registros de tu aplicación, revisa los tiempos de keep-alive. El servidor HTTP de Node cierra las conexiones keep-alive inactivas tras 5 segundos por defecto en Node 26 y anteriores (server.keepAliveTimeout; Node 24.6 y 22.19 añadieron encima un keepAliveTimeoutBuffer de 1 segundo, y la próxima versión mayor sube el valor por defecto a 65 segundos), mientras que un ALB de AWS mantiene abiertas las conexiones inactivas durante 60 segundos. A veces el balanceador reutiliza una conexión justo cuando Node la cierra, y esa petición vuelve como un 502.

La solución es que el tiempo de espera de la aplicación sea más largo que el del balanceador:

const server = app.listen(3000)
// Debe ser mayor que el tiempo de inactividad del balanceador (ALB por defecto: 60s)
server.keepAliveTimeout = 65_000
server.headersTimeout = 66_000 // solo hace falta antes de Node 18; no molesta después

502 Bad Gateway en Cloudflare

Detrás de Cloudflare, mira primero quién generó la página de error (guía de Cloudflare sobre 502/504):

• Página con la marca de Cloudflare (Browser ✓ / Cloudflare ✓ / Host ✗): tu servidor de origen devolvió un 502 o un 504 a Cloudflare. Arréglalo en el origen con los pasos del lado del servidor de arriba. Si Cloudflare no puede conectar con el origen en absoluto, recibes un 521 o un 522, no un 502.
• Una página simple que dice "502 Bad Gateway" con "cloudflare" debajo: esta la genera el propio Cloudflare. Su documentación señala dos causas: que tu origen envíe contenido gzip defectuoso, o contenido gzip sin un Content-Length actualizado (desactiva la compresión en el origen para probarlo), y un pico repentino de tráfico en un centro de datos de Cloudflare, que se pasa solo.
• Una página que nombra a nginx o Apache: normalmente la petición llegó a tu servidor sin pasar por Cloudflare, así que el registro DNS no tiene proxy (nube gris, "DNS only") o estás mirando el origen directamente (salvo que una Cache Rule active "Origin error page pass-through").
• ¿Cambiaste de hosting? Actualiza el registro A del origen en el DNS de Cloudflare (una IP de origen incorrecta suele verse como 521, 522 o 523). Un DNS Lookup solo muestra el origen de los registros con nube gris (DNS only); los registros con proxy responden con las IP de Cloudflare.

¿Un error 502 perjudica el SEO?

Una caída breve, no. La documentación de Google dice que los errores de servidor 5xx hacen que sus rastreadores ralenticen temporalmente el rastreo. Las páginas que ya están indexadas se mantienen en el índice al principio, pero si los errores persisten, Google acaba eliminando esas URL.

Así que un 502 que dura unos minutos durante un despliegue es inofensivo. Un 502 en páginas importantes que dura días, o que aparece de forma intermitente durante semanas, puede reducir el rastreo y costar posiciones. Monitoriza tus URL clave y revisa el informe de Estadísticas de rastreo de Search Console después de cualquier caída.