A pilha VLESS moderna em 2026

Em 2026, o VLESS continua sendo um protocolo de proxy leve e sem estado, mas “o VLESS não tem criptografia” já não é uma descrição completa. O Xray-core agora oferece o VLESS Encryption opcional. As implantações também podem combinar o VLESS com TLS, REALITY, XTLS Vision, XHTTP e XUDP de acordo com o seu modelo de ameaças. Essas camadas resolvem problemas diferentes e não devem ser tratadas como um único protocolo.

Política de fontes: este guia usa fontes primárias do Project X, do Xray-core, do sing-box e do AnyTLS. Os pull requests e as discussões no GitHub documentam o projeto e a implementação feitos pelos mantenedores; não são auditorias de segurança independentes. As menções ao SingLink são comparações de arquitetura, e não afirmações de que o SingLinkVPN implementa esses projetos.

1. A pilha VLESS moderna em resumo

• VLESS: uma camada leve de identidade, comando e destino.
• VLESS Encryption: uma camada nativa e opcional de proteção do payload no Xray-core atual.
• TLS 1.3 / REALITY: segurança do transporte externo, autenticação e aparência na rede.
• XTLS Vision: controle de fluxo e otimização do caminho dos dados, não uma cifra à parte.
• RAW / XHTTP / gRPC / WebSocket: transportes que carregam os dados do proxy.
• XUDP: uma opção de codificação de pacotes UDP no ecossistema Xray.
• XMUX e outros sistemas MUX: formas de compartilhar as conexões subjacentes.
• Padding / FinalMask / Browser Dialer: ferramentas para tamanho, temporização, comportamento do transporte externo ou rede do navegador.

Uma conexão pode, portanto, ser modelada assim: tráfego do aplicativo → identidade e destino VLESS → protocolo ou segurança externa → controle de fluxo Vision → um transporte como RAW ou XHTTP → TCP ou UDP. Nem todo módulo é necessário ou compatível em todos os projetos.

2. O que faz o protocolo base VLESS

A documentação do Project X define o VLESS como um protocolo de transporte leve e sem estado, que não depende da hora do sistema e usa um UUID ou um ID mapeado para autenticação. A implementação pública da codificação no Xray-core mostra versão, ID do usuário, complementos (addons), comando, porta de destino, endereço e os dados que vêm em seguida.

Na prática, a camada base responde: quem é o cliente, qual conexão está sendo pedida e para onde ela deve ir? O roteamento inteligente, a carga dos nós, os direitos do plano e a reconexão automática normalmente pertencem às camadas superiores de produto e de controle.

As configurações tradicionais costumam usar `encryption: "none"`. A orientação atual do Project X exige segurança no transporte externo, a menos que o par e o enlace sejam uma infraestrutura privada confiável ou que o VLESS Encryption esteja ativado.

3. O que muda com o VLESS Encryption

O VLESS Encryption é uma camada nativa e opcional de proteção incorporada ao Xray-core em 2025. O PR #5067 incorporado e a documentação de configuração atual descrevem o handshake `mlkem768x25519plus`, as aparências `native`, `xorpub` e `random`, o comportamento de sessão `1rtt` e `0rtt` e o padding variável.

Objetivos de projeto publicados

• Derivar as chaves de sessão por meio de uma combinação de ML-KEM-768 e X25519;
• proteger os payloads VLESS sem exigir TLS externo;
• usar tickets para retomadas 0-RTT posteriores e estado de curta duração para reduzir o risco de repetição (replay);
• usar padding variável e modos XOR opcionais para alterar aparências de tamanho fixo ou de chave pública.

Essas são afirmações de projeto e de implementação dos mantenedores. Não encontramos uma auditoria criptográfica independente que cubra todas as propriedades, por isso este guia não chama o projeto de “à prova de replay” nem de “absolutamente seguro contra computação quântica”.

O que ele não substitui automaticamente

O VLESS Encryption protege o payload do protocolo. Ele não cria automaticamente uma cadeia de certificados HTTPS comum, um handshake de site, um comportamento HTTP/2 ou HTTP/3 nem compatibilidade com CDN. Por isso, ele não equivale a TLS nem a REALITY.

4. TLS 1.3 e REALITY

O TLS oferece validação de certificados padronizada, troca de chaves, integridade e criptografia do transporte. Ele pode acompanhar RAW, XHTTP, gRPC ou WebSocket; a versão negociada, o ALPN e a verificação de certificados continuam dependendo da configuração e do suporte do par.

