Arrêter une boucle de rotation de proxies qui tourne sans fin
Donner à un pool de proxies Python un budget d'essais fini et distinguer les échecs de connexion des réponses de la destination.
Un pool de proxies peut transformer une simple panne en boucle active. Choisissez une adresse, échouez, choisissez-en une autre, échouez encore. Si chaque point de terminaison est injoignable parce que votre propre réseau est en panne, changer d'adresse ne corrige jamais la cause.
Donnez à l'opération un budget avant de choisir le premier proxy de votre pool ou de la liste de proxies gratuits : un nombre fini de tentatives, des attentes de connexion et de lecture bornées, et une échéance pour la tâche entière. Un timeout de Requests contrôle son comportement documenté de connexion ou de lecture ; il ne plafonne pas à lui seul une boucle qui continue à émettre de nouvelles requêtes.
Décider ce qui mérite une nouvelle tentative
- Une connexion de proxy refusée peut justifier d'essayer un autre point de terminaison.
- Une réponse de destination demande sa propre interprétation. Recevoir une erreur HTTP prouve qu'un chemin de requête s'est terminé.
- Un échec d'authentification du proxy appelle à vérifier le point de terminaison et le compte plutôt qu'à marteler les mêmes identifiants dans une liste grandissante.
Conservez l'exception ou le statut d'origine avec l'enregistrement de la tentative. Un message final contenant seulement « tous les proxies ont échoué » cache si les échecs avaient même la même cause.
Vérifier l'état de chaque proxy avant chaque requête réelle ajoute une requête et ne garantit toujours pas que la suivante réussira. Réutilisez les informations de santé récentes lorsqu'elles conviennent à la tâche, puis laissez l'opération réelle rapporter son propre résultat.
Une nouvelle tentative peut répéter le travail
Pour une récupération en lecture seule, passer à un autre proxy est généralement plus simple que de rejouer un envoi. Si une connexion tombe après l'envoi d'un achat ou d'un formulaire, la destination l'a peut-être déjà traité. Suivez le mécanisme d'idempotence du service et les règles de nouvelle tentative HTTP avant de rejouer le travail.
Une fois le budget épuisé, renvoyez un échec utile. Une tâche qui s'arrête avec des preuves est plus facile à réparer qu'une qui tourne silencieusement jusqu'à ce que quelqu'un le remarque.