Shadowsocks e Xray: quando a VPN é bloqueada

Trabalho frequentemente com VPNs. Não como teoria, mas na prática: ligar sites, dar acesso de clientes à rede da empresa, manter servidores acessíveis, configurar firewalls, renovar certificados, estabilizar túneis IPsec, depurar clientes SSL VPN e descobrir por que uma localização deixou de passar de repente.

Normalmente isso é trabalho de rede sólido e pouco excitante. E é assim que deve ser.

Mas há casos em que uma VPN tecnicamente correta deixa de ser suficiente. Com clientes de países onde a Internet é fortemente regulada, como China ou Rússia, vemos situações em que protocolos VPN clássicos são bloqueados, degradados ou reconhecidos de forma direcionada. Como trabalho em Dubai com uma clientela muito internacional, isso não é abstrato. A pergunta operacional é: como manter acesso legítimo à própria infraestrutura quando a ligação é filtrada no caminho?

É aí que surgem Shadowsocks, ShadowsocksR, V2Ray, Xray-core, VLESS, Trojan, REALITY ou XHTTP. No começo parece uma mistura confusa de projetos, forks e siglas. E, sinceramente, em parte é mesmo.

Por que o Shadowsocks surgiu

O Shadowsocks não veio do mundo clássico das VPNs corporativas. Ele não nasceu para ser uma solução site-to-site mais bonita nem porque IPsec era complicado demais. A origem foi mais direta: em 2012, um desenvolvedor com o pseudônimo clowwindy queria uma forma leve de sair de uma rede fortemente filtrada para a Internet aberta.

Isso explica o desenho. Shadowsocks deveria ser leve, rápido e prático: não um cliente VPN pesado, não um grande gateway, não uma suíte de acesso remoto com identidade e compliance. A ideia era um proxy SOCKS5 local que criptografa o tráfego e o envia para um servidor fora do bloqueio.

A necessidade não era “mais recursos de segurança empresarial”, mas “preciso de uma saída funcional de uma rede que filtra certos protocolos e destinos”. Por isso Shadowsocks continua interessante e também é facilmente mal interpretado. Ele é um componente de transporte enxuto, não uma VPN corporativa completa por si só.

Em 2015, a história ficou política: clowwindy escreveu no GitHub que a polícia o havia visitado e que ele precisava parar de trabalhar no projeto. O desenvolvimento continuou por forks e outras implementações. Ferramentas assim muitas vezes nascem de uma dor técnica concreta e depois entram numa corrida maior entre usuários, desenvolvedores e infraestruturas de filtragem.

Por que uma VPN se destaca

Quando se fala em VPN, muita gente pensa primeiro em criptografia. Está certo, mas é só parte da história.

Um censor, provedor ou grande firewall nacional não precisa necessariamente ler o conteúdo criptografado para interferir. Muitas vezes basta reconhecer o envelope. IPsec, SSL VPN, WireGuard e OpenVPN têm sinais típicos: portas, tamanhos de pacotes, padrões de handshake, comportamento de certificados, timing, uso de UDP, repetições, erros ou endereços IP de servidores conhecidos.

Pense no envelope, não na carta. O conteúdo está cifrado, mas o envelope tem tamanho, cor, selo e remetente recorrentes. Quem separa envelopes não precisa ler o texto para dizer: conheço este tipo, vai para inspeção especial.

Com tráfego de rede é parecido. Deep Packet Inspection e classificação de tráfego analisam padrões, não apenas portas. Em TLS, Client Hello fingerprints, SNI, cadeias de certificados ou ALPN podem chamar atenção. Em protocolos totalmente criptografados, a aparência aleatória dos primeiros pacotes pode ser o próprio sinal. Pesquisas sobre a Great Firewall mostram que tamanhos de pacotes, entropia e caracteres ASCII imprimíveis nos primeiros pacotes também importam.

O ponto desconfortável: “parece tudo aleatório” não significa automaticamente “discreto”. Às vezes isso é justamente o suspeito.

O que a pesquisa mostra

O ponto decisivo não é apenas que sistemas de censura “detectam VPN”. Isso já era conhecido em linhas gerais. O interessante é como muitas detecções começam de forma tecnicamente pouco espetacular.

