Réponse rapide
Comment savoir pourquoi une requête via proxy a échoué ?
Commencez par déterminer qui a répondu : la passerelle proxy (407, échecs CONNECT, certains 502 et 504), le site web (401, 403, 429, la plupart des 503), ou votre propre client (erreurs TLS et timeout). Ensuite, associez le message exact à une page ci-dessous. Cette référence couvre 15 erreurs rencontrées par les scrapers avec des proxies résidentiels CrawlRelay ou tout proxy HTTP ou SOCKS5, avec le code pour résoudre chacune.
À quelle erreur ai-je affaire ?
Trouvez votre symptôme, puis ouvrez la page pour un diagnostic complet.
| Symptôme | Envoyé par | Recommencer ? | Page |
|---|---|---|---|
407, 'Échec de la connexion tunnel : 407' | Proxy | Non | 407 Proxy Authentication Required |
401 avec WWW-Authenticate | Site web | Non | 401 vs 407 |
403 page ou message de pare-feu | Site web | Une fois, puis arrêt | 403 Forbidden |
429, souvent avec Retry-After | Site web | Oui, plus tard | 429 Too Many Requests |
502, 'Échec du tunnel CONNECT, réponse 502' | Proxy ou CDN | Oui, nouveau point de sortie | 502 Bad Gateway |
503, page de maintenance ou défi | Site web ou CDN | Oui, avec temporisation | 503 Service Unavailable |
504 | Proxy ou CDN | Une ou deux fois | 504 Gateway Timeout |
net::ERR_TUNNEL_CONNECTION_FAILED | Navigateur (proxy a refusé CONNECT) | Après correction de la cause | ERR_TUNNEL_CONNECTION_FAILED |
net::ERR_PROXY_CONNECTION_FAILED | Navigateur (proxy inaccessible) | Non | ERR_PROXY_CONNECTION_FAILED |
ProxyError: Unable to connect to proxy | Client Python | Définit selon la cause | Impossible de se connecter au proxy |
[SSL: WRONG_VERSION_NUMBER] | Votre bibliothèque TLS | Non | SSL : WRONG_VERSION_NUMBER |
CERTIFICATE_VERIFY_FAILED | Votre bibliothèque TLS | Non | Échec de vérification du certificat |
ReadTimeout, 'Délai de lecture dépassé' | Votre client | Oui, nouveau point de sortie | Délai de lecture dépassé |
ECONNRESET, 'socket hang up', 'Connexion réinitialisée par le pair' | Réseau | Oui, requêtes sécurisées | Connexion réinitialisée |
| 'Dépendances manquantes pour le support SOCKS', erreur curl 97 | Client ou serveur SOCKS | Ça dépend | Erreurs SOCKS5 |
Toutes les erreurs par type
Codes d'état HTTP
- 401 Unauthorized vs 407
- 403 Forbidden
- 407 Proxy Authentication Required
- 429 Too Many Requests
- 502 Bad Gateway
- 503 Service Unavailable
- 504 Gateway Timeout
Erreurs du navigateur et du client
Erreurs de connexion et TLS
Quelles erreurs un scraper devrait-il retenter automatiquement ?
Retentez ce qui peut changer tout seul, et arrêtez-vous sur ce qui ne peut pas :
- Retentez avec une nouvelle connexion : 502, 504, réinitialisations de connexion et délais de lecture dépassés. Une nouvelle connexion obtient généralement une nouvelle sortie proxy résidentiel.
- Retentez plus tard, plus lentement : 429 et 503. Attendez
Retry-Afterou faites un backoff exponentiel avec jitter, et réduisez la concurrence sur cet hôte. - Retentez une fois, puis arrêtez : 403. Une seule relance avec une nouvelle IP éloigne une adresse flagguée d’une règle du site.
- Ne jamais retenter aveuglément : 407, 401, erreurs TLS et proxies inaccessibles. Ce sont des problèmes de configuration.
Le guide Python montre une politique de retry qui suit ces règles avec urllib3 Retry.
Comment enregistrer les erreurs pour faciliter le débogage ?
Enregistrez cinq champs pour chaque requête échouée : l’hôte de l’URL, le code de statut ou la classe d’exception, l’identifiant de session si présent, le temps jusqu’au premier octet, et les 200 premiers caractères du corps de la réponse. Le corps indique si une CDN, un pare-feu ou le proxy a généré la page d’erreur. Comptez les erreurs par hôte et par statut chaque minute : une hausse sur un seul hôte signifie que ce site a changé quelque chose ; une hausse sur tous les hôtes indique un problème dans votre configuration ou votre réseau.
Référence d’erreurs : questions
Comment savoir si une erreur vient du proxy ou du site web ?
Regardez où elle se produit. Les erreurs pendant l’étape CONNECT, indiquées par curl -v avant toute négociation TLS, viennent du proxy résidentiel : 407, ou 502/504 sur CONNECT. Les statuts arrivant après le handshake TLS, avec les en-têtes et le HTML du site, viennent du site web. Les erreurs client comme les timeouts et échecs TLS viennent de votre code ou réseau.
Les requêtes échouées sont-elles facturées ?
Le trafic est compté en octets passant par la passerelle, donc une réponse d’erreur qui n’a jamais atteint un site, comme un 407, génère presque aucun trafic. Une page de blocage d’un site est une réponse normale et a une taille comme n’importe quelle autre page. Réduisez-les en corrigeant vite les erreurs de configuration et en ralentissant sur 403 et 429.
Quel est le taux d’erreur normal pour un scraper utilisant des proxies résidentiels ?
Cela dépend des cibles. L’étude Proxyway 2026 a enregistré un taux de succès médian de 99,28 % sur les réseaux de proxies résidentiels, mais de 74,43 % sur des cibles réelles protégées comme Amazon, Google et Instagram. Mesurez vos cibles et suivez le taux dans le temps : un changement soudain est plus important que le chiffre absolu.