Cloudflare Quick Tunnels: localhost en Internet con un comando, lo que no cuenta la portada y las alternativas open source

Un vistazo en 30 segundos

• Un Quick Tunnel de Cloudflare publica un servidor local con un solo comando, cloudflared tunnel --url http://localhost:8000, sin cuenta, sin DNS y sin abrir puertos. En nuestra prueba, la URL pública respondía a los 10 segundos.
• Funciona porque la conexión sale de tu máquina hacia Cloudflare. Nadie entra por el router. Pero el HTTPS termina en Cloudflare: el tráfico viaja en claro dentro de su red.
• La portada no lo dice, pero la documentación sí: 200 peticiones simultáneas como máximo, sin Server-Sent Events, sin SLA y una URL nueva cada vez. Es una herramienta de desarrollo, no de producción.
• Desde septiembre de 2026, cloudflared crea túneles protegidos: solo entra quien valide un código enviado a un correo o dominio que tú autorices. Todavía no está en la documentación.
• Los atacantes lo usan desde hace años para servir malware. Si gestionas una red corporativa, decide a propósito si trycloudflare.com debe resolverse en ella.
• Alternativas: ngrok, Tailscale Funnel y Microsoft dev tunnels como servicio. Y, si quieres que el tráfico no pase por un tercero, frp, rathole, sish, zrok o Pangolin en un servidor tuyo.

---

Cloudflare ha estrenado una página propia para sus túneles rápidos, try.cloudflare.com, con un mensaje directo: pon localhost en Internet. El servicio no es nuevo: lleva años funcionando con el nombre de TryCloudflare. Lo nuevo es el enfoque. La página ya no habla solo de enseñar una maqueta a un compañero. Habla de recibir webhooks, lanzar pruebas de navegador y dar a un agente de programación una URL real con la que trabajar.

La idea es buena y funciona. La hemos probado con la última versión de cloudflared (2026.9.3, del 24 de septiembre). Pero la portada vende la mitad de la historia. Aquí va la otra mitad: qué pasa por debajo, qué límites tiene, por qué a los equipos de seguridad no les hace ninguna gracia y qué alternativas existen, incluidas las que puedes montar en tu propio servidor.

Qué hace exactamente un Quick Tunnel

Arrancas cualquier servidor web local y, en otra terminal, ejecutas:

cloudflared tunnel --url http://localhost:8000

cloudflared pide a Cloudflare un subdominio aleatorio de trycloudflare.com y abre una conexión cifrada de salida hacia el centro de datos de Cloudflare más cercano. Cuando alguien visita la URL, la petición llega al borde de Cloudflare, baja por esa conexión ya abierta hasta tu máquina y la respuesta sube por el mismo camino. Tu router no acepta nada entrante. Por eso funciona detrás de NAT, de un cortafuegos corporativo o de un operador con CG-NAT, donde abrir un puerto hacia casa es imposible.

Lo que vimos al lanzarlo desde Madrid:

• La URL tarda unos 10 segundos en aparecer (cuatro palabras al azar, del tipo released-plate-matters-governance.trycloudflare.com) y responde con un 200 casi al instante.
• La conexión cayó una vez en París (cdg09) y otra en Madrid (mad01). No eliges tú dónde.
• Un túnel rápido abre una sola conexión con el borde (ha-connections:1). Un túnel con nombre, de los de cuenta, abre cuatro. Si esa conexión se cae, el túnel se cae con ella.
• cloudflared negocia el canal con X25519MLKEM768, el intercambio de claves híbrido poscuántico. Es el mismo que ya trae por defecto el SSH de las distribuciones actuales.
• Usa QUIC por el puerto 7844 UDP. Si la red lo bloquea, pasa a HTTP/2 por el 7844 TCP. En una de las pruebas lo detectó solo y avisó en el arranque.
• Cloudflare añade x-robots-tag: none a las respuestas, así que los buscadores no indexan estas URLs.

Dónde se descifra el tráfico

Este es el punto que la portada pasa por alto. El visitante negocia HTTPS con Cloudflare, no con tu máquina. Cloudflare descifra la petición en su borde y la vuelve a cifrar dentro del túnel. Es el mismo modelo que su CDN y que sus túneles de pago. Entre medias, el contenido está en claro en la infraestructura de una empresa estadounidense sujeta a la CLOUD Act.

