VLESS vs WireGuard
VLESS vs WireGuard: WireGuard é provavelmente o melhor protocolo VPN já projetado pra redes não restritas. VLESS Reality é provavelmente o melhor protocolo pra redes onde alguém está ativamente tentando te parar. Esses são problemas diferentes, e os protocolos que os resolvem não se parecem nada.
Maioria dos artigos de comparação escolhe um vencedor. Não vamos, porque a resposta depende de onde está e como a rede entre você e o servidor parece. Enviamos ambos os protocolos no Fexyn e auto-trocamos entre eles por essa razão. (Pra visão de mais alto nível de o que é um protocolo VPN, comece lá.)
Aqui está o que realmente importa ao escolher entre eles.
WireGuard: por que se tornou o padrão
WireGuard ganhou sua reputação. O protocolo inteiro é aproximadamente 4.000 linhas de código kernel. Pra comparação, OpenVPN tem mais de 100.000 linhas. Implementações IPsec rodam ainda mais longas. Codebases menores significam menos lugares pra bugs se esconderem, o que importa enormemente pra software crítico de segurança.
As escolhas criptográficas são opinativas e fixas: ChaCha20-Poly1305 pra criptografia simétrica, Curve25519 pra troca de chave, BLAKE2s pra hashing. Não há negociação de cipher, sem matriz de configuração, sem menu "escolha seu algoritmo favorito". Essa é decisão de design deliberada do Jason Donenfeld, e elimina uma classe inteira de ataques de downgrade que afetam protocolos com cipher suites configuráveis.
Performance segue da arquitetura. WireGuard opera no nível do kernel (ou em userspace via boringtun), processando pacotes com troca de contexto mínima. Transporte UDP evita o problema de head-of-line blocking do TCP inteiramente. Numa conexão fibra de 500 Mbps, WireGuard consistentemente entrega cerca de 480 Mbps em nossos testes. Isso é 96% do throughput baseline. Você está mal pagando taxa pela criptografia.
Estabelecimento de conexão também é rápido. Um handshake WireGuard é uma única ida e volta: iniciador manda mensagem criptografada, respondedor manda uma de volta, e o túnel está ativo. Na implementação Fexyn no Windows, a sequência completa de conexão de "usuário clica conectar" a "tráfego fluindo pelo túnel" tem média de cerca de 611 milissegundos. Maior parte desse tempo é gasto configurando o adaptador TUN e configurando rotas, não esperando pelo protocolo em si.
Pra maioria dos usuários na maioria das redes, WireGuard é a escolha correta. É rápido, é simples, e tem anos de hardening de produção entre Linux, Windows, macOS, iOS, e Android.
O problema dos 148 bytes
WireGuard tem fraqueza que nenhuma quantidade de engenharia inteligente pode corrigir, porque é consequência direta da filosofia de design do protocolo.
Toda mensagem de iniciação de handshake WireGuard tem exatamente 148 bytes. O primeiro byte é 0x01 (tipo de mensagem 1: iniciação de handshake). Os próximos três bytes são 0x00 0x00 0x00 (reservados, sempre zero). Isso é seguido por índice de remetente de 4 bytes e depois chave pública efêmera Curve25519 não criptografada de 32 bytes.
Essa estrutura nunca varia. Não pode variar; a especificação do protocolo requer.
Sistemas de inspeção profunda de pacotes exploram isso. A lógica de detecção é embaraçosamente simples. Aqui está o que nDPI, biblioteca DPI open-source usada por fornecedores de equipamento de rede mundialmente, realmente checa:
if (message_type == 1 && packet_length == 148)
→ classificar como WireGuard
Só isso. Uma condicional. O handshake de 148 bytes com 0x01 0x00 0x00 0x00 inicial é fingerprint único que nenhum outro protocolo produz. Você não precisa de machine learning ou análise estatística. Um estudante de redes do primeiro ano poderia escrever esse filtro.
TSPU da Rússia (Sistemas Técnicos pra Combater Ameaças) tem bloqueado WireGuard com precisão próxima de 100% desde meados de 2024. Não estrangulando, não degradando. Bloqueando. Os pacotes UDP carregando handshakes WireGuard simplesmente desaparecem. Great Firewall da China faz a mesma coisa. Irã bloqueia. Qualquer governo rodando equipamento DPI moderno pode adicionar WireGuard à sua lista de bloqueio numa tarde.
O projeto WireGuard está ciente disso. Não é bug. O protocolo foi projetado pra velocidade e simplicidade, não pra stealth. Tornar o handshake de tamanho variável ou adicionar padding complicaria o protocolo e violaria o princípio de design central de complexidade mínima. Esses são tradeoffs razoáveis pro modelo de ameaça que WireGuard visa. Só significam que WireGuard é a ferramenta errada se está numa rede onde alguém está ativamente inspecionando tráfego.
AmneziaWG: correção parcial
AmneziaWG 2.0 tenta endereçar o problema de fingerprinting adicionando padding aleatório a pacotes WireGuard, usando cabeçalhos dinâmicos, e injetando pacotes lixo. Faz a detecção mais difícil. Mas ainda está trabalhando dentro do framework UDP do WireGuard, o que significa que censores podem aplicar análise estatística à distribuição de tamanho de pacote, intervalos de timing, e características de entropia. Tráfego UDP que não combina com qualquer protocolo conhecido é suspeito por padrão em ambientes pesadamente censurados.
AmneziaWG é passo adiante. Não é solução pro problema fundamental.
VLESS Reality: escondido à vista
VLESS toma a abordagem oposta ao WireGuard em quase todo jeito. Onde WireGuard é protocolo VPN construído pra propósito com formato de fio único, VLESS é protocolo de proxy que delega sua criptografia inteiramente ao TLS 1.3. O cabeçalho VLESS em si adiciona só 25 a 50 bytes de overhead, contendo byte de versão, UUID pra autenticação, e informação de roteamento.
O protocolo só faz sentido dentro de conexão TLS. Tira TLS e VLESS não tem criptografia, sem proteção de integridade, nada. Essa dependência de TLS é frequentemente criticada como fraqueza. Na verdade é a fonte da maior força do VLESS.
VLESS Reality com Vision flow estende o protocolo base com sistema de camuflagem que faz a conexão genuinamente indistinguível de tráfego HTTPS normal. Quando você conecta a servidor Fexyn usando Reality+Vision, o servidor realiza handshake TLS real com site real, como www.microsoft.com, e encaminha o certificado legítimo daquele site ao seu cliente. Seu cliente usa biblioteca uTLS pra produzir mensagem ClientHello que é byte-por-byte idêntica ao que Chrome ou Firefox mandariam.
Se censor proba o servidor, é encaminhado pra microsoft.com real. Certificado real. Conteúdo real. Cabeçalhos HTTP reais. Não há simulação envolvida. O servidor funciona como proxy reverso transparente pra conexões não autenticadas e como túnel VLESS pras autenticadas.
O resultado é que nenhum sistema DPI passivo pode distinguir uma sessão VLESS Reality de alguém navegando no site da Microsoft. Probing ativo também falha porque o probe recebe respostas genuínas de site genuíno. Detecção exigiria que o censor de algum jeito diferencie entre "usuário visitando microsoft.com" e "servidor Reality fazendo proxy pra microsoft.com", que de uma perspectiva de rede são a mesma coisa.
Isso funciona na Rússia. Funciona na China. Funciona no Irã. Não teoricamente. Agora, em produção, pra usuários reais.
O que VLESS abre mão
VLESS Reality não é grátis. Você troca coisas pra conseguir essa invisibilidade.
O maior custo é TCP. VLESS roda sobre TCP (via TLS), o que significa que herda o problema de head-of-line blocking do TCP. Se um único pacote é perdido, todo pacote subsequente naquele stream TCP espera retransmissão. WireGuard evita isso rodando em UDP. Em conexões com perda, o tipo que se tem em Wi-Fi cheio ou redes móveis com cobertura irregular, a diferença é mensurável. VLESS também é apenas TCP, ponto. XHTTP (uma opção de transporte mais nova no XRay-core) adiciona multiplexing mas não muda a restrição TCP subjacente. Pra games ou voz em tempo real, onde latência importa mais que confiabilidade, transporte UDP do WireGuard é melhor.
O caminho de conexão é mais complexo também. Sessão VLESS Reality envolve handshake TLS 1.3 (1-RTT ou 0-RTT), negociação de protocolo VLESS, e potencialmente setup de adaptador TUN com roteamento tun2socks. Mais peças móveis que o handshake de uma rodada do WireGuard. No lado do servidor, Reality mantém conexão TLS ao destino de camuflagem e gerencia a lógica de proxy pra conexões não autenticadas. Isso custa mais memória e CPU por cliente que processamento de pacote em kernel-space do WireGuard. Em escala, a diferença soma pra operadores de servidor.
Depois há auditabilidade. As 4.000 linhas de código do WireGuard foram formalmente verificadas e amplamente auditadas. XRay-core é grande codebase Go com superfície significativamente maior. O protocolo VLESS central é simples, mas a implementação ao redor (Reality, fingerprinting uTLS, múltiplos modos de transporte) não recebeu o mesmo nível de revisão de segurança independente.
Esses são custos reais. São aceitáveis quando a alternativa é ter sua conexão bloqueada. Não são custos que deveria pagar quando não tem que.
Cabeça a cabeça: números de performance do Fexyn
Testamos ambos protocolos no mesmo hardware, mesmo servidor, mesmas condições de rede. Windows 11, fibra 500 Mbps, conectando ao nosso servidor de Frankfurt. Esses números vêm de benchmarks automatizados, não rodadas escolhidas a dedo.
| Métrica | WireGuard | VLESS Reality |
|---|---|---|
| Tempo de conexão fria | ~611 ms | ~627 ms |
| Tempo de reconexão warm | N/A | ~42 ms |
| Tempo de desconexão | ~108 ms | ~100 ms |
| Throughput (baseline 500 Mbps) | ~480 Mbps (96%) | Menor (overhead TCP) |
| Transporte | UDP | TCP (TLS 1.3) |
| Rodadas de handshake | 1 ida e volta | TLS 1-RTT + cabeçalho VLESS |
| Detectável por DPI | Sim, trivialmente | Não, com Reality |
| Overhead de protocolo por pacote | ~32 bytes (tag Poly1305 + contador) | 25-50 bytes (VLESS) + registro TLS |
Os tempos de conexão estão mais próximos do que maioria das pessoas espera. A diferença de 16 milissegundos entre 611 ms e 627 ms pra conexão fria não é algo que usuário perceberia. Maior parte desse tempo em ambos os casos é setup de adaptador, configuração de rota, e verificação, não latência no nível de protocolo.
VLESS tem vantagem interessante em reconexões warm. Porque XRay-core pode ser mantido rodando como processo persistente entre conexões, uma reconexão (trocar servidores ou recuperar de mudança de rede) só requer re-estabelecer a sessão TLS. Isso leva cerca de 42 milissegundos em nossos testes. Reconexões WireGuard também são rápidas, mas o ciclo completo de teardown e recriação de adaptador na nossa implementação Windows não tem a mesma otimização de caminho warm.
Onde WireGuard sai à frente claramente é throughput. Transporte UDP com processamento de pacote no nível de kernel (ou userspace de alta performance) dá ao WireGuard vantagem mensurável, especialmente em conexões de alta banda. O gap aumenta em redes com perda onde comportamento de retransmissão TCP adiciona picos de latência.
Quando usar qual
Isso é mais simples do que o resto do artigo pode sugerir.
Use WireGuard se está numa rede onde tráfego VPN não é bloqueado ou estrangulado. Internet doméstica em maioria dos países ocidentais, redes de escritório que permitem uso de VPN, redes móveis em países sem censura ativa. WireGuard te dá o melhor throughput, a menor latência, e o modelo de conexão mais simples. É o padrão certo.
Use VLESS Reality se está numa rede que bloqueia ou degrada protocolos VPN. Redes universitárias que bloqueiam WireGuard. Firewalls corporativos que só permitem HTTPS na porta 443. Wi-Fi público com restrições baseadas em DPI. E obviamente, em qualquer lugar na Rússia, China, Irã, ou outros países com censura ativa de internet. VLESS Reality é o único protocolo de produção que testamos que confiavelmente passa por todos esses.
Use rotação automática se viaja entre ambos ambientes ou não tem certeza do que sua rede permite. Esse é o modo padrão do Fexyn: tente WireGuard primeiro pra velocidade, caia pra VLESS Reality se WireGuard falha, depois caia pra OpenVPN como último recurso. A troca acontece automaticamente sem derrubar sua proteção de kill switch.
Por que Fexyn envia ambos
Maioria dos provedores de VPN envia um protocolo e talvez ofereça OpenVPN como fallback legado. NordLynx do NordVPN é WireGuard com camada NAT (veja Fexyn vs NordVPN pra análise completa). Lightway do ExpressVPN é protocolo customizado que ainda é detectável por DPI. Nenhum dos provedores ocidentais grandes envia VLESS Reality porque vem do ecossistema XRay/V2Ray, que é principalmente em chinês e requer familiaridade profunda com codebase que não tem especificação formal.
Achamos que VPN deve funcionar em todo lugar. No seu Wi-Fi de casa onde nada está bloqueando você, sim. Também na rede de hotel em Moscou que está rodando TSPU. No campus universitário que só permite HTTPS. No Wi-Fi de cafeteria que bloqueia UDP inteiramente.
Isso requer múltiplos protocolos com propriedades diferentes. WireGuard pra velocidade quando nada está no caminho. VLESS Reality pra invisibilidade quando algo está. OpenVPN pras redes raras onde nenhum funciona mas tráfego VPN legado baseado em TLS ainda é permitido.
O motor de rotação de protocolo do Fexyn tenta na ordem baseado na sua configuração de modo de conexão. "Velocidade primeiro" começa com WireGuard. "Stealth primeiro" começa com VLESS Reality. De qualquer jeito, você acaba conectado. A seleção de protocolo é automática, o kill switch fica ativo durante rotação, e o usuário não precisa entender qualquer das diferenças descritas neste artigo.
Só precisam que sua internet funcione. Mesmo quando alguém está tentando garantir que não funcione.
Você pode experimentar ambos protocolos hoje com uma assinatura Fexyn.