Você está rodando um parser ou aquecendo contas através de um proxy, calculando o consumo pelo tamanho das páginas — e recebe uma conta 2-3 vezes maior do que o esperado. Não se trata de engano do provedor: o tráfego inclui tudo o que realmente passou pelo canal — cabeçalhos de requisições, handshake TLS, tentativas de reconexão e pacotes de controle. Vamos analisar de onde vem a "conta" pelo tráfego e como reduzir o consumo sem perder a qualidade do trabalho.
O que o provedor realmente considera tráfego
Quando você avalia o consumo "a olho", geralmente tem em mente a fórmula: tamanho da página HTML mais imagens. Mas o provedor de proxy considera o volume total de dados que passou por ambas as direções do canal — saída (requisição) e entrada (resposta). Esse volume inclui não apenas a carga útil, mas também todo o tráfego de controle: cabeçalhos de protocolo, metadados TLS, pacotes ACK TCP, tentativas de reconexão em caso de timeouts.
Para uma requisição a uma página comum, a proporção de "dados úteis" para "dados de controle" pode ser de 80/20. Mas se você trabalha com APIs, onde as respostas são pequenas (alguns kilobytes de JSON), e há muitos cabeçalhos e handshakes — a proporção facilmente se inverte. É por isso que os arbitradores, que fazem dezenas de milhares de pequenas requisições a APIs de anúncios ou marketplaces, muitas vezes se surpreendem com a conta: cada requisição carrega um "imposto" fixo independentemente do tamanho da carga útil.
Outro ponto importante: o provedor contabiliza o tráfego no nível do servidor proxy, ou seja, todo o tráfego que realmente passou pelo IP — incluindo tentativas malsucedidas, redirecionamentos, recarregamentos de recursos na página (estilos, scripts, rastreadores), que seu script ou navegador solicitou automaticamente, mesmo que você precisasse apenas do texto.
Cabeçalhos HTTP/HTTPS: o peso oculto de cada requisição
Cada requisição HTTP e cada resposta carregam um conjunto de cabeçalhos: User-Agent, Cookie, Accept-Language, Referer, Content-Type e dezenas de outros. Nos navegadores modernos e ferramentas anti-detect (Dolphin Anty, AdsPower, Multilogin), o conjunto de cabeçalhos pode ocupar de 500 bytes a 2-3 KB por requisição — especialmente se os cookies acumularam uma sessão com dezenas de valores.
Exemplo: se você faz 10.000 requisições a uma API de marketplace com cookies de sessão de 1,5 KB, apenas para os cabeçalhos serão cerca de 15 MB de tráfego — e isso sem contar o corpo da resposta. Ao escalar para várias contas e perfis, esse número cresce linearmente.
| Tipo de Cabeçalho | Tamanho Médio | Impacto no Tráfego |
|---|---|---|
| User-Agent | 100-150 bytes | Baixo, mas se acumula em grande escala |
| Cookie (sessão) | 500-2000 bytes | Alto em sessões longas |
| Referer / Origin | 50-200 bytes | Baixo |
| Cabeçalhos Accept-* | 150-300 bytes | Baixo |
| Cabeçalhos de Resposta do Servidor | 300-800 bytes | Médio, não depende de você |
Conclusão prática: se você está escrevendo um script para monitorar preços na Wildberries ou Ozon, limpe os cookies de valores não utilizados e não carregue em suas requisições cabeçalhos desnecessários, copiados "por precaução" do DevTools do navegador.
Handshake TLS: quanto tráfego a criptografia consome
Praticamente toda a web moderna opera através de HTTPS, o que significa que cada nova conexão começa com um handshake TLS — troca de certificados, chaves de criptografia e parâmetros de protocolo. Um handshake TLS completo (TLS 1.2 ou 1.3) pesa de 4 a 8 KB, dependendo do tamanho do certificado do site e das extensões de protocolo utilizadas.
Se você abre uma nova conexão para cada requisição (e não utiliza uma conexão persistente), o handshake TLS se repete a cada vez. Com 10.000 requisições sem reutilização de conexão, você terá adicionalmente 40-80 MB de tráfego apenas para criptografia — isso pode ser mais do que o próprio conteúdo útil.
O TLS 1.3 é um pouco mais leve que o TLS 1.2 devido ao número reduzido de round-trips, mas a diferença é perceptível apenas com um grande número de conexões. Para proxies móveis, onde a própria rede do operador adiciona sua latência e reinstalações de sessão, o overhead do TLS é especialmente notável — isso deve ser considerado ao escolher proxies móveis para tarefas com requisições curtas e frequentes.
Retries: como requisições repetidas dobram o consumo
Retries são a parte mais discreta e mais cara do consumo de tráfego. Se seu parser ou script está configurado para repetir automaticamente em caso de timeout ou erro 429/503, cada requisição malsucedida já consumiu tráfego para estabelecer a conexão, handshake TLS e cabeçalhos — e então todo esse processo se repete.
Um erro comum na automação de SMM e parsing de marketplaces é uma política agressiva de retries sem atraso exponencial: o script faz 5 tentativas seguidas com intervalo de um segundo ao primeiro sinal de bloqueio do IP. Como resultado, para uma única resposta "útil", você consome o tráfego de cinco tentativas malsucedidas mais a requisição final bem-sucedida.
Isso é especialmente crítico ao trabalhar com proxies de data center em sites com proteção agressiva (como Avito ou grandes marketplaces), que podem retornar captcha ou bloqueio para a maioria das requisições de um IP "quente". Nesse caso, faz sentido considerar proxies residenciais — eles raramente são bloqueados na primeira requisição, o que reduz o número de retries e, consequentemente, o consumo real de tráfego.
Keep-Alive vs novas conexões
O HTTP Keep-Alive permite reutilizar uma única conexão TCP/TLS para várias requisições consecutivas, evitando o handshake repetido. Esta é uma das otimizações de tráfego mais eficazes, disponível na maioria dos clientes HTTP e navegadores anti-detect.
Se você está usando bibliotecas para parsing (requests, httpx, axios) sem especificar explicitamente uma sessão com conexão persistente, cada requisição por padrão pode abrir uma nova conexão TCP. Em conjunto com proxies, isso significa: nova conexão até o servidor proxy, novo TLS até o site de destino, e todo o overhead se repete a cada chamada.
| Modo de Conexão | Overhead em 1000 requisições |
|---|---|
| Nova conexão para cada requisição | 4-8 MB (apenas TLS) |
| Keep-Alive, uma sessão para 50 requisições | 0.1-0.2 MB (um handshake para o grupo) |
A diferença é enorme — e isso é uma economia pura de tráfego sem qualquer alteração na carga útil das requisições.
Como diferentes tipos de proxy contabilizam o tráfego
O modelo de cobrança de tráfego depende do tipo de proxy. Proxies de data center geralmente têm tarifação por volume de tráfego ou por número de IPs/portas — a própria infraestrutura é mais rápida e adiciona um overhead mínimo na roteação. Proxies residenciais e móveis costumam ter tarifas mais rigorosas, porque os IPs reais dos usuários são um recurso mais caro e limitado, e a rota através do operador ou provedor doméstico adiciona hops adicionais e, consequentemente, um pouco mais de dados de controle.
Proxies móveis, nesse sentido, são os mais "caros" em termos de tráfego: redes móveis adicionam seus próprios mecanismos de reinstalação de sessão, traduções NAT e às vezes compressão/descompressão de tráfego no nível do operador, o que aumenta o contador de dados passados em comparação com a mesma requisição através de uma rede fixa.
Se a tarefa é um volume estável e alto de requisições com mínimo overhead (por exemplo, parsing em massa de preços na Wildberries ou Ozon), proxies de data center são mais adequados — eles são mais rápidos e previsíveis em termos de consumo de tráfego para tarefas semelhantes.
Como reduzir o consumo de tráfego na prática
Vamos analisar passos concretos que reduzem o consumo real de tráfego sem perder a funcionalidade do parser, automação ou multi-contas.
1. Desative o carregamento de recursos desnecessários. Se você precisa apenas do texto da página ou da resposta JSON da API, desative o carregamento de imagens, fontes, scripts analíticos e rastreadores publicitários nas configurações do navegador anti-detect ou ferramenta headless. Isso frequentemente reduz o consumo de tráfego em 60-80% para tarefas de parsing.
2. Use Keep-Alive e pool de conexões. Configure o cliente HTTP para reutilizar a sessão para um grupo de requisições a um único host — isso reduz drasticamente o número de handshakes TLS.
3. Configure uma política razoável de retries. Atraso exponencial (1s → 2s → 4s) com um limite de 3 tentativas em vez de 5-10 tentativas agressivas consecutivas reduz o tráfego inútil de requisições malsucedidas e, ao mesmo tempo, diminui o risco de bloqueio adicional do IP.
4. Limpe cookies e cabeçalhos de sessão. Periodicamente, remova os valores acumulados de cookies que não são utilizados pelo site-alvo — especialmente relevante para longas sessões de aquecimento de contas no Instagram ou TikTok através de navegadores anti-detect.
5. Armazene em cache respostas estáticas. Se os dados (por exemplo, catálogo de produtos) não mudam a cada minuto, armazene a resposta localmente em vez de fazer uma nova requisição através do proxy a cada ciclo de monitoramento.
6. Use compressão. Verifique se o cabeçalho Accept-Encoding: gzip é enviado e se o servidor realmente fornece uma resposta comprimida — isso reduz o volume de tráfego de entrada em páginas com muito texto ou JSON.
Ferramentas para monitoramento de tráfego
Para entender para onde realmente vai o tráfego, é útil observar não apenas o contador do provedor, mas também a divisão detalhada das requisições. Para isso, são adequados:
- Charles Proxy / Fiddler — mostram o tamanho de cada requisição e resposta, incluindo cabeçalhos, o que ajuda a encontrar cookies "pesados" ou recursos desnecessários.
- Wireshark — para análise profunda do overhead TCP/TLS no nível de pacotes, se você precisar avaliar o peso real do handshake.
- Contadores de tráfego integrados em navegadores anti-detect (Dolphin Anty, AdsPower, GoLogin) — muitos mostram o consumo por perfil separadamente, o que é conveniente para distribuir o orçamento entre contas.
- Registro no nível do cliente HTTP — ao escrever seus próprios scripts de parsing, é útil registrar o tamanho da requisição/resposta para cada chamada, a fim de identificar anomalias.
Comparar as leituras de suas ferramentas com o contador do provedor de proxy ajuda a entender rapidamente onde o tráfego está se perdendo — em retries, TLS ou carregamento de recursos desnecessários.
Checklist de otimização antes do lançamento
Antes de um lançamento em grande escala de um parser, automação de SMM ou aquecimento de contas publicitárias, passe por uma lista curta:
- Carregamento de imagens, fontes e análises desativado onde não são necessários;
- Keep-Alive / reutilização de sessão configurados para uma série de requisições a um único host;
- A política de retries é limitada a 2-3 tentativas com atraso, e não repetições infinitas;
- Cookies de sessão são periodicamente limpos de valores não utilizados;
- Compressão de respostas (gzip/deflate/br) está ativada;
- Há cache local para requisições estáticas repetidas;
- O tipo de proxy é escolhido de acordo com a tarefa: data center para velocidade e volume, residenciais para contornar bloqueios, móveis para redes sociais e plataformas publicitárias.
Conclusão
O consumo de tráfego através de proxies não é apenas dados úteis da página, mas também todo o overhead de controle: cabeçalhos, handshakes TLS, tentativas de reconexão em caso de erros. Compreender essa mecânica permite planejar melhor o orçamento para proxies e evitar surpresas desagradáveis na conta, especialmente ao escalar o parsing de marketplaces, automação de SMM ou aquecimento de contas publicitárias.
Se sua tarefa é um parsing estável com consumo de tráfego previsível, preste atenção nos proxies de data center. Para trabalhar com redes sociais e plataformas publicitárias, onde a baixa frequência de bloqueios é importante, os proxies móveis são mais adequados. E se você precisa de um equilíbrio entre anonimato e estabilidade para contornar a proteção de sites — considere os proxies residenciais, que reduzem o número de retries devido a bloqueios menos frequentes.