Guía de Cloudflare Tunnel: expón servicios internos sin IP pública

Tue, 23 Jun 2026 20:37:00 +0800

Cloudflare Tunnel es una solución de conexión inversa de Cloudflare. La idea es sencilla: en lugar de abrir puertos públicos de entrada en tu servidor, ejecutas un daemon ligero llamado cloudflared en una máquina interna, y este establece una conexión cifrada saliente hacia Cloudflare.

Con esto, tus servicios web, APIs, entornos de prueba, servidores domésticos, paneles NAS e incluso algunas aplicaciones internas pueden estar disponibles mediante un hostname público gestionado por Cloudflare. El origen no necesita una IP pública, y tampoco hace falta configurar port forwarding en el router.

Documentación oficial:

Qué problema resuelve Cloudflare Tunnel

La forma tradicional de exponer un servicio suele traer varios problemas:

El servidor necesita una IP pública.
El router o firewall en la nube debe abrir puertos de entrada.
La IP de origen puede ser escaneada y atacada directamente.
Las redes domésticas, redes internas y entornos temporales de prueba son incómodos de exponer con HTTPS.
Hay que mantener reverse proxy, certificados, port forwarding y DNS dinámico.

Cloudflare Tunnel cambia la dirección de la conexión. El tráfico externo no llega directamente a tu servidor. En su lugar, tu servidor se conecta hacia Cloudflare. Cuando los usuarios visitan tu dominio, el tráfico entra primero en Cloudflare y luego se reenvía por el Tunnel ya establecido hasta tu servicio local.

Para un uso normal, las ventajas más claras son:

No necesitas IP pública.
No necesitas abrir puertos de entrada.
Puedes ocultar la dirección del origen.
Puedes reutilizar capacidades de Cloudflare como HTTPS, WAF, protección DDoS y Bot Management.
Es una buena opción para publicar servicios web internos de forma segura bajo un dominio real.

Cómo funciona

Un flujo típico de Cloudflare Tunnel es así:

Instalas cloudflared en un servidor, máquina virtual, equipo doméstico o contenedor.
cloudflared se conecta de forma saliente a la red global de Cloudflare.
Creas un Tunnel en el panel de Cloudflare y asignas un hostname público a un servicio local.
Los usuarios visitan ese hostname público.
Cloudflare recibe la solicitud y la reenvía por el Tunnel hasta tu servicio interno.

Por ejemplo, si tienes un servicio local en:

`1`	`http://localhost:8080`

Puedes mapearlo a:

`1`	`app.example.com`

Cuando un usuario visita https://app.example.com, la solicitud pasa primero por Cloudflare y luego llega a http://localhost:8080 en tu máquina.

La documentación de Cloudflare también indica que cada Tunnel mantiene varias conexiones persistentes hacia distintos centros de datos de Cloudflare de forma predeterminada. En producción, también puedes ejecutar varias réplicas de cloudflared para mejorar la disponibilidad.

Casos de uso adecuados

Cloudflare Tunnel encaja especialmente bien en estos escenarios:

Paneles web internos: NAS, Homelab o paneles de administración en una máquina de desarrollo.
Entornos temporales de demo: compartir una aplicación web local todavía en desarrollo.
Servicios autohospedados: publicar APIs, paneles de administración de blogs, dashboards de monitoreo y servicios similares bajo un dominio.
Redes sin IP pública: banda ancha doméstica, redes de campus, intranets corporativas o máquinas detrás de NAT.
Cargas donde quieres ocultar la IP de origen: reducir escaneos directos, intentos de credenciales y ataques contra el origen.
Entrada unificada para múltiples servicios: un Tunnel puede publicar varios hostnames públicos apuntando a servicios locales distintos.

Dicho eso, Cloudflare Tunnel no es un botón mágico de “túnel universal de red interna”. Si quieres publicar servicios no HTTP como SSH, RDP o TCP sin procesar, normalmente también necesitas cloudflared del lado del cliente, o combinarlo con Cloudflare Zero Trust / Access para un modelo de control de acceso más completo.

Si solo quieres publicar un servicio web normal, empezar es muy rápido. Si quieres usarlo como una solución corporativa de acceso privado, también debes diseñar autenticación de identidad, grupos de permisos y políticas de auditoría.

Requisitos previos

Antes de crear un Tunnel para uso formal, conviene revisar lo siguiente:

Tienes una cuenta de Cloudflare.
Tu dominio está gestionado por Cloudflare.
Tienes un servidor, VM, contenedor o máquina local con acceso a internet.
Esa máquina puede llegar a la red de Cloudflare.
Si la red tiene reglas de firewall estrictas, confirma que puede acceder al puerto de conexión saliente usado por Cloudflare Tunnel.

La documentación oficial menciona específicamente revisar el acceso al puerto 7844 de Cloudflare cuando el servidor está en un entorno de red restrictivo.

Crear un Tunnel desde el panel

La forma más sencilla es usar el Cloudflare Dashboard.

Después de entrar al panel, la ruta aproximada es:

`1`	`Zero Trust / Networking -> Tunnels -> Create Tunnel`

Luego sigues las indicaciones:

Selecciona Cloudflare Tunnel.
Ponle un nombre al Tunnel.
Selecciona el sistema operativo y la arquitectura de CPU del servidor.
Copia el comando de instalación generado por Cloudflare.
Ejecuta el comando en el servidor para instalar e iniciar cloudflared.
Vuelve al panel y confirma que el estado del Tunnel sea Healthy.