Um bom ponto de entrada é o trabalho de medição do GFW Report apresentado em 2020 na ACM Internet Measurement Conference. GFW Report não é produto nem fornecedor, mas um projeto de pesquisa e medição sobre a Great Firewall.

O essencial: não foi um ataque mágico de descriptografia. A Great Firewall combinou observação passiva com probes ativos. Primeiro, conexões ficavam suspeitas por características como tamanho e entropia do primeiro pacote de dados. Depois vinham testes ativos: o censor conectava ao servidor suspeito, reproduzia pacotes antigos ou modificados e observava se o outro lado respondia como um servidor Shadowsocks.

Para administradores, isso separa duas camadas:

• O tráfego não pode parecer óbvio passivamente.
• O servidor não pode responder a testes ativos como proxy.

Em 2023, outro estudo GFW mostrou que tráfego totalmente criptografado pode ser bloqueado com heurísticas simples. Se o primeiro payload TCP não parece TLS, HTTP nem texto imprimível, mas um bloco aleatório, isso já pode ser um sinal. “Máxima aleatoriedade” nem sempre é o melhor alvo de camuflagem.

Em 2024, pesquisas sobre handshakes TLS encapsulados acrescentaram outro problema: mesmo com um túnel externo criptografado e bem disfarçado, um handshake TLS interno pode aparecer como padrão dentro de uma pilha de protocolos aninhada. Padding aleatório ajuda pouco; multiplexação de streams parece mais promissora, mas não resolve tudo se no fim só um fluxo de aplicação fica visível.

Timing e RTTs cross-layer reforçam isso. Um proxy desloca sessões de transporte e aplicação entre si. Essas diferenças podem ser mensuráveis, esteja o cliente perto ou longe do proxy. Não é algo que se corrige simplesmente com outro header.

A consequência é sóbria: não decide o rótulo do protocolo, mas o comportamento completo do setup.

Shadowsocks não é uma VPN clássica

Shadowsocks é frequentemente colocado no mesmo grupo das VPNs. No dia a dia isso é compreensível, mas tecnicamente impreciso.

Shadowsocks é um proxy criptografado, vagamente baseado em SOCKS5. Um cliente local oferece um proxy às aplicações, criptografa o tráfego e o envia a um servidor Shadowsocks remoto. O servidor descriptografa a requisição, conecta ao destino real e devolve a resposta pelo caminho criptografado.

É mais leve que uma VPN completa. Shadowsocks não coloca automaticamente todo o sistema operacional dentro de um túnel. Ele envia tráfego selecionado por outro caminho. Com clientes e componentes adicionais dá para construir algo quase parecido com VPN, mas a ideia base continua sendo proxy, não site-to-site VPN.

Para administradores, isso corrige expectativas:

• Shadowsocks não substitui um IPsec site-to-site bem feito.
• Shadowsocks não protege magicamente contra toda detecção.
• Shadowsocks é útil quando se precisa de um proxy criptografado simples e rápido numa rede restritiva.

Tecnicamente, Shadowsocks evoluiu. Configurações antigas com stream ciphers não devem ser referência. Deployments modernos ficam no mundo AEAD, e Shadowsocks 2022 adiciona chaves simétricas pré-compartilhadas, derivação baseada em BLAKE3, proteção contra replay e outras correções. Limite importante: pela especificação, não há Forward Secrecy. Se uma chave vazar, rotação correta é obrigatória.

Com shadowsocks-rust, há uma implementação moderna que também roda com Docker. No servidor pode rodar ssserver; no cliente, sslocal. Entre os dois é preciso mais que uma senha qualquer: segredos bem gerados, porta alcançável, cifras atuais e decisão clara sobre TCP, UDP ou ambos.

Por que Xray-core é outra categoria

Xray-core não é simplesmente “Shadowsocks mais novo”. É mais um framework para cenários de proxy e túnel.

Xray combina protocolos inbound e outbound como VLESS, VMess, Trojan, Shadowsocks, WireGuard, Hysteria, SOCKS e HTTP. Em cima entram transports como RAW, WebSocket, gRPC, XHTTP ou Hysteria, combinados com TLS, REALITY ou XTLS Vision. VMess ainda aparece em setups antigos, mas para novos deployments é mais legacy; em Xray atual, VLESS costuma estar no centro.

