Como medir a qualidade de um proxy móvel: 7 métricas, protocolo e scripts

Introdução: por que um único número de velocidade não resolve nada

Imagine que você está escolhendo um proxy móvel e vê um belo anúncio: velocidade de 50 megabits. Parece convincente, certo? Mas esse número quase não diz nada sobre como o proxy se comportará no trabalho real. A velocidade é apenas uma faceta da qualidade, e nem de longe a mais importante. Muito mais frequentemente, o que decepciona as pessoas não é um canal lento, mas a instabilidade: o proxy ora responde instantaneamente, ora trava por vários segundos.

Neste guia, você aprenderá a medir a qualidade de um proxy móvel de forma honesta e sistemática. Você dominará sete métricas principais, terá scripts prontos em bash e Python, conhecerá um protocolo de medição unificado e aprenderá a interpretar os resultados corretamente. No final, você conseguirá consolidar os dados em uma única tabela e comparar objetivamente dois fornecedores.

O que você vai obter ao final: sua própria metodologia de verificação, ferramentas prontas e compreensão de quais números são preocupantes. Você deixará de acreditar em números de propaganda e começará a se basear em suas próprias medições.

Para quem é este guia: para quem compra ou já usa proxies móveis e quer entender pelo que está pagando. É adequado para iniciantes, pois cada passo é explicado detalhadamente. Também há elementos para avançados: percentis, execuções longas, interpretação de distribuições.

O que você precisa saber antecipadamente: basta saber abrir o terminal e copiar comandos. Experiência em programação não é obrigatória. Tudo o que for necessário será explicado ao longo do caminho.

Quanto tempo será necessário: as medições básicas levam cerca de duas a três horas. Uma execução completa de 24 horas, é claro, dura 24 horas, mas funciona em segundo plano e não exige sua atenção constante. Para leitura e configuração, reserve uma noite tranquila.

Por que uma única execução não prova nada. A rede móvel vive sua própria vida. Em um segundo a torre está livre, no outro está sobrecarregada. Se você fizer uma única requisição e ela for rápida, isso é coincidência. O quadro real só é dado por uma série de dezenas e centenas de medições distribuídas no tempo. É por isso que mediremos não uma vez, mas em séries, e olharemos não para a média, mas para a distribuição.

Preparação inicial: ferramentas e protocolo unificado

Antes de apertar botões, vamos montar o kit de trabalho. Uma preparação adequada garante que seus números sejam comparáveis entre si.

Ferramentas necessárias

• curl – utilitário para enviar requisições a partir da linha de comando. Na maioria dos sistemas, já vem instalado.
• Python versão 3.8 ou superior – para o script que calcula as métricas e os percentis.
• Terminal – o prompt de comando do seu sistema operacional.
• Editor de texto – para salvar scripts e anotações.
• Acessos ao proxy – endereço, porta, login e senha do seu proxy móvel.

Como verificar se está tudo instalado

1. Abra o terminal.
2. Digite o comando curl --version e pressione Enter.
3. Se aparecer o número da versão, o curl está pronto.
4. Digite python3 --version e pressione Enter.
5. Se aparecer algo como Python 3.11, está tudo certo.

Dica: se python3 não for encontrado, baixe o Python do site oficial dos desenvolvedores. Ao instalar no Windows, marque a opção Add Python to PATH, caso contrário o terminal não reconhecerá o comando.

Conjunto de endpoints de referência

Endpoints são os endereços para os quais enviamos as requisições. É muito importante escolher alvos reais, semelhantes àqueles com os quais você trabalhará. Não teste o proxy apenas em servidores especiais de teste de velocidade – eles não refletem a carga real.

Prepare três ou quatro endereços diferentes. Por exemplo, uma página de verificação de IP, uma página de texto leve e um ou dois recursos com os quais você planeja trabalhar. Alvos diferentes dão quadros diferentes, e isso é normal.

⚠️ Atenção: use apenas recursos cujo acesso seja permitido por suas regras e não viole a legislação. Não utilize proxies e scripts de teste para ações contrárias à lei ou aos termos de serviço.

