Comment configurer le timeout et la logique de retry pour les proxies : protection contre la perte de données lors du scraping

Lorsque vous travaillez avec des proxies pour le parsing de marketplaces, l'automatisation des réseaux sociaux ou la collecte de données, le problème le plus fréquent est les requêtes bloquées et la perte de données. Un serveur proxy peut ne pas répondre à temps, la connexion peut être interrompue, et votre script peut se bloquer pendant plusieurs minutes. En conséquence, vous perdez du temps, des données et de l'argent.

Dans ce guide, je vais vous montrer comment configurer correctement le timeout (timeouts) et la logique de retry (logique de répétition) pour travailler avec des proxies. Vous apprendrez quelles valeurs de timeout utiliser pour différentes tâches, comment se reconnecter automatiquement en cas d'erreurs et comment ne perdre aucune requête. Cet article convient aussi bien à ceux qui écrivent du code en Python qu'à ceux qui utilisent des outils de parsing prêts à l'emploi.

Pourquoi le timeout est-il crucial lors de l'utilisation de proxies

Imaginez la situation : vous avez lancé un parser de prix sur Wildberries pour 10 000 produits. Le script fonctionne via un proxy pour éviter d'être banni. Tout se passe bien, mais à la 523e requête, le serveur proxy cesse de répondre — peut-être qu'il est surchargé ou temporairement indisponible. Sans un timeout configuré, votre script attendra indéfiniment une réponse (ou jusqu'à ce que le timeout système de 2 à 5 minutes expire). En fin de compte, le parsing s'arrête, vous perdez du temps, et lorsque vous remarquerez le problème, plusieurs heures peuvent s'être écoulées.

Le timeout est le temps maximal d'attente pour une réponse du serveur. Si le serveur ne répond pas dans ce délai, la requête est interrompue, et vous pouvez soit réessayer avec un autre proxy, soit enregistrer l'erreur dans le journal. Cela est particulièrement important lors de l'utilisation de proxies, car :

• Les serveurs proxy peuvent être instables — en particulier les publics ou bon marché. Même les proxies résidentiels de qualité perdent parfois la connexion parce qu'un utilisateur réel s'est déconnecté d'internet.
• Le site cible peut bloquer l'IP — si le proxy est banni, il ne répondra pas du tout ou mettra beaucoup de temps à répondre (en renvoyant un captcha ou une redirection).
• Les latences réseau sont imprévisibles — surtout lors de l'utilisation de proxies d'autres pays. La requête peut passer par plusieurs nœuds intermédiaires.
• Les opérations massives nécessitent de la stabilité — si vous parsez 100 000 pages ou gérez 50 comptes Instagram, même 1 % de requêtes bloquées = 1000 opérations perdues.

Sans des timeouts correctement configurés, votre script perdra du temps à attendre des proxies inaccessibles au lieu de passer à des proxies fonctionnels. Cela affecte directement la vitesse de fonctionnement et la stabilité des résultats.

Types de timeouts : connect, read et total timeout

Il existe trois types principaux de timeouts que vous devez comprendre et configurer séparément. De nombreux développeurs débutants et utilisateurs de parsers ne configurent qu'un seul timeout général, ce qui entraîne des problèmes.

1. Connect timeout (timeout de connexion)

C'est le temps alloué pour établir une connexion avec le serveur proxy. Si la connexion n'est pas établie dans ce délai, la requête est interrompue. Le connect timeout est responsable de la poignée de main initiale (TCP handshake) entre votre client et le proxy.

Quand cela se produit : Le serveur proxy est inaccessible, surchargé ou l'IP est bloquée par un pare-feu.

Valeurs recommandées :

• Pour les proxies de data centers rapides : 3-5 secondes
• Pour les proxies résidentiels : 5-10 secondes
• Pour les proxies mobiles : 10-15 secondes (internet mobile est plus lent)

2. Read timeout (timeout de lecture)

C'est le temps d'attente pour une réponse du serveur cible après que la connexion avec le proxy a déjà été établie. Si le serveur ne commence pas à renvoyer des données dans ce délai, la requête est interrompue. Le read timeout protège contre les situations où le serveur a accepté la requête, mais est "bloqué" et ne renvoie pas de réponse.

Quand cela se produit : Le site cible traite lentement la requête, est surchargé ou ralentit intentionnellement les requêtes suspectes.

Valeurs recommandées :

• Pour le parsing de pages simples (HTML) : 10-15 secondes
• Pour le parsing avec rendu JavaScript : 30-60 secondes
• Pour les requêtes API : 5-10 secondes
• Pour le téléchargement de gros fichiers : 120+ secondes

3. Total timeout (timeout total)

C'est le temps maximal pour l'exécution de toute la requête du début à la fin, y compris la connexion, l'envoi de la requête, la réception et la lecture de la réponse. Le total timeout est un "disjoncteur" qui garantit qu'aucune requête ne sera exécutée plus longtemps que le temps imparti.

Quand l'utiliser : Lorsque vous avez besoin que chaque requête respecte des délais stricts (par exemple, lors du parsing en temps réel pour l'arbitrage).

