Como o VLESS Reality torna o tráfego VPN invisível

Todo protocolo VPN tem um fingerprint. A iniciação de handshake do WireGuard é sempre exatamente 148 bytes com estrutura fixa. O canal de controle do OpenVPN tem padrões de timing que são óbvios sob análise. Mesmo Shadowsocks, projetado especificamente pra resistência à censura, produz tráfego com entropia mensuravelmente alta que sistemas DPI podem sinalizar como "não HTTPS normal".

Criptografia protege conteúdo. Não faz nada pra esconder o fato de que está usando VPN.

VLESS Reality, lançado em Xray-core v1.8.0 no início de 2023, toma uma abordagem completamente diferente. Em vez de criptografar tráfego e esperar que censores não consigam identificar o wrapper, faz conexões VPN parecerem idênticas a navegação HTTPS comum. Não similares. Idênticas. O certificado TLS que sua conexão apresenta é real, emitido por uma autoridade certificadora real, pra um site real.

Aqui está como isso funciona, por que é difícil de bloquear, e o que você abre mão pra conseguir.

O problema da detecção

Um sistema de inspeção profunda de pacotes não precisa descriptografar seu tráfego pra saber qual protocolo você está rodando. Só precisa reconhecer padrões.

WireGuard é o exemplo mais fácil. A mensagem de iniciação de handshake começa com campo de tipo de 1 byte, 3 bytes de zeros reservados, índice de remetente de 4 bytes, depois chave efêmera não criptografada de 32 bytes. Essa estrutura nunca muda. TSPU da Rússia (Sistemas Técnicos pra Combater Ameaças) pode detectar WireGuard com precisão próxima de 100% combinando esse padrão no primeiro pacote.

OpenVPN é ligeiramente mais difícil de detectar mas não muito. Seu handshake TLS tem timing distintivo e seu canal de controle usa formato de framing reconhecível. Great Firewall da China bloqueia confiavelmente há anos.

O problema mais difícil é análise de entropia. Tráfego completamente criptografado (bytes aleatórios sem estrutura reconhecível) na verdade parece suspeito. Tráfego HTTPS normal tem perfil estatístico específico: handshake TLS com cadeias de certificado previsíveis, seguido de dados de aplicação criptografados com tamanhos de registro característicos. Uma conexão Shadowsocks é stream de bytes de alta entropia desde o primeiro pacote. Pra um classificador estatístico, essa diferença é óbvia.

Esse é o desafio fundamental. Criptografia torna seus dados ilegíveis, mas o tráfego em si ainda tem forma. Censores não precisam ler seus dados. Só precisam reconhecer essa forma.

Por que ofuscação tradicional falha

Antes do Reality existir, a comunidade de resistência à censura tentou várias abordagens de ofuscação de tráfego pra esse problema.

obfs4 envolve tráfego em camada projetada pra parecer ruído aleatório. Funcionou por um tempo. Depois China e Irã implantaram classificadores que sinalizam streams de alta entropia que não combinam com qualquer protocolo conhecido. Se tráfego não parece HTTP, HTTPS, DNS, ou outro protocolo comum, é bloqueado ou estrangulado. Ruído aleatório é na verdade bem distintivo quando tudo ao redor é estruturado.

Shadowsocks teve o mesmo problema de entropia. Variantes AEAD melhoraram coisas, mas a questão fundamental permaneceu: o tráfego não parece nada legítimo. Sistemas DPI chineses começaram a bloquear conexões Shadowsocks detectando a ausência de handshake TLS padrão combinado com payloads de alta entropia.

Domain fronting (mandando tráfego pra um domínio via CDN que roteia pra outro) funcionou bem até Google, Amazon, e Cloudflare todos pararem entre 2018 e 2020. Dependeu de provedores de CDN tolerarem a prática. Pararam.

