ProxyError de Requests contre ProxyError d'urllib3
Interceptez l'exception de la bibliothèque HTTP réellement utilisée et remontez la chaîne des causes : le nom de classe ne suffit pas.
requests.exceptions.ProxyError et urllib3.exceptions.ProxyError sont des classes d'exception différentes. Un nom court commun ne fait pas qu'une clause except attrape les deux.
Pour un appel Requests, commencez par l'API publique des exceptions de Requests. Son adaptateur de transport traduit normalement les échecs de bas niveau en exceptions exposées par Requests. Les anciennes versions avaient des bugs d'enveloppement précis, conservez donc la version de la bibliothèque avec une trace inattendue.
Lors de l'investigation, examinez le module, la classe et la cause chaînée de l'exception. Un MaxRetryError imbriqué ou un échec de connexion peut conserver des preuves utiles sur l'étape de proxy précédente.
Évitez d'importer dans une application moderne un ancien chemin embarqué issu d'un contournement historique. Interceptez l'exception publique adaptée à l'appel en cours, conservez la cause pour le diagnostic et décidez séparément le comportement de réessai. Attraper chaque Exception et continuer indéfiniment ne fait que masquer la discordance d'origine.