Para enseñar una maqueta no importa. Para una aplicación interna con datos de clientes, datos de salud o algo que caiga bajo el RGPD o el ENS, sí importa. Y es precisamente lo que alguien acaba publicando con prisa un viernes por la tarde.

Lo nuevo de 2026: salida para agentes y túneles protegidos

--output json

La página presume de una salida «lista para agentes»: añades --output json y un programa puede leer el resultado. Funciona, pero conviene saber qué hace. La opción cambia el formato de los registros. Cada línea pasa a ser un objeto JSON. La URL no llega en un campo propio: en la versión 2026.9.3 viene dentro del texto de un mensaje, enmarcada en el recuadro de siempre. Para capturarla hay que buscarla con una expresión regular:

cloudflared tunnel --url http://localhost:8000 --output json 2>&1 \
  | grep -o -m1 'https://[a-z0-9-]*\.trycloudflare\.com'

Es cómodo para un agente que levanta un servidor de pruebas y necesita pasar la URL a otra herramienta. Pero no es la API estructurada que sugiere la portada.

Túneles protegidos por correo

La novedad importante no está en la portada ni en la documentación, que a 30 de septiembre sigue sin mencionarla. Está en las notas de versión de cloudflared de septiembre: los túneles rápidos protegidos. Se activan con una opción:

cloudflared tunnel --url http://localhost:8000 --allowed-mail "*@tuempresa.es"

--allowed-mail admite direcciones concretas o dominios con comodín, separados por comas o repetidos. Con ella, el aviso de arranque cambia a «Your protected quick Tunnel has been created» e indica autenticación por código de un solo uso con Cloudflare Access. Al pedir la URL sin sesión, la respuesta ya no es la página, sino un 302 hacia login.trycloudflare.com. Allí el visitante escribe su correo y recibe un código. Según las notas de versión, cloudflared valida la sesión antes de pasar la petición a tu servidor y elimina los datos de autenticación antes de reenviarla.

Es un cambio sustancial. La principal objeción a los túneles rápidos era que cualquiera con la URL veía lo que hubiera detrás. Ahora se puede limitar a tu dominio sin crear cuenta. Eso sí: sigue siendo una función sin documentar, en un servicio sin garantías. Úsala para enseñar algo a un cliente, no como el control de acceso de nada que importe.

Los límites que están en la documentación y no en la portada

La página de Quick Tunnels de la documentación es clara:

• 200 peticiones en vuelo como máximo. A partir de ahí, Cloudflare responde con un 429. Basta para una demo, no para una prueba de carga ni para una campaña.
• Sin Server-Sent Events (SSE). Parece un detalle y no lo es. SSE es lo que usan las interfaces de chat que muestran la respuesta de un modelo de IA palabra a palabra, muchos paneles en tiempo real y el transporte HTTP de bastantes servidores MCP. Si tu aplicación depende de eso, un túnel rápido no sirve.
• Sin SLA ni garantía de disponibilidad. Cloudflare dice expresamente que usa estos túneles para probar funciones nuevas antes de llevarlas a sus clientes de pago.
• No conviven con un config.yaml. Si tienes uno en ~/.cloudflared, el túnel rápido no arranca hasta que lo renombres.
• La URL cambia en cada arranque y el túnel muere con el proceso. Si la pegaste en la configuración de un webhook, tendrás que actualizarla cada vez.
• Y en el arranque, el propio cloudflared recuerda que estos túneles están sujetos a los términos de uso de Cloudflare y que Cloudflare se reserva el derecho a investigar su uso.

La salida que propone Cloudflare para todo esto es crear una cuenta, usar un dominio propio con sus DNS en Cloudflare y montar un túnel con nombre. No tiene los límites anteriores y el plan gratuito lo cubre. Pero entonces ya no es «sin cuenta y sin configuración», y el tráfico sigue descifrándose en su red.

Para qué sí y para qué no

Encaja cuando el túnel dura lo que dura una tarea:

