Cloudflare Tunnel para self-hosting: expón tu homelab sin abrir un solo puerto

Por qué redirigir puertos es una pésima idea en 2026

Si todavía abres agujeros en tu firewall para acceder a tus servicios autoalojados desde fuera de casa, para. Cada puerto abierto es superficie de ataque. Tu proveedor de internet puede bloquear las conexiones entrantes al puerto 443. Probablemente no tienes IP fija. Y si corres Proxmox con una docena de servicios (Jellyfin, Immich, Gitea, Grafana, tu propio endpoint de LLM), manejar reglas de NAT por servicio se vuelve rápidamente una pesadilla de mantenimiento.

Cloudflare Tunnel resuelve todo esto. El demonio cloudflared en tu servidor abre una conexión saliente hacia el borde de Cloudflare. El tráfico entra por ese túnel: sin puertos de entrada, sin IP fija y con TLS completo del cliente al origen. Cloudflare se convierte en tu proxy inverso, tu escudo contra DDoS y tu autoridad de certificados, sin que toques la tabla de redirección de puertos de tu router.

Aquí te explico exactamente cómo funciona, la configuración real que necesitas y los detalles que te van a hacer tropezar.

Cómo funciona realmente Cloudflare Tunnel

La arquitectura es simple, pero vale la pena entenderla antes de escribir un solo archivo de configuración:

1. Instalas cloudflared en un equipo dentro de tu red (un LXC de Proxmox, una VM, un contenedor).
2. cloudflared abre conexiones WebSocket salientes y persistentes hacia el borde de Cloudflare, normalmente 4 por redundancia.
3. Configuras registros DNS (CNAME) que apuntan tu subdominio al endpoint del túnel de Cloudflare.
4. Las peticiones HTTPS a jellyfin.yourdomain.com llegan a Cloudflare, atraviesan el túnel y terminan en http://192.168.0.x:8096 dentro de tu red.

Tu router no ve ninguna conexión entrante. Tu origen nunca es accesible directamente desde internet. Cloudflare termina el TLS en el borde, así que obtienes certificados válidos sin correr Certbot ni Let's Encrypt internamente (aunque también puedes agregar TLS interno como defensa en profundidad).

El plan gratis cubre todo lo que necesita un homelab: túneles ilimitados, peticiones ilimitadas y Cloudflare Access para autenticación zero-trust. El único requisito: tu dominio tiene que estar en el DNS de Cloudflare.

Requisitos previos

• Un dominio administrado en Cloudflare (sirve el plan gratis)
• Un host de Proxmox con uno o más LXC/VMs corriendo servicios
• Un equipo liviano donde correr cloudflared: un LXC Debian 12 con 512 MB de RAM y 1 CPU maneja una docena de servicios sin esfuerzo

En cuanto a hardware, no necesitas nada especial. Un mini PC como el Beelink EQR6 con Proxmox puede correr el LXC de cloudflared junto a muchos otros contenedores. Un Beelink EQ12 o un mini PC similar con N100/N150 maneja esta carga con un uso de CPU muy bajo en reposo.

Para la red, una buena práctica es poner los LXC en una VLAN dedicada con un switch administrable TP-Link TL-SG108E, lo que te permite aislar el tráfico entre el LXC del túnel y los LXC de los servicios. No es estrictamente necesario, pero es recomendable.

Paso 1: crea el túnel en el panel de Cloudflare

1. Entra a dash.cloudflare.com y ve a Zero Trust → Networks → Tunnels.
2. Haz clic en Create a tunnel y elige Cloudflared como tipo de conector.
3. Ponle un nombre como homelab-proxmox y guarda.
4. Cloudflare generará un token del túnel. Cópialo: lo necesitas en el siguiente paso.

También puedes hacerlo con la API de Cloudflare o con Terraform si quieres versionar la configuración del túnel, pero para un homelab el panel es suficiente.

Paso 2: instala cloudflared en un LXC de Proxmox

Crea un LXC Debian 12 en Proxmox (sin privilegios, 512 MB de RAM y 4 GB de disco es más que suficiente). Luego, dentro de él:

# Add Cloudflare's apt repo
curl -fsSL https://pkg.cloudflare.com/cloudflare-main.gpg | tee /usr/share/keyrings/cloudflare-main.gpg >/dev/null
echo 'deb [signed-by=/usr/share/keyrings/cloudflare-main.gpg] https://pkg.cloudflare.com/cloudflared any main' | tee /etc/apt/sources.list.d/cloudflared.list

apt update && apt install -y cloudflared

