Por qué nadie fuera de tu red puede llegar a localhost

Un proveedor de webhooks necesita una URL a la que hacer POST, y tu servidor está en localhost:3000. O un compañero quiere probar la rama que tienes corriendo, o tu móvil necesita golpear el servidor de desarrollo para revisar un layout. El servidor está levantado. Nada fuera de tu red puede alcanzarlo.

Abrir un puerto en el router funcionaría, pero expone tu IP doméstica y necesita acceso de administrador que muchas veces no tienes. Cloudflare Tunnel toma el camino contrario. cloudflared, un daemon pequeño que corres junto a tu servidor, abre una conexión saliente hacia el borde de Cloudflare, y Cloudflare devuelve el tráfico a través de ella. No abres ningún puerto entrante y no necesitas una IP pública.

Existe en dos formas. Un túnel rápido te da una URL HTTPS pública en un solo comando, con un hostname aleatorio que muere en cuanto detienes el proceso. Esa es la herramienta para una demo de cinco minutos o una prueba de webhook. Un túnel con nombre te da un hostname estable en tu propio dominio que sobrevive a los reinicios, lo que lo convierte en una pieza pequeña de infraestructura real.

Cómo funciona Cloudflare Tunnel sin abrir ningún puerto

El truco es un cambio de dirección. Exponer un servicio normalmente significa abrir un puerto entrante: algo en internet inicia una conexión hacia tu máquina, así que tu máquina necesita una dirección enrutable y una regla de firewall que deje pasar ese tráfico. Bloquear justo eso es para lo que existen el NAT y la mayoría de los firewalls domésticos y de oficina.

cloudflared nunca escucha conexiones entrantes. Marca hacia el borde de Cloudflare por HTTPS saliente normal, el mismo tipo de conexión que tu navegador abre todo el día, y la mantiene abierta. Cloudflare empuja las peticiones por esa conexión y lee las respuestas de vuelta, de forma parecida a como un servidor empuja mensajes por un WebSocket a un navegador que se conectó primero. Tu firewall ve una única conexión saliente que ya permite. Por eso el túnel se comporta igual detrás de NAT o en un portátil sin IP pública: a una conexión saliente no le importa nada de eso.

El coste es que Cloudflare ahora está en medio. El hostname de tu túnel resuelve a Cloudflare, que descifra cada petición en su borde, la vuelve a cifrar y la envía por el túnel hasta tu daemon. Es la misma arquitectura que correr detrás de una CDN o de un reverse proxy: renuncias al acceso directo a cambio de un intermediario que termina el TLS y puede aplicar reglas de acceso antes de que nada llegue a tu máquina.

Cómo crear un túnel rápido con un solo comando

Instala cloudflared primero: brew install cloudflared en macOS, el paquete .deb/.rpm del repositorio de Cloudflare en Linux, o el instalador de Windows desde la página de releases en GitHub. Luego, con algo ya escuchando en un puerto local:

1

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

Unos segundos después obtienes una salida como esta:

1
2
3
4
5

2026-09-23T10:14:02Z INF Thank you for trying Cloudflare Tunnel. Doing so...
2026-09-23T10:14:03Z INF +--------------------------------------------------------------------------------------------+
2026-09-23T10:14:03Z INF |  Your quick Tunnel has been created! Visit it at (it may take some time to be reachable):  |
2026-09-23T10:14:03Z INF |  https://wise-juvenile-pink-recovered.trycloudflare.com                                   |
2026-09-23T10:14:03Z INF +--------------------------------------------------------------------------------------------+

Esa URL sirve HTTPS con un certificado que gestiona Cloudflare, así que nunca tocas la configuración de TLS. Dale unos segundos para que empiece a resolver. A partir de ahí, cualquiera con el enlace llega a tu localhost:3000 hasta que pulses Ctrl-C. El hostname desaparece entonces para siempre, y la siguiente ejecución genera uno nuevo. No inicias sesión, no creas un registro DNS ni necesitas una cuenta.

Los límites son reales, eso sí. El hostname es aleatorio, así que no puedes ponerlo en la config de un webhook que tenga que sobrevivir a un reinicio. Cloudflare limita los túneles rápidos a 200 peticiones concurrentes y no soporta Server-Sent Events en ellos, así que un stream SSE de larga duración se corta. Tampoco hay garantía de uptime: los términos de Cloudflare tratan los túneles rápidos como una comodidad para pruebas, no como un servicio.

Para depurar un webhook ahora mismo o dejar que tu móvil golpee el servidor de desarrollo, con esto te basta. Si tiene que seguir corriendo mañana, monta un túnel con nombre.

Cómo configurar un túnel con nombre en tu propio dominio

Un túnel con nombre necesita una cuenta gratuita de Cloudflare y un dominio cuyo DNS esté en Cloudflare. La configuración se hace una sola vez.

