wstunnel: TCP/UDP sobre WebSocket em 2026 (guia completo)

Divulgação de afiliados — Este artigo contém links de afiliados da Contabo. Se encomendar um VPS através dos nossos links, ganhamos uma comissão sem custo adicional para si. As nossas recomendações baseiam-se no comportamento documentado das ferramentas e nas especificações publicadas pelo fornecedor.

Você conhece a história: o seu VPN WireGuard funciona perfeitamente em casa, mas quando vai a um cliente ou se senta num espaço de coworking, a porta UDP 51820 está bloqueada. O Wi-Fi corporativo permite apenas 80, 443, às vezes 22, e é só. Você faz login através do portal cativo, o seu túnel não se estabelece e fica bloqueado fora da sua própria infraestrutura.

Esse é o cenário exato que o wstunnel resolve. A ideia é simples: encapsular qualquer tráfego TCP ou UDP em WebSockets na porta 443 — ou seja, fazer com que o seu WireGuard (UDP) pareça tráfego legítimo de WebSocket HTTPS. O firewall vê wss://cdn.seudominio.com na porta 443, permite a passagem, e do outro lado o wstunnel desembrulha para entregar os pacotes UDP de volta ao WireGuard.

Este guia cobre a instalação do wstunnel num VPS Contabo (Ubuntu 24.04), configuração do cliente em Linux/Windows/macOS/Android, os compromissos de latência e throughput esperados, e quando o wstunnel é a escolha certa em comparação com V2Ray ou Cloak.

Por que o wstunnel funciona onde o WireGuard simples falha

Três tipos de bloqueios matam um túnel WireGuard "puro":

• Firewall corporativo clássico: lista de permissões de saída restritiva, apenas 80/443/53 saem. A porta UDP 51820 não tem hipótese.
• Portais cativos de hotel/aeroporto: antes da autenticação, tudo exceto 80/443 TCP é descartado. E mesmo após o login, alguns mantêm o UDP fechado.
• DPI nacional/corporativo avançado: vê o handshake do WireGuard, identifica o protocolo e descarta. A porta de escuta não importa.

O WebSocket na porta 443 contorna os dois primeiros porque É HTTPS — uma atualização do HTTP/1.1, aceita por todos os proxies TLS. Para DPI nacional (GFW, SmartFilter), é necessário emparelhá-lo com TLS real e um certificado válido; o wstunnel lida com isso via wss://.

A ferramenta wstunnel é escrita em Rust por Erebe (repositório GitHub). É um único binário, ~7 MB, que atua como servidor e cliente. Sem Python para corrigir, sem Node.js para manter, sem Docker obrigatório. Você copia o binário, executa um comando, e o tunelamento começa.

Instalação do servidor num VPS Contabo

Usamos um VPS Contabo S (4 vCPU, 8 GB RAM, €4.99/mês) executando Ubuntu 24.04 LTS. Se ainda não tem um VPS, consulte o negócio de 24 meses do Contabo VPS S. Pode compartilhar este VPS com o seu WireGuard existente — o wstunnel usa menos de 50 MB de RAM em repouso.

Passo 1 — Obtenha o binário do wstunnel

WSTUNNEL_VER="10.1.4"  # verifique a última versão em 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

Passo 2 — Domínio + proxy reverso Caddy (recomendado)

Para um wss:// convincente, colocamos o Caddy à frente para lidar automaticamente com o TLS do Let's Encrypt. Pré-requisito: um domínio apontando para o IP do VPS (registro A cdn.seudominio.com → 188.245.x.x).

# Instalação do 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.seudominio.com {
  root * /var/www/html
  file_server

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

