Mbps não dizem nada sobre a qualidade de um proxy móvel

A cena é dolorosamente familiar. Você pegou um proxy mais rápido, pagou por um canal de 50 Mbps, configurou o navegador antidetect. E mesmo assim os perfis caem do nada, o parser pega uma enxurrada de timeouts e os captchas aparecem onde antes não existiam. Você vai reclamar com o vendedor. Como resposta, ele manda um print do speedtest, tudo verde e bonito: banda no lugar, velocidade ótima. Formalmente, ele está certo. Na prática, sua tarefa não funciona.

Então, qual é o problema? O problema é que você está medindo a coisa errada. Megabits por segundo descrevem apenas uma característica do canal: a largura de banda. Mas a qualidade de um proxy móvel é definida por outras métricas. E nenhum speedtest de navegador mostra isso. Neste artigo, vamos analisar o que realmente quebra o funcionamento e aprender a medir do jeito certo — com script, não no olho.

O que realmente quebra o funcionamento

Quando falamos em qualidade de conexão, quase sempre reduzimos tudo a um número: velocidade. É prático, mas totalmente errado. Por trás do funcionamento estável de um proxy existem quatro métricas independentes, e cada uma é responsável por uma classe de problemas. Largura de banda é apenas uma delas, e nem de longe a mais importante para a maioria das tarefas.

Vamos analisar cada uma em ordem. E veremos imediatamente a que cada uma é sensível.

Quatro métricas em vez de uma

RTT é o tempo que um pacote leva para chegar ao servidor e voltar. É o RTT que determina o quão responsiva a interface parece. RTT alto — e cada ação no navegador demora, cada captcha carrega com atraso, e os timeouts do parser disparam antes da resposta chegar. A banda pode ser enorme. De nada adianta.

Jitter é a variação dos valores de RTT ao longo do tempo. Se a latência salta de 40 para 300 milissegundos, o comportamento da conexão se torna imprevisível. Sessões caem em operações longas, e sistemas de análise de comportamento notam uma irregularidade artificial nos padrões de requisição. Um canal estável de 15 Mbps com jitter baixo se comporta muito melhor do que um instável de 50.

Perda de pacotes é o percentual de dados que não chegam e precisam ser reenviados. Mesmo 2-3% de perda transformam um download longo em loteria. O arquivo baixa pela metade, a resposta chega corrompida, e uma requisição POST longa se interrompe no meio. Para scraping de grandes volumes, isso é crítico.

Rota é o caminho que o tráfego percorre. Nós desnecessários, loops por data centers distantes, cair em um sistema autônomo errado — tudo isso adiciona latência e estraga a geolocalização. Um proxy móvel que fisicamente não está onde diz estar se denuncia justamente pela rota.

A ideia central desta seção é simples. Largura de banda só importa para upload de mídia — quando você baixa arquivos grandes ou faz streaming de vídeo. Todo o resto — trabalho com antidetect, scraping, automação de ações — é sobre estabilidade, não velocidade. E a estabilidade vive naquelas três métricas que o speedtest ignora.

Por que o speedtest de navegador é inútil

Agora, sobre a principal ferramenta em que todos confiam. O speedtest de navegador te dá um número em um único momento. Ele abre uma conexão, baixa um bloco de dados de teste, mede a velocidade de pico e mostra uma seta bonita. Uma medição — um segundo de um dia inteiro.

Agora lembre-se da natureza da rede móvel. Ela é instável por definição. Aqui está o que acontece com ela ao longo do dia:

• Sobrecarga da célula. Quando muitos assinantes se conectam à estação base ao mesmo tempo, os recursos são divididos entre todos. Sua latência real aumenta, embora a velocidade de pico no momento da medição possa permanecer alta.
• Troca de faixa de frequência. A operadora transfere o dispositivo entre faixas de frequência conforme a carga e o nível de sinal. Cada troca é uma microinterrupção, um pico de jitter e às vezes perda de pacotes.
• Shaping programado. Em horários de pico, as operadoras aplicam gerenciamento de tráfego. A banda formalmente continua lá, mas as prioridades mudam e a latência oscila.

