Por que suas requisições de proxy residencial estão expirando

“Minhas requisições estão dando timeout” é uma das mensagens de suporte mais comuns que recebemos, e também uma das menos específicas. Um timeout é um sintoma, não uma causa. O mesmo erro aparece tanto quando o gateway não conseguiu encontrar um IP de saída compatível, quanto quando seu cliente desistiu após 5 segundos numa conexão que precisava de 8, quando o site de destino está lento, ou quando seu próprio container está mal configurado e nunca chega a alcançar o proxy.

Este é um guia de diagnóstico: como identificar qual dessas situações está realmente ocorrendo, na ordem que encontra a resposta mais rápido. É o complemento de reduzindo latência, que trata de tornar uma configuração funcional mais rápida; este aqui trata de uma configuração que está travando ou falhando, e por quê.

Etapa 0: isso é realmente um timeout?

Antes de diagnosticar, classifique com precisão, porque três falhas diferentes são relatadas como “timeout” e cada uma tem uma correção diferente:

• Timeout de conexão — seu cliente não conseguiu estabelecer conexão com o gateway. Isso aponta para o seu lado: saída de rede, firewall, host/porta errados ou configuração de container.
• Timeout de leitura/resposta — a conexão foi estabelecida normalmente, a requisição passou, mas nenhuma resposta voltou a tempo. Isso aponta para a saída ou o destino: nenhum IP compatível, um dispositivo de saída lento, ou um site de destino lento.
• Não é um timeout de verdade — um 407 (autenticação), um 502 (nenhum IP correspondeu ao seu filtro), ou uma página de CAPTCHA travada. Esses casos costumam ser relatados como timeouts por código wrapper que captura tudo como uma única exceção.

A maioria dos clientes permite separar explicitamente timeout de conexão e de leitura. Fazer isso é a etapa de diagnóstico de maior valor, e geralmente é uma mudança de uma linha:

import requests

# (connect_timeout, read_timeout) - separe-os, não passe um único número
r = requests.get(url, proxies=proxies, timeout=(10, 30))

Se falhar nos primeiros 10 segundos, é um problema de conexão. Se sobreviver à conexão e falhar aos 30, é um problema de leitura. Continue para a seção correspondente.

Causa 1: seu filtro de geolocalização está apertado demais

Esta é a causa real mais comum, e a mais fácil de corrigir.

Cada flag de segmentação reduz o pool de IPs de saída elegíveis. country-us seleciona a partir de um conjunto enorme. country-us-city-scranton-asn-12345 pode selecionar a partir de quase nada. Quando poucas ou nenhuma saída corresponde, as requisições esperam e depois falham, e dependendo do seu cliente isso aparece como timeout ou como 502.

Diagnostique afrouxando uma flag por vez:

# Funciona apenas com país?
curl -x customer-USER-country-us:PASS@p.shifter.io:443 https://api.ipify.org --max-time 30

# Depois adicione a cidade de volta e compare
curl -x customer-USER-country-us-city-chicago:PASS@p.shifter.io:443 https://api.ipify.org --max-time 30

Se apenas o país funcionar e o filtro mais restrito der timeout, você encontrou o problema. Correção: mantenha apenas a precisão que seus dados realmente exigem. Se o seu caso de uso realmente precisa daquela cidade, espere um pool menor e vazão mais baixa, e planeje-se para isso (veja quando a segmentação por cidade importa para entender quando vale o custo).

Causa 2: seu timeout está calibrado para datacenter, não para residencial

Um segundo motivo muito próximo, e que produz “timeouts” em requisições que nunca estiveram realmente quebradas.

O tráfego residencial passa por um dispositivo de consumidor real numa rede doméstica, então tem um piso de latência que os proxies de datacenter não têm (residencial vs datacenter). Um timeout total de 5 segundos, perfeitamente razoável para datacenter, vai interromper uma requisição residencial saudável no meio do caminho e relatá-la como falha.

Diagnostique medindo antes de ajustar: colete a latência p50 e p95 para seu destino real através do proxy (veja o método em como testar velocidade, taxa de sucesso e precisão de localização do proxy). Se seu timeout está abaixo do seu p95, você está fabricando falhas.

