feat(episode): DEPURA_embermcp-devuelve-502-tras-reinicio-de_S20260315.R4_XX.imp.3.hot_inf.pr.fi.es.0RC.HPQ_J.PFDFX_E.SGNCD

Skill: NONE | Type: troubleshooting
Summary: EPISODIO 1 — CADDY: ember-mcp devuelve 502 tras reinicio de Caddy

episodes/DEPURA_embermcp-devuelve-502-tras-reinicio-de_S20260315.R4_XX.imp.3.hot_inf.pr.fi.es.0RC.HPQ_J.PFDFX_E.SGNCD.md

@@ -0,0 +1,19 @@
+---
+episode_id: "988d9988-8da8-46b2-86d4-fabdbdc5845e"
+puente_flat: "DEPURA_embermcp-devuelve-502-tras-reinicio-de_S20260315.R4_XX.imp.3.hot_inf.pr.fi.es.0RC.HPQ_J.PFDFX_E.SGNCD"
+session_code: "S20260413"
+acto_dialogico: "informar"
+actor_flujo: "multi_actor"
+criticidad_aegis: "moderate"
+skill_dominante: "NONE"
+fase_proyecto: "implementation"
+tipo_semantico: "troubleshooting"
+summary_one_line: "EPISODIO 1 — CADDY: ember-mcp devuelve 502 tras reinicio de Caddy"
+source_type: "chat_ember"
+trust_boundary: "private"
+created_at: "2026-04-13T12:07:31.169334+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`....