Protocolo de medição unificado

Para que a comparação seja justa, fixe as condições e não as altere entre os testes de diferentes fornecedores.

• Horário fixo do dia. Meça ambos os proxies no mesmo intervalo de tempo. A rede móvel se comporta de forma diferente ao meio-dia e à noite.
• Número mínimo de execuções. Faça uma série de pelo menos algumas dezenas de requisições para cada métrica. Quanto mais amostras, mais confiável o resultado.
• Mesmos endpoints. Teste ambos os proxies no mesmo conjunto de endereços.
• Configurações de timeout idênticas. Defina um limite de espera único para todas as requisições.
• Mesmo computador e canal. Não troque de dispositivo no meio do teste.

Dica: crie uma pasta separada para cada fornecedor e coloque os logs lá. Assim você não confunde nada na hora da comparação.

✅ Verificação: você instalou curl e Python, preparou a lista de endpoints e anotou o protocolo de condições. Agora pode passar para a teoria.

Conceitos básicos em linguagem simples

Vamos destrinchar os termos que aparecerão em cada etapa. Entender essas palavras é metade do caminho.

Latência

Latência é o tempo entre o envio da requisição e o recebimento da resposta. Mede-se em milissegundos. Quanto menor, melhor. Imagine que você grita em uma montanha e espera o eco: a latência é a pausa até o primeiro som.

TTFB

TTFB significa Tempo até o Primeiro Byte (Time to First Byte). É o momento em que o servidor começa a enviar a resposta. É a parte mais importante da latência, pois mostra a rapidez com que o proxy e o servidor reagiram à sua requisição, antes mesmo da transmissão do conteúdo principal.

Largura de banda

Largura de banda é a quantidade de dados que o proxy consegue transmitir por segundo. É aquela velocidade que costumam anunciar. Ela é importante, mas apenas em conjunto com as outras métricas.

Jitter

Jitter é a variação da latência de uma requisição para outra. Se uma resposta chega em 100 milissegundos, a seguinte em 105 e a terceira em 98, o jitter é pequeno e isso é bom. Se os valores saltam de 80 para 900, o jitter é enorme e o trabalho será irregular.

Taxa de respostas bem-sucedidas

É a porcentagem de requisições que foram concluídas com sucesso, sem erros ou interrupções. Essa métrica mostra a confiabilidade. O proxy pode ser rápido, mas se a cada dez requisições uma falhar, trabalhar com ele será desgastante.

Percentis p50, p95 e p99

Essa é uma forma de descrever a distribuição dos valores. O percentil p50 é a mediana: metade das requisições é mais rápida que esse valor, metade é mais lenta. O percentil p95 indica que 95% das requisições ficaram dentro desse tempo, e 5% foram piores. O percentil p99 mostra o comportamento dos casos mais lentos.

Dica: lembre-se da regra principal. A média engana, os percentis dizem a verdade. Se você tem nove respostas rápidas e uma travada por dez segundos, a média parece tolerável, mas o p99 mostra o problema na hora.

Diferença entre lento e instável

Um proxy lento entrega valores de latência grandes de forma estável. É previsível. Um proxy instável dá resultados às vezes ótimos, às vezes péssimos. Muitas vezes, a instabilidade é pior do que uma lentidão constante, porque não é possível planejá-la.

✅ Verificação: você entende o que é latência, TTFB, largura de banda, jitter, taxa de sucesso e percentis. Ótimo, vamos à prática.

Passo 1: medir disponibilidade e taxa de respostas bem-sucedidas

Objetivo da etapa: descobrir quão confiável o proxy é ao responder requisições e entender quais erros ocorrem.

O que vamos fazer

Enviaremos uma série de dezenas de requisições idênticas e contaremos quantas foram concluídas com sucesso. Além disso, coletaremos os erros por tipo: timeouts, quedas de conexão, respostas com códigos de erro.

Instruções passo a passo

