Como configurar timeout e lógica de retry para proxies: proteção contra perda de dados durante o scraping

Quando você trabalha com proxies para scraping de marketplaces, automação de redes sociais ou coleta de dados, o problema mais comum é a suspensão de requisições e a perda de dados. O servidor proxy pode não responder a tempo, a conexão pode ser interrompida e seu script pode travar por vários minutos. Como resultado, você perde tempo, dados e dinheiro.

Neste guia, eu vou mostrar como configurar corretamente o timeout e a lógica de retry para trabalhar com proxies. Você vai aprender quais valores de timeout usar para diferentes tarefas, como reconectar automaticamente em caso de erros e como não perder nenhuma requisição. O artigo é adequado tanto para aqueles que escrevem código em Python quanto para aqueles que utilizam ferramentas de scraping prontas.

Por que o timeout é criticamente importante ao trabalhar com proxies

Imagine a situação: você iniciou um scraper de preços com Wildberries para 10.000 produtos. O script está funcionando através de proxies para evitar um banimento. Tudo está indo bem, mas na 523ª requisição, o servidor proxy para de responder — talvez esteja sobrecarregado ou temporariamente indisponível. Sem um timeout configurado, seu script vai esperar indefinidamente por uma resposta (ou até que o timeout do sistema de 2-5 minutos expire). Como resultado, o scraping para, você perde tempo e, quando perceber o problema, podem se passar várias horas.

Timeout é o tempo máximo de espera por uma resposta do servidor. Se o servidor não respondeu dentro desse tempo, a requisição é interrompida, e você pode tentar novamente com outro proxy ou registrar o erro em um log. Isso é especialmente importante ao trabalhar com proxies, porque:

• Os servidores proxy podem ser instáveis — especialmente os públicos ou baratos. Mesmo proxies residenciais de qualidade às vezes perdem a conexão porque o usuário real se desconectou da internet.
• O site alvo pode bloquear o IP — se o proxy foi banido, ele não responderá de forma alguma ou responderá muito lentamente (apresentando um captcha ou redirecionamento).
• Os atrasos de rede são imprevisíveis — especialmente ao usar proxies de outros países. A requisição pode passar por vários nós intermediários.
• Operações em massa requerem estabilidade — se você está fazendo scraping de 100.000 páginas ou gerenciando 50 contas do Instagram, mesmo 1% de requisições pendentes = 1.000 operações perdidas.

Sem timeouts configurados corretamente, seu script vai gastar tempo esperando por proxies indisponíveis em vez de mudar para os que estão funcionando. Isso afeta diretamente a velocidade de operação e a estabilidade do resultado.

Tipos de timeouts: connect, read e total timeout

Existem três tipos principais de timeouts que você precisa entender e configurar separadamente. Muitos desenvolvedores iniciantes e usuários de scrapers configuram apenas um timeout geral, o que leva a problemas.

1. Connect timeout (timeout de conexão)

Este é o tempo alocado para estabelecer uma conexão com o servidor proxy. Se a conexão não for estabelecida dentro desse tempo — a requisição é interrompida. O connect timeout é responsável pelo handshake inicial (TCP handshake) entre seu cliente e o proxy.

Quando ocorre: O servidor proxy está indisponível, sobrecarregado ou o IP está bloqueado por um firewall.

Valores recomendados:

• Para proxies de data center rápidos: 3-5 segundos
• Para proxies residenciais: 5-10 segundos
• Para proxies móveis: 10-15 segundos (a internet móvel é mais lenta)

2. Read timeout (timeout de leitura)

Este é o tempo de espera por uma resposta do servidor alvo após a conexão com o proxy já ter sido estabelecida. Se o servidor não começou a enviar dados dentro desse tempo — a requisição é interrompida. O read timeout protege contra situações em que o servidor aceitou a requisição, mas "travou" e não retorna uma resposta.

Quando ocorre: O site alvo processa a requisição lentamente, está sobrecarregado ou intencionalmente retarda requisições suspeitas.

Valores recomendados:

• Para scraping de páginas simples (HTML): 10-15 segundos
• Para scraping com renderização JavaScript: 30-60 segundos
• Para requisições de API: 5-10 segundos
• Para download de arquivos grandes: 120+ segundos

3. Total timeout (timeout total)

Este é o tempo máximo para a execução de toda a requisição do início ao fim, incluindo conexão, envio da requisição, recebimento e leitura da resposta. O total timeout é um "interruptor de emergência" que garante que nenhuma requisição será executada por mais tempo do que o tempo definido.

Quando usar: Quando é importante que cada requisição se encaixe em prazos rigorosos (por exemplo, ao fazer scraping em tempo real para arbitragem).

Fórmula: Total timeout = Connect timeout + Read timeout + reserva de 20-30%

Valores ideais de timeout para diferentes tarefas

