Error 502 Bad Gateway: qué es, causas y cómo solucionarlo

El error 502 Bad Gateway es un código de estado HTTP que indica que un servidor actuando como proxy o gateway recibió una respuesta inválida, inesperada o ninguna respuesta del servidor al que reenvió la solicitud. El nombre "Bad Gateway" describe exactamente el problema: el intermediario recibió una respuesta "mala" del servidor de destino. Es un error de la familia 5xx, lo que significa que el cliente hizo su solicitud correctamente y el problema está en la infraestructura del servidor. Es especialmente frecuente en configuraciones con Nginx actuando como proxy inverso delante de PHP-FPM, Node.js o Apache, y en sitios que usan Cloudflare.

Qué significa exactamente el error 502

El código 502 está definido en el RFC 9110 como: "The server, while acting as a gateway or proxy, received an invalid response from an inbound server it accessed while attempting to fulfill the request." (El servidor, actuando como gateway o proxy, recibió una respuesta inválida del servidor de entrada al que accedió al intentar completar la solicitud).

Para entender el 502 hay que entender la arquitectura de dos capas que lo genera. En un servidor web moderno, rara vez hay un solo proceso sirviendo las solicitudes directamente. La arquitectura típica es:

1. El proxy inverso (Nginx, HAProxy, Cloudflare) recibe la solicitud del navegador del usuario.
2. El proxy reenvía la solicitud al servidor de aplicación (PHP-FPM, Node.js, Apache con PHP, Gunicorn para Python).
3. El servidor de aplicación procesa la solicitud y devuelve una respuesta al proxy.
4. El proxy devuelve esa respuesta al navegador del usuario.

El error 502 se genera en el paso 3: el proxy esperaba una respuesta válida del servidor de aplicación, pero recibió algo inesperado (una respuesta malformada, un mensaje de error de bajo nivel, o ninguna respuesta antes de que se cerrara la conexión). El proxy no puede reenviar esa respuesta inválida al usuario, así que devuelve el código 502.

Error 502 vs 503 vs 504: diferencias fundamentales

La distinción práctica más importante entre 502 y 504: el 502 indica que el servidor de destino respondió pero con algo inválido o cerró la conexión inesperadamente (el servicio está roto o caído); el 504 indica que el servidor de destino no respondió dentro del tiempo límite (el servicio existe pero está demasiado lento o sobrecargado).

¿Cómo identificar si el 502 viene de Cloudflare o de tu servidor?

Antes de buscar la causa, es fundamental saber en qué capa de la infraestructura se genera el 502. Cloudflare y otros CDN muestran páginas de error con su propio diseño cuando el error ocurre en la comunicación entre ellos y tu servidor de origen:

El Ray ID de Cloudflare es tu mejor aliado: cada error que genera Cloudflare incluye un Ray ID único (una cadena alfanumérica al pie de la página de error). Si tienes acceso al panel de Cloudflare, puedes buscar ese Ray ID en los logs para ver exactamente qué respuesta recibió Cloudflare de tu servidor de origen.

Causas más comunes del error 502

1. PHP-FPM caído o sin responder

En stacks LEMP (Linux + Nginx + MySQL + PHP-FPM), Nginx actúa como proxy inverso y reenvía las solicitudes de archivos PHP a PHP-FPM a través de un socket Unix o TCP. Si PHP-FPM está parado, bloqueado o no responde, Nginx no puede obtener una respuesta válida y devuelve un 502.

El mensaje típico en los logs de Nginx cuando PHP-FPM está caído:

2026/06/03 10:45:23 [error] 1234#1234: *567 connect() to unix:/run/php/php8.2-fpm.sock failed
(111: Connection refused) while connecting to upstream, client: 195.234.1.1,
server: tudominio.com, request: "GET / HTTP/1.1", upstream: "fastcgi://unix:/run/php/php8.2-fpm.sock:"

El mensaje "Connection refused" en el socket de PHP-FPM es diagnóstico inequívoco: PHP-FPM no está ejecutándose o no está escuchando en ese socket.

Comandos de diagnóstico y solución:

