Error 502 Bad Gateway en WordPress: causas y soluciones

Índice

1 ¿Qué significa el error 502 Bad Gateway?
2 ¿Por qué pasa esto en WordPress?
3 Diagnóstico paso a paso (sin perder la cabeza)
4 Soluciones que funcionan (de verdad)
5 Cómo evitar que vuelva a pasar
6 Para terminar

¿Qué significa el error 502 Bad Gateway?

El error 502 Bad Gateway es un código de estado HTTP. Básicamente, un servidor que actúa como puerta de enlace o proxy recibió una respuesta no válida desde el servidor upstream (el que realmente aloja tu WordPress). El navegador se queda congelado y muestra cosas como «502 Bad Gateway», «502 Proxy Error» o «502 Server Error».

No es lo mismo que el error 500 (error interno del servidor). El 502 suele ser un problema de comunicación entre servidores. En WordPress con Apache/Nginx + PHP-FPM + MySQL/MariaDB, lo más común son fallos en PHP-FPM, tiempos de ejecución excedidos, plugins o temas que se pelean, o configuraciones mal hechas del servidor web o balanceador.

Si ves este error, respira. Casi siempre se arregla sin perder datos. Aquí te dejo una guía paso a paso para diagnosticar y resolver.

¿Por qué pasa esto en WordPress?

1. PHP-FPM se murió

PHP-FPM (FastCGI Process Manager) es el que ejecuta el código PHP de WordPress. Si el servicio se para, se satura o se queda sin procesos, el servidor web recibe una respuesta vacía o inválida. Y zas, 502. Es la causa número uno en servidores Nginx.

Síntoma: Aparece de repente, sin que hayas tocado nada.
Verificación: Desde SSH, ejecuta systemctl status php-fpm (o php8.x-fpm.service según la versión).

2. Recursos al límite (memoria, tiempo de ejecución)

WordPress o algún plugin se vuelve glotón. Consume más memoria PHP de la permitida, o tarda demasiado. PHP-FPM lo mata, y el servidor responde con 502.

Síntoma: Pasa en páginas con scripts pesados (backups, actualizaciones masivas, importaciones).
Límites típicos: memory_limit 128M-256M, max_execution_time 30-60 segundos.

3. Plugins o temas que se portan mal

Un plugin defectuoso o un tema mal hecho lanzan errores fatales de PHP. Entonces PHP-FPM devuelve una respuesta incorrecta. Y adivina: 502.

Síntoma: El error aparece justo después de instalar o activar algo.
Diagnóstico: Desactiva plugins desactivando archivos vía FTP o renombrando la carpeta wp-content/plugins.

4. Configuración del servidor web o proxy mal hecha

Con Nginx como proxy inverso o balanceadores (HAProxy, Cloudflare), los parámetros de timeout, buffer o tamaño de petición pueden ser demasiado restrictivos. Si un backend tarda más de lo esperado, Nginx o el proxy cortan la conexión y devuelven 502.

Síntoma: Pasa en todas las páginas, hasta en el panel de administración.
Verificación: Revisa logs de Nginx (/var/log/nginx/error.log) y de PHP-FPM.

5. Firewall o reglas de seguridad bloqueando

ModSecurity en Apache, o reglas de iptables/fail2ban, pueden bloquear peticiones legítimas al backend.

Síntoma: Solo en ciertas rutas o para algunos usuarios/IPs.
Solución: Desactiva temporalmente ModSecurity o fail2ban para probar.

Diagnóstico paso a paso (sin perder la cabeza)

Antes de meter mano, identifica la causa exacta. Esto te ahorrará tiempo. Y disgustos.

Revisa los logs. Accede por SSH y ejecuta: tail -f /var/log/nginx/error.log o tail -f /var/log/php-fpm/error.log. Busca «upstream timed out», «connect() failed» o «child exited».
Estado de PHP-FPM. Ejecuta systemctl status php-fpm. Si está inactivo, reinícialo (systemctl restart php-fpm).
MySQL respira? A veces el 502 es porque la base de datos no responde. Prueba con mysqladmin ping o systemctl status mysql.
Accede por FTP o cPanel. Si el panel de administración da 502, renombra la carpeta wp-content/plugins a wp-content/plugins_desactivados. Si el sitio vuelve, el problema es un plugin.

