Tutoriales de VPS
Oculta la IP de origen de tu VPS con Cloudflare Tunnel (2026): Zero Trust, sin abrir puertos y guía de despliegue de penetración de red interna
Cloudflare Tunnel permite que los servicios web en un VPS no expongan directamente puertos públicos: cloudflared se conecta activamente a Cloudflare y Cloudflare luego accede al servicio local. Este artículo explica para qué escenarios es adecuado, cómo desplegarlo, cómo vincular un dominio, cómo proteger el panel de administración con Access y cómo solucionar problemas comunes como el estado Inactive, errores 502 y que el origen siga siendo accesible directamente.
Muchos sitios web en VPS, tras conectarse a Cloudflare, solo cambian sus registros DNS al proxy de nube naranja. Esto oculta parte de la ruta de acceso, pero si la IP de origen ya se ha filtrado, los atacantes aún pueden eludir Cloudflare y atacar tu VPS directamente.
Cloudflare Tunnel resuelve otro problema: elimina la necesidad de que el origen abra los puertos públicos 80/443. Un demonio cloudflared se ejecuta en el VPS y establece activamente una conexión cifrada solo de salida hacia Cloudflare; cuando los usuarios externos visitan tu dominio, las solicitudes entran primero en Cloudflare y luego se reenvían a través de este túnel al servicio local del VPS.
Este artículo sigue escenarios reales de usuarios de VPS: cuándo usar Tunnel, cómo crear un túnel, cómo publicar un servicio autoalojado, cómo proteger el panel de administración y cómo solucionar fallos comunes.
Cloudflare Tunnel es más adecuado para estas necesidades:
| Escenario | ¿Adecuado? | Descripción |
|---|---|---|
| Exponer un blog, sitio de herramientas o SaaS pequeño | Adecuado | No requiere abrir 80/443 en el origen; oculta la IP de origen |
| Exponer paneles de administración de n8n, Gitea o Grafana | Muy adecuado | Se puede combinar con Cloudflare Access para proteger el inicio de sesión |
| Servicios detrás de banda ancha doméstica/NAT | Adecuado | No requiere IP pública ni reenvío de puertos |
| Sitios de descargas de alta concurrencia, negocios de archivos grandes | Con precaución | Hay que considerar las políticas de Cloudflare y las características del ancho de banda |
| Servidores de correo, servidores de juegos, servicios TCP arbitrarios | No necesariamente | HTTP es lo más sencillo; los no HTTP dependen del protocolo y del enfoque |
En una frase: si tu servicio es esencialmente HTTP/HTTPS y quieres ocultar la IP de origen, Tunnel merece mucho la pena.
Pero no es una bala de plata. Tunnel no puede corregir vulnerabilidades de la aplicación por ti, ni sustituir copias de seguridad, registros y control de acceso. Resuelve los problemas de "superficie de exposición de la entrada" y "origen que elude Cloudflare".
El enfoque tradicional es:
用户 -> Cloudflare -> VPS 公网 IP:443 -> Nginx -> 应用
El enfoque con Tunnel es:
用户 -> Cloudflare Edge -> cloudflared 隧道 -> 127.0.0.1:3000
La diferencia clave es que cloudflared se conecta activamente desde el VPS hacia fuera, por lo que el firewall del VPS puede cerrar la entrada 80/443 y mantener solo SSH, o incluso gestionarse únicamente por consola/VPN.
La documentación oficial de Cloudflare también indica claramente que Tunnel usa un modelo de conexión solo de salida: cloudflared se conecta activamente desde el origen a la red global de Cloudflare, y el tráfico se reenvía bidireccionalmente a través de esta conexión.
Esto es muy valioso para un VPS:
- La IP de origen no necesita exponerse directamente a los usuarios;
- Los servicios internos sin IP pública también se pueden publicar;
- La entrada del panel de administración se puede colocar detrás de Cloudflare Access;
- La política de firewall es más sencilla: denegar la entrada por defecto y permitir solo los puertos de gestión necesarios.
Necesitas:
- Un dominio ya conectado a Cloudflare;
- Un VPS con acceso a internet saliente;
- Un servicio que se ejecute localmente, por ejemplo
127.0.0.1:3000; - Acceso al panel de Cloudflare Zero Trust.
Primero confirma que el servicio local es accesible:
curl -I http://127.0.0.1:3000
Si no puedes acceder ni siquiera localmente, no configures Tunnel todavía. Tunnel no es una herramienta de reparación de aplicaciones; solo reenvía tráfico.
Ve a Cloudflare Zero Trust:
Zero Trust -> Networks -> Connectors -> Cloudflare Tunnels -> Create a tunnel
Selecciona Cloudflared y dale un nombre al túnel, por ejemplo:
vps-main-tunnel
Cloudflare te dará un comando de instalación. En Debian/Ubuntu tiene aproximadamente esta forma:
curl -L --output cloudflared.deb https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64.deb
sudo dpkg -i cloudflared.deb
sudo cloudflared service install <你的-token>
Tras la instalación, vuelve al panel. Si el conector muestra Healthy, el VPS ha establecido conexión con Cloudflare.
En Public Hostname o Published applications del Tunnel, añade:
Subdomain: app
Domain: example.com
Type: HTTP
URL: http://localhost:3000
Tras guardar, visita:
https://app.example.com
Si el servicio funciona, las solicitudes llegarán al puerto 3000 local del VPS a través de Cloudflare Tunnel.
En este punto tu aplicación puede escuchar solo en localhost:
HOST=127.0.0.1 PORT=3000 npm start
Nginx tampoco necesita ser la entrada pública; puede ser solo una capa de proxy inverso local:
server {
listen 127.0.0.1:8080;
server_name _;
location / {
proxy_pass http://127.0.0.1:3000;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
}
}
Luego apunta Tunnel a:
http://localhost:8080
El método de instalación del panel normalmente registra un servicio systemd automáticamente. Comprueba el estado:
systemctl status cloudflared
journalctl -u cloudflared -n 100 --no-pager
Comandos habituales:
systemctl restart cloudflared
systemctl enable cloudflared
Si más adelante reinstalas el sistema, recuerda reinstalar el conector. El objeto Tunnel está en el panel de Cloudflare; el cloudflared en el VPS es solo el conector.
Tras usar Tunnel, los puertos públicos de entrada se pueden restringir mucho.
Si tu sitio se publica completamente a través de Tunnel, puedes hacer esto:
ufw default deny incoming
ufw default allow outgoing
ufw allow OpenSSH
ufw enable
Si quieres proteger aún más SSH, puedes permitir solo tu propia IP:
ufw allow from 你的固定IP to any port 22 proto tcp
Pero no cierres SSH a la ligera antes de haber preparado consola/VNC/modo de rescate. Ya hay artículos relacionados de auto-rescate:
La fortaleza de Tunnel no es solo ocultar el origen; también puede combinarse con Cloudflare Access.
Por ejemplo, si tienes estos paneles:
n8n.example.comgitea.example.comgrafana.example.comadmin.example.com
Puedes crear una Access Application en Zero Trust que exija a los visitantes pasar una de las siguientes opciones antes de acceder:
- OTP por correo electrónico;
- Inicio de sesión con Google / GitHub;
- Correo del equipo especificado;
- Política de país/región o IP especificada;
- Autenticación multifactor.
Así, aunque la página de inicio de sesión de la propia aplicación de administración esté expuesta, hay una capa adicional de verificación de identidad de Cloudflare por fuera.
Políticas recomendadas:
| Servicio | Recomendación de Access |
|---|---|
| Frontend del blog | No necesita Access |
| Panel de n8n / Grafana / Gitea | Se recomienda encarecidamente añadir Access |
| URL de Webhook | No añadas Access a ciegas; puede afectar a las devoluciones de llamada de terceros |
| Herramientas internas | Permitir solo correos u cuentas de organización especificados |
Primero revisa el servicio:
systemctl status cloudflared
journalctl -u cloudflared -n 100 --no-pager
Luego confirma que el VPS puede acceder a Cloudflare:
curl -I https://www.cloudflare.com
Si el servidor está detrás de un firewall estricto, confirma que las conexiones salientes no están bloqueadas. La documentación de Cloudflare recuerda que en redes restringidas hay que hacer primero una comprobación previa de conectividad, especialmente para confirmar la accesibilidad a Cloudflare.
Causas comunes:
- Token copiado incorrectamente;
- Servicio systemd no iniciado;
- Salida del VPS bloqueada por el firewall;
- DNS o hora del sistema anómalos;
- Versión de cloudflared demasiado antigua.
Tunnel ya está Healthy, pero al visitar el dominio se produce un error; normalmente la dirección del servicio local está mal escrita.
Prueba en el VPS:
curl -I http://localhost:3000
curl -I http://127.0.0.1:3000
Ten en cuenta que localhost puede resolverse a IPv6 ::1, mientras que tu aplicación solo escucha en IPv4. En ese caso, en Public Hostname puedes escribir explícitamente:
http://127.0.0.1:3000
Si tu aplicación requiere un encabezado Host, es posible que también tengas que ajustar el HTTP Host Header en la configuración de origin request del Tunnel.
Tener Tunnel configurado no garantiza que el origen esté oculto. También debes confirmar:
- Que no hay registros A de nube gris en DNS que expongan la IP real;
- Que el firewall del VPS ya no abre 80/443;
- Que los registros DNS históricos, los registros de transparencia de certificados y las cabeceras de correo no filtran el origen;
- Que la antigua entrada de Nginx ya no escucha públicamente.
Prueba el acceso directo al origen:
curl -I http://你的VPS_IP
curl -kI https://你的VPS_IP
Si todavía se puede acceder al sitio web, significa que el origen aún no está realmente cerrado.
| Comparación | Proxy de nube naranja normal | Cloudflare Tunnel |
|---|---|---|
| ¿Requiere entrada pública 80/443? | Sí | No |
| ¿Oculta la IP de origen? | Parcialmente | Más completo, pero aún hay que limpiar filtraciones históricas |
| ¿Adecuado para NAT/banda ancha doméstica? | No | Sí |
| ¿Compatible con Access? | Sí | Sí, con una experiencia más completa |
| Complejidad de diagnóstico | Menor | Algo mayor |
La nube naranja normal ya resuelve muchos problemas de CDN/WAF/caché; Tunnel es más adecuado para escenarios en los que quieres reducir aún más la superficie de exposición del VPS o no tienes condiciones de entrada pública.
Antes de publicar un servicio, comprueba al menos:
- El servicio local
curl http://127.0.0.1:端口es normal; - El conector de Cloudflare Tunnel muestra Healthy;
- Public Hostname apunta al puerto local correcto;
- UFW no ha bloqueado SSH;
- El 80/443 público del VPS está cerrado o ya no devuelve páginas de negocio;
- El dominio del panel de administración tiene Cloudflare Access añadido;
- Las rutas de Webhook no están bloqueadas por error por Access;
-
journalctl -u cloudflaredno tiene errores persistentes; - Se ha probado el acceso por dominio, la IP directa y la red móvil.
Hay que tener precaución en estos casos:
- Necesitas control total sobre los detalles de TLS de Nginx y la cadena de certificados;
- El negocio tiene muchas descargas de archivos grandes o protocolos especiales;
- No quieres que la entrada dependa fuertemente de Cloudflare;
- Tu red tiene conexiones salientes inestables hacia Cloudflare;
- Necesitas protocolos no HTTP pero no quieres introducir clientes adicionales ni configuración de Zero Trust.
Si solo es un sitio web normal, un panel de administración, una herramienta autoalojada o un panel interno, los beneficios de Tunnel normalmente superan la complejidad.
Cloudflare Tunnel es muy adecuado para que los usuarios de VPS hagan tres cosas: ocultar la IP de origen, reducir los puertos públicos de entrada y añadir una capa de control de acceso Zero Trust a los servicios de administración.
Su núcleo no es "hacer que el sitio web sea más rápido", sino "exponer menos el origen". Si ya estás en Cloudflare y te preocupa que el origen sea accedido directamente, que el panel sea escaneado o que la banda ancha doméstica/NAT no pueda abrir puertos, entonces Tunnel es una solución que merece mucho la pena dominar.
La forma realmente segura es: publicar servicios con Tunnel, cerrar en el firewall las entradas innecesarias, proteger el panel con Access y observar los registros de forma continua. Así el VPS no queda expuesto solo en la internet pública, sino colocado detrás de la red perimetral de Cloudflare con acceso controlado.