Entendeu a pegadinha? Um speedtest rodado às 14h vai mostrar um cenário perfeito. Mas seu parser vai cair às 21h, quando a célula está congestionada com tráfego noturno. O vendedor mostra o print diurno e tecnicamente está certo. Uma medição isolada descreve um segundo — e não diz nada sobre como o canal se comporta nos outros 86.399 segundos do dia.

A conclusão é óbvia. Para entender a qualidade real de um proxy móvel, é preciso medir continuamente e medir as métricas certas. Um clique no navegador não faz isso.

Método: medir com script, não no olho

Já que a medição manual não funciona, vamos automatizar o processo. A ideia é simples: um pequeno script roda em agendamento, coleta todas as métricas necessárias e salva em um arquivo. Em um dia, você tem o panorama completo do comportamento do canal — não um instantâneo aleatório.

Para isso, é conveniente usar o SpeedMeter — um utilitário de linha de comando que mede não apenas a banda, mas também RTT, jitter e perda de pacotes, devolvendo o resultado em formato legível por máquina. É exatamente uma ferramenta, não um assunto de conversa: ele apenas faz o trabalho e fica quieto.

Passo 1. Instalação da CLI

O utilitário é distribuído como um único binário sem dependências. Baixe, torne-o executável, coloque no PATH. A verificação de funcionamento é um único comando.

curl -sL https://speedmeter.dev/cli -o speedmeter && chmod +x speedmeter && sudo mv speedmeter /usr/local/bin/ && speedmeter --version

Nada de bibliotecas, interpretadores ou ambientes virtuais. O binário pesa cerca de 400 kilobytes e roda em qualquer host Linux, VPS ou até roteador com memória suficiente.

Passo 2. Execução com saída em JSON e acumulação em arquivo

A flag --json transforma a saída em uma estrutura fácil de analisar. Adicionamos o resultado a um arquivo com carimbo de tempo — este é o nosso acumulador de métricas.

speedmeter --proxy socks5://user:pass@host:port --json >> /var/log/proxy_metrics.jsonl

Cada execução adiciona uma linha de JSON. O formato JSONL (um registro por linha) é ideal para análise posterior — qualquer ferramenta consegue ler.

Passo 3. Cron a cada 15 minutos

Agendamos a tarefa. A cada 15 minutos — são 96 medições por dia, densidade suficiente para ver todas as quedas e picos.

*/15 * * * * /usr/local/bin/speedmeter --proxy socks5://user:pass@host:port --json >> /var/log/proxy_metrics.jsonl 2>&1

E para analisar rapidamente o acumulado, use o jq. Veja como calcular em um segundo o RTT médio e o jitter máximo do dia:

jq -s 'map(.rtt_ms) | add/length' /var/log/proxy_metrics.jsonljq -s 'map(.jitter_ms) | max' /var/log/proxy_metrics.jsonl

Pronto. Três blocos curtos de código — e você tem um monitoramento funcional da qualidade do canal. Agora vamos falar sobre o que esse monitoramento vai mostrar.

Experimento: 24 horas em um único SIM

Para provar de forma clara a diferença entre banda e qualidade, fizemos um experimento simples. As condições eram extremamente limpas e reproduzíveis:

• Um único chip SIM, uma única operadora móvel.
• Medição a cada 15 minutos via cron.
• 96 pontos de dados em um dia inteiro.
• Registro simultâneo de banda, RTT, jitter e perda de pacotes.

A hipótese era a seguinte: esperávamos ver uma queda de qualidade à noite, entre 19h e 23h, quando a rede está carregada com tráfego doméstico. E a queda seria no jitter, não na banda.

O que o gráfico mostrou

Abaixo, o panorama médio de RTT e jitter por hora do dia. Observe o formato das curvas.

Jitter (ms) por hora do dia:00 |#### 12 ms03 |###9 ms06 |#### 13 ms09 |###### 22 ms12 |####### 26 ms15 |######## 31 ms18 |########### 48 ms19 |################ 71 ms20 |################### 95 ms21 |#################### 110 ms22 |################ 74 ms23 |########### 49 msRTT (ms) por hora do dia:00 |#### 45 ms09 |###### 68 ms15 |######## 92 ms20 |############ 140 ms21 |############### 175 ms23 |####### 85 ms

O panorama fala por si. Durante a noite e de madrugada, o canal se comportava perfeitamente: RTT em torno de 45 milissegundos, jitter abaixo de 15. Mas a partir das 19h começava um crescimento acentuado. Às 21h, o jitter aumentava quase dez vezes em relação ao mínimo noturno, e o RTT quase triplicava.