1. Abra o terminal.
2. Prepare a string de acesso ao proxy no formato login, senha, endereço e porta.
3. Execute uma série de requisições com um loop simples, onde o comando curl acessa seu endpoint através do proxy.
4. Para cada requisição, registre o código de resposta e o fato de sucesso ou erro.
5. Após concluir a série, calcule a porcentagem de respostas bem-sucedidas.

O comando básico para uma requisição é: curl com a flag de proxy, flag de timeout e o endereço. A flag --max-time limita o tempo de espera, evitando que uma requisição travada pare toda a série.

Como interpretar o resultado

Divida as respostas em grupos. As bem-sucedidas são aquelas com códigos normais. Conte separadamente os timeouts (quando o servidor não respondeu a tempo). Conte separadamente as quedas de conexão. E separadamente as respostas com códigos de erro do servidor.

Atenção: a distribuição dos erros é mais importante que o número total. Se todas as falhas são timeouts, o problema está na velocidade ou sobrecarga da rede. Se são quedas de conexão, talvez o proxy seja instável no nível do canal móvel.

Dica: não tire conclusões com base em cinco requisições. Uma série mínima significativa é de algumas dezenas. Para decisões importantes, faça centenas.

Possíveis problemas

• Todas as requisições falham. Verifique se o login, senha, endereço e porta estão corretos. Um único erro de digitação estraga tudo.
• Algumas requisições travam para sempre. Use obrigatoriamente um limite de tempo, caso contrário a série nunca terminará.
• Códigos de erro do servidor variam. Talvez o recurso alvo em si seja instável. Tente outro endpoint de controle.

✅ Verificação: você tem o número de respostas bem-sucedidas, o número de erros de cada tipo e entende onde o proxy tropeça.

Passo 2: medir latência e TTFB por meio de percentis

Objetivo da etapa: obter um quadro honesto da latência, baseado na distribuição, e não na enganosa média.

Por que a média engana

Suponha que você tenha dez requisições. Nove chegam em cem milissegundos, e uma trava por cinco segundos. A média mostrará cerca de seiscentos milissegundos, e isso será mentira dos dois lados. Na verdade, quase sempre o proxy é rápido, mas às vezes catastroficamente lento. Os percentis mostram isso com honestidade.

Formato de saída do curl com a flag -w

O utilitário curl consegue fornecer uma discriminação detalhada dos tempos. A flag -w permite solicitar indicadores específicos. As variáveis mais úteis para nós: time_starttransfer – que é essencialmente o TTFB, o tempo até o primeiro byte. Há também time_connect – tempo de estabelecimento da conexão, e time_total – tempo total da requisição.

1. Monte o comando curl com a flag -o para descartar o corpo da resposta, para que não atrapalhe.
2. Adicione a flag -s para remover o indicador de progresso.
3. Adicione a flag -w com as variáveis de tempo desejadas.
4. Execute o comando em loop o número de vezes necessário através do seu proxy.
5. Salve todos os valores de TTFB em um arquivo, um número por linha.

Como calcular os percentis

Ordene os números coletados em ordem crescente. O valor na posição do meio da lista é o p50. O valor na posição de 95% do comprimento da lista é o p95. O valor na posição de 99% é o p99. No script em Python no final do guia, isso é feito automaticamente.

Dica: sempre observe o par p50 e p95 juntos. Se estiverem próximos, o proxy é estável. Se houver um abismo entre eles, o proxy tem quedas raras, mas dolorosas.

Possíveis problemas

• Valores de TTFB suspeitamente baixos. Talvez o cache tenha agido. Desative a reutilização da conexão com a flag que desabilita keep-alive e adicione um parâmetro único ao endereço.
• Valores variam muito entre execuções. Isso é normal em redes móveis. Por isso fazemos séries, e não medições isoladas.

✅ Verificação: você tem um arquivo com valores de TTFB e três números de percentis que descrevem o comportamento real da latência.

Passo 3: medir a largura de banda de forma honesta

Objetivo da etapa: descobrir a velocidade real de transferência de dados sem autoengano.

