504 en Coolify: no declares redes propias en el compose

Era medianoche. Todo en mi consola decía que la infraestructura estaba lista. Los contenedores de WordPress y MariaDB reportaban un estado impecable: healthy. Traefik, el guardián de mi tráfico, no arrojaba ninguna queja. Pero al entrar a blog.rafaelmarin.dev, la pantalla se congelaba y arrojaba el temido, frío y silencioso error:

504 Gateway Timeout

Si has estado en esta situación, conoces la frustración. Es ese tipo de error donde no hay una traza de excepción que seguir, no hay un log de PHP llorando por memoria. Todo parece perfecto en la teoría, pero en la práctica nada funciona. Esta es la crónica de cómo una sola línea innecesaria en mi archivo de configuración saboteó mi despliegue, y lo que aprendí sobre el funcionamiento interno de Coolify en el proceso.

---

El espejismo del «Todo OK»

Al desplegar mi blog usando el template oficial wordpress-with-mariadb dentro de Coolify, mi primer impulso de programador meticuloso fue «ordenar» la casa. Abrí la configuración del docker-compose.yml y decidí declarar explícitamente una red propia para aislar mis contenedores:

networks:
  blog-network:
    driver: bridge

services:
  wordpress:
    # ...
    networks:
      - blog-network
  mariadb:
    # ...
    networks:
      - blog-network

Guardé los cambios y le di a Redeploy. Coolify hizo su magia habitual: descargó imágenes, montó volúmenes, levantó la base de datos y por último el blog. El panel se pintó de verde brillante. Pero la web no cargaba.

¿Cómo era posible que WordPress funcionara de forma óptima a nivel interno pero nadie desde internet pudiera acceder a él?

---

El cartero que no encuentra el edificio

Para entender el error 504, primero hay que entender cómo funciona el tráfico en Coolify. Coolify usa Traefik como proxy inverso global. Cuando un usuario escribe tu dominio en su navegador, el tráfico llega a Traefik. Traefik mira su tabla de rutas y dice: «Ah, blog.rafaelmarin.dev debe ser enviado al contenedor X en el puerto 80».

Pero para que Traefik pueda entregar ese paquete de datos, ambos contenedores (Traefik y tu WordPress) deben poder hablar entre sí en la misma red física virtual. Coolify gestiona esto de forma automática creando una red llamada coolify y conectando silenciosamente tu servicio a ella en el momento del despliegue.

Al declarar yo mi propia blog-network de forma explícita y exclusiva, Docker sacó los contenedores del canal común. Los colocó en una isla privada. WordPress y MariaDB podían hablar entre ellos perfectamente en su isla, pero Traefik quedó afuera. Cuando Traefik intentaba enviar el tráfico, se quedaba esperando una respuesta de una dirección IP inalcanzable, hasta que se cansaba y arrojaba el 504.

---

Cómo logré diagnosticarlo (El comando salvador)

Después de dar vueltas en los logs de la base de datos sin éxito, decidí meterme a la terminal del servidor por SSH e inspeccionar directamente qué estaba pasando con la red de Docker:

docker inspect wordpress-emvgnhh7wi2o3cc40vxvsswl --format '{{json .NetworkSettings.Networks}}'

El resultado lo aclaró todo de inmediato:

{
  "blog-network": {
    "IPAddress": "172.18.0.3",
    "Gateway": "172.18.0.1",
    ...
  }
}

La red de Traefik («coolify») no existía por ningún lado en la configuración del contenedor. Había secuestrado mi propio servicio de la red de Coolify.

---

La regla de oro de la automatización

La solución fue tan dolorosamente simple como drástica: **borré por completo la sección de redes del Compose**. Dejé que Coolify se encargara de conectar las piezas.

Una vez eliminado el bloque networks del Compose, le di a redesplegar. Inspeccioné de nuevo el contenedor y esta vez vi la hermosa etiqueta de red coolify compartida. Recargué la web y allí estaba: la pantalla de inicio de WordPress cargando en menos de un segundo.