Os valores corretos de timeout dependem da sua tarefa, do tipo de proxy e do site alvo. Timeouts muito curtos levarão a um grande número de erros falsos (o proxy está funcionando, mas você o descarta). Timeouts muito longos resultarão em perda de tempo aguardando proxies mortos.

Lógica de retry: como configurar corretamente as tentativas

O timeout resolve o problema de requisições pendentes, mas não resolve a questão da perda de dados. Se o proxy não respondeu — você simplesmente receberá um erro e perderá essa requisição. É por isso que a lógica de retry é criticamente importante.

A lógica de retry é a repetição automática da requisição em caso de erro. Os princípios principais para uma configuração correta são:

1. Defina quais erros requerem repetição

Nem todos os erros precisam ser repetidos. Por exemplo:

• Repetir: Timeout, Connection refused, Proxy error, 502/503/504 (erros temporários do servidor), Rate limiting (429)
• Não repetir: 404 (página não encontrada), 403 (acesso negado permanentemente), 401 (autenticação inválida), erros de validação de dados

2. Configure o número de tentativas

O número ideal de retries depende da criticidade dos dados:

• Para tarefas não críticas (scraping para análise): 2-3 tentativas
• Para tarefas importantes (monitoramento de preços de concorrentes): 3-5 tentativas
• Para tarefas críticas (trabalho com contas de anúncios): 5-10 tentativas

3. Use exponential backoff (atraso exponencial)

Não repita a requisição imediatamente — isso pode agravar o problema (por exemplo, se o servidor estiver sobrecarregado). Use um atraso crescente entre as tentativas:

• 1ª tentativa: imediatamente
• 2ª tentativa: após 1-2 segundos
• 3ª tentativa: após 4-5 segundos
• 4ª tentativa: após 10-15 segundos

Fórmula: atraso = atraso_base * (2 ^ número_tentativa). Por exemplo: 1 seg, 2 seg, 4 seg, 8 seg, 16 seg.

4. Rotação de proxies ao tentar novamente

A regra mais importante: ao tentar novamente, use um PROXY DIFERENTE do seu pool. Se um proxy não conseguiu executar a requisição, a probabilidade de que ele funcione na repetição é baixa. Mas outro proxy tem uma alta probabilidade de sucesso.

Isso é especialmente importante ao trabalhar com proxies residenciais, onde você tem um pool de centenas ou milhares de endereços IP. A cada retry, escolha um novo IP aleatório do pool.

Exemplos de configuração de timeout e retry em Python

Vamos considerar exemplos práticos de implementação de timeout e lógica de retry em Python usando bibliotecas populares.

Exemplo 1: Configuração básica com requests

A biblioteca requests é a mais popular para requisições HTTP em Python. Veja como configurar timeout e um retry simples:

import requests
from requests.adapters import HTTPAdapter
from urllib3.util.retry import Retry

# Configuração da lógica de retry
retry_strategy = Retry(
    total=5,  # Máximo de 5 tentativas
    backoff_factor=1,  # Atraso: 1, 2, 4, 8, 16 segundos
    status_forcelist=[429, 500, 502, 503, 504],  # Códigos de erro para retry
    allowed_methods=["HEAD", "GET", "POST", "PUT", "DELETE"]
)

adapter = HTTPAdapter(max_retries=retry_strategy)
session = requests.Session()
session.mount("http://", adapter)
session.mount("https://", adapter)

# Configuração do proxy
proxies = {
    'http': 'http://username:password@proxy.example.com:8080',
    'https': 'http://username:password@proxy.example.com:8080'
}

# Execução da requisição com timeout
try:
    response = session.get(
        'https://www.wildberries.ru/catalog/electronics',
        proxies=proxies,
        timeout=(5, 15)  # connect timeout 5 seg, read timeout 15 seg
    )
    print(f"Sucesso! Status: {response.status_code}")
    print(f"Tamanho da resposta: {len(response.content)} bytes")
except requests.exceptions.Timeout:
    print("Erro: timeout excedido")
except requests.exceptions.ProxyError:
    print("Erro: problema com o proxy")
except requests.exceptions.RequestException as e:
    print(f"Erro na requisição: {e}")

Neste exemplo, configuramos um retry automático no nível da sessão. Em caso de erros 429, 500, 502, 503, 504, a biblioteca tentará automaticamente repetir a requisição até 5 vezes com um atraso exponencial.

Exemplo 2: Rotação de proxies ao tentar novamente

Um exemplo mais avançado com rotação de proxies do pool a cada tentativa:

import requests
import random
import time

# Pool de proxies (substitua pelos seus proxies reais)
PROXY_POOL = [
    'http://user:pass@proxy1.example.com:8080',
    'http://user:pass@proxy2.example.com:8080',
    'http://user:pass@proxy3.example.com:8080',
    'http://user:pass@proxy4.example.com:8080',
]

