Como Detectamos uma Falha Silenciosa de TLS 1.3 em Milhares de Dispositivos Android

Se você trabalha com proxies móveis, conhece bem essa dor: algo quebra e ninguém consegue te dizer o porquê. O dispositivo está em outro país. O usuário diz "não está funcionando." Sem logs, sem mensagens de erro, sem stack traces. Apenas silêncio.

Foi exatamente isso que aconteceu conosco — só que detectamos antes que a maioria dos usuários percebesse. Aqui está o motivo.

Precisa de proxies móveis?
Crie um proxy agora mesmo!
Inicie o teste gratuito de 48 horas

O iProxy executa diagnósticos de rede em cada dispositivo. Continuamente.

Nosso aplicativo Android não apenas encaminha tráfego. Ele executa um conjunto completo de verificações de saúde da rede — checando conectividade, latência, resolução DNS, acessibilidade via HTTP e HTTPS, e muito mais. Essas verificações rodam continuamente contra servidores controlados, então conhecemos o estado da rede de cada dispositivo a qualquer momento.

Foi assim que identificamos o problema: uma pequena porcentagem de dispositivos começou a falhar nas verificações HTTPS enquanto o HTTP funcionava perfeitamente. A falha ocorria na etapa do handshake TLS. Sem erro, sem mensagem de timeout — apenas uma conexão que silenciosamente não ia a lugar nenhum.

Sem diagnósticos integrados, isso teria sido invisível. Os usuários veriam falhas intermitentes no proxy sem nenhum padrão e nenhuma explicação. Estaríamos no escuro.

O que estava acontecendo de fato

As falhas estavam vinculadas especificamente ao TLS 1.3. Conexões TLS 1.2 pelo mesmo dispositivo, para o mesmo servidor, ao mesmo tempo — funcionavam perfeitamente. TLS 1.3 não.

A causa raiz acabou sendo uma combinação de dois fatores:

Clientes TLS modernos enviam mensagens de handshake muito maiores do que antes. Go 1.23+ e Chrome 124+ agora incluem compartilhamentos de chave de criptografia pós-quântica (ML-KEM) por padrão. Isso faz com que a primeira mensagem de uma conexão TLS — o ClientHello — seja grande o suficiente para exceder um único pacote TCP. A resposta do servidor no TLS 1.3 também é enviada de uma vez (certificado e tudo mais), podendo chegar a 4–6 KB para sites como Google ou Cloudflare.

Dispositivos Android sob pressão de memória têm dificuldade em armazenar essas mensagens maiores em buffer. Nosso aplicativo funciona como um proxy TCP — ele lê bytes de um socket e os escreve em outro. Quando o dispositivo está com pouca RAM, esse buffer pode falhar silenciosamente. Os dados do handshake ou não são encaminhados, ou a resposta não retorna. Sem erro. Sem travamento. Simplesmente nada.

O TLS 1.2 evita isso completamente: seu handshake é dividido em múltiplas trocas menores, e nenhuma mensagem individual é grande o suficiente para causar problemas.

Por que isso importa para a qualidade do proxy

Esse é o tipo de problema que separa um serviço de proxy confiável de um frustrante.

Sem diagnósticos ativos, um provedor veria usuários reclamando de falhas HTTPS aleatórias. O suporte diria "reinicie o aplicativo" ou "verifique sua conexão com a internet." O problema apareceria e desapareceria. Ninguém o associaria a versões do TLS ou à memória do dispositivo.

No iProxy, detectamos o padrão automaticamente. Nosso sistema de diagnóstico identificou que o TLS 1.3 estava falhando enquanto o TLS 1.2 funcionava — em dispositivos específicos, em momentos específicos. Isso nos disse exatamente onde procurar.

O que fizemos a respeito

Assim que entendemos o problema, lançamos duas correções:

Fallback inteligente de TLS. Quando nossos diagnósticos detectam o padrão de falha do TLS 1.3 em um dispositivo, ajustamos automaticamente. O tráfego continua fluindo sem que o usuário precise fazer nada.

Recuperação automática. Se um dispositivo entra em estado degradado, podemos acionar uma reinicialização remota do aplicativo para liberar a pressão de memória e restaurar a funcionalidade completa. Os diagnósticos detectam quando isso é necessário e tratam disso sem intervenção do usuário.

Também rastreamos e corrigimos vazamentos de memória no nosso aplicativo que contribuíam para o problema. A melhora foi imediatamente visível nos nossos painéis de monitoramento — a taxa de falhas do TLS 1.3 caiu significativamente em toda a frota.

É isso que "infraestrutura de proxy gerenciada" realmente significa

Qualquer um pode escrever um aplicativo que encaminha pacotes TCP. A parte difícil é saber quando ele para de funcionar, por que parou de funcionar, e corrigi-lo antes que o usuário abra um chamado de suporte.

O iProxy monitora a saúde da rede em cada dispositivo em tempo real. Não esperamos que os usuários reportem problemas — nós os detectamos, diagnosticamos e, em muitos casos, os corrigimos automaticamente. Essa é a diferença entre um aplicativo de proxy e uma infraestrutura de proxy.

Nossa equipe de engenharia publicou um mergulho técnico completo nessa investigação. Se você tiver interesse nos detalhes — as capturas de pacotes, as diferenças entre Go e curl, o ângulo da criptografia pós-quântica — você pode ler aqui: Quando o TLS 1.3 morre silenciosamente dentro do seu proxy Android.

O iProxy.online fornece infraestrutura de proxy móvel em mais de 100 países e 600+ operadoras. Nosso aplicativo Android transforma celulares em servidores proxy confiáveis com diagnósticos de rede integrados, monitoramento automático de saúde e gerenciamento remoto.