• Enseñar a un cliente o a un compañero una rama en desarrollo, sin desplegarla.
• Recibir los webhooks de Stripe, GitHub o un proveedor de pagos en tu máquina mientras programas la integración.
• Probar una web desde un móvil real o desde otro país.
• Dar a un agente de programación un endpoint público durante una sesión, sabiendo que cae cuando termina.

No encaja en cuanto aparece la palabra «permanente»:

• Publicar una aplicación interna «mientras tanto». Esos «mientras tanto» se quedan años.
• Cualquier cosa con datos personales o regulados, por el punto de descifrado y porque no hay registro de quién ha entrado.
• Dar acceso remoto al equipo. Para eso existe una VPN propia o, si hay varias sedes, una red entre sedes bien diseñada.

Por qué tu equipo de seguridad lo mira con recelo

Lo que hace cómodo a un túnel rápido para un desarrollador lo hace igual de cómodo para un atacante: no hay cuenta, no hay rastro y el dominio pertenece a una empresa en la que todo el mundo confía. En agosto de 2024, Proofpoint documentó campañas que usaban túneles de trycloudflare.com para alojar la carga y repartir troyanos de acceso remoto como Xworm, AsyncRAT o Remcos. Las observaba desde febrero de ese año. Hablaba de volúmenes de cientos a decenas de miles de correos por campaña, contra organizaciones de todo el mundo, también con señuelos en español.

Hay un segundo riesgo, más doméstico: el shadow IT. Alguien de la plantilla publica el panel interno o el entorno de pruebas con un comando, desde su portátil, y no lo sabe nadie más.

Si gestionas una red corporativa, estas medidas cuestan poco:

1. Decide si trycloudflare.com debe resolverse en tu red. Si nadie lo necesita, bloquéalo en el DNS o en el proxy. Cortas a la vez la salida de tus equipos y el acceso a cargas maliciosas alojadas ahí.
2. Vigila la salida al puerto 7844, TCP y UDP. Es el que usa cloudflared para llegar a Cloudflare. Si tenéis túneles con nombre legítimos, permitidlo solo desde los servidores que los ejecutan.
3. Inventaría el binario. cloudflared, ngrok o frpc en un portátil que no es de desarrollo merecen una pregunta.
4. Ofrece una vía oficial. Si el equipo de desarrollo necesita enseñar cosas hacia fuera, dale un servidor de túneles propio o un servicio aprobado. Si no lo tiene, lo buscará por su cuenta.

Estas herramientas no son maliciosas: sirven igual para lo bueno que para lo malo. Pero los antivirus no siempre distinguen. frp, por ejemplo, lleva años marcado como amenaza por Microsoft Defender y otros (el último aviso en su repositorio es de mayo de 2026). Al descargarlo en un Mac para preparar este artículo, los binarios desaparecieron del disco en cuanto intentamos ejecutarlos.

Alternativas como servicio

Si quieres la misma comodidad con otras condiciones, estas son las opciones más usadas. Precios y límites comprobados el 30 de septiembre de 2026:

Dos detalles. localhost.run y Pinggy no necesitan instalar nada, porque usan el cliente SSH que ya trae cualquier sistema: ssh -R 80:localhost:8080 localhost.run y listo. Y Tailscale Funnel tiene sentido si tu equipo ya usa Tailscale, porque decide quién puede publicar desde la misma política que el resto de la red.

Todas comparten el problema de fondo: el tráfico entra por la red de otra empresa, casi siempre estadounidense, y se descifra allí. La única excepción es el paso TLS directo de algunos planes.

Alternativas open source que puedes alojar tú

La otra vía es montar tu propio «Cloudflare en pequeño»: un servidor con IP pública que recibe las visitas y un cliente en tu máquina que abre la conexión de salida hacia él. El esquema es el mismo, pero el punto de descifrado es tuyo, igual que los registros y el dominio. La URL no caduca y nadie más ve el tráfico. A cambio, ese servidor lo mantienes tú.

Estado de los proyectos a 30 de septiembre de 2026, según sus repositorios:

Tres notas antes de elegir:

