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 dio una respuesta mala (o colgó), 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 no tienen adónde ir.

• 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.

• Un firewall o un cambio de red entre el proxy y el origen. Por ejemplo, una CDN ya no puede llegar a un servidor de origen cuya dirección IP o reglas de firewall cambiaron.

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. La herramienta HTTP Headers de DNS Robot solicita la página desde nuestros servidores y muestra el código de estado exacto. Si nosotros también recibimos un 502, el problema es el sitio, no tú. Un test de ping muestra si la máquina del servidor responde siquiera.

• Fuerza la recarga y borra la caché. Ctrl + Shift + R (Mac: Cmd + Shift + R) omite la copia en caché, por si te está mostrando una página de error obsoleta.

• 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 casi siempre deja escrito exactamente qué falló. Haz estas cuatro comprobaciones en orden.

1. Lee el registro de errores del proxy

Reproduce el 502 y lee las últimas líneas del registro de errores en el servidor proxy:

# 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

Estos mensajes de nginx cubren la gran mayoría de los errores 502, y cada uno apunta a la solución:

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?
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?
grep -rn "proxy_pass\|fastcgi_pass" /etc/nginx/sites-enabled/

# ¿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). Después de cualquier cambio, ejecuta sudo nginx -t y sudo systemctl reload nginx.

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:

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;
}

Tras nginx -t y una recarga, la página devolvió 200. 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 o cookies grandes 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 (server.keepAliveTimeout, en Node.js 26 y anteriores), 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 // un poco por encima de keepAliveTimeout

502 Bad Gateway en Cloudflare

Detrás de Cloudflare, mira primero quién generó la página de error:

• Página con la marca de Cloudflare (Browser ✓ / Cloudflare ✓ / Host ✗): Cloudflare funciona, pero no pudo obtener una respuesta válida de tu servidor de origen. Comprueba que el origen está activo, que escucha en el 443/80 y que su firewall no bloquea los rangos de IP de Cloudflare. Prueba el origen directamente con el Port Checker.

• Página 502 simple, sin marca: si no menciona cloudflare (por ejemplo, nombra a nginx o Apache), fue tu propio servidor de origen el que generó el 502. Sigue los pasos del lado del servidor de arriba. Una página en blanco con solo "cloudflare" al pie la genera el propio Cloudflare, por ejemplo durante un breve redireccionamiento del tráfico o cuando el origen envía contenido gzip defectuoso.

• ¿Cambió la IP del origen? Si te mudaste de hosting, actualiza el registro A en el DNS de Cloudflare. Un DNS Lookup muestra lo que ve el mundo en este momento.

¿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.