Trojan foi melhoria. Imita HTTPS de fato realizando handshake TLS e servindo um site real a conexões não autorizadas. Mas Trojan usa certificado TLS auto-configurado, o que significa que a cadeia de certificado é diferente do que um site real apresentaria. Um prober ativo que compara o certificado do seu servidor contra logs Certificate Transparency conhecidos pode ver a discrepância.

O padrão entre essas ferramentas: tentam aproximar tráfego normal sem ser de fato tráfego normal. Dada análise suficiente, a aproximação sempre se quebra.

RPRX (criador do projeto XTLS) resumiu o problema claramente: censura por whitelist de SNI tornou todas ferramentas de circunvenção baseadas em TLS antes do Reality indisponíveis em certas áreas da noite pro dia. Se um censor decide só permitir conexões a servidores TLS legítimos conhecidos, qualquer ferramenta usando seu próprio certificado está morta.

Como Reality realmente funciona

Reality não aproxima handshake TLS. Realiza um real.

Aqui está o fluxo de conexão, passo a passo:

Passo 1: cliente manda ClientHello. Seu cliente inicia handshake TLS 1.3. O campo Server Name Indication (SNI) contém o hostname de site real popular, como www.microsoft.com. O cliente usa a biblioteca uTLS pra copiar o fingerprint TLS exato de um navegador real (Chrome 120, Firefox, Safari, o que configurar). O ClientHello é byte-por-byte idêntico ao que aquele navegador mandaria.

Passo 2: servidor recebe o ClientHello. O servidor Reality checa um shortId pré-compartilhado e valida o cliente usando key agreement X25519. Essa autenticação acontece dentro de campos que são opacos a qualquer observador, escondidos na extensão de key share do handshake TLS.

Passo 3: servidor contata o site real de camuflagem. O servidor Reality abre sua própria conexão TLS ao real www.microsoft.com (ou qualquer domínio que você configurou como alvo de camuflagem). Realiza um handshake TLS legítimo com servidores da Microsoft.

Passo 4: servidor encaminha o certificado real. A cadeia de certificado que Microsoft retorna é encaminhada de volta ao seu cliente. Isso é certificado real, assinado por CA real, pra domínio real. Não há nada pra detectar porque não há nada falso.

Passo 5: clientes autenticados são tunelados. Se o cliente passou na autenticação shortId e X25519 no passo 2, o servidor estabelece o túnel VLESS. Tráfego VPN flui dentro do que parece sessão HTTPS normal com microsoft.com.

Passo 6: conexões não autenticadas são encaminhadas. Se alguém (prober ativo de censor, pesquisador, qualquer um) conecta sem credenciais válidas, o servidor proxia transparentemente sua conexão pro real microsoft.com. Veem conteúdo real. Cabeçalhos reais. Comportamento real. Não há nada pra distinguir o servidor de um proxy reverso legítimo.

Essa é a diferença chave de toda abordagem anterior. O certificado é real. O site por trás é real. O fingerprint TLS combina com navegador real. Não há mentira detectável na cadeia inteira.

Resistência a probing ativo

Censores não só analisam tráfego passivamente. Probam ativamente servidores suspeitos.

Great Firewall da China faz isso desde pelo menos 2012. Quando detecta conexão que pode ser proxy, replaya o handshake do cliente ou manda seu próprio probe ao servidor. Se o servidor responde de jeito que difere de serviço legítimo, é bloqueado.

É assim que servidores Trojan eventualmente são detectados. Um prober conecta, não autentica, e o servidor retorna página web genérica. Mas o certificado TLS não combina com o que logs de transparência de certificado dizem que aquele domínio deveria ter. Ou os cabeçalhos de resposta HTTP são sutilmente diferentes de uma implantação real daquele software de servidor web. Inconsistências pequenas, mas suficientes.

Reality derrota probing ativo completamente. Quando um prober conecta a um servidor Reality sem credenciais válidas, é encaminhado ao site real de camuflagem. A resposta não é simulação. É microsoft.com, servida por proxy transparente. Mesmo certificado. Mesmos cabeçalhos. Mesmo comportamento. Mesmo conteúdo.

