Pour un petit diagnostic de proxy urllib3, utilisez ProxyManager avec les reprises désactivées. Vous obtenez ainsi le résultat du premier essai, sans attendre plusieurs tentatives sur une entrée qui ne fonctionne plus. Dans un projet géré avec uv :

uv add urllib3

Remplacez le point de connexion de documentation par un proxy HTTP de votre service ou de la liste de proxys HTTP et exécutez la requête via ce gestionnaire :

import urllib3

proxy = urllib3.ProxyManager(
    "http://203.0.113.10:8080",
    timeout=urllib3.Timeout(connect=5, read=10),
    retries=False,
)

try:
    response = proxy.request("GET", "https://example.com/")
    print(response.status)
    print(response.data.decode("utf-8", errors="replace")[:200])
finally:
    proxy.clear()

Lisez d’abord response.status, puis examinez response.data. Ce sont les champs d’urllib3 ; les champs status_code et text de Requests ne les remplacent pas. Un refus du site peut arriver via un proxy fonctionnel. Une exception avant toute réponse indique au contraire l’impossibilité de terminer la requête.

retries=False est un choix de diagnostic, pas une politique de reprise en production. Les réglages de connexion de 5 secondes et de lecture de 10 secondes bornent chacun leur phase ; ils ne constituent pas une échéance totale garantie de 15 secondes. Le DNS et la progression de la réponse peuvent influer sur l’attente totale.

L’exemple précharge le corps et vide les pools du gestionnaire à la fin. Pour des requêtes répétées via le même point, conservez ce gestionnaire jusqu’à la fin du travail afin de réutiliser ses connexions. Passer à preload_content=False change ce cycle de vie : l’appelant doit lire et libérer la réponse en flux.

Choisissez le gestionnaire correspondant au service à l’écoute. Un PoolManager ordinaire ne devient pas un gestionnaire de proxy parce qu’une URL est stockée ailleurs ; SOCKS utilise urllib3.contrib.socks.SOCKSProxyManager et ses dépendances optionnelles. Le code ci-dessus suit la voie HTTP de ProxyManager.

Articles similaires