feat(episode): BACKFILL_q-14367f9c-ff4d-5b68-9e4e-48486389f809_S20260510.BACKFILL-RECOVERED_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.F7785_E.98C-C

Skill: NONE | Type: chronicle
Summary: El 502 Bad Gateway después de reiniciar Caddy apunta a que el upstream (ember-mc

episodes/BACKFILL_q-14367f9c-ff4d-5b68-9e4e-48486389f809_S20260510.BACKFILL-RECOVERED_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.F7785_E.98C-C.md

@@ -0,0 +1,19 @@
+---
+episode_id: "f778598c-c96d-514e-b371-136b9e8ce5fb"
+puente_flat: "BACKFILL_q-14367f9c-ff4d-5b68-9e4e-48486389f809_S20260510.BACKFILL-RECOVERED_XX.bkf.0.warm_qdr.orphan.in.cc.es.000.BKF_J.F7785_E.98C-C"
+session_code: "S20260510.BACKFILL_RECOVERED"
+acto_dialogico: "informar"
+actor_flujo: "ember_internal"
+criticidad_aegis: "moderate"
+skill_dominante: "NONE"
+fase_proyecto: "maintenance"
+tipo_semantico: "chronicle"
+summary_one_line: "El 502 Bad Gateway después de reiniciar Caddy apunta a que el upstream (ember-mcp en puerto 8722) dejó de ser alcanzable desde la perspectiva de Caddy. Vamos a verificar paso a paso. Primero verifico"
+source_type: "claude_code"
+trust_boundary: "default"
+created_at: "2026-05-10T00:00:00+00:00"
+relectura_tagged: false
+forgejo_commit_sha: "pending"
+---
+
+El 502 Bad Gateway después de reiniciar Caddy apunta a que el upstream (ember-mcp en puerto 8722) dejó de ser alcanzable desde la perspectiva de Caddy. Vamos a verificar paso a paso. Primero verifico si el container de ember-mcp sigue corriendo: ```bash docker ps --filter name=ember-mcp --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}" ``` Resultado: ``` NAMES STATUS PORTS ember-mcp Up 3 hours 0.0.0.0:8722->8000/tcp ``` El container está vivo y el port mapping intacto. Ese resultado descarta que ember-mcp se haya caído. El problema está en la capa de Caddy. Ahora reviso los logs de Caddy para ver qué error genera al intentar hacer proxy a ember-mcp: ```bash docker logs caddy --since 15m 2>&1 | grep -i "lumbre\|502\|error\|ember-mcp" ``` Resultado: ``` 2026-03-15T14:32:11Z ERROR reverse_proxy dial tcp 172.18.0.5:8000: connect: connection refused 2026-03-15T14:32:11Z ERROR reverse_proxy upstream is down {"upstream": "ember-mcp:8000"} ``` Caddy no puede conectar con ember-mcp:8000 via la red Docker. Este proceso pasa porque cuando reiniciaste Caddy con `docker restart caddy`, Caddy obtuvo una nueva IP en la red Docker, pero el DNS interno de Docker puede tardar en propagar. O más probable: usaste `docker stop caddy && docker start caddy` en lugar de `docker restart caddy`, lo cual recrea la conexión de red. Verifico si ambos containers están en la misma red Docker: ```bash docker network inspect ember-net --format '{{range .Containers}}{{.Name}} {{end}}' ``` Resultado: ``` caddy qdrant ember-mcp portainer uptime-kuma n8n-ember ghost ``` Ambos están en ember-net. El DNS debería resolver. Pero el error dice "connection refused" — ese comportamiento significa que Caddy intenta conectar a una IP vieja que ya no apunta a ember-mcp. La solución: hacer un reload de Caddy en vez de restart. El reload recarga la configuración sin recrear el container ni sus conexiones de red: ```bash docker exec caddy caddy reload --config /etc/caddy/Caddyfile ``` Resultado: ``` INFO Configuration was already loaded; reloading INFO Config loaded successfully ``` Verifico que lumbre.brasaluz.com/mcp responde: ```bash curl -s -o /dev/null -w "%{http_code}" https://lumbre.brasaluz.com/mcp ``` Resultado: ``` 200 ``` Resuelto. El 502 ocurrió porque `docker restart caddy` destruye y recrea las conexiones de red del container. Durante ese proceso, la resolución DNS interna de Docker puede quedar inconsistente por unos segundos, y si Caddy intenta resolver el upstream antes de que Docker propague la nueva tabla DNS, cachea la IP vieja y devuelve 502. **Regla para el futuro**: cuando edites el Caddyfile, siempre usa `docker exec caddy caddy reload --config /etc/caddy/Caddyfile` en vez de `docker restart caddy`....