Como medir de forma honesta

Baixe através do proxy um arquivo de tamanho conhecido e meça quanto tempo levou. Divida o tamanho pelo tempo e obtenha a velocidade. Parece simples, mas há nuances fáceis de perder.

1. Escolha vários arquivos de tamanhos diferentes em recursos reais.
2. Baixe cada um através do proxy usando curl, medindo o tempo com a flag -w com a variável time_total e a variável size_download.
3. Repita o download várias vezes para cada arquivo.
4. Calcule a velocidade para cada execução e observe a distribuição.

Por que vários arquivos e endpoints

Um único arquivo de um único servidor pode estar limitado pela capacidade do próprio servidor, e não pelo seu proxy. Fontes diferentes dão quadros diferentes. Se em todas as fontes a velocidade for igualmente baixa, o problema é o proxy. Se variar, o gargalo pode estar em um servidor específico.

Impacto dos limites do plano

Muitos planos móveis têm limites de velocidade ou volume de tráfego. Após um certo patamar, a velocidade pode cair drasticamente. Leve isso em conta: se você baixou muitos dados seguidos, a lentidão pode ser consequência do plano, e não da qualidade do proxy.

⚠️ Atenção: não baixe volumes gigantescos de dados apenas para teste se seu plano for limitado. Você corre o risco de esgotar a franquia. Use arquivos de tamanho moderado.

Dica: meça a largura de banda no mesmo horário do dia que as outras métricas. A congestionamento da rede influencia bastante o resultado.

Possíveis problemas

• A velocidade é instável. Isso é típico de redes móveis. Olhe para a mediana da velocidade, e não para um único resultado melhor.
• A velocidade caiu bruscamente durante o teste. Talvez o limite do plano tenha sido atingido ou o modo de rede tenha mudado.

✅ Verificação: você tem valores de velocidade em várias fontes e entende onde está o gargalo.

Passo 4: medir jitter e estabilidade

Objetivo da etapa: entender quão uniforme é o funcionamento do proxy, e não apenas quão rápido ele é.

O que vamos fazer

Pegamos a série de medições de latência dos passos anteriores e observamos a dispersão. O jitter é essencialmente uma medida de quanto os valores vizinhos diferem entre si.

1. Pegue o arquivo com os valores de latência coletados no segundo passo.
2. Calcule a diferença entre medições consecutivas.
3. Calcule a média do módulo dessas diferenças – essa será uma estimativa do jitter.
4. Além disso, observe o desvio padrão de toda a série.

O que é considerado normal

Não existem números universais, pois a norma depende da tarefa. O princípio geral é: quanto menor o jitter em relação à própria latência, melhor. Se a latência é de cem milissegundos e o jitter é cinco, é ótimo. Se o jitter é comparável à latência, o trabalho será irregular.

Dica: visualize a série de medições com um gráfico simples. Uma linha reta é um bom sinal. Uma serra com dentes afiados é preocupante.

Dispersão dos valores

Preste atenção a outliers raros. Um pico isolado a cada cem requisições pode ser tolerável. Picos regulares significam que o proxy sofre oscilações da rede móvel acima do normal.

✅ Verificação: você tem uma estimativa do jitter e entende se o proxy é estável ou instável.

Passo 5: verificar o comportamento durante a troca de IP

Objetivo da etapa: entender a rapidez e a qualidade com que o proxy troca de endereço IP.

O que medimos

Proxies móveis conseguem trocar de IP sob demanda ou em intervalos programados. Estamos interessados em algumas coisas: quanto tempo leva a troca, se o novo endereço permanece na mesma rede e cidade, e quantos endereços únicos são obtidos em uma hora.

1. Consulte o IP atual através de um endpoint de verificação de IP.
2. Inicie a troca de IP da forma que seu fornecedor disponibiliza.
3. Meça o tempo até que o novo endereço fique disponível.
4. Consulte o IP novamente e registre-o.
5. Repita o ciclo várias vezes ao longo de uma hora.
6. Conte o número de endereços únicos e o tempo de cada troca.

