Un script subit une coupure de connexion toutes les cent requêtes via une IP de datacenter, et toutes les dix requêtes via un canal résidentiel ou mobile. Ce n'est pas un défaut du proxy, mais une propriété de l'environnement : une coupure sur une connexion domestique ou cellulaire est un phénomène normal, que le client doit surmonter seul, sans intervention humaine. Voyons d'où vient cet écart de fréquence, quels timeouts et quelles pauses entre les tentatives définir, quelles erreurs il vaut la peine de retenter ou non, et comment les nouvelles tentatives influent sur la consommation de trafic.

Pourquoi un canal résidentiel ou mobile se coupe plus souvent qu'un canal serveur

Une IP de datacenter repose sur une liaison dédiée de l'opérateur, avec redondance et une gigue quasi nulle : une coupure y est rare et correspond généralement à une panne système. Une adresse résidentielle correspond à une vraie connexion domestique : le routeur redémarre, le fournisseur d'accès bascule l'abonné d'un nœud à un autre, le bail DHCP se renouvelle, l'appareil se met en veille pendant une minute. Le canal mobile y ajoute les transferts intercellulaires entre stations de base, les changements de réseau et les pertes temporaires de signal : tout cela se produit sur l'appareil réel d'un abonné réel, et non sur un port qui vous est réservé. Le NAT de l'opérateur mobile, qui permet à des centaines d'abonnés de partager une même adresse, est aussi la raison pour laquelle une telle IP est presque impossible à bannir : pour en savoir plus, consultez l'article pourquoi les proxys mobiles sont difficiles à bannir. La contrepartie de cette résistance au bannissement est que le canal lui-même est physiquement moins stable qu'un canal serveur.

Valeurs raisonnables pour les timeouts de connexion et de lecture

Le timeout de connexion (connect timeout) et le timeout de lecture (read timeout) sont deux choses différentes, qu'il ne faut pas confondre. Le connect timeout limite le temps accordé à l'établissement de la session : 3 à 5 secondes suffisent pour un canal de datacenter, 8 à 15 pour un canal résidentiel ou mobile, car le paquet traverse davantage de nœuds intermédiaires en passant par un appareil réel. Le read timeout limite l'attente de la réponse une fois la connexion établie ; le repère est le temps de réponse attendu du serveur cible, multiplié par 2 ou 3 pour garder une marge, soit en général 15 à 30 secondes pour des requêtes ordinaires, et davantage pour les opérations lourdes. Un timeout trop court sur un canal résidentiel transforme un délai réseau normal en faux échec ; un timeout trop long maintient la connexion ouverte sans utilité et consomme du trafic pour rien.

Pause exponentielle entre les tentatives

Relancer une requête immédiatement après une coupure est une mauvaise idée : si la cause est une surcharge du nœud ou une perte temporaire de signal, la nouvelle tentative immédiate retombera dans le même état. Le backoff exponentiel allonge la pause à chaque tentative, par exemple 1, 2, 4, 8 secondes, et laisse au canal le temps de se rétablir. Il est conseillé d'ajouter à la pause une gigue aléatoire de 20 à 30 % de la valeur calculée : sans elle, après une panne commune, les threads parallèles d'un même script relancent leurs requêtes en même temps et créent leur propre pic de charge. Il est raisonnable de limiter le nombre de tentatives à trois ou quatre : au-delà, la probabilité de succès n'augmente presque plus, alors que le temps et le trafic dépensés croissent de façon linéaire.

Quelles erreurs retenter, et lesquelles non

Il faut retenter ce qui ressemble à une défaillance temporaire : coupure de connexion, timeout, erreurs 502/503/504 et exceptions réseau sans réponse du serveur. Il ne faut pas retenter ce qu'une nouvelle tentative ne changera pas : l'erreur 400 avec un corps de requête incorrect, les erreurs 401/403 en tant que problème d'autorisation, l'erreur 404 en tant que ressource absente. Le code 429 mérite un traitement à part : ce n'est pas une panne, mais une demande explicite de ralentir ; la requête doit alors être renvoyée après la pause que le serveur indique généralement dans un en-tête de la réponse, et non selon le schéma de backoff habituel. Retenter aveuglément toutes les erreurs sans distinction est la cause typique des scripts qui se cognent pendant des heures contre un mur au lieu de s'arrêter et de signaler le problème.

Comment distinguer une coupure de canal d'un blocage par le site

Une coupure de canal se traduit par l'absence de réponse : timeout, réinitialisation de la connexion, erreur au niveau TCP ou TLS. Un blocage, lui, est une réponse, simplement indésirable : code 403, captcha à la place du contenu, redirection vers une page de vérification, HTML de taille normale à la place des données attendues. Le premier cas se règle par une nouvelle tentative, le second non : une nouvelle requête depuis la même adresse reçoit presque toujours la même réponse de blocage, et le changement d'adresse par rotation est une autre question, traitée dans l'article sur la configuration de la rotation d'IP via l'API. Chaque nouvelle tentative constitue une session distincte du canal résidentiel ou mobile, et ces canaux sont facturés au trafic : un retry agressif sur une adresse bloquée ne résout pas le problème, il consomme simplement des gigaoctets pour obtenir le même refus. La limite du nombre de tentatives et l'analyse du code de réponse relèvent donc non seulement de la fiabilité, mais aussi du budget.

Questions fréquentes

Combien de fois faut-il retenter une requête avant d'abandonner ?

Pour la plupart des tâches, trois à quatre tentatives avec une pause qui croît de façon exponentielle suffisent. Si elles échouent toutes, la probabilité de succès d'une cinquième tentative sur la même adresse est faible, tandis que la consommation de trafic continue d'augmenter : il vaut mieux changer d'adresse par rotation ou renvoyer l'erreur au code appelant.

Faut-il des réglages de timeout différents pour un canal de datacenter et un canal résidentiel ?

Oui. Le canal de datacenter offre une latence faible et stable, et un timeout court y est justifié. Les canaux résidentiels et mobiles passent par le matériel réel d'un abonné, c'est pourquoi leurs timeouts doivent être nettement plus larges : sinon, un délai réseau normal sera constamment pris pour une défaillance.

Peut-on utiliser le même algorithme de nouvelles tentatives pour toutes les erreurs ?

Non. Les défaillances réseau et les réponses 5xx sont de bons candidats à une nouvelle tentative différée. Retenter les erreurs d'autorisation ou de requête incorrecte n'a aucun sens. Le code 429 exige une pause conforme aux instructions du serveur, et les signes de blocage (captcha, redirection, code 403) imposent de changer d'adresse plutôt que de retenter depuis la même IP.

Les canaux résidentiels et mobiles adaptés aux tâches avec nouvelles tentatives se trouvent dans la section proxys : vous pouvez aussi y estimer la consommation de trafic pour un scénario précis et choisir le canal offrant le bon équilibre entre stabilité et prix, après avoir comparé les proxys mobiles et résidentiels.