# Verificar el estado de PHP-FPM:
sudo systemctl status php8.2-fpm
sudo systemctl status php8.1-fpm
sudo systemctl status php8.0-fpm

# Ver los últimos errores de PHP-FPM:
sudo tail -50 /var/log/php8.2-fpm.log

# Reiniciar PHP-FPM:
sudo systemctl restart php8.2-fpm

# Verificar que el socket existe y tiene los permisos correctos:
ls -la /run/php/php8.2-fpm.sock

# Si el socket no existe: PHP-FPM no está corriendo o hay un error de configuración
# Verificar la configuración de PHP-FPM:
sudo php-fpm8.2 -t

2. Apache caído en un stack con Nginx como proxy inverso

En configuraciones donde Nginx actúa como proxy inverso delante de Apache (común en Plesk y en algunos setups de WordPress), si Apache está caído, Nginx no puede reenviar las solicitudes y devuelve un 502.

# Verificar el estado de Apache:
sudo systemctl status apache2

# Ver los logs de error de Apache:
sudo tail -50 /var/log/apache2/error.log

# Reiniciar Apache:
sudo systemctl restart apache2

# En Plesk, el estado de Apache se gestiona desde:
# Herramientas y Configuración > Servicios > Apache Web Server

3. Node.js o el proceso de la aplicación no está ejecutándose

En aplicaciones Node.js, Python (Gunicorn, uWSGI), Ruby (Puma, Unicorn) o cualquier otro lenguaje que se ejecuta como un proceso independiente detrás de Nginx, si ese proceso no está ejecutándose, Nginx devuelve 502 al intentar conectarse a él.

# Verificar procesos Node.js con PM2 (el gestor de procesos más común):
pm2 status
pm2 list

# Ver los logs de la aplicación Node.js:
pm2 logs nombre-de-tu-app

# Reiniciar la aplicación:
pm2 restart nombre-de-tu-app

# Si la aplicación no está registrada en PM2, iniciarla:
pm2 start app.js --name "mi-app"
pm2 save  # Guardar la configuración para que arranque en el reinicio

# Para Python con Gunicorn:
sudo systemctl status gunicorn
sudo systemctl restart gunicorn

# Para Python con uWSGI:
sudo systemctl status uwsgi
sudo systemctl restart uwsgi

4. Timeout entre el proxy y el servidor de aplicación

Si el servidor de aplicación tarda más en responder de lo que el proxy tiene configurado como timeout, el proxy cierra la conexión con el servidor de aplicación y devuelve un 502 al cliente. Esto es diferente del 504: en el 502 el servidor respondió con algo (aunque inválido o después de que el proxy ya cerró la conexión); en el 504 el proxy simplemente agotó el tiempo de espera.

El mensaje en los logs de Nginx:

upstream timed out (110: Connection timed out) while reading response header from upstream

Solución: aumentar los timeouts en Nginx para dar más tiempo al servidor de aplicación:

# En /etc/nginx/nginx.conf o en el bloque server del sitio:
proxy_connect_timeout  60s;
proxy_read_timeout     300s;
proxy_send_timeout     300s;

# Para FastCGI (PHP-FPM):
fastcgi_connect_timeout  60s;
fastcgi_read_timeout     300s;
fastcgi_send_timeout     300s;

# Aplicar los cambios:
sudo nginx -t && sudo systemctl reload nginx

5. PHP-FPM sin workers disponibles bajo alta carga

PHP-FPM gestiona un pool de procesos worker que atienden las solicitudes PHP. Si todos los workers están ocupados procesando solicitudes lentas (consultas pesadas a base de datos, importaciones, generación de thumbnails) y llegan nuevas solicitudes, PHP-FPM las encola. Si la cola también se llena, PHP-FPM rechaza las nuevas solicitudes y Nginx recibe una conexión rechazada, devolviendo un 502.

El mensaje en los logs de PHP-FPM:

WARNING: [pool www] seems busy (you may need to increase pm.max_children),
spawning 8 children, there are 0 idle, and 15 waiting for a process slot

Solución: ajustar la configuración del pool de PHP-FPM:

