Vários mecanismos sob um único nome
1. Multiprocessamento OpenVPN. OpenVPN 2 usa uma única thread por processo: um núcleo de CPU pode saturar enquanto os outros ficam sem uso, criando um limite ligado ao processamento, não à largura de banda. Proton afirma distribuir esse processamento em vários processos paralelos. Esse aspecto se refere especificamente ao OpenVPN . WireGuard®, integrado ao núcleo Linux, já gerencia o paralelismo de outra forma. Isso se aplica mais às conexões em computadores, pois Proton removeu OpenVPN de seu aplicativo Android.
2. Segmentação do trajeto, “split path”. A velocidade útil TCP, descontadas as retransmissões, diminui com latência e perdas; por isso os testes usam servidores próximos. Uma VPN aumenta o caminho. Proton documenta sua divisão em segmentos menores: por exemplo, 600 ms tratados como duas vezes 300 ms, cada segmento oferecendo melhor velocidade útil. Isso não encurta fisicamente a internet: aproveita a sensibilidade de TCP ao comprimento dos caminhos. A implementação exata não é publicada.
3. Otimização do encaminhamento. Pequenos bloqueios podem reduzir muito o pacing TCP. Proton delega certas comunicações a processos auxiliares e modifica a pilha de rede Linux de seus servidores para encurtar o caminho dos pacotes de “tráfego conhecido”, em infraestrutura física não virtualizada. Provavelmente é o componente mais abrangente, mas essas afirmações vêm da Proton e não podem ser auditadas de fora.
Observação técnica. BBR é um mecanismo de controle de congestionamento TCP: afeta fluxos em TCP, como OpenVPN TCP, WireGuard encapsulado em TLS ou Stealth. Em túneis inteiramente UDP, como WireGuard UDP, OpenVPN UDP ou IKEv2, os possíveis ganhos vêm dos outros componentes, não de BBR.
Os “400%”: reais, mas condicionais
Proton anuncia um ganho de velocidade de até 400% nos casos mais favoráveis, esclarecendo que ocorre em conexões de longa distância e redes com perdas. Em uma conexão local, com servidor próximo em fibra e sem congestionamento, o efeito é bem menor; essa é a situação diária da maioria dos usuários. Quem realmente se beneficia usa servidores distantes, redes móveis ou conexões de baixa qualidade.
O que não pode ser verificado
Proton não publica a metodologia do número de 400%: não informa RTT alvo, perdas simuladas, protocolo de referência ou servidores. O ganho é plausível em condições ruins, e os mecanismos são reais e documentados, mas o número não é reproduzível de forma independente. As técnicas, como controle de congestionamento TCP, multiprocessamento OpenVPN e ajustes Linux, são conhecidas em outras partes do setor; o mérito da Proton é reuni-las e implantá-las em escala. A afirmação de desempenho continua sendo do provedor, não uma medição de terceiros.
Como verificar se há efeito
Um teste em um servidor próximo pode não mostrar nada: minimiza a latência e esconde os casos nos quais Proton anuncia maior impacto. Um teste correto compara condições idênticas, servidor, horário, dispositivo e destino realmente distante, com a opção ativada e depois desativada, usando uma transferência longa o suficiente para estabilizar a velocidade. Em uma conexão local estável, a ausência de diferença é normal, não uma falha. Se o gargalo é o Wi-Fi ou o roteador, o acelerador não muda nada, pois atua nos servidores da Proton.