Como avaliar o resultado

Observe vários parâmetros. A velocidade da troca mostra a rapidez com que você obtém um endereço novo. O número de endereços únicos por hora indica a diversidade do pool. A pertença à mesma rede e cidade confirma que você permanece no segmento esperado.

Dica: registre não apenas o endereço em si, mas também os dados de rede e cidade que o endpoint de verificação retorna. Assim você verá se a geografia é estável durante a troca.

⚠️ Atenção: use a troca de IP apenas para fins legais e dentro das regras dos serviços com os quais você trabalha. As capacidades técnicas do proxy não anulam as exigências legais e os termos de uso.

Possíveis problemas

• A troca demora muito. Verifique se você está usando o método correto. Consulte o fornecedor sobre o método padrão.
• Endereços se repetem. Uma pequena repetição é normal, mas duplicatas constantes indicam um pool pequeno.

✅ Verificação: você tem o tempo de troca, o número de endereços únicos por hora e os dados de geografia deles.

Passo 6: verificar a conformidade da geografia e do tipo de conexão

Objetivo da etapa: garantir que o proxy realmente corresponda às características declaradas.

O que verificamos

O fornecedor geralmente informa o país, região e tipo de conexão, por exemplo, rede móvel. Nossa tarefa é comparar o declarado com o real.

1. Acesse através do proxy um endpoint que retorna dados sobre seu endereço.
2. Registre o país e a região identificados.
3. Registre o tipo de conexão determinado pelo serviço.
4. Repita a verificação várias vezes com endereços IP diferentes.
5. Compare os resultados com o que o fornecedor prometeu.

Como interpretar o resultado

Se a geografia e o tipo de conexão coincidirem consistentemente com o declarado – ótimo. Se aparecerem outras regiões periodicamente ou o tipo de conexão não coincidir, é motivo para questionar o fornecedor.

Dica: verifique a geografia em várias fontes independentes de geolocalização. As bases de dados de atribuição de endereços às vezes divergem, e uma fonte pode errar.

✅ Verificação: você confirmou ou refutou a conformidade da geografia e do tipo de conexão com o declarado.

Passo 7: executar uma execução longa de 24 horas

Objetivo da etapa: enxergar o que não é possível notar em cinco minutos.

Por que uma execução de 24 horas

Um teste curto captura apenas o estado atual da rede. Uma execução de 24 horas mostra o comportamento do proxy em diferentes horários: de manhã, no pico do almoço, à noite. Você verá como a latência, a taxa de sucesso e a estabilidade variam ao longo do dia.

1. Configure um script para fazer medições periódicas, por exemplo, a cada poucos minutos.
2. Execute-o em segundo plano e deixe-o funcionar por 24 horas.
3. Certifique-se de que os resultados sejam gravados em um arquivo com carimbo de data/hora.
4. Após 24 horas, colete os dados e construa um panorama por hora.

O que uma execução longa revela

Você verá quedas nos horários de pico, quando a rede móvel está sobrecarregada. Notará janelas noturnas de estabilidade. Descobrirá picos raros de erros que em cinco minutos simplesmente não teriam tempo de aparecer. É a execução de 24 horas que separa um proxy bom de um mediano.

⚠️ Atenção: monitore o consumo de tráfego durante a execução de 24 horas. Faça requisições leves para não esgotar o limite do plano com um dia inteiro de operação contínua.

Dica: não execute a execução de 24 horas em um computador que possa entrar em modo de suspensão. Desative a hibernação, caso contrário as medições serão interrompidas.

✅ Verificação: você tem um log de 24 horas com carimbos de data/hora, mostrando o comportamento do proxy em dinâmica.

Scripts prontos para medições

Abaixo estão modelos que calculam as métricas descritas. Adapte-os aos seus dados de acesso e endpoints.

Script em bash

