Formato nuevo
502 Bad Gateway: qué significa y qué hacer
502 Bad Gateway significa que un proxy o gateway (a menudo nginx o un CDN) no recibió una respuesta válida del upstream — PHP, Apache o tu app.
No es una «penalización SEO». Un sitio que se queda caído sigue perdiendo tráfico y crawl mientras el error cuelga. Abajo: causas comunes y qué revisar.
Causas típicas
PHP-FPM o la app está caída o no responde, expiró un timeout de upstream, el servidor está sobrecargado, la config del proxy está rota, el CDN falla, o el SSL entre proxy y backend se rompe.
La misma página puede devolver 502 solo bajo carga — por ejemplo una query pesada a la base que ata todos los workers. Anota la hora exacta y la URL; un screenshot de la página de error solo no basta.
A menudo aparece después de:
- un deploy o cambio de config
- un pico de tráfico
- plugins de CMS atascados
- tocar límites del hosting
Cómo arreglarlo
Revisa el estado del hosting y tu monitor de uptime. Lee logs de nginx o Apache y logs de PHP. Reinicia el pool PHP o el contenedor solo según tu procedimiento habitual. Desactiva un plugin de CMS recién instalado si el timing encaja con el error.
No empieces cambiando DNS, versión de PHP o una docena de ajustes al azar. Localiza primero la capa: CDN, web server, app, base de datos o una API externa. Así el arreglo no oculta la causa — ni crea una nueva.
Orden de chequeos:
- confirma 502 desde fuera (`curl -I`)
- logs del gateway y de la aplicación
- carga de CPU, RAM y disco
- timeouts de upstream
- rollback del último cambio
Prevención
Necesitas monitoring de uptime, límites sensatos, staging antes del release, caché y colas para trabajos pesados, y algo de holgura de recursos.
No mires solo la home. Incluye checkout, login, formularios, APIs y unas cuantas páginas de categoría clave — a menudo estresan la app distinto que una home estática.
Para el equipo SEO:
- alerta cuando URLs clave devuelven 5xx
- no confundas 502 con un filtro de búsqueda
- tras la recuperación, revisa la indexación de páginas importantes
Diagnóstico vía logs y métricas
En el log del proxy, encuentra la petición por hora, URI e id de request, luego crúzala con el log de la app. Mensajes sobre connect() failed, premature response, timeout o workers agotados te dicen dónde cavar después.
Las métricas ayudan a separar un blip puntual de un issue sistémico. Mira CPU y memoria, espacio en disco, conteo de procesos, tiempo de respuesta de la base y la cola de peticiones antes, durante y después del incidente.
Antes de avisar a un developer o al host, prepara:
- URL exacta y hora con timezone
- código de estado y con qué frecuencia se repite
- trozos de log sin contraseñas ni tokens
- lista de releases recientes y cambios de config
Qué revisar tras la recuperación
Tras el arreglo, vuelve a pegar las URLs desde fuera, en ventana privada y vía monitoring. Asegura que el error no desapareció solo en un nodo o en caché local — y que los flujos clave de usuario siguen funcionando.
Si bots y visitantes vieron 502 durante un tramo largo, revisa informes de webmaster y tendencias de crawl. No pidas recrawl automático de miles de URLs hasta que la respuesta del servidor sea estable.
Cierra el incidente cuando:
- varios checks devuelven los códigos esperados
- carga y errores de log vuelven a verse normales
- causa y acciones quedan anotadas
- hay una alerta clara ante una repetición
FAQ
¿El 502 es un problema SEO?
De forma indirecta: bots y visitantes no pueden ver la página. Un downtime largo duele. El código en sí habla de infraestructura, no de un filtro de ranking.
¿En qué se diferencia de 500 y 504?
500 es un error de aplicación. 504 significa que el gateway agotó el tiempo de espera. 502 significa que la respuesta del backend faltaba o estaba rota.
¿Puede verlo un visitante y yo no?
Sí — caché local, otro POP del CDN o un blip corto. Revisa en ventana privada y con un check externo de uptime.
¿Cambiar DNS lo arregla al momento?
Rara vez como primeros auxilios. Empieza por logs, estado del backend y límites de PHP o workers.
¿Debes hacer redirect alrededor de un 502?
No. Arregla el servidor o la app. No tapes un 502 con un redirect.
¿Debes vaciar caché ante un 502?
Solo si tienes motivo para pensar que se cacheó una respuesta mala. Vaciar caché no sustituye revisar backend, logs y límites.
¿Cuándo contactar al soporte del hosting?
De inmediato si no tienes acceso al servidor o los logs muestran fallos de infraestructura. Envía la hora del error, URL, código de estado y lo que ya revisaste.
¿El sitio devuelve 502 y el soporte solo dice «vacía la caché»?
Localizamos gateway vs backend, leemos logs y restauramos respuestas estables — sin tapar con redirects.
Hablar del proyecto
