Pocas cosas generan más ansiedad en un equipo de TI que un error 502 Bad Gateway o 504 Gateway Timeout. Cuando el proxy inverso muestra esto, significa que cortó la comunicación con tu aplicación, pero no te dice por qué.

En REACTIV, nuestro enfoque para el troubleshooting es metódico. Adivinar reiniciando contenedores al azar solo alarga el tiempo de caída (Downtime). Aquí tienes nuestro manual de diagnóstico rápido.

Entendiendo al enemigo: 502 vs 504

  • 502 Bad Gateway: El proxy intentó conectarse al servicio interno (upstream), pero este rechazó la conexión o la cerró de golpe.
  • 504 Gateway Timeout: El proxy se conectó al servicio, le hizo una petición, pero el servicio tardó demasiado en responder y el proxy se rindió.

La lista de verificación paso a paso (El método de las capas)

  1. La capa de aplicación (¿Está vivo el servicio?): Revisa los logs del contenedor final (ej. docker logs mi-app). ¿Se quedó sin memoria? ¿Está reiniciándose en un loop infinito? Si la app está caída, el proxy siempre dará 502.
  2. La capa de red interna (¿Se pueden ver?): Si usas Docker, asegúrate de que el proxy y la aplicación compartan la misma red de Docker (docker network). Un error clásico es tener el proxy en la red proxy-net y la aplicación en app-net.
  3. La capa de resolución de nombres (DNS interno): ¿El proxy está intentando llegar a app:8080? Entra a la consola del proxy (docker exec -it proxy sh) y haz un ping app. Si no resuelve la IP interna, el problema es de DNS de Docker, no de tu código.
  4. La capa de la base de datos (El culpable silencioso del 504): Casi todos los errores 504 ocurren porque la aplicación web está esperando que una consulta lenta (query) de la base de datos termine. Revisa los logs de tu MySQL/PostgreSQL. Si la base de datos está bloqueada, la app se cuelga y el proxy arroja 504.

Cómo puede ayudarte REACTIV

Resolver incidentes rápido requiere observabilidad y experiencia. Te ayudamos a:

  • Implementar paneles de monitoreo que separen las métricas del proxy de las de la aplicación.
  • Configurar logs estructurados para que rastrear una petición desde el cliente hasta la base de datos sea trivial.
  • Entrenar a tu equipo en metodologías de troubleshooting para que dejen de “reiniciar a ver si se arregla”.
  • Brindar soporte nivel 3 para incidentes complejos en infraestructura Linux y Docker.
ObservabilidadProxyRedesSysadminTroubleshooting