# En /etc/php/8.2/fpm/pool.d/www.conf:
pm = dynamic
pm.max_children = 50        ; Máximo de workers simultáneos
pm.start_servers = 5        ; Workers al arrancar
pm.min_spare_servers = 5    ; Workers mínimos en espera
pm.max_spare_servers = 35   ; Workers máximos en espera
pm.max_requests = 500       ; Solicitudes por worker antes de reiniciarse

# Calcular pm.max_children según la RAM disponible:
# pm.max_children = RAM disponible para PHP / RAM media por proceso PHP
# Ejemplo: 2GB RAM / 40MB por proceso = 50 workers máximo

# Verificar el uso actual de los workers en tiempo real:
sudo watch -n1 'ps aux | grep php-fpm | wc -l'

# Aplicar los cambios:
sudo systemctl reload php8.2-fpm

6. Configuración incorrecta del upstream en Nginx

Un error en la configuración del upstream de Nginx (dirección incorrecta, puerto equivocado, socket mal especificado) hace que Nginx intente conectarse a un destino que no existe y devuelva 502 al cliente.

# Configuración INCORRECTA — socket incorrecto:
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.1-fpm.sock;  # PHP 8.2 está instalado, no 8.1
}

# Configuración CORRECTA:
location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.2-fpm.sock;
    fastcgi_index index.php;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
}

# Verificar qué sockets de PHP-FPM existen realmente:
ls -la /run/php/

# Verificar la configuración de Nginx antes de aplicar:
sudo nginx -t

7. Respuesta malformada de la aplicación

En algunos casos, la aplicación web devuelve una respuesta HTTP malformada que Nginx no puede parsear correctamente y que clasifica como inválida, generando un 502. Esto puede ocurrir cuando:

• La aplicación genera cabeceras HTTP con caracteres inválidos.
• El script PHP imprime contenido antes de las cabeceras (causando cabeceras duplicadas).
• La aplicación genera una respuesta HTTP que excede los límites del buffer de Nginx.
• Hay caracteres BOM (Byte Order Mark) al inicio de un archivo PHP que se imprimen antes de las cabeceras.

# El mensaje en los logs de Nginx para respuesta malformada:
upstream sent invalid header while reading response header from upstream

# Aumentar los buffers de Nginx para respuestas grandes:
proxy_buffer_size          128k;
proxy_buffers              4 256k;
proxy_busy_buffers_size    256k;

# Para PHP-FPM:
fastcgi_buffer_size          128k;
fastcgi_buffers              4 256k;
fastcgi_busy_buffers_size    256k;

8. Error 502 de Cloudflare: origen no accesible

Cuando el error 502 lo muestra Cloudflare (con el diseño de nube y el Ray ID), significa que Cloudflare no pudo obtener una respuesta válida de tu servidor de origen. Las causas específicas de Cloudflare son:

• El servidor de origen está caído: Cloudflare no puede conectarse en absoluto.
• El servidor de origen devuelve un error 5xx: Cloudflare recibe el error y lo convierte en 502 hacia el usuario.
• El servidor de origen tarda más que el timeout de Cloudflare: Cloudflare tiene un timeout de 100 segundos para las respuestas del origen; si tu servidor tarda más, Cloudflare devuelve 502.
• El certificado SSL del origen no es válido en modo Full (Strict): Cloudflare no puede establecer la conexión HTTPS con el origen.

# Comprobar desde Cloudflare si el origen responde:
# Panel de Cloudflare > Health Checks > ver el estado del origen

# Bypass de Cloudflare para verificar si el origen responde directamente:
# Añade la IP del servidor directamente en el archivo hosts local:
# 195.234.56.78  tudominio.com
# Y accede con HTTPS directamente al servidor

Cómo solucionar el error 502: proceso de diagnóstico completo

Paso 1: Identifica la capa que genera el 502

Mira el diseño de la página de error: si tiene el aspecto de Cloudflare, el problema está entre Cloudflare y tu servidor. Si tiene el aspecto de Nginx o Apache, el problema está entre el proxy y el servidor de aplicación. Si la página está en blanco, el servidor de aplicación devuelve algo malformado.