Correção: defina o timeout acima do seu p95 medido, com uma margem, e não por adivinhação. Como ponto de partida, um timeout de conexão em torno de 10s e um timeout de leitura de 30s ou mais é razoável para residencial; depois ajuste com base nos seus próprios números.

Causa 3: o destino está lento, não o proxy

Fácil de confirmar, fácil de errar. Cronometre o mesmo caminho de requisição contra um endpoint neutro e rápido, e contra seu destino real, através do mesmo proxy:

# Endpoint neutro - mede a sobrecarga do proxy
requests.get("https://api.ipify.org", proxies=proxies, timeout=(10, 30))

# Seu destino real - mede a sobrecarga do proxy + latência do destino
requests.get("https://your-target.example/page", proxies=proxies, timeout=(10, 30))

Se o endpoint neutro for rápido e o destino for lento, o proxy não é o seu problema, e nenhuma quantidade de ajuste no proxy vai resolver isso. Aumente o timeout de leitura para esse destino, ou reduza quanto da página você carrega.

Causa 4: a concorrência está alta demais

Timeouts que aparecem apenas sob carga e somem quando você testa uma única requisição apontam para isso.

Dois mecanismos: você pode estar esgotando recursos locais (slots do pool de conexões, descritores de arquivo, capacidade do event-loop), então as requisições ficam na fila do seu próprio lado antes mesmo de saírem; ou o destino está limitando sua taxa e travando em vez de retornar um 429 limpo.

Diagnostique reduzindo a concorrência para 1 e testando novamente. Se os timeouts desaparecerem, é relacionado à carga. Correção: aplique limites de concorrência por host em vez de um único número global, que é a arquitetura em balanceamento de carga de proxy.

Causa 5: manejo de conexões

Dois erros opostos, ambos produzindo timeouts:

Nenhuma reutilização de conexão. Criar uma conexão nova para cada requisição significa pagar um handshake completo de TCP + TLS através do proxy toda vez, o que é lento e dá ao seu timeout muito menos margem. Use uma session/client com pooling.

Conexões em pool obsoletas. Se você faz pooling de conexões mas rotaciona os IPs de saída a cada requisição, os sockets em pool podem apontar para saídas que não são mais válidas, e essas travam. Combine pooling com uma sessão fixa (sticky session) para que a conexão em pool permaneça numa única saída, e recicle as conexões periodicamente.

Causa 6: o próprio dispositivo de saída

As saídas residenciais são dispositivos de consumidor reais em redes domésticas reais. Alguns estão em links congestionados, alguns são móveis, alguns caem no meio de uma requisição. Uma pequena porcentagem de requisições lentas ou com falha é normal e esperada em residencial, não um defeito.

Correção: não aumente seu timeout para acomodar o pior dispositivo, isso só torna cada falha mais lenta. Falhe rápido e tente novamente numa nova identidade, o que te dá uma saída diferente. O guia de failover de ontem cobre como classificar falhas de transporte e tentar novamente corretamente. A qualidade do pool determina o quão grosso é essa cauda (reputação de IP).

Causa 7: nunca chegou ao proxy

Vale a pena verificar cedo se tudo der timeout, especialmente em containers.

Confirme se a requisição está de fato saindo pelo gateway:

curl -x customer-USER-country-us:PASS@p.shifter.io:443 https://api.ipify.org
# Retorna um IP residencial -> o proxy está funcionando.
# Retorna seu próprio IP    -> seu cliente está ignorando o proxy.
# Trava completamente       -> a saída local está bloqueada (firewall, VPN, rede corporativa).

No Docker e no Kubernetes, essa é uma causa frequente: o cliente não respeita HTTP_PROXY de forma alguma, ou NO_PROXY está mal configurado, ou localhost não significa o que você pensa dentro de um container. O guia de configuração do Docker cobre esses casos especificamente.

Causa 8: erros de autenticação ou credencial disfarçados

Um nome de usuário malformado (um erro de digitação numa flag de segmentação, um parâmetro não suportado) ou credenciais erradas podem se apresentar como um travamento ou uma falha genérica, dependendo de como seu cliente lida com um 407. Se sua configuração mais permissível ainda falhar, verifique a string de credenciais caractere por caractere antes de presumir um problema de rede.

