wstunnel: túnel TCP/UDP sobre WebSocket en 2026 (guía completa)

Divulgación de afiliados — Este artículo contiene enlaces de afiliación Contabo. Si contratas un VPS a través de nuestros enlaces, recibimos una comisión sin coste adicional para ti. Sólo documentamos lo que probamos realmente en producción en nuestros propios VPS.

Ya conoces la historia: tu VPN WireGuard funciona perfecto en casa, te vas en misión a un cliente o trabajas desde un coworking, y el puerto UDP 51820 está bloqueado de raíz. El wifi corporativo deja pasar 80, 443, a veces 22, y nada más. Te conectas al captive portal, tu túnel no levanta y te quedas atrapado fuera de tu infraestructura.

Ese es exactamente el escenario que wstunnel resuelve. La idea es simple: encapsular cualquier tráfico TCP o UDP en WebSockets sobre el puerto 443 — es decir, hacer que tu WireGuard (UDP) parezca tráfico HTTPS WebSocket legítimo. El firewall ve wss://cdn.tudominio.com en el puerto 443, deja pasar, y del otro lado wstunnel desencapsula para devolver los paquetes UDP a WireGuard.

Esta guía cubre la instalación de wstunnel en un VPS Contabo (Ubuntu 24.04), la configuración cliente Linux/Windows/macOS/Android, los benchmarks reales de latencia y ancho de banda, y los casos donde wstunnel es la opción adecuada frente a V2Ray o Cloak.

Por qué wstunnel funciona donde WireGuard puro falla

Tres familias de bloqueos matan un túnel WireGuard "normal":

• Firewall corporativo clásico: política de salida restrictiva (egress allowlist), solo 80/443/53 salen. El puerto 51820 UDP no tiene ninguna posibilidad.
• Captive portals de hoteles/aeropuertos: antes de autenticarse, todo salvo 80/443 TCP está bloqueado. Y aun después del login, algunos mantienen UDP cerrado.
• DPI nacional / corporativo avanzado: ve el handshake WireGuard, identifica el protocolo y descarta. El puerto de escucha importa poco.

WebSocket sobre 443 evita los dos primeros porque ES HTTPS — un upgrade desde HTTP/1.1, aceptado por todos los proxies TLS. Para el DPI nacional (GFW, SmartFilter), hay que combinar con TLS real y certificado válido; wstunnel se encarga via wss://.

La herramienta wstunnel está escrita en Rust por Erebe (repositorio GitHub). Es un binario único, ~7 MB, que hace de servidor y cliente a la vez. Sin Python que parchear, sin Node.js que mantener, sin Docker obligatorio. Copias el binario, lanzas un comando, túnel funcionando.

Instalación del servidor en Contabo VPS

Usamos un VPS Contabo S (4 vCPU, 8 GB RAM, 4,99 €/mes) con Ubuntu 24.04 LTS. Si todavía no tienes VPS, mira la oferta Contabo VPS S 24 meses. Puedes compartir este VPS con tu WireGuard existente — wstunnel consume menos de 50 MB de RAM en reposo.

Paso 1 — Obtener el binario wstunnel

WSTUNNEL_VER="10.1.4"  # verifica la última en github.com/erebe/wstunnel/releases
curl -L -o /usr/local/bin/wstunnel \
  "https://github.com/erebe/wstunnel/releases/download/v${WSTUNNEL_VER}/wstunnel_${WSTUNNEL_VER}_linux_amd64"
chmod +x /usr/local/bin/wstunnel
wstunnel --version

Paso 2 — Dominio + reverse proxy Caddy (recomendado)

Para un wss:// creíble, ponemos Caddy delante para gestionar TLS Let's Encrypt automáticamente. Requisito: un dominio apuntando a la IP del VPS (registro A cdn.tudominio.com → 188.245.x.x).

# Instalación Caddy
apt update && apt install -y debian-keyring debian-archive-keyring apt-transport-https
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/gpg.key' | gpg --dearmor -o /usr/share/keyrings/caddy-stable-archive-keyring.gpg
curl -1sLf 'https://dl.cloudsmith.io/public/caddy/stable/debian.deb.txt' | tee /etc/apt/sources.list.d/caddy-stable.list
apt update && apt install -y caddy

/etc/caddy/Caddyfile:

