Protocolo VLESS: VPN V2Ray, Servidor Xray e Guia para Contornar a Censura
Aproximadamente cinco anos após surgir em um obscuro repositório de incubação do GitHub, o VLESS tornou-se discretamente o protocolo padrão por trás dos proxies usados por pessoas na Rússia, Irã e China. Os motivos são pouco românticos. É pequeno. Não criptografa nada por si só. É também o único protocolo amplamente implementado que os maiores sistemas estatais de inspeção profunda de pacotes (DPI) ainda não conseguiram superar decisivamente até meados de 2026.
Este guia explica o que é o VLESS como um protocolo leve, como ele funciona internamente, o que roda sobre ele (Xray, XTLS, REALITY), como ele se compara ao VMess, Trojan, Shadowsocks, WireGuard e protocolos VPN tradicionais como o OpenVPN, e como é uma configuração real de VPN VLESS na prática. É uma explicação técnica, não um passo a passo de configuração. Se você terminar de ler e ainda quiser copiar e colar comandos de servidor, a documentação do projeto em xtls.github.io é o próximo passo certo.
O que é VLESS e por que a comunidade V2Ray o criou.
VLESS, abreviação de "VMess Less", é um protocolo proxy leve e sem estado, introduzido em 2020 pelo desenvolvedor conhecido como RPRX, que manteve um repositório de incubação em RPRX/v2ray-vless desde 2019. Ele foi projetado como uma simplificação deliberada do VMess, o protocolo V2Ray original, que havia se tornado complexo no final da década de 2010 devido à sua própria criptografia, proteção contra repetição e mecanismos de sincronização de relógio.
Atualmente, o VLESS reside principalmente em duas bases de código. O repositório original v2fly/v2ray-core o contém para fins de compatibilidade. O fork XTLS/Xray-core, também mantido por RPRX, é a implementação com desenvolvimento mais ativo: 38.600 estrelas no GitHub e aproximadamente 5.400 forks em maio de 2026, contra 33.900 estrelas no v2fly/v2ray-core. O Xray inclui os recursos essenciais, como o controle de fluxo do XTLS Vision e o transporte REALITY, que o v2fly original não oferece.
Como funciona o protocolo VLESS: UUID, sem criptografia, TLS externo
O protocolo de rede VLESS é suficientemente curto para ser descrito em um parágrafo. Um cliente abre uma conexão. Ele envia um cabeçalho. O cabeçalho contém um byte de versão, um UUID de 16 bytes para o usuário, um indicador de comprimento para o campo opcional de complementos, os próprios complementos, um comando de um byte (TCP ou UDP), a porta de destino, um byte de tipo de endereço e o endereço. Isso resulta em 25 a 50 bytes por conexão. O OpenVPN utiliza mais de 100 bytes por pacote.
O cabeçalho não é criptografado de forma alguma pelo próprio VLESS. O protocolo exige explicitamente `encryption: "none"` em sua configuração JSON, e a documentação do v2fly afirma que este campo não pode ser deixado em branco — ele deve exibir "none" em voz alta, para que os operadores se lembrem de que o protocolo delega toda a confidencialidade ao transporte subjacente. Na prática, esse transporte é quase sempre o TLS 1.3.
Essa escolha de design é a origem de todas as propriedades interessantes do VLESS. Ao não executar sua própria camada de criptografia, o VLESS evita a falha que condenou o VMess em redes censuradas. Uma segunda camada de criptografia dentro de um túnel TLS externo produz o que pesquisadores de análise de tráfego chamam de padrões "TLS-em-TLS". Sistemas de inspeção profunda de pacotes (DPI) estaduais, treinados para detectar exatamente esse formato de dupla criptografia, foram o principal motivo pelo qual as taxas de detecção do VMess ultrapassaram 80% no Grande Firewall da China até setembro de 2025. O VLESS, carregando apenas um bloco de autenticação e metadados de roteamento, se assemelha muito mais a uma única conversa TLS comum, o que impede o tipo de identificação de protocolo em que os sistemas de inspeção profunda de pacotes se baseiam.
Outra omissão deliberada é a ausência de estado. O VMess depende de relógios sincronizados entre o cliente e o servidor, com timestamps de pacotes usados para evitar ataques de repetição. O resultado foram anos de falhas de conexão confusas sempre que o relógio de um celular se desviava, um laptop iniciava em dual boot ou um servidor estava em um fuso horário diferente. O VLESS é sem estado. O UUID é todo o processo de autenticação. Se o UUID corresponder, a conexão é autorizada; caso contrário, é rejeitada no primeiro byte. Nada depende do tempo.
Os UUIDs no VLESS são identificadores padrão RFC-4122. O comando `xray uuid` os gera; qualquer gerador de UUID padrão também funciona. Strings personalizadas de até 30 bytes são aceitas e mapeadas para UUIDs através do que a documentação chama de "Padrão de Mapeamento de UUID do VLESS". A maioria das configurações utiliza UUIDs canônicos porque o mapeamento não altera nada na prática.
As opções de transporte ficam subjacentes ao protocolo: TCP (com ou sem TLS), mKCP, WebSocket, gRPC e QUIC são todos suportados. Cada um deles molda o tráfego de forma diferente. O WebSocket permite que o VLESS se oculte por trás de um handshake de atualização HTTP/1.1 normal e rote o tráfego por meio de CDNs como o Cloudflare. O gRPC utiliza a multiplexação do HTTP/2. O QUIC transporta tudo dentro de uma sessão TLS 1.3 externa baseada em UDP. O protocolo não se importa com o meio de transporte em que é executado. Essa separação é o que o torna portátil.
Raio-X, REALIDADE e XTLS: A pilha que o VLESS realmente utiliza.
Na prática, ninguém corre com a VLESS completamente nu. O interessante é o que corre ao redor dela.
O Xray-core é o ambiente de execução dominante. Trata-se de um fork do V2Ray-core, iniciado por RPRX e pelos colaboradores do XTLS após uma divisão na comunidade, e inclui duas tecnologias das quais o VLESS depende para trabalhos sérios de burla à censura: XTLS Vision e REALITY.
XTLS Vision (especificado como `flow: "xtls-rprx-vision"` na configuração) é um esquema de preenchimento aplicado ao tráfego TLS 1.3. O problema que ele resolve é sutil. Os registros TLS 1.3 têm assinaturas de comprimento previsíveis quando transportam dados internos da aplicação com formatos fixos — os comprimentos vazam informações sobre o que está sendo tunelado. O Vision adiciona bytes de preenchimento durante a fase inicial do handshake. Assim que a conexão é estabelecida, ele alterna para a cópia bruta do socket. No Linux, ele usa a chamada de sistema `splice()` para encaminhar pacotes TCP no kernel sem copiá-los pelo espaço do usuário. O resultado é uma taxa de transferência próxima à que uma conexão TCP sem proxy ofereceria, com o vazamento da assinatura de comprimento minimizado.
O REALITY, lançado em 2023 e mantido em github.com/XTLS/REALITY, é mais radical. Um servidor VLESS+TLS padrão apresenta seu próprio certificado TLS, o que significa que ele possui um domínio, executa um Certbot em algum lugar e expõe uma impressão digital de certificado que um sistema DPI pode correlacionar com o uso de proxy. O REALITY descarta completamente essa ideia. Em vez de executar seu próprio TLS, o servidor simula o handshake de um site legítimo de terceiros. O operador escolhe o alvo: `microsoft.com`, `apple.com`, qualquer domínio. O servidor usa falsificação de SNI e uma troca de chaves X25519. Os clientes que conhecem a chave pública correta do REALITY completam um handshake TLS 1.3 real contra a cadeia de certificados simulada, exatamente como um navegador faria com um servidor web real, e então são roteados para o túnel VLESS. Os clientes que não conhecem a chave, incluindo sistemas DPI de sondagem, veem o que parece ser uma conexão normal com o site simulado, incluindo o certificado real.
A combinação de VLESS como protocolo interno, XTLS Vision para achatamento da assinatura de comprimento e REALITY para camuflagem do handshake é o que as pessoas querem dizer quando falam "VLESS+REALITY" ou "VLESS+Vision+REALITY". É a configuração que, em meados de 2026, ainda funciona em ambientes onde quase nada mais funciona.
VLESS vs VMess vs Trojan vs Shadowsocks vs WireGuard
O espaço de protocolos em torno do VLESS é pequeno e as diferenças são importantes. A versão resumida está abaixo; a versão completa está na tabela.
O VMess é o antecessor do VLESS. Ele possui sua própria criptografia AEAD, proteção contra repetição e variantes baseadas em alterId. Em uma rede sem censura, esses recursos custam alguns pontos percentuais de throughput e não agregam nenhum benefício. Em uma rede censurada, o padrão de criptografia dentro do TLS é detectável, e a telemetria do GFW indica uma taxa de detecção de aproximadamente 80% desde setembro de 2025.
Trojan é um projeto irmão de uma equipe diferente. É ainda mais simples que o VLESS: usa uma senha em vez de um UUID, não possui campo para complementos e utiliza TLS externamente. Durante anos, esse minimalismo o tornou robusto; a atualização do GFW em agosto de 2025 mudou isso, e o Trojan agora tem uma taxa de detecção de cerca de 90%.
O Shadowsocks pertence a uma família completamente diferente. Trata-se de uma cifra AEAD simétrica sem fachada TLS, projetada para se parecer com bytes aleatórios em vez de HTTPS. Essa abordagem funcionou até que o Grande Firewall da China (GFW) começou a sinalizar o tráfego totalmente criptografado como suspeito por padrão; as implementações modernas do Shadowsocks dependem de plugins de transporte (v2ray-plugin, cloak) que encapsulam a cifra em TLS ou HTTP, reconstruindo efetivamente a arquitetura VLESS na direção oposta.
O WireGuard merece uma discussão completamente diferente. Trata-se de uma VPN em nível de kernel, não de um protocolo proxy. Em uma rede limpa, ele é cerca de 2 a 3% mais rápido que VLESS+XTLS em termos de taxa de transferência bruta, com uma sobrecarga de CPU muito menor, e continua sendo a solução ideal para casos de uso comuns que exigem privacidade em relação ao provedor de internet. Em redes censuradas, seu byte de handshake fixo 0x01 é facilmente identificado, e a taxa de transferência efetiva cai para quase zero.
| Protocolo | Família | Camada externa | resistência DPI | Ideal para |
|---|---|---|---|---|
| VLESS+REALIDADE | Proxy V2Ray/Raio-X | TLS 1.3 personificado | Alta (≤5% de detecção em relatórios de campo) | Redes hostis |
| VMess | proxy V2Ray | Autocriptografia dentro do TLS | Baixo (~80% GFW) | Compatibilidade apenas com versões anteriores. |
| Trojan | Proxy de front-end TLS | TLS próprio | Baixo (~90% GFW pós-agosto de 2025) | Hospedagem própria mais simples |
| Meias Sombrias (AEAD) | Ofuscação simétrica | Bytes aleatórios / plugin TLS | Variável (depende do plugin) | Usuários de dispositivos móveis em links instáveis |
| WireGuard | VPN do kernel | Aperto de mãos UDP + Ruído | Muito baixo (detectável por DPI) | Privacidade e velocidade de rede limpa |
VLESS, censura e o bloqueio do DPI russo
O VLESS seria apenas uma nota de rodapé na história dos softwares proxy se não fosse pelo fato de que ele burla a censura na Rússia e em regimes similares de forma mais confiável do que qualquer outro protocolo amplamente utilizado. Desde 2024, os maiores sistemas estatais de inspeção profunda de pacotes (DPI) do mundo têm tentado ativamente desativá-lo. O que se seguiu foi uma lenta escalada pública de tensões.
Na Rússia, a Roskomnadzor relatou o bloqueio de 439 serviços de VPN até janeiro de 2026. O orçamento federal para bloqueio de VPNs é de aproximadamente 60 bilhões de rublos (cerca de US$ 780 milhões) para o período de 2025 a 2027, com outros 2,27 bilhões de rublos (aproximadamente US$ 29 milhões) destinados especificamente à filtragem de tráfego baseada em IA, de acordo com reportagem da zona.media em abril de 2026. Em 17 de fevereiro de 2026, a Roskomnadzor intensificou as medidas novamente, com uma forte onda de bloqueios direcionada especificamente a VLESS sobre TCP com TLS, conforme documentado pela Mezha e digirpt. Os usuários migraram para REALITY, gRPC e protocolos de transporte com CDN em questão de horas. A taxa de bypass da comunidade para VLESS+REALITY contra DPI russo ficou próxima de 99,5% durante essa onda, um número que deve ser interpretado como indicativo e não como uma medida definitiva.
Na China, o Grande Firewall passou por uma sequência semelhante em 2025. A detecção de Trojans caiu para cerca de 90% em agosto, e a de VMess para cerca de 80% em setembro. Um evento de segurança cibernética separado em setembro de 2025, um vazamento de 600 GB de um contratado chinês do Grande Firewall, relatado pela Cybernews, expôs partes da infraestrutura interna de classificação, mas não alterou, por si só, a economia de implantação. Testes da comunidade no greatfirewallguide.com relataram taxas de bypass de 98% para VLESS+REALITY+Vision no início de 2026.
No Irã, o IRGFW da MCI vem aplicando bloqueios a endereços IP da REALITY desde pelo menos abril de 2024, conforme documentado na Discussão nº 3269 do XTLS/Xray-core. Operadoras relatam que um IP que transporta cerca de 100 GB de tráfego da REALITY tende a ser bloqueado pela Irancell em até 48 horas, motivo pelo qual a rotação de servidores e o uso de CDN fronting se tornaram práticas comuns no país.
Como é a configuração de uma VPN sem VHS: servidor, clientes e configurações.
Uma implementação VLESS funcional possui três partes: um servidor em algum lugar, um cliente em cada dispositivo e uma string de conexão que os interliga.
O lado do servidor é pouco exigente. Qualquer VPS barato serve: Hetzner, Vultr, OVH, qualquer um com IPv4 público. Instale o Xray-core a partir dos binários da versão do projeto ou de um gerenciador de pacotes, gere um UUID (`xray uuid`), gere um par de chaves X25519 para o REALITY (`xray x25519`), escolha um alvo de representação (um site HTTPS real que suporte TLS 1.3 e HTTP/2) e escreva uma configuração de servidor JSON que se vincule à porta 443. Tempo total de configuração, depois de feita uma vez: talvez dez minutos. Painéis web como o 3X-UI e o Hiddify-Manager encapsulam a mesma configuração em uma interface de navegador para operadores que preferem não editar JSON. Também existem appliances gerenciados. O AWS Marketplace lista uma imagem do servidor VPN Xray VLESS por US$ 0,063 por hora em uma instância t3.micro, com um período de teste gratuito de 5 dias.
Do lado do cliente, o ecossistema é fragmentado, mas confiável. v2rayN e Nekoray são os clientes dominantes para Windows. v2rayNG, NekoBox e Hiddify atendem o Android. O Hiddify também funciona em várias plataformas, como macOS e Linux. No iOS, onde a política da App Store da Apple dificulta as coisas, Streisand é a opção gratuita e Shadowrocket ou V2Box são as opções pagas. Todos eles utilizam o protocolo VLESS; a maioria suporta REALITY. A configuração geralmente é importada por meio de um esquema de URI `vless://`, uma única URL contendo UUID, endereço, porta, protocolo de transporte e parâmetros REALITY, ou escaneada como um código QR no painel do servidor.
Desempenho, riscos e quando o VLESS não é a ferramenta certa.
Desempenho em primeiro lugar. Testes da comunidade mostram que o VLESS oferece uma taxa de transferência de aproximadamente 15 a 25% superior à do VMess no mesmo transporte, principalmente porque o cabeçalho do VLESS é muito mais curto e não há criptografia interna. Com o XTLS Vision e a otimização de splice do Linux, uma implementação bem configurada do VLESS se aproxima da taxa de transferência nativa do TCP, limitada apenas pela largura de banda do VPS e pelo tempo de ida e volta até o servidor. O WireGuard permanece 2 a 3% mais rápido em redes sem censura, onde seu handshake não representa uma desvantagem.
Os riscos são reais. O protocolo VLESS é neutro e de código aberto, mas o status legal de seu uso para burlar a censura estatal varia bastante de acordo com a jurisdição. A lei federal russa sobre ferramentas de evasão criminaliza a promoção de configurações funcionais, e não o uso pessoal; a postura regulatória da China é mais rigorosa e arbitrária; o Irã processa operadores de grandes redes de proxies. Redes corporativas frequentemente proíbem todo o tráfego de proxy e VPN. Usuários nesses ambientes devem conhecer as regras sob as quais operam antes de configurar qualquer coisa. Aplicativos VPN gratuitos que incluem assinaturas VLESS pré-instaladas pertencem a uma categoria regulatória separada em algumas jurisdições e podem atrair escrutínio diferenciado.
Um último ponto, menos dramático. Se você não estiver em uma rede censurada, o VLESS é um exagero. Para privacidade comum em relação ao seu provedor de internet em uma conexão limpa, o WireGuard ou uma configuração moderna do OpenVPN são mais rápidos, simples e já são suportados por todos os provedores de VPN comerciais. O VLESS+REALITY é uma ferramenta para um problema específico, e recorrer a ela quando o problema é outro geralmente só traz mais complexidade.
