Durante años, enseñar un proyecto en local a un cliente, pasar una demo a un compañero o validar un webhook desde casa implicaba casi siempre lo mismo: abrir puertos en el router, pelearse con NAT, o tirar de servicios tipo ngrok. En los últimos meses, sin embargo, una opción se está popularizando entre desarrolladores y perfiles técnicos por su sencillez: Cloudflare Tunnel en modo “Quick Tunnels”, ejecutado desde cloudflared con un solo comando.
La promesa es tentadora y, bien entendida, bastante realista: convertir un servidor local en una URL pública accesible desde cualquier parte del mundo, con HTTPS automático, sin tener que exponer puertos en la máquina ni tocar el firewall doméstico.
Un comando y listo… pero con un matiz importante
El ejemplo que circula en redes suele resumirse así:
brew install cloudflared
cloudflared tunnel --url http://localhost:8080
Lenguaje del código: JavaScript (javascript)Ese segundo comando es la clave: el parámetro --url no apunta a un “dominio local”, sino a la URL local real del servicio que se quiere publicar (por ejemplo, http://localhost:3000, http://127.0.0.1:5173 o http://localhost:8080). Es la fórmula que Cloudflare documenta para arrancar un “Quick Tunnel” de prueba.
Al ejecutarlo, cloudflared crea un túnel efímero y devuelve una URL pública bajo el dominio trycloudflare.com, normalmente ya con HTTPS. Esa dirección se puede compartir al instante para que otra persona vea la web o consuma el endpoint desde fuera.
“Sin registro ni coste”: cuándo es cierto y cuándo deja de serlo
El gancho de “sin registro” se sostiene en el modo Quick Tunnels, donde Cloudflare enfatiza que no hace falta crear cuenta ni preparar ficheros de configuración: un comando y estás online.
Ahora bien, conviene separar dos usos distintos:
- Quick Tunnels (efímeros): pensados para pruebas rápidas, demos y validaciones puntuales. Normalmente no requieren cuenta y la URL suele cambiar cuando se reinicia.
- Túneles “persistentes” con dominio propio: si se quiere una URL estable bajo un dominio del usuario (por ejemplo,
demo.tudominio.com) entonces entra el modo de túnel gestionado: hay que autenticar cloudflared, crear el túnel, configurar DNS/rutas y mantenerlo como servicio. Es el flujo que marca la documentación para “túneles gestionados localmente” y requiere cuenta y zona/dominio en Cloudflare.
En cuanto al coste, la parte básica del ecosistema de Cloudflare incluye un plan gratuito, y los Quick Tunnels están diseñados precisamente como “prueba inmediata”. Aun así, si se entra en dominios propios o en funciones empresariales (controles avanzados, Zero Trust a gran escala, etc.), pueden aparecer límites y condiciones según el plan y el caso.
Por qué gusta a tanta gente: el valor está en lo que no hace falta hacer
El atractivo no es solo la URL bonita. Es lo que te ahorras:
- No hay que abrir puertos en el router ni exponer el servicio directamente a Internet.
- HTTPS viene de serie, algo fundamental cuando se prueban integraciones que exigen TLS (por ejemplo, callbacks, OAuth o webhooks).
- Sirve detrás de NAT y en redes donde publicar un puerto es inviable.
Por eso encaja tan bien en tareas cotidianas: enseñar una web en desarrollo, validar un endpoint desde un móvil en 4G, o comprobar que un sistema externo llega correctamente a tu máquina durante una prueba.
Lo que conviene saber antes de compartir el enlace
Que sea rápido no significa que sea “sin consecuencias”. Publicar un localhost al mundo implica riesgos si se hace sin cuidado:
- No se debería exponer un panel de administración ni entornos con datos reales.
- Si el servicio no está preparado para tráfico externo, pueden aparecer errores, timeouts o comportamientos inesperados.
- En pruebas largas, lo normal es que una URL efímera no sea suficiente: si cambia, rompe integraciones.
Aquí es donde los túneles persistentes (con cuenta) y capas de control de acceso ganan sentido para trabajo serio: no solo por la URL estable, también por poder añadir políticas, autenticación y segmentación por rutas, dependiendo del escenario.
¿Alternativa a ngrok? Sí, pero no es la misma película
En el día a día, mucha gente lo presenta como “ngrok sin líos”. En la práctica, lo que ofrece cloudflared con Quick Tunnels es una salida ultra directa para compartir y probar, mientras que otras herramientas del ecosistema de túneles pueden aportar extras (sesiones con límites, dominios reservados, controles específicos por protocolo, etc.) según proveedor.
Dicho de forma simple: para enseñar algo rápido con HTTPS, cloudflared es difícil de superar por fricción mínima. Para entornos repetibles, equipos grandes o integraciones “de producción”, conviene dar el salto a un túnel persistente con dominio y controles, o valorar alternativas según requisitos.
Preguntas frecuentes
Cómo compartir un servidor local con HTTPS usando cloudflared en macOS
Tras instalarlo con Homebrew, se ejecuta cloudflared tunnel --url http://localhost:PUERTO. El comando genera una URL pública (normalmente bajo trycloudflare.com) con HTTPS automático para acceder al servicio local.
Cloudflare Tunnel “Quick Tunnels” necesita cuenta o registro para funcionar
En el modo Quick Tunnels, Cloudflare indica que no hace falta crear cuenta ni configurar ficheros: se lanza con un comando. Para túneles persistentes con dominio propio, sí se requiere autenticación y configuración del túnel.
Por qué la URL del túnel cambia y cómo tener una dirección estable
Los Quick Tunnels están pensados para pruebas rápidas y la URL puede cambiar al reiniciar. Para una dirección estable, se utiliza un túnel persistente asociado a un dominio y configuración de rutas/DNS.
Es seguro exponer localhost con cloudflared para enseñar una demo a un cliente
Es útil para demos, pero conviene evitar paneles sensibles o datos reales. Si la demo va a durar, se recomienda usar controles de acceso y una configuración persistente, en lugar de un enlace efímero.
fuente: Cloudflare tunnel