A ordem de diagnóstico

Execute isso em sequência; cada etapa elimina uma grande classe de causas:

1. Separe timeout de conexão do de leitura. Falha de conexão significa o seu lado; falha de leitura significa a saída ou o destino.
2. Verifique se você está de fato no proxy (a verificação com ipify acima).
3. Teste apenas com country. Se funcionar, seu filtro de geolocalização estava apertado demais.
4. Compare um endpoint neutro com seu destino. Isso isola a sobrecarga do proxy da lentidão do destino.
5. Reduza a concorrência para 1. Se os timeouts sumirem, é carga, não o proxy.
6. Verifique seu timeout contra o seu p95 medido. Se estiver abaixo, você está criando as falhas.

Seis verificações, e na prática uma delas explica quase todo relato de timeout que vemos.

Quando timeouts na verdade são normais

Uma pequena cauda de requisições lentas e com falha é inerente aos proxies residenciais, porque dispositivos de consumidor reais são inerentemente variáveis. Perseguir uma taxa de sucesso de 100% com timeouts cada vez mais longos é o objetivo errado, isso torna suas falhas mais lentas sem torná-las menos numerosas.

O alvo correto é um SLO: defina uma taxa de sucesso e um p95 aceitáveis para sua carga de trabalho, falhe rápido na cauda, e tente novamente numa identidade nova. Um pipeline que falha uma requisição em 30 segundos e tem sucesso na nova tentativa é mais saudável do que um que espera 120 segundos na esperança de dar certo.

Perguntas frequentes

Por que recebo timeouts com um filtro de cidade ou ASN, mas não apenas com país? Porque cada flag reduz o pool de saídas elegíveis. País + cidade + ASN pode deixar muito poucos IPs correspondentes, então as requisições esperam e depois falham. Afrouxe até a precisão que seus dados realmente precisam, e espere vazão menor quando você genuinamente precisa de segmentação apertada.

Quais valores de timeout devo usar para proxies residenciais? Meça primeiro: seu timeout deve ficar acima do seu p95 observado, com margem. Como ponto de partida, cerca de 10s de conexão e 30s+ de leitura é razoável para residencial, depois ajuste com base nos seus próprios números. Timeouts calibrados para datacenter vão interromper requisições residenciais saudáveis.

Como eu identifico se o proxy ou o destino está lento? Cronometre um endpoint neutro rápido e seu destino real através do mesmo proxy. O endpoint neutro mede a sobrecarga do proxy; a diferença é a latência própria do destino. Se o endpoint neutro for rápido, o proxy não é o problema.

Tudo dá timeout, até requisições simples. O que está errado? Verifique se você está alcançando o proxy: faça um curl num endpoint de eco de IP através dele. Seu próprio IP significa que o cliente está ignorando o proxy; um travamento total significa que a saída local está bloqueada (firewall, VPN, configuração de container). Depois verifique suas credenciais e flags.

Devo simplesmente aumentar meu timeout? Geralmente não. Se a causa for um filtro de geolocalização apertado, um destino lento, ou um dispositivo de saída ruim, um timeout mais longo só faz a falha demorar mais. Corrija a causa, e para a cauda inevitável, falhe rápido e tente novamente numa nova identidade.

Conclusão

Um timeout é um sintoma com pelo menos oito causas distintas, e a correção depende inteiramente de qual delas você tem. Separe conexão de leitura, confirme que você está de fato no proxy, afrouxe seu filtro de geolocalização, isole a lentidão do destino da sobrecarga do proxy, teste com concorrência 1, e verifique seu timeout contra o seu p95 medido. Essa sequência resolve a grande maioria dos casos, geralmente em minutos.

E aceite a cauda: as saídas residenciais são dispositivos reais, então alguma variabilidade é o custo da confiança de usuário real. Falhe rápido, tente novamente numa identidade nova, e julgue a configuração pela taxa de sucesso e pelo p95, e não por se alguma requisição chega a dar timeout. Se você ainda estiver preso depois das seis verificações, a documentação do gateway residencial e nossa equipe podem ajudar a restringir o problema, traga sua separação de conexão/leitura e uma amostra da string de credencial que está falhando, e a resposta costuma ser rápida.