Paso 2: Revisa los logs del proxy inverso

# Nginx — buscar errores upstream:
sudo tail -100 /var/log/nginx/error.log | grep upstream

# Filtrar solo los errores 502 de los logs de acceso:
sudo grep " 502 " /var/log/nginx/access.log | tail -20

# En tiempo real mientras reproduces el error:
sudo tail -f /var/log/nginx/error.log

El log de error de Nginx siempre indica la causa exacta del 502. Los mensajes más frecuentes y lo que significan:

Paso 3: Verifica el estado del servicio de aplicación

# PHP-FPM:
sudo systemctl status php8.2-fpm
sudo systemctl restart php8.2-fpm

# Apache:
sudo systemctl status apache2
sudo systemctl restart apache2

# Node.js con PM2:
pm2 status
pm2 restart all

# Gunicorn:
sudo systemctl status gunicorn
sudo systemctl restart gunicorn

# Verificar que el proceso escucha en el puerto o socket correcto:
ss -tlnp | grep php
ss -tlnp | grep :8080   # Si Node.js escucha en el 8080

Paso 4: Ajusta los timeouts si la causa es lentitud

# /etc/nginx/sites-available/tudominio.conf
server {
    listen 443 ssl;
    server_name tudominio.com;

    location ~ \.php$ {
        fastcgi_pass   unix:/run/php/php8.2-fpm.sock;
        fastcgi_index  index.php;
        fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include        fastcgi_params;

        # Timeouts generosos para aplicaciones lentas:
        fastcgi_connect_timeout 60s;
        fastcgi_read_timeout    300s;
        fastcgi_send_timeout    300s;
    }
}

sudo nginx -t && sudo systemctl reload nginx

Paso 5: Ajusta el pool de PHP-FPM para alta carga

# Calcular cuánta RAM usa cada proceso PHP-FPM:
ps --no-headers -o "rss,cmd" -C php-fpm8.2 | awk '{ sum+=$1 } END { printf "%.0f MB total, %.0f MB por proceso\n", sum/1024, sum/1024/NR }'

# Ajustar el pool según la RAM disponible:
# /etc/php/8.2/fpm/pool.d/www.conf
pm = dynamic
pm.max_children = 30      ; Ajusta según: RAM disponible / RAM por proceso PHP
pm.start_servers = 5
pm.min_spare_servers = 5
pm.max_spare_servers = 20
pm.process_idle_timeout = 10s
pm.max_requests = 500

sudo systemctl reload php8.2-fpm

Paso 6: Verifica y corrige la configuración del upstream

# Verificar qué sockets de PHP-FPM están disponibles:
ls -la /run/php/

# Verificar la versión de PHP activa:
php --version

# Verificar la configuración de Nginx:
sudo nginx -t

# Ver la configuración efectiva del sitio:
sudo nginx -T | grep -A5 "fastcgi_pass\|proxy_pass"

Error 502 en WordPress con Nginx y PHP-FPM

WordPress sobre un stack LEMP es uno de los escenarios donde el error 502 aparece con más frecuencia. Estos son los casos más habituales y sus soluciones específicas:

Prevención del error 502: configuración robusta del servidor

Un servidor bien configurado debería poder gestionar el error 502 de forma que minimice su impacto en los usuarios. Estas son las mejores prácticas:

# Configurar reinicio automático de PHP-FPM si falla:
# /etc/systemd/system/php8.2-fpm.service.d/override.conf
[Service]
Restart=always
RestartSec=3s

# Aplicar:
sudo systemctl daemon-reload

# Configurar Nginx para intentar un servidor de backup si el principal falla:
upstream php_backend {
    server unix:/run/php/php8.2-fpm.sock;
    # Si el principal falla, intenta el backup:
    # server unix:/run/php/php8.1-fpm.sock backup;
}

# Configurar página de error 502 personalizada en Nginx:
error_page 502 /error-502.html;
location = /error-502.html {
    root /var/www/html;
    internal;
}

Impacto del error 502 en el SEO

