Consultar health por la URL pública
Vamos a consultar desde Internet el mismo origen que ya respondió por los otros dos caminos. Dejá Next y cloudflared activos, y usá la terminal de consultas del host. Después vamos a comparar también desde el navegador de otro dispositivo. Necesitás la URL que imprimen los logs actuales, no la de un arranque anterior.
En el comando, TU_URL_PUBLICA es un marcador para reemplazar, no una variable de shell. Usá sólo el hostname real de los logs. Por ejemplo, si copiaste https://ejemplo.trycloudflare.com, reemplazalo por ejemplo.trycloudflare.com. El comando ya incluye https:// y /api/health:
curl -i https://TU_URL_PUBLICA/api/healthEsperá HTTP 200 y compará el JSON con el del origen:
{"status":"ok","service":"nodoserrano"}Abrí también la URL pública desde el teléfono u otro navegador. Comprobá la landing, agregá /api/health a esa misma URL y compará el body. Identificá qué terminal mantiene Next y cuál mantiene el túnel.
El diagrama del taller es conceptual y permite seguir la request completa. El cliente llega por HTTPS a Cloudflare. Desde allí, la request viaja por la conexión saliente de cloudflared, que consulta http://lab-app:3000/api/health en la red interna. Next genera la respuesta y ésta vuelve al cliente por el camino inverso. El puerto publicado del host no participa de este recorrido.
| Nombre o ruta | Dónde se interpreta |
|---|---|
| localhost / 127.0.0.1 | Propio entorno de la consulta |
| lab-app | DNS interno de red-taller |
| Hostname trycloudflare.com actual | DNS público hacia Cloudflare |
| /api/health | Ruta dentro de la aplicación, no nombre DNS |
No sigas si la respuesta pública no coincide con el origen o usás hostname de un proceso anterior. Usá diagnóstico por capas, no cambies rutas al azar.