Shadowsocks é a chave de fenda rápida. Xray é a caixa de ferramentas. Ele permite setups simples e também cadeias em que um cliente local SOCKS ou TUN recebe o tráfego, envia via VLESS com REALITY para um servidor e dali sai para a Internet por um outbound freedom.

VLESS não é a camuflagem em si. É um protocolo proxy leve com autenticação por UUID. A confidencialidade e a camuflagem real vêm da camada de transporte e segurança abaixo, como TLS, REALITY ou XTLS Vision.

REALITY é mais interessante porque não faz apenas “mais TLS”. Para fora, o servidor empresta o handshake TLS de um site HTTPS real de terceiros. Para o observador, parece um certificado real de um site real, não um certificado proxy caseiro. Só um cliente autorizado reconhece, pelo material de chave configurado, que fala com seu próprio servidor Xray.

Isso ataca principalmente fingerprint TLS do lado do servidor e active probing. uTLS ajuda no cliente imitando Client Hellos de navegadores. Mesmo assim, Xray não é invisível: timing, tamanhos de pacotes, ALPN, comportamento do servidor e padrões TLS aninhados ainda podem sinalizar. XTLS Vision e XHTTP são blocos interessantes, não garantias. Um pouco de padding ajuda pouco se o padrão básico continuar visível.

Abordagens UDP como Hysteria ou QUIC podem ser rápidas, mas em redes restritivas muitas vezes são limitadas, bloqueadas ou tratadas pior que TCP/443 de saída. Por isso Xray exige disciplina: fixar versões, testar mudanças, ler release notes e não copiar recomendações de fórum sem entender.

A confusão de forks e nomes

Quem começa a pesquisar cai rapidamente em posts antigos, forks no GitHub e clientes meio mantidos. Isso vem da história dessas ferramentas.

Shadowsocks é protocolo e ecossistema com várias implementações. shadowsocks-rust é hoje uma escolha natural para um servidor moderno. Implementações como shadowsocks-libev continuam conhecidas, mas conforme o estado do projeto podem ser vistas como legacy ou focadas em bugfix.

ShadowsocksR foi um fork com ideias extras de obfuscation. SSR aparece em muitos guias antigos. Eu teria cuidado hoje: não porque toda instalação antiga seja ruim, mas porque é preciso verificar cliente, servidor, criptografia, updates e comunidade.

Xray-core veio do ambiente V2Ray, mas evoluiu de forma independente. Aplicar tutoriais antigos de V2Ray ao Xray sem revisão é arriscado. Conceitos podem se parecer, mas configurações e recomendações mudaram.

V2Fly segue relevante como projeto comunitário mais conservador. Xray-core avança mais rápido com REALITY, XTLS Vision ou XHTTP. Também existe sing-box como plataforma universal moderna. Aqui mantenho Xray em foco, mas em laboratório eu olharia sing-box também.

Meu conselho prático:

• Para setups simples novos: Shadowsocks com implementação atual.
• Para redes difíceis: Xray-core com design limpo e atual.
• Para guias antigos de SSR ou V2Ray: verificar primeiro projeto e segurança.
• Para clientes em produção: não copiar setup sem entender.

O que é necessário nos dois lados

Um setup mínimo sempre tem dois lados.

No lado remoto, é preciso um servidor fora da rede restritiva: VPS, servidor próprio em datacenter ou infraestrutura controlada numa região alcançável pelo cliente. Ele precisa estar endurecido, atualizado, monitorado e documentado. Uma instância barata esquecida vira risco.

No lado cliente, é preciso o programa certo: para Shadowsocks, muitas vezes um cliente SOCKS local ou app de proxy do sistema; para Xray, um cliente Xray, modo TUN, roteador ou app que importe perfis.

Também são necessários:

• objetivo claro
• autenticação limpa
• versões atuais
• DNS controlado
• logs sem dados desnecessários de clientes
• monitoramento de disponibilidade
• plano de rotação de servidores, portas e segredos
• revisão legal e contratual

O último ponto não é decoração. Em alguns países, usar essas ferramentas pode ser juridicamente problemático. Em empresas, também importa se você expõe sistemas próprios, opera redes de clientes ou dá acesso geral à Internet.

DNS costuma ser subestimado. Se navegador ou sistema ainda resolve domínios pelo provedor local, o túnel ajuda só pela metade. O conteúdo pode passar pelo proxy, mas a consulta DNS revela o destino. É preciso testar caminho DNS, IPv6 e comportamento quando o túnel cai.