Este script faz uma série de requisições, coleta TTFB e códigos de resposta, e os salva em um arquivo. A lógica é: em um loop, executa-se curl através do proxy, a flag -w exibe o tempo até o primeiro byte e o código de resposta, e o resultado é acrescentado ao log.

Os principais elementos do script: uma variável com o endereço do proxy no formato protocolo, login, senha, endereço e porta. Uma variável com o endpoint alvo. Um loop com o número de repetições desejado. Dentro do loop, uma chamada curl com as flags -s (silencioso), -o (descartar corpo), --max-time (limitar tempo de espera) e -w com as variáveis time_starttransfer e http_code. Cada linha de resultado é acrescentada a um arquivo de texto. Após o loop, o bash pode calcular uma estatística simples ou passar o arquivo para o Python.

Para desabilitar o cache, adicione um parâmetro único à URL e use a flag que desativa a reutilização da conexão. Isso garante que cada medição seja honesta, e não obtida da memória.

Script em Python

O script em Python é mais conveniente para calcular percentis e jitter. Ele lê um arquivo com valores ou faz as requisições diretamente usando uma biblioteca HTTP que suporta proxy.

A lógica do script é a seguinte. Primeiro, definem-se os parâmetros: endereço do proxy, lista de endpoints, número de repetições e timeout. Em seguida, em um loop, as requisições são executadas, registrando para cada uma o tempo até o primeiro byte, o tempo total e o código de resposta. As respostas bem-sucedidas e mal-sucedidas são contadas separadamente. Todos os valores de latência são armazenados em uma lista.

Após a coleta dos dados, o script ordena a lista de latências e calcula os percentis. A mediana é obtida do meio da lista ordenada. O percentil p95 é da posição de 95% do comprimento. O percentil p99 é da posição de 99%. O jitter é calculado como a média dos módulos das diferenças entre medições consecutivas. A taxa de respostas bem-sucedidas é o número de sucessos dividido pelo total de requisições.

Ao final, o script imprime um relatório resumido: taxa de sucesso, percentis de latência, estimativa de jitter e distribuição dos erros por tipo. Para uma execução de 24 horas, adicione um carimbo de data/hora a cada registro e envolva as medições em um loop com pausa entre as séries.

Dica: salve os dados brutos, não apenas os números finais. Se depois você precisar recalcular uma métrica de outra forma, terá os originais.

⚠️ Atenção: armazene o login e a senha do proxy em um arquivo de configuração separado, e não diretamente no script que você pode acidentalmente mostrar a alguém.

Como consolidar os resultados em uma única tabela

Quando você tiver os dados coletados, é importante apresentá-los de forma visual. Uma tabela unificada permite comparar fornecedores de forma honesta.

Estrutura da tabela final

Faça uma tabela onde as linhas são as métricas e as colunas são os fornecedores. Para cada métrica, indique o valor e, quando apropriado, os percentis. Assim você verá imediatamente quem é mais forte em quê.

• Taxa de respostas bem-sucedidas – porcentagem de cada fornecedor.
• TTFB – três números: p50, p95, p99.
• Largura de banda – mediana da velocidade.
• Jitter – estimativa de dispersão.
• Troca de IP – tempo de troca e número de endereços únicos por hora.
• Geografia e tipo de conexão – coincide com o declarado ou não.
• Comportamento ao longo de 24 horas – há quedas nos horários de pico.

Tabela de interpretação das métricas

Abaixo, uma tabela descritiva do tipo métrica, como é medida, o que significa um valor ruim. Não inventamos números específicos – as normas dependem da tarefa.

