Diagnóstico del túnel por capas
Si alguna consulta falla, vamos a buscar el primer tramo que dejó de responder. Usá la terminal de consultas del host y mantené separados los logs de Next y de cloudflared. Antes de cambiar nada, identificá el hostname del arranque actual, el origen http://lab-app:3000 y los containers que pertenecen a esta práctica.
| Síntoma | Primera comprobación |
|---|---|
| Connection refused o falla curl local | Next activo, build terminado y puerto publicado |
| No resuelve lab-app | Nombre correcto y containers en red-taller |
| Falla lab-app:3000 desde la red | Red compartida y escucha 0.0.0.0 |
| Connector no conecta | Salida de red y logs de cloudflared |
| 502 público | Origen activo, puerto y dirección --url |
| 404 u origen sano pero ruta ausente | Path y Route Handler de la aplicación que recibe |
| URL anterior ya no responde | Hostname del último proceso cloudflared |
Empezá por la primera capa que falla, no por la última que muestra un síntoma. Consultá primero host, luego red interna y finalmente URL pública. Si la app está detenida, abrir más túneles no va a recuperarla.
Recordá que 127.0.0.1 pertenece al entorno donde corre el cliente. Dentro de red-taller, el connector necesita llegar a lab-app:3000, no a su propio localhost. Por la misma razón, que la conexión pública esté activa no implica que Next esté disponible.
Si la red ya existe, revisala con docker network inspect red-taller en el host antes de reutilizarla. No borres redes, containers ni volúmenes ajenos. Para un hostname nuevo, actualizá enlaces y sólo los webhooks de esta práctica que aún apunten al anterior.
Cuando recuperes el servicio, compará las respuestas de las tres capas. Deben estar sanas, coincidir y usar el hostname vigente. No sigas si el origen público apunta a otro servicio o devuelve información privada. Detené sólo el túnel de la práctica en su terminal.
Documentación de diagnóstico de Cloudflare.
Volvé a recuperar el origen.