Proxies residenciais são mais lentos do que uma conexão direta, e isso não é um bug. Seu tráfego é roteado por um dispositivo de consumidor real em uma rede doméstica real, o que é exatamente o que compra a confiança de usuário real, e isso custa milissegundos. Existe um piso, e nenhuma quantidade de ajuste fino consegue ficar abaixo dele.
Mas eis o que a maioria das reclamações de performance ignora: a maior parte da latência com a qual as pessoas lutam não é o piso, é overhead que elas mesmas adicionaram. Refazer o handshake a cada requisição, filtros geográficos superconstrangidos, payloads com tamanho excessivo e tempestades de retry costumam custar muito mais do que o salto residencial em si. Este guia separa o que é irredutível do que não é, e percorre as técnicas que de fato movem o número, aproximadamente em ordem de impacto.
Primeiro, saiba para onde vai o tempo
Uma requisição via proxy é uma cadeia: seu cliente → o gateway → o dispositivo de saída → o alvo, e de volta. O tempo se divide em quatro categorias:
- Configuração da conexão — handshake TCP com o gateway, o túnel CONNECT, e depois um handshake TLS com o alvo. Esse costuma ser o maior custo evitável, e você paga por ele novamente a cada nova conexão.
- O salto residencial — o dispositivo de consumidor real e sua rede doméstica. Esse é o piso. Varia conforme o dispositivo e a qualidade da rede, e não há como ajustar isso para eliminá-lo.
- Tempo de resposta do alvo — quanto tempo o próprio site leva. Não é culpa do proxy, e vale a pena isolar isso antes de culpar qualquer outra coisa.
- Retries — uma requisição bloqueada ou que expirou e precisa ser refeita não custa apenas sua própria latência, ela multiplica sua latência efetiva.
Apenas a segunda categoria é fixa. As outras três estão sob seu controle para otimizar.
1. Reutilize conexões (a maior vitória isolada)
Toda conexão totalmente nova paga a cadeia completa de handshake através do proxy, o que pode facilmente superar em muito a requisição em si. Se o seu código cria uma conexão nova a cada requisição, você está pagando esse imposto repetidamente.
Use uma sessão ou cliente com pooling de conexões em vez de chamadas isoladas:
import os, requests
USER, PASS = os.environ["SHIFTER_USER"], os.environ["SHIFTER_PASS"]# Sticky session para que a conexão do pool permaneça em um único IP de saídaproxy_url = f"http://{USER}-country-us-sid-job1-ttl-600:{PASS}@p.shifter.io:443"proxies = {"http": proxy_url, "https": proxy_url}
with requests.Session() as s: # agrupa e reutiliza conexões s.proxies.update(proxies) for url in urls: r = s.get(url, timeout=30) # handshake pago uma vez, não por requisiçãoO detalhe que vale a pena entender: rotação e reutilização de conexão puxam em direções opostas. Se você rotaciona para um novo IP a cada requisição, cada requisição é uma nova conexão e um novo handshake. Isso é aceitável quando você precisa de rotação por requisição, mas reconheça que você está comprando rotação com latência.
2. Use sessões sticky onde a carga de trabalho permitir
Seguindo o ponto acima: uma sessão sticky (sid + ttl) fixa você em um único IP de saída, o que é o que torna as conexões agrupadas de fato reutilizáveis. Rotacione entre unidades lógicas de trabalho, por job, por alvo, por identidade, em vez de entre cada requisição individual.
Se um fluxo abrange várias requisições que deveriam de qualquer forma parecer um único usuário (paginando resultados, uma página com múltiplas etapas), sticky é tanto o comportamento correto quanto o mais rápido. Veja sticky vs proxy rotativo residencial para escolher o modo certo.
3. Escale com concorrência, não perseguindo uma requisição mais rápida
A latência residencial por requisição tem um piso, então a forma de aumentar o throughput é o paralelismo, não economizar milissegundos em uma única chamada. Async leva você muito mais longe do que microotimizar:
import asyncio, httpx
async def fetch(client, url): r = await client.get(url, timeout=30) return r.status_code
async def main(urls): async with httpx.AsyncClient(proxy=proxy_url) as client: # conexões reutilizadas return await asyncio.gather(*(fetch(client, u) for u in urls))Mas não aumente a concorrência às cegas. Concorrência excessiva em um único alvo dispara limites de taxa e detecção comportamental, e bloqueios custam muito mais latência (em retries) do que a concorrência economizou. Encontre o nível que o alvo tolera e permaneça abaixo dele.
4. Não superconstranja seus filtros geográficos
Cada flag de segmentação reduz o conjunto de IPs de saída elegíveis. Empilhe country + city + asn e você pode acabar selecionando de um conjunto pequeno, o que significa dispositivos mais escassos, possivelmente mais lentos, mais falhas e mais retries. Afrouxe qualquer filtro que seus dados não precisem de fato.
A ressalva: se o seu caso de uso genuinamente exige uma localização específica para que os dados estejam corretos, mantenha-o. Precisão vence velocidade, uma resposta rápida do mercado errado não vale nada (quando a segmentação em nível de cidade importa). Só não pague o imposto por uma precisão que você não está usando.
5. Payloads menores são payloads mais rápidos
Otimizações de latência e de largura de banda são o mesmo trabalho aqui: menos bytes cruzam a rede, menos tempo para transferir. Pule a renderização do navegador quando o HTML ou um endpoint JSON já tiver seus dados, bloqueie imagens/mídia/fontes quando precisar renderizar, e mantenha a compressão ativada. A lista completa está em como reduzir custos de largura de banda de proxy, e cada item ali encurta suas requisições assim como sua fatura.
6. Defina timeouts e falhe rápido
Uma requisição travada prende um worker e arrasta sua latência de cauda. Defina timeouts explícitos de conexão e leitura, e quando algo travar, abandone e tente novamente com um IP novo em vez de esperar um padrão de 60 segundos. Falhar rápido em uma saída ruim é quase sempre mais rápido do que esperar que ela se recupere.
7. Reduza retries não sendo bloqueado
Este é o ponto oculto. Uma requisição que é bloqueada e refeita custa duas ou três idas e vindas em vez de uma, então sua latência efetiva é muito pior do que sua latência medida por requisição. Reduzir a taxa de bloqueio é uma otimização de latência: use IPs de qualidade, envie cabeçalhos realistas e uma fingerprint compatível, e mantenha um ritmo sensato. Veja por que scrapers são bloqueados e como evitar ser bloqueado.
8. Meça percentis e isole o alvo
Otimize o que você consegue enxergar. Acompanhe p50 e p95 em vez de uma média, a cauda é o que trava workers concorrentes, e separe o overhead do proxy da lentidão do alvo cronometrando um endpoint neutro rápido junto com seu alvo real. O método está em como testar velocidade, taxa de sucesso e precisão de localização de proxy residencial. Sem essa separação, você vai passar uma semana ajustando um proxy quando o alvo era a parte lenta.
O que você não pode consertar, e o que fazer a respeito
O salto residencial é um piso. Ajustado perfeitamente, o residencial não vai igualar o p50 do datacenter, porque um dispositivo de consumidor real está no caminho por design. Essa é a troca: latência pela confiança que te dá a página real em alvos defendidos (residencial vs datacenter).
Se sua carga de trabalho genuinamente precisa de latência mais baixa e mais consistente e um IP estável, e não precisa de um pool residencial rotativo, isso é um sinal de que você talvez queira um produto diferente em vez de uma configuração residencial mais rápida. Os proxies ISP ficam no meio-termo: velocidade de nível datacenter com endereços registrados como residenciais (o meio-termo). Escolher a ferramenta certa vence superajustar a errada.
Perguntas frequentes
Por que proxies residenciais são mais lentos que proxies de datacenter? Porque o tráfego é roteado por um dispositivo de consumidor real em uma rede doméstica, o que adiciona um salto por design. Esse salto é o que faz você parecer um usuário genuíno em sites que bloqueiam IPs de datacenter. É uma troca deliberada, não um defeito.
Qual é a forma mais rápida de reduzir a latência de proxy residencial? Reutilizar conexões. Uma sessão em pool com um IP sticky paga o handshake TCP/TLS uma vez em vez de a cada requisição, o que costuma ser a maior parcela evitável de latência em uma configuração ingênua.
Rotacionar IPs deixa as requisições mais lentas? Sim, um pouco: um novo IP significa uma nova conexão e um novo handshake, então a rotação por requisição abre mão da reutilização de conexão. Rotacione entre unidades lógicas de trabalho em vez de a cada requisição quando seu caso de uso permitir.
Filtros geográficos mais restritos deixam as coisas mais lentas? Podem deixar. Cada filtro reduz o conjunto elegível, então country + city + ASN juntos podem deixar poucas saídas, significando dispositivos mais lentos e mais falhas. Mantenha a precisão que seus dados de fato precisam e descarte o resto.
Como sei se é o proxy ou o alvo que está lento? Cronometre o mesmo teste contra um endpoint neutro rápido e contra seu alvo real através do mesmo proxy. A diferença é aproximadamente o próprio tempo de resposta do alvo. Meça p50 e p95, não a média.
Conclusão
Proxies residenciais têm um piso de latência que você não consegue ajustar para eliminar, mas quase tudo acima desse piso está sob seu controle. Reutilize conexões, use sessões sticky onde o trabalho permitir, escale com concorrência em vez de perseguir a velocidade de uma única requisição, não superconstranja a geolocalização, encolha payloads, falhe rápido em travamentos e, acima de tudo, pare de ser bloqueado, porque retries dominam a latência efetiva. Depois meça percentis para que você esteja otimizando a cauda que de fato prejudica.
Faça isso e uma configuração de proxy residencial terá desempenho próximo ao seu teto realista. Se você ainda precisar de latência mais baixa com um IP estático, procure por proxies ISP em vez de lutar contra a física. A página de preços tem os planos por GB para testar contra sua própria carga de trabalho.