El error 502 tiene el mismo impacto en el SEO que otros errores 5xx. Google tolera errores transitorios de pocas horas de duración, pero un 502 persistente tiene consecuencias graves:

• Googlebot no puede rastrear ni indexar el contenido de las URLs afectadas.
• Si el error persiste más de 24 horas, Google puede empezar a reducir la frecuencia de rastreo del sitio completo.
• Si persiste más de una semana, Google puede desindexar las páginas afectadas.
• Los usuarios que encuentran un 502 tienen una tasa de rebote del 100%, lo que puede afectar indirectamente al posicionamiento.

Monitoriza los errores 502 en Google Search Console (sección Cobertura) y configura alertas de disponibilidad con herramientas como UptimeRobot para detectar el error en cuanto ocurre.

Preguntas frecuentes sobre el error 502

¿El error 502 significa que mi servidor está caído?

No exactamente. El error 502 significa que el servidor proxy (Nginx, Cloudflare) está activo y funcionando, pero el servidor de aplicación al que reenvía las solicitudes (PHP-FPM, Node.js, Apache) no está respondiendo correctamente. Es posible que tu servidor web esté activo (Nginx responde) pero el proceso PHP esté caído, generando el 502. El servidor de la capa de proxy está funcionando; el problema está en la capa de aplicación.

¿Cómo sé si el 502 está generado por Cloudflare o por mi servidor?

Fíjate en el diseño de la página de error: si tiene el logotipo o el estilo visual de Cloudflare y un Ray ID al pie, el 502 lo está generando Cloudflare al no poder contactar con tu servidor de origen. Si la página tiene el texto "502 Bad Gateway" con "nginx" o "Apache" al pie, es tu propio servidor el que genera el error internamente. En ambos casos, la causa subyacente suele ser la misma: el servidor de aplicación no responde.

¿Por qué el error 502 aparece solo a ciertas horas del día?

Si el 502 aparece de forma intermitente en horas de mayor tráfico (por ejemplo, de 9 a 14h en un sitio de negocio), la causa más probable es que PHP-FPM se queda sin workers disponibles bajo la carga de tráfico pico. Los workers están todos ocupados procesando solicitudes y las nuevas solicitudes son rechazadas, generando 502. La solución es aumentar pm.max_children en la configuración del pool de PHP-FPM o implementar un sistema de caché (FastCGI cache en Nginx, Redis, Varnish) para reducir la carga sobre PHP.

¿Cuánto tarda en resolverse un 502 si reinicio PHP-FPM?

El reinicio de PHP-FPM suele tardar entre 2 y 10 segundos. Una vez que PHP-FPM está activo y escuchando en el socket, Nginx puede reenviarle solicitudes inmediatamente. El error 502 desaparece en la siguiente solicitud que Nginx intenta procesar, sin necesidad de reiniciar Nginx. Si tienes una página de error 502 cacheada en el navegador, puede que necesites refrescar con Ctrl+F5 para ver que el error ya se resolvió.

¿El error 502 puede aparecer durante el proceso de actualización de WordPress?

Sí, y es relativamente frecuente en servidores con timeouts ajustados. Durante las actualizaciones de WordPress (especialmente actualizaciones mayores del núcleo o actualizaciones de plugins pesados que ejecutan migraciones de base de datos), el proceso PHP puede tardar más de lo que permiten los timeouts configurados en Nginx o PHP-FPM. La solución es aumentar fastcgi_read_timeout a 300 segundos temporalmente antes de hacer la actualización, y reducirlo de vuelta una vez completada.

¿Qué diferencia hay entre el error 502 y el error 504?

Ambos los genera el servidor proxy cuando no recibe una respuesta válida del servidor de aplicación, pero por razones distintas. El 502 ocurre cuando el servidor de aplicación responde con algo inválido o cierra la conexión inesperadamente (está caído o roto). El 504 ocurre cuando el servidor de aplicación no responde dentro del tiempo límite configurado en el proxy (está vivo pero demasiado lento). En la práctica: si PHP-FPM está caído, verás 502; si PHP-FPM está vivo pero procesando una consulta lenta que supera el timeout, verás 504.