XRay core explicado

As pessoas insistem em chamar XRay de protocolo VPN. Não é. XRay é uma plataforma de proxy. Pense nele como nginx, mas em vez de rotear requisições HTTP para servidores backend, roteia conexões de rede inteiras por túneis criptografados usando o protocolo que você quiser.

VLESS é um protocolo. Reality é uma camada de autenticação. WireGuard é um protocolo. XRay é o que roda VLESS e Reality no lado servidor. Acertar essa distinção importa se você quer entender por que o ecossistema de resistência à censura funciona do jeito que funciona.

De onde veio o XRay

A história começa com o V2Ray, projeto criado por volta de 2015 por alguém usando o pseudônimo "Victoria Raymond". V2Ray introduziu o protocolo VMess e uma arquitetura modular onde se podia trocar transportes (TCP, WebSocket, gRPC) independentemente do próprio protocolo de proxy. Era boa ideia e ganhou tração rapidamente, especialmente na China onde as pessoas precisavam de ferramentas que sobrevivessem à Great Firewall.

Em 2020, o criador original do V2Ray tinha ficado quieto. A comunidade V2Fly mantinha um fork chamado v2fly-core. Um desenvolvedor conhecido como RPRX contribuiu com XTLS, otimização de performance que permitia ao tráfego de proxy pular camadas redundantes de criptografia TLS. Foi contribuição técnica significativa.

Aí as coisas ficaram bagunçadas.

Em novembro de 2020, o código XTLS do RPRX foi removido do v2ray-core por uma disputa de licenciamento. Os detalhes são complicados e meio políticos, mas o resultado foi limpo: RPRX deu fork no v2fly-core (do commit 9a03cc5) e criou o xray-core. Quebra limpa.

XRay se moveu mais rápido depois do split. RPRX entregou XTLS Vision, depois Reality, depois XHTTP. O projeto atualmente está em 35.900+ estrelas no GitHub versus os ~22.000 do V2Ray. A comunidade votou com os commits. A maior parte do desenvolvimento ativo no espaço de proxy anti-censura agora acontece no xray-core ou em projetos construídos em cima.

O que o XRay faz de fato

XRay é um binário Go. Você alimenta com uma config JSON que define inbounds (listeners) e outbounds (destinos), e ele faz proxy do tráfego entre eles. Esse é o modelo todo.

O poder está no que você consegue combinar. XRay suporta múltiplos protocolos de proxy:

• VLESS, que é leve sem overhead de criptografia (depende da camada de transporte para isso)
• VMess, o protocolo original do V2Ray com criptografia AES-128-GCM (auth MD5 foi recentemente removida)
• Trojan, que imita tráfego HTTPS usando auth baseada em senha
• Shadowsocks-2022, a reescrita moderna com cifras AEAD-2022

Cada um desses pode rodar sobre qualquer transporte do XRay:

• TCP raw
• mKCP (baseado em UDP, como KCP mas modificado)
• WebSocket
• HTTP/2 (h2)
• gRPC
• QUIC
• XHTTP (transporte HTTP multiplexado próprio do XRay, adicionado em 2025)

Então você pode rodar VLESS sobre WebSocket atrás de uma CDN, ou Trojan sobre gRPC pela Cloudflare, ou VLESS sobre TCP raw com autenticação Reality. O protocolo e o transporte são independentes. Misture e combine baseado no que o seu ambiente de rede permite.

XRay também tem motor de roteamento. Você pode escrever regras que mandam tráfego de certos domínios por um outbound, bloqueiam ads por outro, e direcionam todo o resto pelo proxy. Está mais para uma stack de rede programável do que para um simples túnel.

XTLS e por que performance importa

Configurações de proxy padrão têm um problema. Quando você visita https://example.com por um proxy, a criptografia TLS acontece duas vezes: uma vez entre o seu navegador e example.com (TLS interno) e uma vez entre o seu cliente e o servidor proxy (TLS externo). Você está criptografando dado já criptografado. É CPU desperdiçada e latência adicionada.