1. Autentica cloudflared contra tu cuenta:

1

cloudflared tunnel login

Esto abre un navegador y te pide elegir el dominio a autorizar. Luego guarda un certificado en ~/.cloudflared/cert.pem, que usan todos los comandos posteriores.

2. Crea el túnel y anota su ID:

1

cloudflared tunnel create my-app

Esto registra un túnel llamado my-app y escribe un archivo de credenciales, <TUNNEL-ID>.json, en ~/.cloudflared/. Ese archivo es la identidad del túnel. Trátalo como un secreto: cualquiera que lo tenga puede hacer pasar tráfico por tu túnel.

3. Escribe la config. Crea ~/.cloudflared/config.yml:

1
2
3
4
5
6
7
8
9

tunnel: my-app
credentials-file: /home/you/.cloudflared/<TUNNEL-ID>.json

ingress:
  - hostname: app.example.com
    service: http://localhost:3000
  - hostname: api.example.com
    service: http://localhost:8080
  - service: http_status:404

ingress es una lista ordenada de reglas hostname-a-servicio, que se evalúan de arriba a abajo. Si tienes nginx configurado como reverse proxy delante de tus apps, es la misma idea de enrutamiento escrita en YAML en lugar de directivas proxy_pass. Un solo túnel puede exponer varios servicios locales en hostnames distintos. La última regla es obligatoria: es el catch-all que devuelve 404 para cualquier hostname que las reglas anteriores no hayan capturado, y cloudflared se niega a arrancar sin ella.

4. Apunta el DNS al túnel:

1

cloudflared tunnel route dns my-app app.example.com

Esto crea un registro CNAME para app.example.com que apunta a <TUNNEL-ID>.cfargotunnel.com. Es resolución DNS normal, dirigida a la infraestructura de túneles de Cloudflare en lugar de a la IP de un servidor. Ejecútalo una vez por cada hostname de tu lista de ingress.

5. Ejecútalo:

1

cloudflared tunnel run my-app

app.example.com ahora sirve lo que sea que escuche en localhost:3000, por HTTPS. Cloudflare termina el TLS en el borde, y tu origen puede quedarse en HTTP plano porque la conexión del túnel ya va cifrada.

Un túnel corriendo en una terminal muere con la terminal. Para que sobreviva a un reinicio, instálalo como servicio del sistema:

1

sudo cloudflared service install

En Linux, al ejecutarlo con sudo, $HOME pasa a ser /root y cloudflared ya no encuentra el config.yml que creaste como tu propio usuario. Apúntalo al archivo explícitamente:

1

sudo cloudflared --config /home/you/.cloudflared/config.yml service install

Esto copia tu config a /etc/cloudflared/config.yml y registra cloudflared con systemd (o launchd, o el gestor de servicios de Windows), así que arranca al inicio y se reinicia si falla.

Cuándo Cloudflare Tunnel no es la herramienta adecuada

Un túnel encaja cuando el tráfico empieza fuera de tu red y tiene que llegar a una máquina sin IP pública, o a una que no quieres exponer directamente: un portátil, un servidor doméstico, una máquina detrás del NAT corporativo. Es la herramienta equivocada en estos casos:

  • Ya tienes un servidor con IP pública. El túnel añade el borde de Cloudflare como un salto extra sin ninguna ganancia. Un registro A de DNS más tu propio reverse proxy o terminación TLS es más simple y tiene una pieza móvil menos que puede fallar.
  • Necesitas latencia baja garantizada o mueves grandes volúmenes de datos. Cada byte pasa por la red de Cloudflare. Para la mayoría del tráfico web ese coste es despreciable; para cargas de alto throughput o sensibles a la latencia, no lo es.
  • Necesitas que el servicio siga arriba cuando una máquina cae. Un único cloudflared en una sola máquina es un punto único de fallo, y service install solo cubre reinicios del proceso. Si ese host muere, el hostname se apaga. La redundancia significa correr el mismo túnel desde una segunda máquina.
  • Tu código confía en la dirección TCP de origen para tomar decisiones de seguridad. Las peticiones llegan a tu origen desde los rangos de IP de Cloudflare. La IP real del cliente viaja en la cabecera CF-Connecting-IP, y cualquier cosa que lea la dirección del socket verá el borde de Cloudflare en su lugar.

Túnel rápido o túnel con nombre: por cuál empezar

Si no tienes claro cuál necesitas, necesitas un túnel rápido. Ejecuta cloudflared tunnel --url http://localhost:<puerto> contra lo que sea que estés trabajando ahora y abre la URL. Pasa a un túnel con nombre cuando choques con uno de sus dos límites reales: un hostname que tenga que sobrevivir a la sesión de terminal, o un servicio que tenga que seguir corriendo sin supervisión.

Artículos relacionados