A documentação do REALITY no Project X descreve uma camada de segurança modificada no estilo TLS, com as configurações target, serverNames, chaves X25519 e shortId, além de dados opcionais de verificação ML-DSA-65. O REALITY pode acompanhar RAW, XHTTP e gRPC.

O REALITY não deve ser reduzido a “TLS sem certificado”. O comportamento dele combina autorização do cliente com a aparência de um handshake externo. Os resultados ainda dependem do target, da impressão digital do cliente, do transporte e da qualidade da implantação; ele não garante invisibilidade diante de qualquer classificador.

5. O XTLS Vision não é um protocolo de criptografia

A documentação do VLESS/Vision classifica o Vision como controle de fluxo. Em condições compatíveis, ele consegue reconhecer tráfego TLS interno e reduzir criptografia ou cópias extras. Em caminhos Linux e TCP compatíveis, o núcleo pode tentar usar `splice` para que o kernel transfira os dados diretamente.

A divisão correta é: TLS, REALITY ou VLESS Encryption fornecem a segurança; o Vision otimiza a forma como os dados protegidos atravessam a camada de proxy. Nem toda plataforma, transporte ou tipo de tráfego pode usar o splice.

6. Os três modos do XHTTP

A discussão de projeto do XHTTP feita pelos mantenedores descreve um sistema de transporte HTTP capaz de operar em ambientes HTTP/1.1, HTTP/2 e HTTP/3:

• packet-up: várias requisições POST de upload com uma resposta de download contínua; feito para ampla compatibilidade com intermediários.
• stream-up: um POST de upload em streaming e um GET de download em streaming separado.
• stream-one: uma única requisição de streaming bidirecional; o desempenho e a compatibilidade dependem dos intermediários.

O XHTTP também pode usar padding nos cabeçalhos, caminhos separados para upload e download e XMUX. Se ele funciona ou não por meio de uma CDN específica depende do modo, da versão do HTTP, do comportamento do proxy reverso e da configuração do provedor.

7. XMUX, multiplexação em geral e bloqueio head-of-line

O XMUX gerencia a concorrência do XHTTP, a quantidade de conexões subjacentes, a reutilização, o tempo de vida e o keepalive. O objetivo não é manter exatamente uma conexão para sempre; ele equilibra o custo dos handshakes, a concorrência e os padrões de conexões de longa duração.

A documentação de multiplexação do sing-box também lista smux, yamux e h2mux. A multiplexação pode reduzir handshakes, mas uma perda ou um bloqueio em uma conexão TCP subjacente pode afetar vários fluxos. O HTTP/3 evita o bloqueio head-of-line entre fluxos no nível do TCP, mas um fluxo QUIC individual ainda pode ficar esperando a recuperação de perdas.

8. O XUDP é uma opção de codificação UDP

A documentação do VLESS no sing-box lista `xudp` como uma opção de codificação de pacotes, ao lado de `packetaddr` e da desativação da codificação adicional. Isso sustenta apenas a conclusão limitada de que o XUDP transporta UDP nesse ecossistema; não se trata de uma especificação de pacotes completa e versionada.

Os detalhes de sessão, endereço, limites e migração devem ser verificados na versão exata do núcleo e no código. Este guia evita de propósito apresentar detalhes de enquadramento deduzidos como se fossem um padrão universal.

9. Padding, FinalMask, ECH e Browser Dialer

• Padding: altera características de tamanho ou de temporização; não é criptografia.
• FinalMask: a documentação de configuração dele o coloca em uma etapa de processamento do transporte externo, com configurações relacionadas a TCP, UDP e QUIC.
• ECH: a documentação de TLS do sing-box inclui a configuração do Encrypted ClientHello para proteger parte do ClientHello; o ECH não substitui a criptografia do túnel.
• Browser Dialer: a documentação do Project X permite que um navegador real estabeleça as conexões TLS e HTTP, ganhando um comportamento de navegador mais autêntico em troca de limitações de implantação e de desempenho.

10. O que o Fallback pode e não pode fazer

A documentação do Fallback no Project X mostra como SNI, caminhos ou tráfego de protocolo sem correspondência podem ser encaminhados para Nginx, Caddy ou um site comum, permitindo que um único ponto de entrada hospede o proxy e serviços comuns.

O Fallback pode evitar que toda tentativa de autenticação malsucedida receba o mesmo erro óbvio. Ele não dá imunidade contra sondagem ativa; a possibilidade de reconhecimento ainda depende do TLS, do transporte, das respostas, da temporização e da configuração do servidor.