Um censor precisaria distinguir entre "um usuário visitando microsoft.com" e "um servidor Reality fazendo proxy pra microsoft.com". De fora, são idênticos. A sessão TLS parece a mesma. As respostas HTTP são as mesmas. O endereço IP é a única coisa diferente, e um endereço IP hospedando proxy reverso pra microsoft.com não é inerentemente suspeito.

Vision flow e TLS-em-TLS

Há um vetor de detecção mais sutil que Reality também endereça. Quando você roda VPN dentro de um túnel TLS, o tráfego VPN criptografado contém seus próprios handshakes TLS (todo site HTTPS que visita gera um). Isso cria padrão TLS-em-TLS: registros TLS contendo o que são claramente mais registros TLS, visíveis através de análise de tráfego mesmo que o conteúdo seja criptografado.

O XTLS Vision flow (xtls-rprx-vision) elimina isso. Em vez de criptografar duplamente o tráfego TLS, Vision detecta quando o payload interno já é protegido por TLS e o passa adiante com wrapping mínimo. A camada TLS externa lida com autenticação e framing; os dados TLS internos fluem sem criptografia redundante.

Um paper USENIX confirmou que Vision atingiu suas metas de design. O padrão de tráfego de uma conexão VLESS+Vision é estatisticamente indistinguível de uma conexão HTTPS direta ao site de camuflagem.

Isso importa porque análise de tráfego (olhar tamanhos de pacote, timing, e padrões sem descriptografar nada) é o ataque restante mais plausível contra Reality. Vision fecha esse gap.

O que torna difícil de bloquear

Pra bloquear VLESS Reality, um censor precisaria fazer uma das seguintes:

Bloquear o domínio de camuflagem inteiramente. Se Reality é configurado pra impersonar microsoft.com, o censor precisaria bloquear microsoft.com. Ou google.com. Ou qualquer outro domínio que operadores escolham. Bloquear grandes serviços de nuvem e produtividade tem custos econômicos enormes. China aceitou esse custo pra alguns serviços, mas mesmo China não bloqueou microsoft.com.

Detectar a autenticação X25519 no handshake TLS. Essa informação é carregada na extensão de key share, que é criptografada em TLS 1.3. Sem quebrar o handshake TLS em si, a autenticação é invisível.

Identificar servidores Reality por reputação de IP. Essa é na verdade a abordagem mais efetiva que censores acharam até agora. TSPU da Rússia começou a sinalizar endereços IP VPS que recebem conexões combinando certos padrões comportamentais: conexões de IPs residenciais a IPs VPS que também fazem proxy a sites bem conhecidos. Isso não é detectar Reality em si. É detectar os padrões de infraestrutura ao redor. A taxa de detecção pra VLESS Reality bem configurado ainda está abaixo de 5% baseado em relatórios da comunidade de fevereiro 2026.

Análise de timing de tráfego. Tráfego VPN tem características de timing diferentes de navegação web normal. Um usuário fazendo streaming de vídeo por Reality gera fluxos sustentados de alto throughput que não combinam com padrões típicos de navegação HTTPS pra microsoft.com. Essa é uma fraqueza real, embora exija análise sofisticada e produza muitos falsos positivos.