E aqui está o mais interessante. A largura de banda nessa mesma janela noturna permanecia bastante razoável — a queda era pequena e completamente imperceptível. Um speedtest às 21h mostraria quase os mesmos megabits que ao meio-dia. Você jamais imaginaria que o canal estava se desintegrando naquele momento.

A conclusão do experimento é inequívoca. É na janela noturna que as tarefas quebram: sessões de antidetect caem, timeouts do parser disparam, as impressões digitais de comportamento ficam irregulares. E é exatamente isso que o speedtest de navegador não vê, porque ele olha apenas para a banda e apenas em um momento. E suas tarefas, como se não bastasse, geralmente rodam justamente à noite.

Valor prático da descoberta

Assim que você ver esse tipo de gráfico no seu proxy, terá um conhecimento concreto. Por exemplo:

• Scraping pesado é melhor rodar à noite, quando o jitter é mínimo.
• O aquecimento de múltiplas contas faz sentido migrar para o período da manhã.
• Se a queda noturna for profunda demais, vale trocar de provedor ou de nó — e agora você tem números para uma conversa fundamentada.

Limites: quais valores são aceitáveis para sua tarefa

Gráfico é bom, mas precisamos de uma régua. Abaixo, uma tabela de limites para você verificar seu provedor de forma autônoma. Basta comparar os valores médios do seu log de métricas com estes números e entender na hora se o canal serve para a tarefa específica.

Vamos explicar a lógica desses limites para você entender de onde vêm os números.

Scraping e coleta de dados

O mais importante aqui é baixa perda de pacotes e RTT previsível. Requisições longas e varreduras página por página são sensíveis a interrupções. A banda quase não importa — você baixa texto e HTML, não terabytes. Um proxy de 5 Mbps dá conta se o jitter se mantiver dentro do normal.

Múltiplas contas

A tarefa mais exigente em relação ao jitter. Cada conta precisa se comportar como um usuário real em uma conexão móvel estável. Jitter irregular denuncia a automação e estraga o perfil comportamental. Por isso, os limites aqui são os mais rígidos em estabilidade e os mais flexíveis em banda.

Automação de SMM

Publicações, comentários, reações — tudo são ações interativas curtas. RTT baixo garante responsividade, e jitter baixo garante naturalidade. A banda precisa ser moderada, principalmente para upload de imagens nos posts.

Trabalho com vídeo

A única tarefa da lista em que a banda é realmente crítica. Aqui, elevamos os requisitos de largura de banda para 25 Mbps ou mais. Por outro lado, as tolerâncias de jitter e perda são um pouco mais flexíveis — o buffer suaviza pequenas irregularidades.

Cinco maneiras práticas de usar o SpeedMeter

Agora que o método está claro, vamos mostrar cenários específicos em que a medição regular de métricas economiza tempo, dinheiro e nervos. Cada maneira é uma receita pronta.

Maneira 1. Avaliação do proxy antes da compra

Para quem: para todos que compram ou alugam proxies móveis. Para quê: para não pagar por um speedtest bonito, mas obter qualidade real.

O algoritmo é simples. Peça ao vendedor um acesso de teste por um dia. Configure o cron com medição a cada 15 minutos. Depois de um dia, calcule o jitter médio e máximo, o RTT médio e o percentual de perda. Compare com a tabela de limites acima.

1. Obtenha as credenciais de teste.
2. Execute a tarefa do cron por 24 horas.
3. Analise o log com jq: RTT médio, pico de jitter, perdas.
4. Compare com os limites da sua tarefa.
5. Tome a decisão com base em números, não promessas.

Resultado da prática: em um teste, o vendedor mostrava 48 Mbps. A medição de 24 horas revelou jitter noturno de até 130 ms e perdas de 4%. Para múltiplas contas, o canal era totalmente inadequado, embora a banda parecesse excelente. Recusar a compra economizou um mês de pagamento e uma pilha de perfis caídos.

Maneira 2. Planejamento de janelas para tarefas pesadas

Para quem: para quem roda scraping de grande volume ou aquecimento em massa de contas. Para quê: para iniciar a carga quando o canal está em sua melhor forma.