# Authenticate and install the tunnel using the token from the dashboard
cloudflared service install <YOUR_TUNNEL_TOKEN>

# Start and enable the service
systemctl enable --now cloudflared

Eso es todo. Revisa el panel de Cloudflare: tu conector debería aparecer como Healthy en unos 30 segundos.

Paso 3: configura los hostnames públicos (rutas)

Aquí asignas subdominios a servicios internos. En el panel de Cloudflare, ve a tu túnel → pestaña Public Hostname → Add a public hostname.

Ejemplos de asignaciones:

• jellyfin.yourdomain.com → http://192.168.0.x:8096
• immich.yourdomain.com → http://192.168.0.y:2283
• grafana.yourdomain.com → http://192.168.0.z:3000
• proxmox.yourdomain.com → https://192.168.0.x:8006 (mira la nota de abajo)

Cloudflare crea automáticamente el registro DNS CNAME para cada hostname. No tocas el DNS a mano.

El detalle de la interfaz web de Proxmox

Si vas a exponer la interfaz web de Proxmox, la URL del servicio tiene que ser https:// (Proxmox solo sirve HTTPS) y debes activar No TLS Verify en Additional application settings → TLS dentro de la configuración del hostname, porque Proxmox usa un certificado autofirmado por defecto. Otra opción es configurar un certificado real en Proxmox con Let's Encrypt: Proxmox 8 trae un cliente ACME integrado en Datacenter → ACME.

Agrega además esta cabecera HTTP para evitar problemas de WebSocket con la consola de Proxmox:

Origin-Header: https://proxmox.yourdomain.com

Sin esto, la consola noVNC se niega a conectar.

Paso 4: agrega autenticación zero-trust con Cloudflare Access

Cloudflare Tunnel expone tus servicios a internet, así que necesitas autenticación delante de todo lo que no quieras público. Cloudflare Access lo resuelve como una capa zero-trust gratuita, y es excelente.

Ve a Zero Trust → Access → Applications → Add an application → Self-hosted.

• Application domain: grafana.yourdomain.com
• Session duration: 24 horas
• Policy: Emails → tu dirección de correo

Ahora cualquiera que entre a grafana.yourdomain.com tendrá que pasar por el flujo de identidad de Cloudflare antes de que la petición llegue a tu túnel. Puedes usar OAuth de GitHub, Google, un PIN de un solo uso enviado a tu correo o el magic link de Cloudflare. Una combinación práctica: autenticación con GitHub para todo lo administrativo y OTP por correo para accesos compartidos.

Para servicios con su propia autenticación (Jellyfin, Immich, Gitea), puedes omitir Access o sumarlo como factor extra. Para servicios sin autenticación (Grafana en modo anónimo, APIs sin protección), Access no es negociable.

# Confirm Access is working — should redirect to Cloudflare auth, not your service
curl -I https://grafana.yourdomain.com
# HTTP/2 302 → Location: https://cloudflareaccess.com/...

Paso 5: archivo de configuración local (opcional pero recomendado)

Si prefieres manejar las rutas como código en lugar de desde el panel, cloudflared soporta una configuración local en YAML:

# /etc/cloudflared/config.yml
tunnel: <your-tunnel-id>
credentials-file: /root/.cloudflared/<tunnel-id>.json

ingress:
  - hostname: jellyfin.yourdomain.com
    service: http://192.168.0.x:8096
  - hostname: immich.yourdomain.com
    service: http://192.168.0.y:2283
    originRequest:
      connectTimeout: 30s
  - hostname: proxmox.yourdomain.com
    service: https://192.168.0.x:8006
    originRequest:
      noTLSVerify: true
  - hostname: grafana.yourdomain.com
    service: http://192.168.0.z:3000
  - service: http_status:404

La regla final de cierre http_status:404 es obligatoria: sin ella, cloudflared falla al iniciar.

Aplica los cambios:

cloudflared tunnel ingress validate
systemctl restart cloudflared

Rendimiento y latencia en el mundo real

La respuesta honesta: Cloudflare Tunnel agrega latencia. Las conexiones pasan por el borde de Cloudflare en lugar de ir directo a tu IP. Para uso en tu propia red, sumas 10-40 ms según el PoP de Cloudflare más cercano. Para la mayoría de los servicios (Jellyfin, Immich, paneles web) es imperceptible. Para SSH o tareas administrativas sensibles a la latencia, conviene usar Tailscale con acceso directo.

Las dos herramientas se complementan, no compiten: Cloudflare Tunnel para servicios públicos y Tailscale (o Headscale autoalojado) para el acceso administrativo privado. Ambos pueden correr al mismo tiempo sin conflictos.