Logging também é sensível. Para troubleshooting, você quer saber se o túnel vive; para privacidade, quer guardar o mínimo. Um bom setup coleta estados técnicos, latência, erros e volume, não listas completas de conexões. Debug logs, TLS keylogs e access logs sem máscara não pertencem a produção permanente.

Monitoramento deve testar um caminho real pelo túnel, DNS correto, bloqueios por região e diferenças vistas a partir do país afetado, não apenas se o container está rodando.

Como eu classificaria operacionalmente

Para mim, Shadowsocks ou Xray não substituem arquitetura de firewall, Zero Trust, MFA ou segmentação. São ferramentas de transporte para casos especiais.

Uma abordagem empresarial sensata:

1. Testar primeiro SSL VPN, IPsec ou WireGuard.
2. Se bloquear, medir DNS, porta, protocolo, IP do servidor, fingerprint TLS e throttling UDP.
3. Testar então Shadowsocks ou Xray-core.
4. Usar o túnel só para destinos necessários.
5. Filtrar no servidor quais serviços internos ficam acessíveis.
6. Monitorar para não descobrir o bloqueio pelo cliente.
7. Ter fallback: outro exit, provedor, região ou protocolo.
8. Separar segredos e perfis por site ou usuário.
9. Criar logs e métricas sem rastros desnecessários.

Quando uma sede perde acesso, “pelo menos voltou” é compreensível. Mas depois é preciso arrumar e documentar. Caso contrário, um workaround temporário vira um caminho produtivo invisível.

Por que os bloqueios acompanham

A outra parte adapta continuamente a detecção.

Se muitos usam o mesmo Docker Compose, a mesma porta, o mesmo fingerprint TLS, a mesma estratégia de domínio e o mesmo provedor VPS, o padrão aparece. Não se bloqueia “Xray” ou “Shadowsocks” em abstrato, mas um padrão concreto: handshakes, tamanhos de pacotes, ranges de IP, clientes típicos, fallbacks ruins ou erros chamativos.

Camuflagem não é só recurso da ferramenta. É operação: mesmas ferramentas, domínios diferentes, provedores diferentes, perfis diferentes e padrões de tráfego diferentes podem parecer muito diferentes.

Por isso sou cauteloso com promessas de projetos. Se uma ferramenta diz que é indetectável, isso é uma afirmação do projeto. Se um paper mostra que uma característica foi detectada numa rede real, isso tem outro peso. Na prática, precisamos da velocidade dos projetos e da sobriedade da pesquisa.

Minha avaliação

Shadowsocks faz sentido quando se precisa de um proxy criptografado leve, rápido e relativamente simples: primeiros testes, acessos temporários e ambientes sem detecção extremamente agressiva.

Xray-core faz sentido quando a rede é mais difícil, quando são necessários vários transports ou quando se quer usar VLESS, REALITY, WebSocket, gRPC ou XHTTP. Mas exige mais entendimento e perdoa menos erros.

Para clientes, eu não venderia nenhum dos dois como “substituto de VPN”. Eu chamaria de caminho de transporte alternativo para acessos legítimos. É menos espetacular, mas mais honesto.

A diferença mais importante não é Shadowsocks contra Xray, mas entender o problema. Para acesso remoto normal, uso VPN normal. Para detecção estatal ou do provedor, falo de reconhecibilidade, fingerprints e estratégia operacional. Se eu não consigo explicar isso, não deveria operar em produção para clientes.

Conclusão

Shadowsocks e Xray-core são ferramentas de um mundo em que conexões de rede não apenas “funcionam” ou “não funcionam”. Elas podem ser classificadas, limitadas, testadas ativamente ou bloqueadas. Quem atende clientes internacionais acaba encontrando essa realidade.

O tema me interessa porque torna redes muito concretas: criptografia, padrões, fingerprints, roteamento, DNS, operação, lei, responsabilidade e o fato de que um túnel funcional não é automaticamente um bom desenho.

Meu próximo passo é claro: quero testar Shadowsocks e Xray-core num pequeno laboratório. Não para contornar censura às cegas, mas para entender melhor por que VPNs clássicas às vezes se destacam e quais alternativas podem ser operadas com seriedade técnica.

Até à próxima,
Joe

FAQ