O bloco @ws corresponde apenas a pedidos de upgrade de WebSocket no caminho /ws/*. Qualquer outro pedido vê um site HTML estático normal (coloque um blog fictício ou página de manutenção em /var/www/html).

Passo 3 — Serviço systemd do wstunnel

/etc/systemd/system/wstunnel.service:

[Unit]
Description=servidor wstunnel
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

A flag --restrict-to proíbe que clientes usem o wstunnel como um proxy aberto: apenas 127.0.0.1:51820 (nosso WireGuard) será permitido. Crítico para a segurança.

systemctl daemon-reload
systemctl enable --now caddy wstunnel
journalctl -u wstunnel -f  # verifique se está a escutar

Neste estágio, o seu servidor expõe https://cdn.seudominio.com (página HTML fictícia) e um túnel WS em wss://cdn.seudominio.com/ws/*. Nenhuma porta UDP exótica exposta externamente — para um firewall, é um site HTTPS normal.

Configuração do cliente: Linux, Windows, macOS, Android

O binário do cliente wstunnel é o mesmo que o do servidor. Você baixa a versão correta para o seu sistema operativo e executa um comando diferente.

Linux / macOS:

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

Isto abre um ouvinte UDP local em 127.0.0.1:51820 e encaminha tudo o que chega lá para 127.0.0.1:51820 no servidor via WebSocket na porta 443. Você então aponta a sua configuração local do WireGuard para Endpoint = 127.0.0.1:51820 em vez do IP público do VPS.

Exemplo de configuração do cliente WireGuard (/etc/wireguard/wg0-via-ws.conf):

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

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

Inicie nesta ordem:

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

Windows: obtenha wstunnel.exe da página de lançamentos, inicie a partir de um PowerShell com privilégios de administrador. Para automatizar, crie uma tarefa agendada wstunnel-client que inicie no login. A aplicação oficial do WireGuard para Windows aceita Endpoint = 127.0.0.1:51820 sem reclamar.

Android: não há binário ARM nativo oficialmente distribuído, mas o Termux permite compilar ou buscar a build ARM64 (wstunnel_*_linux_arm64). Combinado com o WireGuard Android e a funcionalidade "Aplicações Excluídas" para excluir o PID do Termux, funciona. É a opção menos prática — em dispositivos móveis, o V2Ray Android é mais simples se não precisar especificamente do WireGuard.

O que esperar: latência e throughput

Cada camada que adiciona para encapsular o WireGuard em WebSocket/TLS custa alguma latência e throughput. A tabela abaixo mostra a direção do compromisso — meça a sua própria rota com iperf3 e ping para números exatos, pois dependem muito da sua ligação e do datacenter escolhido.

Leitura: encapsular o WireGuard em TLS adiciona um modesto overhead de latência e reduz significativamente o throughput — esse é o preço a pagar para atravessar um firewall corporativo ou DPI. Colocar o Cloudflare à frente adiciona outro salto por cima.

Para navegação web, vídeo Zoom/Meet 720p e Netflix HD: nenhuma diferença perceptível. Para 4K, jogos competitivos ou transferências grandes, o túnel WS é subótimo — volte ao WireGuard simples quando possível.

Casos de uso típicos

1. Funcionário remoto atrás de um firewall corporativo rigoroso. Configuração clássica: VPS pessoal Contabo + wstunnel + WireGuard para se reconectar à sua rede doméstica (NAS, Home Assistant, caixa de desenvolvimento). O firewall corporativo vê HTTPS em direção a um domínio pessoal, não bloqueia. Compatível com políticas BYOD razoáveis.

2. Nómada digital com Wi-Fi de hotel imprevisível. O wstunnel é o seu plano B quando o WireGuard não consegue sair. Mantenha um perfil "WireGuard direto" para as boas redes, um perfil "via wstunnel" para as más. Mudança manual em 5 segundos.

3. CTF / pentest / homelab. Quando quer expor um serviço interno (laboratório RDP Windows, MySQL de desenvolvimento, bastião SSH) na porta 443 de um VPS público sem tocar no proxy reverso da aplicação. O wstunnel TCP é mais simples que o tunelamento SSH para colegas menos técnicos.

4. Migração progressiva de um VPN de consumidor para auto-hospedagem. Se ainda usa um VPN comercial e quer testar a auto-hospedagem enquanto mantém um backup: configure o seu stack Contabo + WireGuard + wstunnel, e mantenha a sua subscrição de VPN comercial ativa por um mês como backup. Uma vez que a configuração auto-hospedada se prove estável, pode cancelar o serviço pago.

Fortalecendo a implementação

Autenticação forte do cliente. Por padrão, qualquer pessoa que conheça o URL wss://cdn.seudominio.com/ws pode abrir um túnel. Ative a opção --http-upgrade-path-prefix com um segredo aleatório de 32 caracteres:

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

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

Sem o prefixo correto, o servidor retorna 404. Combinado com fail2ban nos logs do Caddy, isso bloqueia scanners rápidos.

Restrinja explicitamente os destinos. O --restrict-to 127.0.0.1:51820 só permite tunelamento para o WireGuard local. Não omita — caso contrário, o seu VPS torna-se um proxy aberto que bots irão abusar.

fail2ban em 404s do Caddy. Adicione uma jail que bane um IP após 10 respostas 404 em 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

O filtro caddy-404.conf corresponde a linhas JSON com "status":404 — veja documentação de logs do Caddy para o esquema exato.

Renovação de certificados. O Caddy lida automaticamente com o Let's Encrypt, nada a fazer. Verifique a cada 60 dias com caddy adapt se a configuração ainda é válida.

wstunnel vs alternativas

Veredito pragmático:

• Solo / 1–3 utilizadores / contorno de firewall corporativo ou DPI leve → wstunnel.
• Multi-utilizador / contorno do GFW da China → V2Ray (veja o nosso guia V2Ray VMess/VLess).
• Quer adicionar uma camada TLS em cima de um WireGuard existente sem refazer tudo → Cloak.
• Apenas escapar de uma rede corporativa para SSH / web → sshuttle (não requer VPS).

Resolução de problemas comuns

Sintoma: wss handshake failed: 502 bad gateway. O servidor wstunnel não está a escutar na porta 8080, ou o Caddy não consegue encontrá-lo. Verifique systemctl status wstunnel e ss -tlnp | grep 8080.

Sintoma: o túnel sobe mas não flui tráfego. O WireGuard do lado do servidor não autoriza o peer do cliente. Verifique novamente wg show e o bloco [Peer] do servidor — geralmente um erro de cópia e colagem em AllowedIPs.

Sintoma: throughput anormalmente baixo (< 30 Mbps). Proxy Cloudflare ativado (nuvem laranja): o Cloudflare limita WebSockets no plano gratuito. Desative o proxy DNS (nuvem cinza) ou mude para um domínio sem Cloudflare.

Sintoma: desconexões a cada 10 minutos. O Caddy tem um timeout padrão em sessões WS longas. Adicione dentro do bloco reverse_proxy:

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

Leituras adicionais

• VPN auto-hospedado no Contabo: guia completo do WireGuard 2026
• V2Ray VMess/VLess: configuração completa 2026
• Cloak: ofuscação TLS para VPN auto-hospedado
• Roteamento VPN personalizado no Contabo: contorno de DPI Irão / China

Fontes e referências:

• Erebe/wstunnel — repositório oficial no GitHub
• RFC 6455 — O Protocolo WebSocket
• Documentação do Caddy — diretiva reverse_proxy
• Whitepaper do WireGuard — Jason A. Donenfeld

Publicado em 2026-06-03. Testes realizados num VPS Contabo S Nuremberg + cliente de fibra residencial em Paris, março de 2026. O desempenho pode variar significativamente dependendo do datacenter Contabo escolhido, ISP do cliente e qualidade de peering — sempre faça benchmark no seu próprio contexto antes de se comprometer com uma configuração.

Lembrete: wstunnel e auto-hospedagem de VPN são perfeitamente legais na UE, EUA, Canadá e na maioria dos países democráticos. Verifique as regulamentações locais na China, Irão, EAU, Rússia antes de implantar — a VPNSmith publica este conteúdo para fins educacionais.