XTLS Vision conserta isso. Quando o XRay detecta que a conexão interna já é TLS 1.3, ele para de criptografar o payload na camada do proxy depois que o handshake completa. O TLS interno fornece confidencialidade. A camada externa só precisa lidar com a negociação inicial.

XTLS splice vai além no Linux. Usa o syscall splice() do kernel para encaminhar dados TCP diretamente entre file descriptors sem copiar pela memória de userspace. O dado se move do socket de rede para o socket do túnel inteiramente em kernel space. O processo Go do XRay mal toca nele.

O resultado: throughput de proxy dentro de poucos por cento de uma conexão direta. Num servidor com link de 1 Gbps, XTLS splice consegue saturar. Proxies tradicionais de criptografia dupla atingem teto bem abaixo disso.

É por isso que VLESS com Reality tem performance muito melhor que ferramentas mais antigas de contorno. O protocolo é leve, o transporte é eficiente, e XTLS elimina o imposto de criptografia redundante.

O ecossistema em torno do XRay

XRay é o motor. Um ecossistema inteiro de ferramentas cresceu em torno.

Painéis de gerenciamento de servidor como 3X-UI dão a você uma interface web para configurar inbounds XRay, gerenciar contas de usuário e monitorar banda. São populares para servidores de proxy pessoais porque removem a necessidade de editar JSON na mão. Se você viu screenshots da configuração de proxy de alguém com gráficos bonitos e listas de usuário, provavelmente é 3X-UI ou um fork.

Clientes desktop como V2RayN (Windows) e V2RayA (Linux) envelopam o xray-core com GUI. Leem links de subscription, gerenciam listas de servidor, e tratam regras de roteamento. A maioria dos usuários em países censurados interage com o XRay via um desses clientes, não com o binário cru.

sing-box é o interessante. É uma plataforma de proxy mais nova escrita do zero pelo desenvolvedor SagerNet. Suporta todos os protocolos do XRay (VLESS, VMess, Trojan, Shadowsocks) mais Hysteria2, TUIC e outros. Mais importante, compila para biblioteca mobile via gomobile. É isso que torna VLESS Reality possível em celular. Você não consegue rodar xray-core razoavelmente no iOS ou Android, mas pode embutir o libbox do sing-box num app nativo.

O ecossistema se divide aproximadamente assim: xray-core domina em servidores, V2RayN/V2RayA em desktops, e sing-box em mobile. Todos falam os mesmos protocolos.

Como a Fexyn usa o XRay

Rodamos xray-core nos nossos servidores VPN. Cada servidor tem um inbound VLESS Reality na porta 443 (TCP com autenticação Reality) e um inbound XHTTP na porta 8444 (para ambientes onde TCP raw para a porta 443 é filtrado mas transportes baseados em HTTP passam).

No servidor, nosso Fexyn Agent gerencia o processo xray-core, lida com rotação de chave e provisiona UUIDs por usuário. Quando você conecta com VLESS selecionado, o agente gera suas credenciais e o cliente recebe uma config que aponta para o servidor certo com as chaves Reality certas.

O lado do cliente é onde as coisas ficam interessantes. No Windows, não usamos xray-core de jeito nenhum. Em vez disso, criamos um adaptador TUN Wintun e rodamos tun2socks para rotear todo o tráfego do sistema para um proxy SOCKS5 que o xray-core fornece. Na verdade, rodamos um xray-core enxuto em modo proxy SOCKS, e o tun2socks captura pacotes da interface TUN, reconstrói sessões TCP/UDP e encaminha pelo proxy SOCKS. O sistema operacional vê um adaptador de rede normal. Todo o tráfego passa por ele. Sem configuração de proxy em nível de app necessária.

No Android e iOS, usamos sing-box compilado como biblioteca nativa. Lida com o mesmo protocolo VLESS Reality mas roda dentro do framework de VPN do SO (VpnService no Android, NEPacketTunnelProvider no iOS). sing-box foi a escolha certa aqui porque xray-core não compila limpo para plataformas mobile, e o libbox do sing-box foi projetado exatamente para esse caso.