En cuanto a hardware, si corres todo en un solo mini PC, los switches administrables de 8 puertos te permiten separar VLANs por poco dinero. También recomiendo tener un UPS: que el túnel de cloudflared se caiga por un parpadeo de luz es molesto, sobre todo si está delante de algo importante.

Consideraciones de ancho de banda

El plan gratis de Cloudflare no tiene límites de ancho de banda, pero sus Términos de Servicio prohíben usar Tunnel para "servir archivos grandes" de formas que abusen del plan gratis. En la práctica, transmitir Jellyfin hacia afuera es una zona gris: mucha gente lo hace y Cloudflare no lo persigue activamente. Para un Jellyfin familiar está bien. Para una alternativa pública a Plex con cientos de usuarios, necesitarías los planes de pago de Cloudflare o un enfoque distinto (IP directa con Caddy + Let's Encrypt, servido desde un VPS).

Immich está más claramente permitido porque suele ser de uso personal. Lo mismo para Gitea, Grafana y servicios similares.

Hardware de referencia para este setup

Un setup de túnel bien armado podría verse así:

• Mini PC Beelink EQR6: Ryzen 5 6600H de 6 núcleos, 32 GB de RAM y NVMe de 500 GB, con Proxmox 8 como hipervisor principal
• Switch administrable TP-Link TL-SG108E de 8 puertos: segmentación por VLANs para aislar los servicios
• APC Back-UPS 600VA: protege contra cortes momentáneos
• SSD SATA Samsung 870 EVO de 2 TB: almacenamiento masivo para las bibliotecas de Immich y Jellyfin
• Raspberry Pi 5 de 8 GB: nodo secundario para Home Assistant y servicios de menor prioridad

Si empiezas de cero, el Beelink EQ14 (Intel N150, ~$200) o el Minisforum UM790 Pro (Ryzen 9 7940HS, si quieres potencia en serio) son mis recomendaciones actuales. Ambos corren Proxmox 8 sin problemas.

Para la red, combínalos con un router TP-Link Archer AX55 (Wi-Fi 6, buen soporte de OpenWRT) y el switch administrable de arriba.

Solución de problemas comunes

El túnel aparece como Degraded en lugar de Healthy: Verifica que cloudflared pueda llegar a region1.cloudflaretunnels.com y region2.cloudflaretunnels.com en los puertos 443 y 7844. Algunos proveedores bloquean QUIC (7844); cloudflared vuelve automáticamente a HTTP/2 por el 443, pero deja advertencias en el log.

cloudflared tunnel info <tunnel-name>
journalctl -u cloudflared -f

Los servicios con WebSocket no funcionan (consola de Proxmox, n8n, Jupyter): Activa --no-chunked-encoding en la configuración del origen, o agrega noChunkedEncoding: true en el YAML. Asegúrate también de que la configuración del hostname tenga HTTP2Origin desactivado si el servicio de origen es HTTP/1.1.

La app móvil de Immich no conecta: La app móvil de Immich necesita que la URL del servidor coincida exactamente con la configurada en Access (si está activado). Desactiva Access para Immich si usas la autenticación propia de Immich: la app maneja el inicio de sesión por su cuenta.

Tiempo al primer byte lento: Normalmente es propagación de DNS. Después de agregar un hostname nuevo, espera 1-2 minutos. Asegúrate también de que el proxy de Cloudflare (nube naranja) esté activado en los registros CNAME: la nube gris se salta el túnel por completo.

Conclusión

Cloudflare Tunnel es una de las mejores mejoras de infraestructura sin costo que puedes hacerle a un homelab. Ganas:

• Ningún puerto expuesto en tu router
• TLS válido automático en cada servicio
• Autenticación zero-trust opcional con Cloudflare Access
• Protección contra DDoS por defecto
• Ninguna dependencia de una IP fija

La contrapartida es que tu tráfico pasa por Cloudflare, así que les confías tu tráfico HTTP (terminan el TLS en su borde). Para servicios sensibles, usa Cloudflare Access + la autenticación de tu propia aplicación, y considera también cifrado de punta a punta en el origen. Para la mayoría de los servicios autoalojados en un homelab personal, es un límite de confianza totalmente aceptable.

No reemplaza una malla privada como Tailscale para el acceso administrativo, pero es la forma más limpia de poner tus servicios autoalojados a disposición del mundo sin los riesgos de exposición de la redirección de puertos tradicional.

Aviso: este artículo contiene enlaces de afiliado. Si compras a través de ellos, puedo ganar una pequeña comisión sin costo extra para ti.