11. O AnyTLS é uma comparação, não um componente do VLESS

O documento do protocolo AnyTLS descreve TCP → TLS → autenticação por `SHA-256(password)` → uma sessão → vários fluxos. Os quadros contêm Command, Stream ID, Data Length e Data, com os comandos SYN, PSH, FIN, settings, padding, heartbeat e SYNACK da versão 2.

O modelo de sessão, os vários fluxos, o padding dinâmico e as verificações de saúde fazem dele uma comparação útil. O AnyTLS continua sendo um protocolo separado; o VLESS não herda esses recursos automaticamente.

12. Combinações comuns e seus limites

• VLESS + REALITY + Vision + RAW: voltada ao desempenho direto e a uma aparência externa no estilo TLS; sem dependência de CDN.
• VLESS + TLS/REALITY + XHTTP: voltada ao transporte por HTTP, a proxies reversos e a uma compatibilidade condicional com CDN.
• VLESS Encryption + Vision: protege o payload do protocolo em cenários de relay ou de segurança externa não padronizada, sem aparência de HTTPS comum.
• VLESS + TLS + XHTTP + Browser Dialer: usa a pilha de rede de um navegador real, com custo operacional maior.
• AnyTLS + TLS: um projeto separado de sessões/fluxos e padding, não uma pilha VLESS.

Nenhuma configuração é sempre a melhor ao mesmo tempo em desempenho, compatibilidade, facilidade de manutenção, aparência e segurança. A escolha deve começar pelo modelo de ameaças, pelo caminho de rede, pelas restrições de CDN ou de proxy, pelas plataformas dos clientes e pelos requisitos de observabilidade.

13. O que isso significa para a pesquisa do SingLink

Os materiais públicos sobre VLESS e AnyTLS podem embasar pesquisas sobre identidade, troca de chaves, sessões, fluxos, UDP, padding, multiplexação, recuperação e negociação de versões. Este artigo não demonstra que o SingLink 2.0 seja baseado em VLESS, REALITY, XHTTP ou AnyTLS.

O SingLinkVPN deve continuar separando o comportamento publicado, as linhas de pesquisa e a implementação não divulgada. Veja o plano de código aberto do SingLinkVPN para conhecer o escopo publicado atualmente.

14. Perguntas frequentes (FAQ)

O VLESS criptografa o tráfego sozinho?

O VLESS tradicional, com `encryption: "none"`, não protege o payload do protocolo e exige uma infraestrutura privada confiável ou segurança externa. O Xray-core atual pode ativar o VLESS Encryption, então a resposta depende da implementação e da configuração.

O VLESS Encryption pode substituir o TLS ou o REALITY?

O VLESS Encryption não é um equivalente. Ele protege os payloads VLESS, mas não oferece automaticamente um certificado HTTPS padrão, um handshake ou a aparência de um site.

O XTLS Vision faz criptografia?

Não. O XTLS Vision oferece principalmente controle de fluxo e otimização do caminho dos dados.

Como escolher entre os três modos do XHTTP?

O packet-up prioriza a compatibilidade, o stream-up separa as direções de streaming e o stream-one usa um único fluxo bidirecional. Cada modo precisa ser testado no caminho real, com os intermediários existentes.

Qual é a diferença entre o XUDP e um proxy UDP genérico?

O XUDP é uma opção de codificação UDP do ecossistema Xray. O comportamento exato depende do núcleo e da versão e não deve ser deduzido apenas pelo nome.

O SingLink 2.0 é baseado em VLESS ou AnyTLS?

Não há evidências públicas suficientes para estabelecer essa relação com o VLESS ou o AnyTLS. Este artigo é uma comparação técnica, não uma divulgação de implementação.

15. Conclusão e data das fontes

O VLESS moderno é uma pilha combinável: o VLESS carrega identidade e destino, o VLESS Encryption acrescenta uma proteção opcional na camada do protocolo, o TLS ou o REALITY fornecem a segurança externa, o Vision otimiza o fluxo, o XHTTP e o XUDP transportam o tráfego, e a multiplexação ou o padding alteram ainda mais o comportamento da conexão.

Data da publicação original: 20 de maio de 2026. Fontes técnicas revisadas em: 28 de julho de 2026. Esses projetos continuam mudando; verifique a documentação, o changelog e a compatibilidade da versão exata antes de implantar.