Colete o perfil diário de qualidade usando o método do experimento. Encontre as janelas verdes no gráfico — geralmente à noite e de madrugada. Configure o agendador para que os jobs mais pesados comecem exatamente nesses horários.

• Rodar o parser à noite em vez de à noite reduz drasticamente a proporção de timeouts.
• Aquecer múltiplas contas pela manhã gera impressões digitais comportamentais mais limpas.
• Exportações que consomem muitos recursos vão para o horário mais silencioso do dia.

Dica: se você tem vários proxies de operadoras diferentes, colete o perfil de cada um. A queda noturna de operadoras diferentes ocorre em horários distintos — você pode alternar os canais e manter a estabilidade 24 horas por dia.

Maneira 3. Monitoramento contínuo e alertas

Para quem: para equipes em que os proxies fazem parte da infraestrutura de produção. Para quê: para saber da degradação do canal antes que as tarefas caiam.

O cron já escreve as métricas em JSONL. Adicione um guarda simples que lê o registro mais recente e compara com o limite. Se o jitter ou a perda ultrapassarem o limite, enviamos uma notificação no mensageiro.

tail -n1 /var/log/proxy_metrics.jsonl | jq 'if .jitter_ms > 60 or .loss_pct > 2 then "ALERT" else "OK" end'

Coloque essa verificação também no cron — e você terá um alerta antecipado. Quando o canal começa a degradar, você fica sabendo em minutos, não depois de as tarefas caírem.

Dica de especialista: guarde os logs históricos por pelo menos um mês. Eles são inestimáveis em uma discussão com o provedor — você tem a dinâmica objetiva em mãos, não emoções.

Maneira 4. Comparação justa entre provedores

Para quem: para quem está escolhendo entre várias ofertas. Para quê: para comparar com a mesma metodologia, não com prints alheios.

Pegue acesso de teste de três ou quatro candidatos. Execute a mesma medição em cada um nos mesmos dias. Consolide os resultados em uma tabela e compare todas as quatro métricas de uma vez.

1. Metodologia única — mesmo intervalo, mesmas métricas.
2. Mesma janela de tempo — elimina a influência do horário.
3. Comparação por jitter e perdas, não apenas banda.

Resultado: muitas vezes o canal mais caro, com maior banda, perde para um mais barato em estabilidade. Uma comparação justa economiza orçamento e aumenta a taxa de sucesso das tarefas.

Maneira 5. Diagnóstico de conexão problemática

Para quem: para todos que têm algo caindo e não sabem por quê. Para quê: para entender em minutos se o problema é o canal ou não.

Quando uma tarefa começa a falhar, a primeira pergunta é: o problema é o proxy? Execute uma medição única agora e observe o perfil. RTT alto? Procure o problema na rota. Jitter oscilando? A célula está sobrecarregada. Perdas crescentes? Talvez sinal fraco ou shaping.

• Aumento repentino de RTT com jitter normal — provavelmente a rota mudou.
• RTT normal, mas jitter enorme — sobrecarga da célula ou troca de faixa.
• Perdas altas de pacotes — sinal fraco, interferência ou gerenciamento de tráfego.

Esse diagnóstico rápido economiza horas. Em vez de adivinhar, você tem uma direção de busca em um único comando.

Comparação com alternativas

Pergunta lógica: por que uma ferramenta separada se existem ferramentas habituais? Vamos comparar honestamente as abordagens.

A diferença fundamental é que o SpeedMeter mede todas as quatro métricas de uma vez e devolve o resultado em formato legível por máquina. Isso o torna adequado para automação desde o início. Não é preciso combinar três ferramentas diferentes e juntar as saídas com scripts — um único comando cobre tudo.

Ele também não tenta ser um canivete suíço. Nada de dashboards, bancos de dados ou agentes. Um binário pequeno sem dependências que você coloca onde quiser e executa como quiser. É exatamente essa concisão que o torna uma ferramenta conveniente, não mais uma plataforma pesada.

Erros típicos ao avaliar a qualidade do proxy

Reunimos as armadilhas mais comuns. Confira você mesmo.

