O script cai com uma queda de conexão a cada cem requisições por um IP de datacenter e a cada dez por um canal residencial ou móvel. Isso não é defeito do proxy, é característica do ambiente: a queda em uma conexão doméstica ou celular é um fenômeno normal, e o cliente precisa superá-la sozinho, sem intervenção humana. Vamos ver de onde vem a diferença na frequência de quedas, quais timeouts e pausas entre tentativas configurar, quais erros vale a pena repetir e quais não, e como os retries afetam o consumo de tráfego.

Por que o canal residencial e o móvel caem mais do que o de servidor

O IP de datacenter fica em um canal dedicado do provedor, com redundância e jitter quase nulo — ali a queda é rara e geralmente indica uma falha de sistema. O endereço residencial é uma conexão doméstica real: o roteador reinicia, o provedor transfere o assinante entre nós, a concessão de DHCP é renovada, o dispositivo entra em modo de suspensão por um minuto. O canal móvel soma a isso handovers entre estações rádio base, troca de redes e perda temporária de sinal — tudo isso acontece em um dispositivo real de um assinante real, e não em uma porta reservada para você. O NAT da operadora móvel, que faz centenas de assinantes compartilharem um mesmo endereço, é a mesma razão pela qual esse IP é quase impossível de banir: detalhes no artigo por que proxies móveis são difíceis de banir. O outro lado da resistência a bans é que o próprio canal é fisicamente menos estável do que o de um servidor.

Valores razoáveis de timeout de conexão e de leitura

O timeout de conexão (connect timeout) e o timeout de leitura (read timeout) são coisas diferentes, e não se deve confundi-los. O connect timeout limita o tempo para estabelecer a sessão; para um canal de datacenter bastam 3–5 segundos, para o residencial e o móvel, 8–15, porque o pacote passa por mais nós intermediários até chegar ao dispositivo real. O read timeout limita a espera pela resposta depois que a conexão já foi estabelecida; a referência é o tempo de resposta esperado do servidor de destino com uma margem de 2 a 3 vezes, normalmente 15–30 segundos para requisições comuns e mais para operações pesadas. Um timeout curto demais em um canal residencial transforma uma latência normal de rede em falha falsa; um timeout longo demais mantém a conexão aberta sem utilidade e gasta tráfego à toa.

Pausa exponencial entre as tentativas

Repetir a requisição imediatamente após a queda é má ideia: se a causa for sobrecarga de um nó ou perda temporária de sinal, a repetição instantânea cai no mesmo estado. O backoff exponencial aumenta a pausa a cada tentativa — por exemplo, 1, 2, 4, 8 segundos — e dá ao canal tempo para se recuperar. Vale somar à pausa um jitter aleatório de 20–30% do valor calculado: sem ele, as threads paralelas do mesmo script repetem as requisições de forma sincronizada depois de uma falha geral e criam um pico de carga próprio. É sensato limitar o número de tentativas a três ou quatro: depois disso a chance de sucesso quase não aumenta, enquanto o gasto de tempo e de tráfego cresce de forma linear.

Quais erros repetir e quais não

Vale repetir o que parece uma falha temporária: queda de conexão, timeout, erros 502/503/504 e exceções de rede sem resposta do servidor. Não vale repetir o que não vai mudar com uma nova tentativa: o erro 400 com corpo de requisição inválido, 401/403 como problema de autorização, 404 como recurso inexistente. O código 429 merece tratamento à parte — não é uma falha, e sim uma instrução direta para ir mais devagar, e esse tipo de requisição deve ser repetido com a pausa que o servidor costuma informar em um cabeçalho da resposta, e não pelo esquema geral de backoff. Repetir às cegas todos os erros, sem distinguir, é a causa típica de um script ficar horas batendo na parede em vez de parar e avisar sobre o problema.

Como distinguir queda de canal de bloqueio pela plataforma

A queda de canal é a ausência de resposta: timeout, reset de conexão, erro no nível de TCP ou TLS. O bloqueio é uma resposta, só que indesejada: código 403, captcha no lugar do conteúdo, redirecionamento para uma página de verificação, HTML de tamanho normal em vez dos dados esperados. O primeiro se resolve com repetição, o segundo não: uma nova requisição do mesmo endereço quase sempre recebe a mesma resposta de bloqueio, e trocar de endereço por rotação já é outra questão, tratada no artigo sobre como configurar a rotação de IP por API. Cada retry é uma sessão separada de um canal residencial ou móvel, e esses canais são cobrados por tráfego: um retry agressivo em um endereço bloqueado não resolve o problema, apenas gasta gigabytes para receber sempre a mesma recusa. O limite de tentativas e a análise do código de resposta são uma questão não só de confiabilidade, mas também de orçamento.

Perguntas frequentes

Quantas vezes vale repetir uma requisição antes de desistir?

Para a maioria das tarefas bastam três ou quatro tentativas com a pausa crescendo de forma exponencial. Se todas falharem, a chance de sucesso da quinta tentativa no mesmo endereço é baixa e o consumo de tráfego continua crescendo — é mais sensato trocar o endereço por rotação ou devolver o erro ao código chamador.

São necessárias configurações de timeout diferentes para o canal de datacenter e o residencial?

Sim. O canal de datacenter mantém uma latência baixa e estável, e ali um timeout curto se justifica. Os canais residencial e móvel passam por equipamentos reais de um assinante real, por isso os timeouts neles devem ser bem mais folgados — caso contrário, a latência normal de rede será tomada o tempo todo como falha.

É possível usar o mesmo algoritmo de retry para todos os erros?

Não. Falhas de rede e respostas 5xx são candidatas a repetição com atraso. Repetir erros de autorização e de requisição inválida não faz sentido. O código 429 exige uma pausa conforme a instrução do servidor, e sinais de bloqueio — captcha, redirecionamento, código 403 — exigem a troca do endereço, e não a repetição no mesmo IP.

Canais residenciais e móveis para tarefas com retries estão na seção de proxies: lá também dá para estimar o consumo de tráfego de um cenário específico e escolher o canal com o equilíbrio desejado entre estabilidade e preço, conferindo a diferença entre proxies móveis e residenciais.