O resultado é o mesmo em todas as plataformas: seu tráfego se parece com alguém navegando no microsoft.com (ou seja qual SNI a config Reality alvo). Sistemas DPI veem uma conexão TLS 1.3 para um domínio legítimo. Sondagens ativas contra o nosso servidor são redirecionadas para o site real. A comparação de protocolo com WireGuard se resume exatamente a isso: WireGuard é mais rápido mas trivialmente fingerprintável, enquanto VLESS Reality sacrifica um pouco de throughput por invisibilidade quase total.

XRay comparado a outras ferramentas

O espaço anti-censura tem vários projetos. Onde o XRay se encaixa.

Shadowsocks foi o original. Simples, rápido, proxy criptografado de propósito único. A reescrita de 2022 (Shadowsocks-2022) corrigiu fraquezas criptográficas antigas, mas Shadowsocks tem problema de detecção: a GFW consegue identificar padrões de tráfego dele via análise estatística de comprimentos e timing de pacote. Ainda funciona em algumas regiões. É menos confiável que VLESS Reality em regiões muito censuradas.

V2Ray (v2fly-core) é o ancestral do XRay. Ainda mantido, ainda funciona. Mas falta XTLS Vision, Reality e XHTTP. Se você precisa dessas features, e em 2026 quase certamente precisa, precisa de xray-core.

Trojan-GFW foi inteligente quando lançou. Disfarça tráfego de proxy como HTTPS rodando um servidor web real ao lado do proxy. Reality levou essa ideia adiante eliminando a necessidade de possuir um certificado TLS real para o domínio alvo.

Hysteria 2 usa QUIC (baseado em UDP) com ofuscação. Ótimo throughput, mas protocolos baseados em QUIC estão recebendo mais atenção dos censores. Algumas redes agora bloqueiam ou fazem throttling em QUIC inteiramente. Ferramentas baseadas em TCP como VLESS Reality são mais difíceis de bloquear em massa porque você teria que bloquear o próprio HTTPS.

NaiveProxy usa a stack de rede do Chrome para gerar tráfego estatisticamente idêntico a um navegador Chrome real. Muito difícil de detectar, mas a configuração do lado cliente é mais complexa e não tem o mesmo ecossistema de painéis e clientes.

A vantagem do XRay não é que ele faz uma coisa melhor que toda alternativa. A vantagem é que é uma plataforma. Roda múltiplos protocolos, suporta múltiplos transportes, tem motor de roteamento maduro, e tem a maior comunidade ativa. Quando a GFW desenvolve novo método de detecção, o xray-core ganha contramedida em semanas. Esse é o benefício de 35.000+ estrelas e um mantenedor ativo que trata isso como corrida armamentista.

Para onde está indo

O desenvolvimento do XRay não desacelerou. Releases recentes tiraram código legado: autenticação MD5 do VMess sumiu, suporte a MTProto foi removido. A base de código está ficando mais enxuta.

Duas features futuras se destacam. XDRIVE é um transporte que disfarça tráfego de proxy como operações de cloud storage. XICMP usa pacotes ICMP como camada de transporte. Ambos experimentais, mas representam o mesmo padrão que define a evolução do XRay: ache um tipo de tráfego que censores permitem, e construa um transporte em torno dele.

O esquema de versão te diz algo sobre o ritmo. XRay usa formato vYY.M.DD. Versão v26.2.6 significa 6 de fevereiro de 2026. Releases são frequentes. O projeto se move rápido porque tem que. A Great Firewall não espera por ciclos trimestrais.

Se você está construindo qualquer coisa que precisa sobreviver numa rede censurada, XRay é o motor que você provavelmente quer rodando do lado servidor. Não é a única opção. Mas é a com mais momentum, suporte mais amplo a protocolo, e resposta mais rápida a novas técnicas de censura. É por isso que escolhemos para a Fexyn.