Por que o proxy móvel funciona pior à noite, enquanto o speedtest mostra o máximo
Coletamos 5.964 medições em redes móveis e analisamos como o canal se comporta ao longo das horas do dia. Acontece que o número pelo qual todo mundo escolhe um proxy cresce exatamente quando a conexão fica pior.
Por que os megabits não dizem nada sobre a qualidade do canal, já explicamos no artigo «Mbps não dizem nada sobre a qualidade de um proxy móvel». Aqui a mesma ideia, mas com dados: como latência, jitter e perdas se comportam ao longo do dia.
Um cenário familiar
Você pega um proxy mais rápido, mas o antidetect continua deslogando sessões, o parser vive dando timeout e os downloads caem no meio. Abre o speedtest — quarenta megabits, tudo certo. O vendedor diz: o canal está normal, veja você mesmo.
O canal está realmente normal — de acordo com a métrica que você mediu. O problema é que você mediu a coisa errada.
O que realmente atrapalha o trabalho
A largura de banda resolve exatamente uma tarefa: a velocidade com que um arquivo grande é baixado. Todo o resto — abrir páginas, manter sessões, resolver CAPTCHAs, requisições longas do parser — depende de outros fatores.
| Métrica | Do que ela cuida |
|---|---|
| Latência (ping) | Capacidade de resposta da interface, disparo de timeouts |
| Jitter | Variação da latência. Rompe conexões longas e websockets |
| Perda de pacotes | Requisições interrompidas, downloads corrompidos, repetições |
| Rota | Hops extras, cair em sistema autônomo errado |
A rede móvel não se diferencia da cabeada por ser mais lenta. Ela é instável: a célula fica sobrecarregada à noite, a operadora alterna faixas de frequência, o shaping entra em ação em horários programados. Uma medição isolada no navegador descreve um segundo do seu dia — e normalmente o segundo em que você resolveu testar.
Como isso aparece nos dados
Reunimos medições feitas nas redes da MTS ao longo de dez meses e calculamos a média por hora do dia. Três métricas em três escalas distintas — de propósito, separadas: juntar tudo num mesmo gráfico seria forçar a barra.
De cima para baixo: velocidade de download (Mbps), jitter (ms), perda de pacotes (%). 5.964 medições nas redes MTS, setembro de 2025 — agosto de 2026. Cada ponto é a média de uma hora, entre 72 e 388 medições por hora. Em laranja, o intervalo noturno entre 18h e 23h; ×3,4 e ×6,8 indicam quantas vezes a métrica cresce à noite. Os pontos marcam os mínimos e máximos diários.
O principal deste gráfico
A velocidade quase não muda. Das sete da manhã à meia-noite, ela fica na faixa de 54–68 Mbps. Quem roda um speedtest a qualquer hora do dia vai ver mais ou menos o mesmo número e concluir que o canal está ótimo.
O jitter, no mesmo período, cresce 3,4 vezes — de 25 ms às oito da manhã para 86 ms às onze da noite. A perda de pacotes cresce 6,8 vezes: de 0,79% durante o dia para 5,37% de madrugada.
E a coincidência mais chata: às 20h a velocidade atinge o máximo do dia — 68 Mbps —, mas o jitter na mesma hora é de 64 ms, duas vezes e meia maior que o da manhã. O speedtest neste momento mostra o melhor resultado do dia. Trabalhar neste momento é o pior que existe.
É exatamente por isso que reclamações do tipo «de noite trava tudo, mas o teste mostra velocidade normal» não são invenção nem efeito placebo. O teste mede a métrica que não piora à noite.
Como medir do jeito certo
Não é uma medição isolada, mas uma série delas. Instale a CLI, agende as execuções e acumule num arquivo:
speedmeter --json | jq -c '{t:.timestamp, d:.download, p:.ping, j:.jitter}' >> proxy.jsonlNo cron, a cada quinze minutos:
*/15 * * * * /usr/local/bin/speedmeter --json >> /var/log/proxy-speed.jsonlEm um dia, você tem 96 pontos e já consegue enxergar se o seu canal tem um vale noturno. O binário é autônomo, tem cerca de 400 KB e não tem dependências — instala em qualquer servidor onde roda a sua automação.
Quais valores são aceitáveis
| Tarefa | Jitter | Perdas |
|---|---|---|
| Parsing, scraping | até 30 ms | até 1% |
| Multicontas, antidetect | até 50 ms | até 2% |
| Automação de SMM | até 60 ms | até 2% |
| Vídeo, chamadas | até 30 ms | até 1% |
Repare no que não tem nesta tabela: coluna de megabits. Para essas tarefas, a largura de banda deixa de ser um gargalo depois de uns dez megabits.
Dados por hora
Os mesmos números do gráfico — para você conferir ou comparar com suas próprias medições.
| Hora | Velocidade, Mbps | Ping, ms | Jitter, ms | Perdas, % | Medições |
|---|---|---|---|---|---|
| 00:00 | 66 | 134 | 52.1 | 4.12 | 140 |
| 01:00 | 61 | 135 | 56.8 | 4.99 | 125 |
| 02:00 | 42 | 167 | 57.9 | 5.37 | 113 |
| 03:00 | 34 | 135 | 60.8 | 2.67 | 86 |
| 04:00 | 43 | 132 | 42.8 | 1.94 | 72 |
| 05:00 | 45 | 131 | 40.8 | 2.50 | 92 |
| 06:00 | 42 | 115 | 34.3 | 2.49 | 131 |
| 07:00 | 54 | 111 | 39.8 | 2.48 | 140 |
| 08:00 | 57 | 113 | 25.0 | 2.44 | 210 |
| 09:00 | 54 | 108 | 44.2 | 1.57 | 302 |
| 10:00 | 64 | 84 | 37.7 | 0.79 | 309 |
| 11:00 | 66 | 89 | 34.6 | 1.06 | 363 |
| 12:00 | 60 | 101 | 38.9 | 1.00 | 388 |
| 13:00 | 60 | 100 | 29.1 | 1.80 | 348 |
| 14:00 | 61 | 95 | 35.2 | 1.45 | 340 |
| 15:00 | 61 | 100 | 40.1 | 1.83 | 322 |
| 16:00 | 66 | 97 | 47.5 | 1.33 | 356 |
| 17:00 | 63 | 95 | 47.1 | 1.06 | 330 |
| 18:00 | 59 | 100 | 60.6 | 0.97 | 348 |
| 19:00 | 61 | 98 | 48.9 | 1.02 | 328 |
| 20:00 | 68 | 112 | 64.1 | 1.74 | 368 |
| 21:00 | 59 | 104 | 57.6 | 2.53 | 322 |
| 22:00 | 62 | 112 | 61.5 | 2.56 | 266 |
| 23:00 | 54 | 149 | 86.1 | 3.86 | 165 |
Observação sobre os dados
Isso é uma média de muitos usuários e muitas células, não de um único chip sob controle. Esse recorte mostra o formato da curva diária, mas não substitui a medição do seu canal específico — você precisa fazer a sua, usando o script acima.
A ferramenta usada para coletar esses números é aberta e gratuita: speedmeter.dev. Ela mede jitter e perdas no lado do servidor, em vez de confiar no relatório do navegador, e devolve o resultado em JSON para scripts.