• Taxa de respostas bem-sucedidas. Medida por uma série de requisições e contagem de sucessos. Um valor ruim é uma proporção notável de erros, especialmente quedas de conexão, indicando falta de confiabilidade.
• TTFB e percentis. Medido via curl com a variável de tempo até o primeiro byte em uma grande série. Um valor ruim é uma enorme diferença entre p50 e p99, indicando quedas raras, mas dolorosas.
• Largura de banda. Medida baixando arquivos de tamanho conhecido. Um valor ruim é uma velocidade que não atende às suas tarefas ou cai drasticamente.
• Jitter. Medido como a variação das latências consecutivas. Um valor ruim é um jitter comparável à própria latência, indicando trabalho irregular.
• Troca de IP. Medida por um ciclo de trocas com medição de tempo. Um valor ruim é uma troca demorada e poucos endereços únicos.
• Geografia e tipo de conexão. Medido pela comparação com um endpoint de geolocalização. Um valor ruim é a não conformidade com o declarado.
• Estabilidade em 24 horas. Medida por uma execução longa. Um valor ruim são fortes quedas nas métricas durante os horários de pico.

Dica: ao comparar, não tire conclusões com base em uma única linha. Pondere as métricas de acordo com a importância para a sua tarefa. Para uns, a estabilidade é crítica; para outros, a velocidade de troca de endereço.

Verificação do resultado: checklist de qualidade da medição

Antes de confiar em seus números, percorra a lista. Isso garante que as medições estejam corretas.

• Cada métrica foi medida em série, não com uma única requisição.
• Os dois fornecedores foram testados no mesmo horário do dia.
• Foram usados os mesmos endpoints e timeouts.
• Para a latência, foram calculados percentis, não apenas a média.
• O cache e a reutilização de conexão foram desabilitados onde necessário.
• O teste foi feito em alvos reais, não apenas em servidores de teste de velocidade.
• Foi realizada pelo menos uma execução de 24 horas.
• Os dados brutos foram salvos para possível recálculo.

✅ Verificação: se todos os itens estão marcados, seus resultados podem ser considerados uma base confiável para a decisão.

Erros comuns em medições e suas soluções

Aqui estão os erros mais frequentes. Cada um é descrito como problema, causa e solução.

Erro um: execução única

Problema: conclusão baseada em uma ou duas requisições. Causa: desejo de obter um número rapidamente. Solução: sempre faça uma série de dezenas ou centenas de requisições e olhe para a distribuição.

Erro dois: teste apenas no horário de pico

Problema: resultados parecem péssimos ou, ao contrário, ideais. Causa: medição feita no momento de pico ou de carga mínima da rede. Solução: meça em horários diferentes e, obrigatoriamente, faça uma execução de 24 horas.

Erro três: medição para servidores de teste de velocidade

Problema: números bonitos, mas no trabalho real é diferente. Causa: servidores especiais de teste de velocidade não refletem alvos reais. Solução: teste nos recursos com os quais você vai trabalhar.

Erro quatro: ignorar o cache

Problema: latência suspeitamente baixa e estável. Causa: respostas vêm do cache, não da rede. Solução: adicione um parâmetro único ao endereço e desabilite o cache.

Erro cinco: keep-alive distorce o quadro

Problema: primeira requisição lenta, as seguintes instantâneas. Causa: a conexão é reutilizada, e as medições seguintes não consideram o estabelecimento da conexão. Solução: para uma medição honesta, desabilite a reutilização da conexão se quiser ver a latência completa.

Erro seis: comparar médias em vez de percentis

Problema: dois proxies parecem iguais na média, mas na prática um é visivelmente pior. Causa: a média esconde quedas. Solução: compare p95 e p99.

Erro sete: condições diferentes para fornecedores diferentes

Problema: comparação injusta. Causa: um proxy foi testado de dia em um endpoint, o outro à noite em outro. Solução: siga rigorosamente o protocolo unificado.

Possibilidades adicionais e otimização

Depois de dominar a metodologia básica, você pode se aprofundar.

Automação de verificações regulares

Configure o script para ser executado em horários agendados, por exemplo, diariamente. Assim, você verá se o proxy está degradando com o tempo. Acumule histórico e construa uma tendência.

Medições paralelas

Usuários avançados podem executar vários threads simultaneamente para avaliar o comportamento sob carga. Faça isso com cuidado e dentro das regras do fornecedor.

Visualização de dados

Crie gráficos a partir dos dados coletados. Um gráfico de latência ao longo do dia mostra claramente os horários de pico. Um histograma da distribuição da latência mostra se há uma cauda longa de respostas lentas.