cdn.tudominio.com {
  root * /var/www/html
  file_server

  @ws {
    path /ws/*
    header Connection *Upgrade*
    header Upgrade websocket
  }
  reverse_proxy @ws 127.0.0.1:8080
}

El bloque @ws empareja únicamente peticiones de WebSocket upgrade en la ruta /ws/*. Cualquier otra petición ve un sitio HTML estático normal (pon un blog ficticio o una página de mantenimiento en /var/www/html).

Paso 3 — Servicio systemd wstunnel

/etc/systemd/system/wstunnel.service:

[Unit]
Description=wstunnel server
After=network-online.target

[Service]
Type=simple
ExecStart=/usr/local/bin/wstunnel server ws://127.0.0.1:8080 \
  --restrict-to 127.0.0.1:51820
Restart=always
RestartSec=5
User=nobody

[Install]
WantedBy=multi-user.target

La opción --restrict-to prohíbe que los clientes usen wstunnel como proxy abierto: solo el destino 127.0.0.1:51820 (nuestro WireGuard) será autorizado. Crucial para la seguridad.

systemctl daemon-reload
systemctl enable --now caddy wstunnel
journalctl -u wstunnel -f  # verificar que escucha

En este punto, tu servidor expone https://cdn.tudominio.com (página HTML ficticia) y un túnel WS en wss://cdn.tudominio.com/ws/*. Ningún puerto UDP exótico expuesto externamente — para el firewall, es un sitio HTTPS normal.

Configuración cliente: Linux, Windows, macOS, Android

El binario cliente wstunnel es el mismo que el servidor. Descargas la release adaptada a tu OS y lanzas un comando distinto.

Linux / macOS:

wstunnel client \
  --local-to-remote 'udp://51820:127.0.0.1:51820' \
  wss://cdn.tudominio.com/ws

Este comando abre un listener UDP local en 127.0.0.1:51820 y tunela todo lo que llega allí hacia 127.0.0.1:51820 en el servidor via WebSocket en el puerto 443. Luego apuntas tu configuración WireGuard local a Endpoint = 127.0.0.1:51820 en lugar de la IP pública del VPS.

Ejemplo de config WireGuard cliente adaptada (/etc/wireguard/wg0-via-ws.conf):

[Interface]
PrivateKey = TU_CLAVE_PRIVADA_CLIENTE
Address = 10.7.0.2/24
DNS = 1.1.1.1

[Peer]
PublicKey = CLAVE_PUBLICA_SERVIDOR
AllowedIPs = 0.0.0.0/0
Endpoint = 127.0.0.1:51820   # local — wstunnel retransmite
PersistentKeepalive = 25

Lanza en este orden:

wstunnel client --local-to-remote 'udp://51820:127.0.0.1:51820' wss://cdn.tudominio.com/ws &
wg-quick up wg0-via-ws

Windows: recupera wstunnel.exe en la página de releases, lanza desde PowerShell admin. Para automatizar, crea una tarea programada wstunnel-client que arranque al logon. La app oficial WireGuard para Windows acepta Endpoint = 127.0.0.1:51820 sin quejarse.

Android: no hay binario ARM nativo distribuido oficialmente, pero Termux permite compilar o recuperar la build ARM64 (wstunnel_*_linux_arm64). Combinado con WireGuard Android y la función "Excluded apps" para excluir el PID de Termux, funciona. Es la solución menos llave en mano — para móvil, V2Ray Android es más simple si no necesitas específicamente WireGuard.

Benchmarks reales: latencia y ancho de banda

Mediciones iperf3 + ping ICMP, cliente residencial fibra Movistar 1 Gbps Madrid, servidor Contabo VPS S Núremberg, finales de marzo 2026. Mediana sobre 10 sesiones.

Lectura: la latencia añadida ronda 10-13 ms cuando hay TLS local, 20 ms si añadimos Cloudflare delante. El ancho de banda baja un 40% entre WireGuard puro y wstunnel wss:// — es el precio a pagar para atravesar un firewall corporativo o un DPI.

Para navegación web, videollamadas Zoom/Meet 720p y streaming Netflix HD: ninguna diferencia perceptible. Para 4K, gaming competitivo o transferencias grandes, el túnel WS es subóptimo — usa WireGuard puro cuando sea posible.

Casos de uso típicos

1. Empleado remoto detrás de un firewall corporativo estricto. Setup clásico: VPS personal Contabo + wstunnel + WireGuard para reconectar con tu red personal (NAS, Home Assistant, dev box). El firewall corp ve HTTPS hacia un dominio personal, no bloquea. Compatible con políticas BYOD razonables.

2. Nómada digital con wifi de hoteles impredecibles. wstunnel es tu plan B cuando WireGuard no sale. Mantén una config "WireGuard directo" para las buenas redes, una config "via wstunnel" para las malas. Cambio manual en 5 segundos.

3. CTF / pentest / homelab. Cuando quieres exponer un servicio interno (RDP Windows lab, MySQL dev, SSH bastion) en el 443 de un VPS público sin tocar el reverse proxy aplicativo. wstunnel TCP es más simple que SSH tunneling para los menos técnicos de tu equipo.

4. Migración progresiva de un VPN consumer a self-host. Si todavía usas un VPN comercial y quieres probar self-host manteniendo un fallback: monta tu stack Contabo + WireGuard + wstunnel, y mantén tu suscripción NordVPN activa un mes como backup. Es lo que hicimos nosotros en 2024 — cortamos Nord a las 6 semanas una vez estabilizado el self-host.

Endurecer el despliegue

Autenticación fuerte de los clientes. Por defecto, cualquiera que conozca la URL wss://cdn.tudominio.com/ws puede establecer un túnel. Activa la opción --http-upgrade-path-prefix con un secreto aleatorio de 32 caracteres:

# Lado servidor
wstunnel server ws://127.0.0.1:8080 --http-upgrade-path-prefix /secret-abc123xyz

# Lado cliente
wstunnel client --http-upgrade-path-prefix /secret-abc123xyz ...

Sin el prefijo correcto, el servidor devuelve 404. Combinado con fail2ban sobre los logs de Caddy, bloquea los escaneos rápidos.

Limita explícitamente los destinos. El --restrict-to 127.0.0.1:51820 SOLO autoriza el túnel hacia el WireGuard local. No omitirlo: si no, tu VPS se convierte en un proxy abierto que los bots usarán para abuso.

fail2ban sobre los 404 de Caddy. Añade una jail que banee una IP tras 10 respuestas 404 en 60 segundos:

# /etc/fail2ban/jail.d/caddy-404.conf
[caddy-404]
enabled = true
port = http,https
filter = caddy-404
logpath = /var/log/caddy/access.log
maxretry = 10
findtime = 60
bantime = 3600

El filtro caddy-404.conf empareja las líneas JSON con "status":404 — ver doc Caddy para el formato exacto.

Renovación de certificado. Caddy gestiona Let's Encrypt automáticamente, nada que hacer. Verifica cada 60 días con caddy adapt que la configuración sigue válida.

wstunnel vs alternativas

Veredicto pragmático:

• Solo / 1-3 usuarios / bypass corporativo o DPI ligero → wstunnel.
• Multi-usuario / bypass GFW China → V2Ray (ver nuestra guía V2Ray VMess/VLess).
• Quieres añadir una capa TLS delante de un WireGuard existente sin rehacer todo → Cloak.
• Sólo salir de una red corp para SSH / web → sshuttle (sin VPS requerido).

Troubleshooting frecuente

Síntoma: wss handshake failed: 502 bad gateway. El servicio wstunnel servidor no escucha en 8080, o Caddy no lo encuentra. Verifica systemctl status wstunnel y ss -tlnp | grep 8080.

Síntoma: el túnel sube pero ningún tráfico pasa. El WireGuard del lado servidor no autoriza al peer cliente. Reverifica wg show y la sección [Peer] del servidor — frecuentemente un AllowedIPs mal copiado.

Síntoma: ancho de banda anormalmente bajo (< 30 Mbps). Cloudflare proxy activado (cloud naranja): Cloudflare throttle los WebSockets en plan gratuito. Desactiva el proxy DNS (cloud gris) o pasa a un dominio sin Cloudflare.

Síntoma: desconexiones cada 10 minutos. Caddy tiene un timeout por defecto en las WS largas. Añade dentro del bloque reverse_proxy:

reverse_proxy @ws 127.0.0.1:8080 {
  transport http {
    keepalive 30s
    keepalive_idle_conns 100
  }
}

Para profundizar

• Self-host VPN en Contabo: guía WireGuard completa 2026
• V2Ray VMess/VLess: configuración completa 2026
• Cloak: ofuscación TLS para VPN self-host
• Enrutado VPN custom Contabo: bypass DPI Irán / China

Fuentes y referencias:

• Erebe/wstunnel — repositorio GitHub oficial
• RFC 6455 — The WebSocket Protocol
• Documentación Caddy — directiva reverse_proxy
• WireGuard whitepaper — Jason A. Donenfeld

Artículo publicado el 2026-06-03. Pruebas realizadas sobre VPS Contabo VPS S Núremberg + cliente residencial fibra Madrid, marzo 2026. El rendimiento puede variar sensiblemente según el datacenter Contabo elegido, el operador cliente y la calidad del peering — siempre realiza benchmarks en tu contexto antes de comprometerte con un setup.

Recordatorio: wstunnel y el auto-alojamiento VPN son perfectamente legales en la UE, EE.UU., Canadá y la mayoría de países democráticos. Verificar las regulaciones locales en China, Irán, EAU, Rusia antes de desplegar — VPNSmith publica este contenido con fines educativos.