def make_request_with_retry(url, max_retries=5, base_delay=1):
    """
    Executa uma requisição com retry e rotação de proxies
    """
    for attempt in range(max_retries):
        # Escolhe um proxy aleatório do pool
        proxy = random.choice(PROXY_POOL)
        proxies = {'http': proxy, 'https': proxy}
        
        try:
            response = requests.get(
                url,
                proxies=proxies,
                timeout=(5, 15),
                headers={'User-Agent': 'Mozilla/5.0 (Windows NT 10.0; Win64; x64)'}
            )
            
            # Verifica o código de status
            if response.status_code == 200:
                return response
            elif response.status_code in [429, 500, 502, 503, 504]:
                # Erro temporário - tenta novamente
                print(f"Tentativa {attempt + 1}: código {response.status_code}, tentando novamente...")
            else:
                # Erro permanente - para as tentativas
                print(f"Erro {response.status_code}, parando tentativas")
                return None
                
        except (requests.exceptions.Timeout, 
                requests.exceptions.ProxyError,
                requests.exceptions.ConnectionError) as e:
            print(f"Tentativa {attempt + 1}: erro {type(e).__name__}, tentando novamente...")
        
        # Se não for a última tentativa - aguarda com atraso exponencial
        if attempt < max_retries - 1:
            delay = base_delay * (2 ** attempt)
            print(f"Aguardando {delay} segundos antes da próxima tentativa...")
            time.sleep(delay)
    
    print("Todas as tentativas esgotadas")
    return None

# Uso
result = make_request_with_retry('https://www.ozon.ru/category/smartfony-15502/')
if result:
    print(f"Sucesso! Recebido {len(result.content)} bytes de dados")
else:
    print("Não foi possível executar a requisição")

Este código escolhe um novo proxy aleatório do pool a cada tentativa, o que aumenta significativamente a probabilidade de sucesso na execução da requisição.

Exemplo 3: Usando a biblioteca tenacity

Para um gerenciamento mais flexível da lógica de retry, você pode usar a biblioteca especializada tenacity:

from tenacity import retry, stop_after_attempt, wait_exponential, retry_if_exception_type
import requests

@retry(
    stop=stop_after_attempt(5),  # Máximo de 5 tentativas
    wait=wait_exponential(multiplier=1, min=1, max=30),  # Atraso exponencial de 1-30 seg
    retry=retry_if_exception_type((requests.exceptions.Timeout, 
                                   requests.exceptions.ProxyError,
                                   requests.exceptions.ConnectionError))
)
def fetch_with_proxy(url, proxy):
    """
    Função com retry automático através de um decorador
    """
    proxies = {'http': proxy, 'https': proxy}
    response = requests.get(url, proxies=proxies, timeout=(5, 15))
    response.raise_for_status()  # Lança uma exceção em caso de erro HTTP
    return response

# Uso
try:
    result = fetch_with_proxy(
        'https://www.avito.ru/rossiya/telefony',
        'http://user:pass@proxy.example.com:8080'
    )
    print(f"Sucesso! Status: {result.status_code}")
except Exception as e:
    print(f"Não foi possível executar a requisição após todas as tentativas: {e}")

A biblioteca tenacity oferece opções muito flexíveis para configuração de retry através de decoradores. Instalação: pip install tenacity

Soluções prontas para scraping sem código

Se você não é programador ou deseja economizar tempo no desenvolvimento, existem ferramentas de scraping prontas com suporte embutido para timeout e lógica de retry. Você não precisa escrever código — basta configurar os parâmetros na interface gráfica.

Octoparse

Um popular scraper visual para Windows e Mac. Configuração de timeout e retry:

• Abra as configurações da tarefa → Opções Avançadas
• Page Load Timeout: defina 20-30 segundos
• Ajax Timeout: 10-15 segundos para conteúdo dinâmico
• Retry Times: 3-5 tentativas em caso de erro
• Nas configurações de proxy, você pode carregar uma lista e ativar a rotação automática

ParseHub

Um scraper em nuvem com um plano gratuito. Configuração:

• Settings → Advanced → Page Load Delay: 5-10 segundos
• Request Timeout: 30 segundos
• Retry Failed Requests: ativar, 3 tentativas
• Suporta proxies através das configurações do projeto

Apify

Uma plataforma para automação de tarefas web com atores (scripts) prontos para scraping de sites populares. Muitos atores para scraping de marketplaces (Wildberries, Ozon) já têm configurações ideais de timeout e retry embutidas. Você só precisa:

• Escolher um ator pronto para o site desejado
• Especificar o proxy (suporta integração com provedores de proxy)
• Iniciar a tarefa — tudo o mais é configurado automaticamente

Navegadores anti-detect para automação