Consejo de viejo: ¿Sin acceso SSH? Pide a tu hosting que active los logs de error en un archivo accesible desde el gestor de archivos. Así ves la línea exacta del fallo.

Soluciones que funcionan (de verdad)

1. Reiniciar servicios

Lo más rápido. A veces es lo único que hace falta. Desde SSH:

Nginx: systemctl restart nginx
PHP-FPM: systemctl restart php-fpm (o systemctl restart php8.2-fpm según versión)
MySQL/MariaDB: systemctl restart mysql

Recarga el sitio. Si el error sigue, pasa al siguiente paso.

2. Subir los límites de PHP

Edita el archivo php.ini (localiza la ruta con php –ini) y sube los valores:

memory_limit = 256M o hasta 512M si tu hosting lo permite.
max_execution_time = 120 (para backups, pon 300).
max_input_time = 120

También puedes hacerlo desde .user.ini en la raíz de WordPress, o en wp-config.php añadiendo define(‘WP_MEMORY_LIMIT’, ‘256M’);. Reinicia PHP-FPM después.

3. Desactivar plugins y tema por defecto

Sin acceso al panel? Usa FTP o el gestor de archivos del hosting. Renombra wp-content/plugins a wp-content/plugins_backup. Si el sitio carga, reactiva los plugins uno por uno renombrándolos de vuelta. Para el tema, renombra la carpeta del tema activo (dentro de wp-content/themes) para forzar a WordPress a usar TwentyTwentyFive (o el tema por defecto).

4. Ajustar tiempos de espera en Nginx

En el bloque server de tu configuración Nginx, aumenta los parámetros proxy:

proxy_connect_timeout 75s;
proxy_send_timeout 300s;
proxy_read_timeout 300s;
fastcgi_read_timeout 300s; (si usas proxy inverso a PHP-FPM)

Recarga Nginx con nginx -t && systemctl reload nginx.

5. ModSecurity y fail2ban

Desactiva temporalmente ModSecurity desde el panel del hosting o desde la configuración de Apache/Nginx. Si el error desaparece, revisa las reglas que bloquean. En fail2ban, verifica con fail2ban-client status y desbloquea tu IP si hace falta.

6. Liberar conexiones de MySQL

Un pico de conexiones satura el servidor. Ejecuta mysqladmin processlist para ver consultas en cola. Si ves muchas en «Locked», reinicia MySQL. Considera un plugin de caché (W3 Total Cache, WP Rocket) para reducir carga.

Cómo evitar que vuelva a pasar

Para no repetir la pesadilla:

Mantén WordPress, plugins y temas actualizados.
Usa monitorización de uptime (UptimeRobot, Pingdom) para alertas.
Vigila recursos del servidor (CPU, memoria, PHP-FPM) con htop o glances.
Configura límites de memoria y tiempo de ejecución desde el principio.
Si usas Nginx, revisa los logs de error periódicamente.
Hazte con un hosting con escalado automático o soporte 24/7.

¿Y si es un ataque DDoS?

Puede ser. Un ataque de denegación de servicio satura los workers de PHP-FPM y provoca 502. Si el error es intermitente y ves picos de tráfico raros, contacta con tu hosting y activa un firewall como Cloudflare.

¿Diferencia entre 502 y 503?

El 503 (Service Unavailable) es que el servidor temporalmente no puede atender, pero el backend funciona. El 502 es que el backend respondió algo incorrecto o no respondió. Ambos se solucionan a veces reiniciando servicios, pero el 502 requiere más análisis del backend.

Para terminar

El error 502 Bad Gateway en WordPress es un problema de comunicación entre servidores. Suena feo, pero casi siempre se arregla con pasos ordenados. Desde reiniciar PHP-FPM hasta subir límites de memoria o desactivar plugins conflictivos. La clave: no actúes al azar. Primero logs, luego soluciones simples, y solo después tocar configuraciones avanzadas.

Si has seguido todo esto y el error sigue, puede ser algo más profundo (balanceadores mal configurados, permisos, versiones de PHP incompatibles). Ahí ya toca llamar a un profesional. En RedServicio (redservicio.net) ofrecemos asistencia técnica especializada para diagnosticar y resolver estos fallos en servidores WordPress. Sin riesgos para tus datos. Contáctanos si necesitas que tu sitio vuelva a funcionar cuanto antes.