• rathole sigue recibiendo cambios en el código (el último, en agosto de 2026), pero no publica una versión etiquetada desde octubre de 2023. Tenlo en cuenta si dependes de binarios oficiales.
• localtunnel, el clásico de Node.js que aparece en muchos tutoriales, no recibe cambios desde agosto de 2025. Para algo nuevo, mejor otra opción.
• Pangolin es open core: la edición Community es AGPL-3.0 y la Enterprise tiene licencia comercial, gratuita para uso personal y para empresas que facturen menos de 100.000 dólares al año. Es la más completa del grupo porque añade usuarios, políticas y acceso a SSH o RDP desde el navegador. También es la que más cuesta mantener.

frp en un servidor propio, en lo mínimo

frp es el caso más habitual y el que mejor documentado está. Necesitas un servidor con IP pública (un VPS pequeño basta) y un dominio con un registro comodín *.dev.tuempresa.es apuntando a él. En el servidor:

# frps.toml
bindPort = 7000
vhostHTTPPort = 8080
auth.method = "token"
auth.token = "un-secreto-largo-y-aleatorio"
transport.tls.force = true

En tu máquina:

# frpc.toml
serverAddr = "tunel.tuempresa.es"
serverPort = 7000
auth.method = "token"
auth.token = "un-secreto-largo-y-aleatorio"

[[proxies]]
name = "demo"
type = "http"
localPort = 8000
customDomains = ["demo.dev.tuempresa.es"]

La conexión entre frpc y frps va cifrada con TLS por defecto desde la versión 0.50.0, y transport.tls.force impide que el servidor acepte clientes sin él. Para servir HTTPS a los visitantes, lo más sencillo es poner Caddy delante, en el puerto 443, con un reverse_proxy 127.0.0.1:8080: gestiona los certificados solo. Al abrir los puertos del servidor, abre el 443 y el 7000. El 8080 debe quedar solo en local. Y guarda el token fuera del fichero con auth.tokenSource en cuanto esto deje de ser una prueba.

Estas configuraciones siguen la documentación oficial de frp 0.71. Antes de usarlas, pásalas por frps verify -c frps.toml y frpc verify -c frpc.toml.

Cómo elegir

• Una demo de diez minutos, un webhook mientras programas: Quick Tunnel. Si hay algo delicado detrás, con --allowed-mail.
• Lo mismo, pero con URL fija y sin límites raros: un túnel con nombre de Cloudflare o ngrok de pago, sabiendo que el tráfico pasa por ellos.
• El equipo ya usa Tailscale: Funnel, y la política de quién publica sale de la misma consola.
• Varias personas publican a menudo, o hay datos que no deben salir de tu infraestructura: un servidor propio con frp o sish si basta con publicar, o con zrok o Pangolin si además hace falta decidir quién entra.
• Algo que tiene que estar siempre arriba: ninguno de los anteriores. Una aplicación de producción no se sirve desde un portátil a través de un túnel. Se despliega en un servidor, con su copia de seguridad y su monitorización.

Lo que nos llevamos

Los Quick Tunnels resuelven bien un problema real: sacar algo de localhost durante un rato sin pelearse con el router. La versión de septiembre los mejora de verdad con el modo protegido. Pero conviene usarlos sabiendo tres cosas: el tráfico se descifra en la red de Cloudflare, la documentación los limita a pruebas y la misma comodidad la aprovecha quien reparte malware.

La pregunta útil no es qué herramienta de túneles es mejor. Es qué parte del tráfico te importa que pase por un tercero. Si la respuesta es «ninguna», el servidor de túneles tiene que ser tuyo, y eso pide una máquina con IP pública, un dominio y alguien que la mantenga. Si quieres montarlo junto al resto de tu infraestructura en un cloud privado en España, o repasar qué está publicando hoy tu equipo sin que lo sepas desde ciberseguridad, cuéntanos cómo lo tienes.

Preguntas frecuentes

¿Hace falta una cuenta de Cloudflare para usar un Quick Tunnel?

No. Basta con instalar cloudflared y ejecutar cloudflared tunnel --url http://localhost:PUERTO. La URL aleatoria de trycloudflare.com sale en la terminal. La cuenta solo hace falta para los túneles con nombre, con dominio propio y sin los límites del túnel rápido.

¿Es seguro un Quick Tunnel?

La conexión va cifrada y no abre puertos en tu red, pero hay dos matices. Cualquiera que tenga la URL ve lo que publicas, salvo que uses el modo protegido con --allowed-mail. Y el HTTPS termina en Cloudflare, que ve el tráfico descifrado. Para una demo es suficiente. Para datos personales o regulados, no.