• Foco apenas na banda. O erro mais comum. Os megabits encantam, mas só importam para mídia.
• Medição isolada. Testar em um horário conveniente mente. É preciso medir 24 horas por dia.
• Ignorar o jitter. É o jitter que mais frequentemente mata múltiplas contas e derruba sessões. E todo mundo esquece dele.
• Confiar em prints alheios. O speedtest do vendedor é o melhor segundo dele. Meça você mesmo.
• Falta de histórico. Sem logs, você não prova a degradação nem planeja janelas.
• Medir no vácuo. Teste o canal pelo mesmo protocolo que você usará na tarefa.

FAQ: perguntas práticas

Qual a diferença entre jitter e RTT em termos simples?

RTT é a latência média, e o jitter é a variação dela. Você pode ter RTT baixo, mas jitter alto: em média rápido, mas irregular e imprevisível. É justamente a irregularidade que prejudica sessões estáveis.

Por que um proxy de 15 Mbps às vezes é melhor que um de 50?

Porque 15 Mbps podem vir com jitter baixo e perdas mínimas, enquanto 50 podem ter picos noturnos e quedas. Para scraping e múltiplas contas, a estabilidade importa mais que a velocidade de pico.

Com que frequência devo medir as métricas?

A cada 15 minutos é um bom equilíbrio. São 96 pontos por dia, suficientes para ver todos os picos. Para monitoramento de produção, pode ser mais frequente; para avaliação de proxy, 15 minutos é mais do que suficiente.

Preciso de permissão de administrador para instalar?

Só para colocar o binário no PATH do sistema. Dá para contornar — execute a partir de uma pasta local. A ferramenta não exige privilégios para as medições em si.

Quanto espaço os logs de métricas ocupam?

Um registro JSONL tem algumas centenas de bytes. Em um dia, com medição a cada 15 minutos, acumula-se cerca de 30-50 kilobytes. Um log mensal ocupa alguns megabytes. Dá para armazenar por muito tempo.

Posso medir vários proxies ao mesmo tempo?

Sim. Crie uma tarefa de cron e um arquivo de log separados para cada proxy. Depois compare os perfis. Isso é útil para alternar canais e comparar provedores com honestidade.

O que fazer se o jitter estiver consistentemente alto 24 horas por dia?

Isso é sinal de um problema sistêmico: célula sobrecarregada, equipamento fraco no lado do provedor ou rota ruim. Colete o log de 24 horas e converse com o provedor sobre a troca de nó com base nos números.

A ferramenta funciona em roteador ou mini PC?

Sim, se houver memória suficiente. O binário é minúsculo e sem dependências, então serve para hosts de baixo consumo. Muitos o instalam bem ao lado do equipamento de modem.

Como saber se o problema é a rota, não a célula?

Observe o padrão das métricas. RTT consistentemente alto com jitter baixo geralmente indica rota longa ou não otimizada. Jitter oscilante com RTT médio normal geralmente indica sobrecarga da célula.

É obrigatório saber usar jq?

Não. A saída em JSON pode ser lida por qualquer ferramenta, e os comandos básicos de jq do artigo podem ser copiados e adaptados. Mesmo sem conhecimento profundo, você obtém médias e picos em um minuto.

Conclusões: para quem é isso e como começar

Vamos resumir. Megabits por segundo é uma das quatro métricas, e para a maioria das tarefas não é a principal. A qualidade real de um proxy móvel vive no RTT, no jitter, na perda de pacotes e na rota. E o speedtest de navegador não vê nenhuma das três últimas e mede apenas um segundo do dia.

A abordagem correta é medir com script, 24 horas por dia, em agendamento. Assim você vê a queda de qualidade noturna, encontra as janelas verdes para tarefas pesadas, compara provedores com honestidade e tem números para uma conversa fundamentada. É isso que transforma suposições em fatos.

Para quem é isso? Para todos que trabalham seriamente com proxies móveis: scrappers, especialistas em múltiplas contas, equipes de SMM e quem constrói automação sobre infraestrutura de proxy. Começar é simples: baixe o binário, configure o cron, colete um dia de métricas, confira a tabela de limites.

A ferramenta é aberta e gratuita. Um binário de 400 kilobytes sem dependências — instale e esqueça. Aliás, nós mesmos medimos nossos canais com esse utilitário e publicamos as métricas abertamente. Porque acreditamos: a qualidade de um proxy deve ser comprovada com números, não com prints bonitos. Meça seu proxy hoje — e você vai se surpreender com como o panorama difere do que o speedtest mostrava.