Irã investigou bloqueio de Reality (discutido no GitHub issue #3269 no repositório Xray-core). Até agora, nenhum método de detecção confiável foi implantado. A abordagem da Rússia de pontuação de reputação de IP é a mais bem-sucedida, mas pega uma fração pequena de conexões e exige tuning manual constante.

Os tradeoffs

Rodamos VLESS Reality em produção no Fexyn, junto com WireGuard e OpenVPN. Não vamos fingir que é almoço grátis. Há custos reais.

Latência. Uma conexão Reality adiciona aproximadamente 100ms de latência comparada com WireGuard. O handshake TLS extra com o site de camuflagem, a autenticação X25519, e a camada de proxy todos levam tempo. Pra navegação geral, isso é mal notável. Pra games ou voz em tempo real, vai sentir.

Overhead TCP. VLESS Reality roda sobre TCP. WireGuard roda sobre UDP. TCP tem head-of-line blocking: se um pacote é perdido, tudo atrás espera. Em redes com perda (conexões móveis, Wi-Fi congestionado), isso significa travamentos periódicos que protocolos UDP evitam. O modo de transporte XHTTP ajuda multiplexando, mas a limitação fundamental TCP permanece.

Complexidade de configuração. WireGuard precisa de par de chaves e endpoint. Reality precisa de domínio de camuflagem, shortId, par de chaves X25519, seleção de fingerprint uTLS, configuração de transporte, e teste cuidadoso pra garantir que o site de camuflagem funciona corretamente. Lidamos com isso automaticamente no Fexyn (o cliente recebe configuração completa da nossa API), mas self-hosters têm mais a gerenciar.

Dificuldade de debug. Quando uma conexão WireGuard falha, os modos de falha são diretos: chave errada, endpoint errado, porta bloqueada. Quando uma conexão Reality falha, pode ser o domínio de camuflagem, o shortId, o par de chaves, o fingerprint uTLS, a camada de transporte, o site de camuflagem ser inalcançável do servidor, ou meia dúzia de outras coisas. Gastamos tempo significativo debugando conexões Reality que se revelaram ser problemas de domínio de camuflagem.

Nem todos domínios de camuflagem funcionam igualmente bem. O site de camuflagem precisa suportar TLS 1.3, ter certificado que encadeia a CA confiável, e ser alcançável do seu servidor. Alguns domínios funcionam perfeitamente. Outros têm peculiaridades que causam falhas sutis. Testamos extensivamente e nos estabelecemos num conjunto de alvos de camuflagem confiáveis, mas isso exigiu trabalho real de tentativa e erro.

Taxas reais de detecção

Baseado em relatórios da comunidade e nossos próprios testes:

País	WireGuard	OpenVPN	VLESS Reality
Rússia (TSPU)	Bloqueado instantaneamente	Bloqueado/estrangulado	~95% sucesso
China (GFW)	Bloqueado	Bloqueado	Funciona, bloqueios periódicos de IP
Irã	Bloqueado	Intermitente	Funciona, sob pesquisa ativa
Turcomenistão	Bloqueado	Bloqueado	Dados limitados, reportado funcionando

A taxa de falha de ~5% na Rússia vem principalmente de pontuação de reputação de IP, não detecção de protocolo. Usar faixas de IP que parecem residenciais ou provedores de nuvem que não estão em listas negras leva a taxa de sucesso pra perto de 100%.

Na China, a ameaça principal é bloqueio baseado em IP em vez de detecção de protocolo. GFW mantém listas de faixas conhecidas de IP VPS e periodicamente bloqueia. Conexões Reality de IPs limpos funcionam consistentemente.

Quando usar

Se está em país sem censura ativa, WireGuard é a melhor escolha. É mais rápido, mais simples, e usa UDP. Não há razão pra aceitar os tradeoffs do Reality se ninguém está tentando bloquear sua conexão.

Se está em ou viajando pra país com DPI ativo (Rússia, China, Irã, EAU, muitos outros), VLESS Reality com Vision flow é o protocolo que de fato funciona. WireGuard será bloqueado antes de você terminar o handshake.

Fexyn suporta ambos, com rotação automática de protocolo que troca pra VLESS Reality quando WireGuard é bloqueado. Você tem velocidade do WireGuard quando está disponível e resistência à censura do Reality quando precisa.

Se quer entender mais sobre o protocolo VLESS em si (separado do transporte Reality), escrevemos análise detalhada do VLESS que cobre a arquitetura do protocolo e como compara a alternativas.

Experimente o Fexyn grátis por 7 dias — Stealth (VLESS Reality com Vision flow) está incluído em todo plano. Ativistas e organizadores de movimento podem querer a página VPN pra ativistas pro enquadramento de modelo de ameaça.