Cuando el Tunnel aparece como Healthy, tu servidor ya estableció correctamente la conexión con Cloudflare.

Publicar un hostname público

Después de crear el Tunnel, todavía necesitas configurar el enrutamiento. En términos simples, le dices a Cloudflare:

`1`	`qué dominio -> reenviar a qué servicio local`

Por ejemplo:

`1`	`app.example.com -> http://localhost:8080`

URLs típicas de servicios locales pueden ser:

1
2
3

http://localhost:80
https://localhost:443
http://192.168.1.10:8080

Cuando guardas la configuración, Cloudflare crea automáticamente un registro DNS que apunta tu hostname público a una dirección de Tunnel como:

`1`	`<TUNNEL_ID>.cfargotunnel.com`

Los usuarios no necesitan visitar esta dirección directamente. Solo se usa internamente en Cloudflare para enrutar el tráfico del dominio hacia el Tunnel.

Un Tunnel puede publicar varias aplicaciones. Por ejemplo:

1
2
3

nas.example.com      -> http://192.168.1.20:5000
git.example.com      -> http://192.168.1.30:3000
monitor.example.com  -> http://localhost:9090

Así, una sola instancia de cloudflared puede gestionar varios servicios web internos.

Formas comunes de ejecutarlo

En Linux o macOS, el panel de Cloudflare normalmente muestra un comando de instalación de servicio parecido a:

`1`	`sudo cloudflared service install <TUNNEL_TOKEN>`

En Windows es similar:

`1`	`cloudflared.exe service install <TUNNEL_TOKEN>`

Si prefieres Docker, también puedes usar la imagen oficial:

`1`	`docker run cloudflare/cloudflared:latest tunnel --no-autoupdate run --token <TUNNEL_TOKEN>`

El <TUNNEL_TOKEN> es una credencial muy sensible. No lo subas a un repositorio público y no compartas capturas en foros públicos. Quien obtenga ese token podría conectar su propio cloudflared a tu Tunnel.

Quick Tunnel sirve para pruebas temporales

Cloudflare también ofrece un modo temporal más rápido llamado Quick Tunnel.

Ejecuta esto localmente:

`1`	`cloudflared tunnel --url http://localhost:8080`

Genera un subdominio aleatorio de trycloudflare.com para que usuarios externos puedan acceder temporalmente a tu servicio local.

Este modo es útil para:

Demos temporales.
Depurar webhooks locales.
Mostrar una página en desarrollo a un compañero.
Probar sin asociar todavía un dominio de producción.

Pero no es adecuado para producción. Según la documentación oficial, Quick Tunnel tiene limitaciones, como un dominio aleatorio que no controlas, límites de solicitudes concurrentes y falta de soporte para ciertos comportamientos de conexión persistente. Los servicios de producción deberían usar un Tunnel estándar con tu propio dominio.

Errores comunes

1. El servicio local escucha en la dirección equivocada

Si tu servicio solo escucha en una dirección interna del contenedor, o solo permite acceso desde una interfaz de red concreta, cloudflared puede no alcanzarlo.

Para diagnosticarlo, primero ejecuta esto en la máquina donde corre cloudflared:

`1`	`curl http://localhost:8080`

Si la propia máquina local no puede acceder al servicio, Cloudflare Tunnel tampoco podrá reenviar tráfico hacia él.

2. El firewall bloquea conexiones salientes

Cloudflare Tunnel no requiere puertos de entrada, pero sí necesita conectarse hacia fuera. Si una red corporativa, un grupo de seguridad en la nube o un firewall local bloquea conexiones salientes, el Tunnel puede no llegar nunca a Healthy.

En ese caso, revisa las reglas de salida, especialmente el puerto de conexión de Tunnel mencionado en la documentación de Cloudflare.

3. El dominio no está gestionado por Cloudflare

Si quieres publicar un hostname público formal, el dominio debe estar gestionado por Cloudflare. De lo contrario, Cloudflare no puede crear automáticamente la ruta DNS necesaria.

4. No expongas paneles de administración sin protección

Cloudflare Tunnel resuelve “cómo llegar al origen de forma segura”, pero no añade automáticamente un sistema de login a tu aplicación.

Si expones servicios sensibles como NAS, Git, monitoreo o paneles de administración de bases de datos, añade al menos una capa con Cloudflare Access y restringe el acceso por correo, cuenta de organización o proveedor de identidad.

5. El modo con archivo de configuración necesita una regla catch-all

Si gestionas ingress rules mediante API o un archivo de configuración local, la documentación oficial requiere una regla catch-all al final. Un patrón común es devolver 404:

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

Esto evita que solicitudes sin coincidencia se reenvíen por error a servicios que no deberían estar expuestos.

Resumen

Cloudflare Tunnel es una buena opción para publicar servicios web internos en dominios públicos de forma segura y estable. No requiere IP pública, no requiere puertos de entrada y su coste operativo es bajo.

Si solo quieres exponer un panel web desde casa o desde un servidor, Cloudflare Tunnel es una opción muy práctica. Si vas a construir un acceso privado corporativo más complejo, combínalo con Cloudflare Access, políticas Zero Trust y controles de permisos más detallados.

Cloudflared on KnightLi Blog