Se você trabalha com redes sociais ou plataformas de anúncios através do Dolphin Anty, AdsPower ou Multilogin, o timeout é configurado no perfil do navegador:

• Dolphin Anty: Configurações do perfil → Proxy → Timeout: 10-15 segundos
• AdsPower: Proxy Settings → Connection Timeout: 10 segundos, Read Timeout: 20 segundos
• Multilogin: Browser Profile → Network → Proxy Timeout: 15 segundos

Ao automatizar através desses navegadores (por exemplo, com scripts Selenium), o timeout do proxy é herdado das configurações do perfil, mas você também pode definir timeouts adicionais no nível do script.

Erros comuns ao configurar timeouts

Mesmo desenvolvedores experientes e especialistas em scraping cometem erros típicos ao trabalhar com timeout e retry. Aqui estão os mais comuns:

Erro 1: Ausência de timeout

Muitas bibliotecas não definem timeout por padrão ou definem um valor muito alto (vários minutos). Se você não especificou um timeout explicitamente — seu script pode travar por muito tempo.

Solução: Sempre especifique explicitamente o timeout em cada requisição. É melhor receber um erro após 15 segundos do que esperar 5 minutos.

Erro 2: Usar o mesmo proxy em todas as tentativas

Se o proxy não respondeu na primeira vez, a probabilidade de sucesso na repetição com o mesmo proxy é muito baixa. Muitos esquecem de rotacionar os proxies entre as tentativas.

Solução: Use um novo proxy do pool a cada retry. Isso é crítico para uma alta taxa de sucesso.

Erro 3: Timeouts muito curtos para proxies lentos

Proxies móveis e alguns residenciais podem ser mais lentos do que os de data center. Se você definir um timeout de 5 segundos para um proxy móvel — receberá muitos erros falsos em IPs que estão funcionando.

Solução: Considere o tipo de proxy. Para proxies móveis, use um timeout mínimo de 10-15 segundos.

Erro 4: Tentativas infinitas sem limite

Alguns implementam retry em um loop while True sem limitar o número de tentativas. Se o problema estiver do lado do site alvo (por exemplo, se ele estiver completamente fora do ar) — o script tentará indefinidamente.

Solução: Sempre limite o número de retries (3-10 tentativas no máximo) e registre requisições malsucedidas para análise posterior.

Erro 5: Ignorar o tipo de erro

Nem todos os erros precisam ser repetidos. Por exemplo, se você recebeu um 404 (página não encontrada) — repetir não faz sentido, a página simplesmente não existe. Mas um 503 (serviço temporariamente indisponível) — faz sentido tentar novamente após alguns segundos.

Solução: Analise o tipo de erro e repita apenas problemas temporários (timeout, erro de conexão, 429, 500, 502, 503, 504).

Erro 6: Falta de registro

Sem logs, você não entenderá por que as requisições falham: é um problema com o proxy, com os timeouts ou com o site alvo?

Solução: Registre cada erro indicando: qual proxy foi usado, qual foi o timeout, quantas tentativas foram feitas, qual erro ocorreu. Isso ajudará a otimizar as configurações.

Conclusão

A configuração correta de timeout e lógica de retry não é apenas um detalhe técnico, mas um fator criticamente importante para a estabilidade e eficiência ao trabalhar com proxies. Sem timeouts, seus scripts ficarão travados em proxies mortos, perdendo tempo. Sem lógica de retry, você perderá dados em erros temporários. E sem rotação de proxies ao tentar novamente — você terá uma baixa taxa de sucesso mesmo com um pool de IPs de qualidade.

Principais conclusões deste guia:

• Sempre defina o timeout explicitamente: connect timeout de 5-10 segundos, read timeout de 10-30 segundos dependendo da tarefa
• Use lógica de retry com limite de 3-5 tentativas e atraso exponencial
• Rotacione proxies a cada tentativa — isso é a chave para uma alta taxa de sucesso
• Repita apenas erros temporários (timeout, 429, 500, 502, 503, 504), não desperdice tentativas em erros permanentes (404, 403)
• Registre todos os erros para análise e otimização das configurações
• Considere o tipo de proxy: proxies móveis são mais lentos que os de data center, aumente os timeouts conforme necessário

Se você trabalha com scraping de marketplaces (Wildberries, Ozon, Avito), automação de redes sociais ou plataformas de anúncios, a estabilidade dos proxies afeta diretamente seu resultado. Use proxies de qualidade com alto uptime e configure corretamente o timeout e o retry — isso economizará horas de tempo e milhares de requisições perdidas.

Para tarefas que exigem máxima estabilidade e um mínimo de erros de timeout, recomendamos experimentar proxies de data center — eles oferecem alta velocidade de resposta e conexão estável, o que é especialmente importante em scraping em massa e automação.