Formule : Total timeout = Connect timeout + Read timeout + marge de 20-30%

Valeurs optimales de timeout pour différentes tâches

Les valeurs correctes des timeouts dépendent de votre tâche, du type de proxy et du site cible. Des timeouts trop courts entraîneront de nombreuses erreurs fausses (le proxy fonctionne, mais vous l'éliminez). Des timeouts trop longs entraîneront une perte de temps à attendre des proxies morts.

Logique de retry : comment configurer correctement les répétitions

Le timeout résout le problème des requêtes bloquées, mais ne résout pas le problème de la perte de données. Si le proxy ne répond pas — vous obtiendrez simplement une erreur et perdrez cette requête. C'est pourquoi la logique de retry est cruciale.

La logique de retry consiste à répéter automatiquement la requête en cas d'erreur. Les principes de base d'une configuration correcte :

1. Déterminez quelles erreurs nécessitent une répétition

Toutes les erreurs ne doivent pas être répétées. Par exemple :

• À répéter : Timeout, Connection refused, Proxy error, 502/503/504 (erreurs temporaires du serveur), Rate limiting (429)
• À NE PAS répéter : 404 (page non trouvée), 403 (accès interdit définitivement), 401 (autorisation incorrecte), erreurs de validation des données

2. Configurez le nombre de tentatives

Le nombre optimal de retries dépend de la criticité des données :

• Pour des tâches non critiques (parsing pour l'analyse) : 2-3 tentatives
• Pour des tâches importantes (suivi des prix des concurrents) : 3-5 tentatives
• Pour des tâches critiques (travail avec des comptes publicitaires) : 5-10 tentatives

3. Utilisez l'exponential backoff (délai exponentiel)

Ne répétez pas la requête immédiatement — cela peut aggraver le problème (par exemple, si le serveur est surchargé). Utilisez un délai croissant entre les tentatives :

• 1ère tentative : tout de suite
• 2ème tentative : après 1-2 secondes
• 3ème tentative : après 4-5 secondes
• 4ème tentative : après 10-15 secondes

Formule : délai = délai_de_base * (2 ^ numéro_de_tentative). Par exemple : 1 sec, 2 sec, 4 sec, 8 sec, 16 sec.

4. Rotation des proxies lors des tentatives de répétition

La règle la plus importante : lors de la répétition, utilisez un AUTRE proxy de votre pool. Si un proxy n'a pas pu exécuter la requête, la probabilité qu'il fonctionne lors de la répétition est faible. En revanche, un autre proxy a de fortes chances de réussir.

Cela est particulièrement important lors de l'utilisation de proxies résidentiels, où vous disposez d'un pool de centaines ou de milliers d'adresses IP. À chaque retry, prenez une nouvelle IP aléatoire du pool.

Exemples de configuration de timeout et de retry en Python

Examinons des exemples pratiques de mise en œuvre de la logique de timeout et de retry en Python en utilisant des bibliothèques populaires.

Exemple 1 : Configuration de base avec requests

La bibliothèque requests est la plus populaire pour les requêtes HTTP en Python. Voici comment configurer le timeout et un simple retry :

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

# Configuration de la logique de retry
retry_strategy = Retry(
    total=5,  # Maximum 5 tentatives
    backoff_factor=1,  # Délai : 1, 2, 4, 8, 16 secondes
    status_forcelist=[429, 500, 502, 503, 504],  # Codes d'erreur pour 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)

# Configuration du proxy
proxies = {
    'http': 'http://username:password@proxy.example.com:8080',
    'https': 'http://username:password@proxy.example.com:8080'
}

# Exécution de la requête avec timeout
try:
    response = session.get(
        'https://www.wildberries.ru/catalog/electronics',
        proxies=proxies,
        timeout=(5, 15)  # connect timeout 5 sec, read timeout 15 sec
    )
    print(f"Succès ! Statut : {response.status_code}")
    print(f"Taille de la réponse : {len(response.content)} octets")
except requests.exceptions.Timeout:
    print("Erreur : timeout dépassé")
except requests.exceptions.ProxyError:
    print("Erreur : problème avec le proxy")
except requests.exceptions.RequestException as e:
    print(f"Erreur de requête : {e}")

Dans cet exemple, nous avons configuré un retry automatique au niveau de la session. En cas d'erreurs 429, 500, 502, 503, 504, la bibliothèque répétera automatiquement la requête jusqu'à 5 fois avec un délai exponentiel.

Exemple 2 : Rotation des proxies lors des retries

Un exemple plus avancé avec rotation des proxies du pool à chaque tentative :

import requests
import random
import time

# Pool de proxies (remplacez par vos vrais proxies)
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):
    """
    Exécute une requête avec retry et rotation des proxies
    """
    for attempt in range(max_retries):
        # Choisir un proxy aléatoire du 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)'}
            )
            
            # Vérifier le code de statut
            if response.status_code == 200:
                return response
            elif response.status_code in [429, 500, 502, 503, 504]:
                # Erreur temporaire - répéter
                print(f"Tentative {attempt + 1} : code {response.status_code}, répétition...")
            else:
                # Erreur permanente - arrêter
                print(f"Erreur {response.status_code}, arrêt des tentatives")
                return None
                
        except (requests.exceptions.Timeout, 
                requests.exceptions.ProxyError,
                requests.exceptions.ConnectionError) as e:
            print(f"Tentative {attempt + 1} : erreur {type(e).__name__}, répétition...")
        
        # Si ce n'est pas la dernière tentative - attendre avec un délai exponentiel
        if attempt < max_retries - 1:
            delay = base_delay * (2 ** attempt)
            print(f"Attente de {delay} secondes avant la prochaine tentative...")
            time.sleep(delay)
    
    print("Toutes les tentatives épuisées")
    return None

# Utilisation
result = make_request_with_retry('https://www.ozon.ru/category/smartfony-15502/')
if result:
    print(f"Succès ! Reçu {len(result.content)} octets de données")
else:
    print("Impossible d'exécuter la requête")

Ce code choisit un nouveau proxy aléatoire du pool à chaque tentative, ce qui augmente considérablement la probabilité de succès de la requête.

Exemple 3 : Utilisation de la bibliothèque tenacity

Pour une gestion plus flexible de la logique de retry, vous pouvez utiliser la bibliothèque spécialisée tenacity :

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

@retry(
    stop=stop_after_attempt(5),  # Maximum 5 tentatives
    wait=wait_exponential(multiplier=1, min=1, max=30),  # Délai exponentiel de 1 à 30 sec
    retry=retry_if_exception_type((requests.exceptions.Timeout, 
                                   requests.exceptions.ProxyError,
                                   requests.exceptions.ConnectionError))
)
def fetch_with_proxy(url, proxy):
    """
    Fonction avec retry automatique via décorateur
    """
    proxies = {'http': proxy, 'https': proxy}
    response = requests.get(url, proxies=proxies, timeout=(5, 15))
    response.raise_for_status()  # Déclenche une exception en cas d'erreur HTTP
    return response

# Utilisation
try:
    result = fetch_with_proxy(
        'https://www.avito.ru/rossiya/telefony',
        'http://user:pass@proxy.example.com:8080'
    )
    print(f"Succès ! Statut : {result.status_code}")
except Exception as e:
    print(f"Impossible d'exécuter la requête après toutes les tentatives : {e}")

La bibliothèque tenacity offre des possibilités de configuration très flexibles pour le retry via des décorateurs. Installation : pip install tenacity

Solutions prêtes à l'emploi pour le parsing sans code

Si vous n'êtes pas programmeur ou si vous souhaitez gagner du temps sur le développement, il existe des outils de parsing prêts à l'emploi avec un support intégré pour le timeout et la logique de retry. Vous n'avez pas besoin d'écrire de code — il suffit de configurer les paramètres dans une interface graphique.

Octoparse

Un parser visuel populaire pour Windows et Mac. Configuration du timeout et du retry :

• Ouvrez les paramètres de la tâche → Options avancées
• Page Load Timeout : définissez 20-30 secondes
• Ajax Timeout : 10-15 secondes pour le contenu dynamique
• Retry Times : 3-5 tentatives en cas d'erreur
• Dans les paramètres du proxy, vous pouvez télécharger une liste et activer la rotation automatique

ParseHub

Un parser cloud avec un tarif gratuit. Configuration :

• Settings → Advanced → Page Load Delay : 5-10 secondes
• Request Timeout : 30 secondes
• Retry Failed Requests : activer, 3 tentatives
• Supporte les proxies via les paramètres du projet

Apify

Une plateforme pour automatiser des tâches web avec des acteurs (scripts) prêts à l'emploi pour le parsing de sites populaires. De nombreux acteurs pour le parsing de marketplaces (Wildberries, Ozon) ont déjà une configuration optimale intégrée pour le timeout et le retry. Vous devez juste :

• Choisir un acteur prêt à l'emploi pour le site souhaité
• Indiquer le proxy (supporte l'intégration avec des fournisseurs de proxies)
• Lancer la tâche — tout le reste est configuré automatiquement

Navigateurs anti-détection pour l'automatisation

Si vous travaillez avec des réseaux sociaux ou des plateformes publicitaires via Dolphin Anty, AdsPower ou Multilogin, le timeout se configure dans le profil du navigateur :

• Dolphin Anty : Paramètres du profil → Proxy → Timeout : 10-15 secondes
• AdsPower : Paramètres Proxy → Connection Timeout : 10 secondes, Read Timeout : 20 secondes
• Multilogin : Profil du navigateur → Réseau → Proxy Timeout : 15 secondes

Lors de l'automatisation via ces navigateurs (par exemple, avec des scripts Selenium), le timeout du proxy est hérité des paramètres du profil, mais vous pouvez également définir des timeouts supplémentaires au niveau du script.

Erreurs courantes lors de la configuration des timeouts

Même les développeurs expérimentés et les spécialistes du parsing commettent des erreurs typiques lors de l'utilisation des timeouts et des retries. Voici les plus courantes :

Erreur 1 : Absence de timeout

De nombreuses bibliothèques ne définissent pas de timeout par défaut ou en définissent un très élevé (plusieurs minutes). Si vous n'avez pas spécifié de timeout explicitement — votre script peut se bloquer pendant longtemps.

Solution : Indiquez toujours explicitement le timeout dans chaque requête. Il vaut mieux obtenir une erreur après 15 secondes que d'attendre 5 minutes.

Erreur 2 : Même proxy pour tous les retries

Si le proxy n'a pas répondu du premier coup, la probabilité de succès lors de la répétition avec le même proxy est très faible. Beaucoup oublient de faire tourner les proxies entre les tentatives.

Solution : Utilisez un nouveau proxy du pool à chaque retry. C'est crucial pour un taux de succès élevé.

Erreur 3 : Timeouts trop courts pour des proxies lents

Les proxies mobiles et certains proxies résidentiels peuvent être plus lents que les data centers. Si vous définissez un timeout de 5 secondes pour un proxy mobile — vous obtiendrez de nombreuses erreurs fausses sur des IP tout à fait fonctionnelles.

Solution : Prenez en compte le type de proxy. Pour les mobiles, utilisez un timeout d'au moins 10-15 secondes.

Erreur 4 : Retrys infinis sans limite

Certains implémentent des retries dans une boucle while True sans limiter le nombre de tentatives. Si le problème vient du site cible (par exemple, il est complètement tombé) — le script continuera à essayer indéfiniment.

Solution : Limitez toujours le nombre de retries (3-10 tentatives maximum) et journalisez les requêtes échouées pour une analyse ultérieure.

Erreur 5 : Ignorer le type d'erreur

Toutes les erreurs ne doivent pas être répétées. Par exemple, si vous obtenez un 404 (page non trouvée) — la répétition est inutile, la page n'existe tout simplement pas. En revanche, un 503 (service temporairement indisponible) — il est judicieux de répéter après quelques secondes.

Solution : Analysez le type d'erreur et ne répétez que les problèmes temporaires (timeout, erreur de connexion, 429, 500, 502, 503, 504).

Erreur 6 : Absence de journalisation

Sans journaux, vous ne comprendrez pas pourquoi les requêtes échouent : est-ce un problème de proxy, de timeouts ou du site cible ?

Solution : Journalisez chaque erreur en indiquant : quel proxy a été utilisé, quel était le timeout, combien de tentatives ont été effectuées, quelle erreur s'est produite. Cela aidera à optimiser les réglages.

Conclusion

La configuration correcte des timeouts et de la logique de retry n'est pas simplement un détail technique, mais un facteur crucial pour la stabilité et l'efficacité du travail avec des proxies. Sans timeouts, vos scripts se bloqueront sur des proxies morts, perdant du temps. Sans logique de retry, vous perdrez des données lors d'erreurs temporaires. Et sans rotation des proxies lors des tentatives de répétition — vous obtiendrez un faible taux de succès même avec un bon pool d'IP.

Principales conclusions de ce guide :

• Toujours définir explicitement le timeout : connect timeout 5-10 secondes, read timeout 10-30 secondes selon la tâche
• Utilisez la logique de retry avec une limite de 3-5 tentatives et un délai exponentiel
• Faites tourner les proxies à chaque tentative de répétition — c'est la clé d'un taux de succès élevé
• Répétez uniquement les erreurs temporaires (timeout, 429, 500, 502, 503, 504), ne gaspillez pas de tentatives sur des erreurs permanentes (404, 403)
• Journalisez toutes les erreurs pour analyse et optimisation des réglages
• Prenez en compte le type de proxy : les mobiles sont plus lents que les data centers, augmentez les timeouts en conséquence

Si vous travaillez avec le parsing de marketplaces (Wildberries, Ozon, Avito), l'automatisation des réseaux sociaux ou des plateformes publicitaires, la stabilité des proxies influence directement votre résultat. Utilisez des proxies de qualité avec un uptime élevé et configurez correctement les timeouts et les retries — cela vous fera économiser des heures de temps et des milliers de requêtes perdues.

Pour des tâches nécessitant une stabilité maximale et un minimum d'erreurs de timeout, nous vous recommandons d'essayer des proxies de data centers — ils offrent une vitesse de réponse élevée et une connexion stable, ce qui est particulièrement important lors de parsing massif et d'automatisation.