¿Qué límites tiene un túnel de trycloudflare.com?

Según la documentación de Cloudflare: 200 peticiones simultáneas (a partir de ahí responde con un error 429), sin soporte para Server-Sent Events y sin garantía de disponibilidad. Además, la URL cambia cada vez que arrancas el túnel, que solo abre una conexión con Cloudflare y se cierra al terminar el proceso.

¿Cuál es la mejor alternativa open source a Cloudflare Tunnel?

Depende de lo que necesites. Para publicar servicios desde tu propio servidor, frp es la opción más usada y mejor documentada, y rathole es la más ligera. sish permite usar solo ssh como cliente. Si además quieres controlar quién entra, con usuarios y políticas, zrok y Pangolin son las más completas.

¿Por qué mi antivirus borra frp o cloudflared?

Porque los atacantes también usan herramientas de túneles para sacar datos o mantener acceso a una red. Microsoft Defender y otros antivirus marcan frp como herramienta potencialmente peligrosa desde hace años. Si lo necesitas, descárgalo de la página oficial de versiones, comprueba el hash y pide a quien gestione la seguridad del equipo que lo autorice. No desactives la protección.

¿Puedo bloquear los Quick Tunnels en la red de mi empresa?

Sí. Bloquear la resolución de trycloudflare.com en el DNS o en el proxy impide tanto que los equipos creen túneles rápidos como que se descarguen cargas alojadas en ellos. Para cortar también los túneles con nombre, hay que controlar la salida al puerto 7844, TCP y UDP, que es por donde cloudflared se conecta con Cloudflare.

Fuentes

• Cloudflare, Quick Tunnels: la página de presentación con el comando, la arquitectura de solo salida y la opción --output json.
• Cloudflare, Quick Tunnels en la documentación de Cloudflare One (actualizada el 20 de abril de 2026): límite de 200 peticiones en vuelo, sin SSE, sin SLA y la incompatibilidad con config.yaml.
• Cloudflare, Tunnel with firewall: el puerto 7844 en TCP y UDP y los destinos a los que se conecta cloudflared.
• Cloudflare, notas de versión de cloudflared: túneles rápidos protegidos, política de destinatarios, autenticación antes de llegar al origen y la opción --allowed-mail (versiones 2026.8.3 a 2026.9.2, del 28 de agosto al 24 de septiembre de 2026).
• Proofpoint, Threat Actor Abuses Cloudflare Tunnels to Deliver RATs (1 de agosto de 2024): campañas de Xworm, AsyncRAT, VenomRAT, GuLoader y Remcos a través de trycloudflare.com.
• ngrok, precios: límites del plan gratuito y el plan Hobbyist de 10 dólares al mes (8,8 € al cambio del BCE del 30 de septiembre de 2026, 1,1355 dólares por euro).
• Tailscale, Tailscale Funnel: disponible en todos los planes, puertos 443, 8443 y 10000 y ancho de banda limitado.
• Microsoft, What are dev tunnels?: acceso privado por defecto con cuenta de Microsoft, Entra ID o GitHub.
• localhost.run, documentación: túneles con el cliente SSH del sistema, sin cuenta para dominios aleatorios.
• Pinggy, página del servicio: límite de 60 minutos por túnel en el plan gratuito.
• fatedier, frp: configuración TOML, autenticación por token y TLS activo por defecto desde la 0.50.0; e issue #5327 (mayo de 2026) sobre la detección de Microsoft Defender.
• Fossorial, Pangolin: licencia dual AGPL-3.0 y comercial, y condiciones de la edición Enterprise.
• Repositorios de rathole, bore, sish, zrok, Expose, chisel y localtunnel: licencias, versiones y actividad consultadas en la API de GitHub el 30 de septiembre de 2026.

Los tiempos, la ubicación de las conexiones, el intercambio de claves, la cabecera x-robots-tag, el formato de --output json y la redirección del modo protegido los hemos comprobado con cloudflared 2026.9.3 en macOS el 30 de septiembre de 2026, con túneles de prueba que sirvieron una página estática y se cerraron al terminar.