Dica: até mesmo um gráfico simples em uma planilha eletrônica torna as conclusões muito mais convincentes do que uma coluna de números.

Segmentação por endpoints

Calcule as métricas separadamente para cada endpoint. Às vezes o proxy funciona perfeitamente com alguns alvos e pior com outros. Esse detalhe ajuda a tomar decisões pontuais.

FAQ: perguntas frequentes sobre medição da qualidade do proxy

Quantas requisições são necessárias para um resultado confiável?

Quanto mais, melhor. O mínimo significativo é algumas dezenas. Para decisões importantes, faça centenas de requisições e, obrigatoriamente, uma execução de 24 horas.

Por que não posso confiar no número de velocidade da propaganda?

Porque a velocidade é apenas uma métrica entre sete. O proxy pode ser rápido, mas instável, com baixa disponibilidade ou troca de IP lenta. A propaganda mostra o melhor caso, não o típico.

O que é mais importante: latência ou largura de banda?

Depende da tarefa. Para requisições leves e rápidas, a latência e a estabilidade são mais importantes. Para transferência de grandes volumes, a largura de banda é mais relevante. Observe o conjunto de métricas.

Por que o valor médio da latência é enganoso?

Porque valores raros e enormes inflam a média, e valores raros e pequenos a diminuem. Os percentis p50, p95 e p99 descrevem a distribuição de forma honesta e mostram o comportamento dos piores casos.

Como saber se o proxy é instável e não apenas lento?

Observe o jitter e a diferença entre os percentis. Um proxy lento entrega valores grandes, mas constantes. Um instável oscila entre ótimos e péssimos.

É obrigatório desabilitar o cache nas medições?

Para uma medição honesta da latência, sim. Caso contrário, você estará medindo a velocidade da memória, e não da rede. Adicione um parâmetro único ao endereço e desabilite a reutilização da conexão.

Por que fazer uma execução de 24 horas se cinco minutos já mostraram algo?

O teste de cinco minutos captura um momento. O de 24 horas mostra o comportamento nos horários de pico, à noite e de manhã, revelando picos raros de erros. Só ele separa um proxy confiável de um que foi sorteado.

Posso comparar dois fornecedores testando-os em horários diferentes?

Não. A rede muda ao longo do dia, e a comparação se torna injusta. Teste ambos no mesmo intervalo, seguindo o protocolo unificado.

O que fazer se os resultados variarem muito de uma execução para outra?

Isso é normal em redes móveis. É por isso que nos baseamos em séries e percentis, e não em medições isoladas. Aumente o número de amostras.

Preciso testar a troca de IP se não pretendo usá-la?

Se a função não for importante para você, pode pular esta etapa. Mas medir rapidamente é útil para uma compreensão geral da qualidade do pool de endereços.

Conclusão: dos números de propaganda às suas próprias medições

Você percorreu o caminho da crença ingênua em um único número de velocidade até uma metodologia sistemática de avaliação da qualidade. Agora você tem sete métricas, um protocolo unificado, scripts prontos e a compreensão de como interpretar os resultados.

O que você dominou. Você aprendeu a medir a taxa de respostas bem-sucedidas, a latência por meio de percentis, a largura de banda, o jitter, o comportamento durante a troca de IP, a conformidade da geografia e a estabilidade em 24 horas. Você sabe por que a média engana e por que uma única execução não prova nada.

O que fazer a seguir. Aplique a metodologia ao seu proxy atual e registre os números de base. Em seguida, teste um fornecedor alternativo seguindo o mesmo protocolo e compare em uma única tabela. A decisão se tornará óbvia.

Para onde evoluir. Automatize verificações regulares, acumule histórico e construa gráficos. Com o tempo, você perceberá a degradação antes que ela afete seu trabalho. Lembre-se do principal: confie não na propaganda, mas em suas próprias medições, feitas de forma honesta e sistemática. É isso que diferencia um usuário confiante daquele que paga no escuro.