Recuperar el origen

Vamos a recuperar el mismo lab-app que detuvimos en la práctica, sin crear otro. La terminal del túnel debe seguir activa. Empezá en el host, con este comando para volver a la shell del container, en /workspace:

docker start -ai lab-app

Cuando vuelva Bash dentro de lab-app, iniciá de nuevo Next con el build que ya terminaste:

pnpm start --hostname 0.0.0.0

Dejá Next activo. En otra terminal del host repetí las tres consultas para comprobar cada camino. En la última, reemplazá TU_URL_PUBLICA por el hostname actual del túnel, sin https:// ni rutas:

curl -i http://127.0.0.1:3000/api/health
docker run --rm --network red-taller \
  taller \
  curl -i http://lab-app:3000/api/health
curl -i https://TU_URL_PUBLICA/api/health

Las tres consultas deben devolver HTTP 200 y {"status":"ok","service":"nodoserrano"}. Así podés reconocer que el mismo origen volvió a responder por cada camino. No sigas si alguna capa sigue fallando. Revisá diagnóstico del túnel.

Comprobar un cambio de hostname

Con el origen recuperado, detené sólo el túnel con Ctrl+C en su terminal. Su container se retira por --rm. Comprobá desde el host que la app todavía responde:

curl -i http://127.0.0.1:3000/api/health

Repetí el comando de abrir el túnel en su terminal dedicada. Copiá el hostname que impriman sus nuevos logs y repetí la consulta pública. Puede ser distinto; la URL anterior no es una dirección reservada. Actualizá tus enlaces y, cuando existan, los webhooks que apuntaban al hostname anterior. Dejá app y túnel activos para el próximo ejercicio.

Llevar el concepto a otro proyecto

Fuera de esta práctica, identificá el proceso y su puerto, elegí un endpoint sencillo de health y probá primero el origen. Elegí la dirección correcta desde donde corre cloudflared y cambiá --url. Seguí una request completa y una interrupción. No depende de Next.js ni de estos nombres; no expongas datos privados para repetir la demostración.