Comment résoudre les codes d'erreur de statut proxyLire les 4xx, 5xx et les connexions abandonnées

Une erreur de proxy est rarement un mystère une fois que vous la lisez comme une phrase. Le code de statut vous dit qui a échoué (votre client, le proxy ou la cible) et le corps ou les en-têtes vous disent généralement pourquoi. Le problème, c'est que le même code peut signifier deux choses différentes selon qu'il provient du saut proxy ou du serveur d'origine, et cette ambiguïté est ce qui fait tourner les gens en rond. Un 403 de la cible est un blocage ; un 407 du proxy est un problème d'authentification ; un 502 peut venir des deux côtés. Identifiez quelle couche a parlé et le correctif est presque toujours évident.

Voici une référence que vous pouvez garder ouverte pendant le débogage. Elle fait correspondre les codes de statut que vous rencontrez réellement lors du scraping via un serveur proxy à ce qu'ils signifient dans un contexte proxy et comment les résoudre, avec les cas spécifiques au proxy (authentification, limites de débit, défaillances de passerelle, blocages géographiques) explicitement identifiés plutôt que résumés comme du HTTP générique. Parcourez le tableau, sautez à votre code, appliquez le correctif.

Codes d'erreur proxy en un coup d'œil

Commencez ici. Le tableau couvre les codes qui stoppent réellement un scrape ; les sections ci-dessous approfondissent ceux qui ont des pièges spécifiques au proxy.

Une règle de lecture avant les détails : demandez quel saut a produit le code. Un 4xx qui mentionne « proxy » (407) est le proxy qui parle ; presque tous les autres 4xx sont la cible qui parle via un proxy fonctionnel. Un 5xx qui arrive instantanément est généralement le proxy qui échoue à atteindre l'amont ; un 5xx après une longue pause est généralement l'origine qui expire. Cette seule distinction vous oriente vers le bon correctif plus vite que mémoriser chaque code.

4xx : la requête a atteint la cible et a été refusée

Ces codes signifient qu'une requête est passée mais a été rejetée. À une exception près (407), le proxy a fait son travail et le verdict vient de l'origine.

403 Forbidden : vous avez été bloqué, pas banni définitivement

C'est le code que les scrapers voient le plus. La cible a accepté la connexion, examiné la requête et décidé qu'elle ne voulait pas y répondre. Dans un contexte proxy, cela signifie presque toujours que l'IP de sortie a été signalée (une plage de datacenter connue, une adresse déjà limitée en débit) ou que l'empreinte de la requête semblait automatisée (en-têtes manquants ou par défaut, aucun User-Agent réaliste, un ordre d'en-têtes qu'aucun navigateur n'envoie).

Le correctif est en couches. D'abord, faites tourner vers une nouvelle IP de sortie et réessayez ; un seul blocage ne signifie pas que tout le pool est compromis. Si des IP propres obtiennent toujours un 403, le problème est la confiance, pas la chance : une cible durcie bloque les plages de datacenter d'emblée, donc passez aux adresses résidentielles. Voir proxies datacenter vs résidentiels pour savoir où se situe cette limite. Si la rotation et un niveau de confiance supérieur échouent tous les deux, le blocage est au niveau de l'empreinte, et vous avez besoin d'en-têtes réalistes et souvent d'une page rendue plutôt qu'une récupération brute. Le guide complet est dans comment scraper sans se faire bloquer.

407 Proxy Authentication Required : c'est le proxy qui demande, pas le site

Le 407 est le seul 4xx qui vient du saut proxy lui-même, et c'est le plus mal interprété. La cible n'a jamais vu votre requête ; le proxy a refusé de la transférer parce que vous ne vous êtes pas authentifié auprès du proxy. Deux choses le causent : des informations d'identification manquantes ou incorrectes, ou un proxy en liste blanche d'IP qui ne reconnaît pas l'adresse depuis laquelle vous appelez.

Envoyez les informations d'identification dans l'URL du proxy, ou mettez votre IP source en liste blanche dans le tableau de bord du fournisseur, selon le mode d'authentification que votre plan utilise. Avec curl, les informations d'identification vont dans l'argument -x, pas dans la requête vers la cible.

# 407 fix: authenticate TO the proxy in the -x URL.
# user:pass here are the proxy's credentials, not the site's.
curl -x "http://USER:[email protected]:8080" \
     "https://httpbin.org/ip"

# IP-whitelist plans take no credentials; the proxy
# checks your source IP instead. Confirm it is allowed.

Si vous vous authentifiez correctement sur toutes les autres requêtes et qu'une soudainement renvoie 407, vérifiez si votre IP sortante a changé (un nouveau conteneur, un VPN, un runner CI) et remettez-la en liste blanche. Plus de schémas curl et proxy dans comment utiliser curl avec un proxy.

401 Unauthorized : la cible veut des informations d'identification

Facile à confondre avec 407, mais c'est la couche opposée. Un 401 signifie que le proxy a transféré votre requête et que la cible a répondu que la ressource nécessite une authentification que vous n'avez pas fournie. Le proxy fonctionne correctement. Corrigez-le en envoyant les propres informations d'identification du site, la clé API ou le jeton de session, exactement comme vous le feriez sans proxy. Si vous voyez 401 et 407 en alternance, vous avez deux problèmes d'authentification distincts empilés : un vers le proxy, un vers l'origine.

400 Bad Request : le message lui-même est cassé

Un 400 signifie que la requête était malformée avant que quiconque puisse évaluer ses mérites : syntaxe invalide, mauvais encodage d'URL, en-têtes dupliqués ou trop volumineux, ou corps qui ne correspond pas à son type de contenu déclaré. Via un proxy, méfiez-vous du double encodage quand vous passez une URL cible comme paramètre de requête à une API, et de l'injection d'en-têtes par concaténation de chaînes. Journalisez les octets exacts que vous envoyez et relisez-les ; le défaut est presque toujours dans votre générateur de requêtes, pas dans le réseau.

429 Too Many Requests : vous avez déclenché une limite de débit

Vous avez envoyé plus de requêtes que la cible (ou votre plan proxy) n'en autorise dans une fenêtre. Le correctif honnête est de ralentir et d'espacer : ajoutez un délai entre les requêtes, limitez la concurrence et faites tourner les IP de sortie pour que la charge se répartisse sur plusieurs adresses plutôt que sur une seule. Respectez l'en-tête Retry-After si la réponse l'inclut plutôt que de réessayer aveuglément.

La rotation des IP est le correctif structurel ici, car une limite de débit comptée par IP se réinitialise quand l'IP change. Voir comment utiliser les proxies rotatifs pour la mécanique, et les proxies résidentiels rotatifs quand la cible prend aussi en compte l'empreinte de confiance de l'IP.

451 Unavailable For Legal Reasons : blocage géographique ou de politique

Un 451 signifie que le contenu est retenu pour des raisons légales ou régionales plutôt qu'une défaillance technique. Dans un contexte proxy, il s'agit généralement d'un géoblocage : l'IP de sortie est dans une région que la cible ne dessert pas. Le correctif est de sortir depuis un pays autorisé. Choisissez un proxy avec du ciblage géographique et confirmez qu'il couvre réellement la région dont vous avez besoin, puis vérifiez l'emplacement de sortie avec un service d'écho avant de supposer la couverture.

5xx : la défaillance est en amont, mais dans quel saut ?

Ces codes viennent d'un serveur, pas de votre requête, mais via un proxy « le serveur » est ambigu : il peut s'agir du proxy qui échoue à atteindre l'origine, ou de l'origine qui échoue par elle-même. Le timing les distingue.

502 Bad Gateway : le proxy a reçu de mauvaises données de l'amont

Un 502 signifie qu'une passerelle (ici, votre proxy) a reçu une réponse invalide ou vide du serveur qu'elle a essayé d'atteindre. Il arrive généralement rapidement, parce que le proxy a abandonné vite. Les causes se divisent en deux : le proxy lui-même est défaillant ou mal configuré, ou la sortie amont qu'il a choisie est morte. Réessayez d'abord, car les 502 sont souvent transitoires ; si les tentatives continuent d'échouer, passez à une IP de sortie différente et confirmez que l'endpoint proxy est bien actif en envoyant une requête vers un service d'écho connu via lui. Si celui-là aussi donne 502, le problème est la couche proxy, pas la cible.

503 Service Unavailable : surchargé ou en panne

Un 503 signifie que le serveur est temporairement incapable de traiter la requête : surchargé, en maintenance ou en train d'alléger la charge. Depuis un proxy, il peut s'agir de la cible qui écarte spécifiquement votre trafic (un blocage doux habillé en 503) ou qui est réellement en panne pour tout le monde. Reculez et réessayez avec jitter ; si une seule IP de sortie obtient 503 tandis que les autres réussissent, cette IP est limitée, alors faites tourner. Si chaque sortie obtient 503 au même moment, la cible est en panne et attendre est la seule option.

504 Gateway Timeout : quelqu'un dans la chaîne a manqué de temps

Un 504 est un délai d'attente sur un saut de passerelle : le proxy a attendu l'origine et l'origine n'a jamais terminé, ou le proxy lui-même a été trop lent à répondre. Contrairement au 502, il arrive après une longue pause. Augmentez le délai de votre client pour les pages genuinement lentes, réessayez (les délais sont souvent transitoires), et changez de sortie si une route est systématiquement lente. Si les pages nécessitent un navigateur pour terminer le rendu, une récupération brute peut sembler expirer alors que le vrai problème est une exécution JavaScript incomplète, que c'est une couche de rendu qui résout plutôt qu'un délai plus long.

Défaillances au niveau de la connexion : rien n'a obtenu de code HTTP

Certaines défaillances n'atteignent jamais le point d'un statut HTTP. Ce sont des erreurs de socket, et elles signifient presque toujours que le proxy était mal configuré plutôt que la requête rejetée.

Connexion refusée signifie que rien n'était en écoute à l'hôte et au port que vous avez composé : mauvais port, mauvais hôte, proxy non démarré, ou incompatibilité de schéma (envoi de HTTP vers un endpoint exclusivement HTTPS). Vérifiez exactement le host:port et le protocole que votre fournisseur vous a donnés.

Connexion réinitialisée / délai d'attente signifie que le socket s'est ouvert mais a été abandonné ou n'a jamais répondu : une IP de sortie morte, un pare-feu agressif, ou la cible qui abandonne silencieusement le trafic signalé. Réessayez avec une nouvelle sortie ; si les réinitialisations se concentrent sur une IP, elle est compromise. Erreurs TLS / certificat via un proxy signifient généralement que quelque chose termine TLS au milieu. Utilisez le tunneling CONNECT pour HTTPS pour que le proxy relaie les octets chiffrés sans les inspecter ; les détails dans proxies HTTP vs HTTPS.

Faire disparaître des classes entières d'erreurs

Remarquez le schéma dans le tableau : 403, 429, 502, 503 et la plupart des réinitialisations de connexion partagent tous un seul correctif : faites tourner vers une sortie propre et réessayez. Le construire vous-même signifie un pool sain, une politique de rotation, un recul avec jitter et une logique de réessai par code. Un endpoint rotatif géré le fait pour vous, ce qui explique pourquoi plusieurs classes d'erreurs cessent simplement d'apparaître une fois que la rotation et les réessais sont côté serveur.

Une boucle de réessai qui lit le code

Quel que soit le proxy que vous utilisez, votre client doit agir sur le code de statut au lieu de traiter chaque défaillance de la même façon. La version minimale : réessayez les classes transitoires avec recul, faites tourner sur un blocage par IP, et arrêtez sur une vraie erreur client que vous ne pouvez pas corriger en réessayant.

import time, requests

RETRY = {429, 502, 503, 504}  # transient: back off and retry
ROTATE = {403, 429}        # per-IP: try a fresh exit

def fetch(url, get_proxy, tries=5):
    for n in range(tries):
        proxy = get_proxy()  # new exit IP each call
        r = requests.get(url, proxies=proxy, timeout=30)
        if r.status_code == 200:
            return r
        if r.status_code not in RETRY and r.status_code not in ROTATE:
            r.raise_for_status()  # 400/401/451: stop, fix the request
        wait = int(r.headers.get("Retry-After", 2 ** n))
        time.sleep(wait)
    r.raise_for_status()

La forme importe plus que le langage : classifiez le code, reculez sur les défaillances transitoires, faites tourner sur les blocages par IP, et échouez rapidement sur les erreurs que les réessais ne peuvent pas corriger. Un endpoint géré intègre en lui-même la moitié rotation-et-réessai, ne laissant votre boucle gérer que les vraies erreurs client.

Foire aux questions

Quelle est la différence entre une erreur proxy 403 et 407 ?

Un 407 vient du proxy lui-même : il a refusé de transférer votre requête parce que vous ne vous êtes pas authentifié auprès de lui, donc la cible n'a jamais vu la requête. Un 403 vient de la cible après que le proxy a transféré avec succès la requête : le site a examiné votre IP ou empreinte et a refusé de la servir. Corrigez 407 avec des informations d'identification proxy ou une mise en liste blanche d'IP ; corrigez 403 en faisant tourner l'IP de sortie ou en augmentant le niveau de confiance de votre proxy.

Comment corriger une erreur 429 Too Many Requests lors du scraping ?

Ralentissez et espacez. Ajoutez un délai entre les requêtes, limitez la concurrence et respectez l'en-tête Retry-After s'il est présent au lieu de réessayer immédiatement. Comme les limites de débit sont généralement comptées par IP, la rotation de votre IP de sortie est le correctif structurel : chaque nouvelle adresse commence avec un quota frais. Combiner l'espacement et la rotation efface la grande majorité des 429.

Qu'est-ce qui cause un 502 Bad Gateway via un proxy ?

Un 502 signifie que votre proxy (agissant comme passerelle) a reçu une réponse invalide ou vide du serveur qu'il a essayé d'atteindre. Il arrive généralement rapidement. La cause est soit un proxy défaillant, soit une IP de sortie amont morte. Réessayez d'abord, car beaucoup de 502 sont transitoires ; s'ils persistent, passez à une sortie différente et confirmez que l'endpoint proxy lui-même fonctionne en envoyant une requête vers un service d'écho connu via lui.

Pourquoi est-ce que j'obtiens une connexion refusée au lieu d'un code d'erreur HTTP ?

Connexion refusée est une défaillance au niveau du socket qui se produit avant qu'une réponse HTTP puisse exister : rien n'était en écoute à l'hôte et au port que vous avez composé. Vérifiez que l'hôte, le port et le schéma du proxy correspondent exactement à ce que votre fournisseur vous a donné, que le processus proxy est en cours d'exécution, et que vous n'envoyez pas du HTTP simple vers un endpoint exclusivement HTTPS. C'est une erreur de configuration, pas un rejet de votre requête.

Les proxies rotatifs peuvent-ils éliminer les codes d'erreur proxy ?

La rotation supprime les classes d'erreurs par IP, principalement les blocages 403 et les limites de débit 429, parce que les deux se réinitialisent quand l'IP de sortie change, et elle aide avec les 5xx transitoires en réessayant sur une nouvelle route. Elle ne corrige pas les codes qui proviennent de votre propre requête, comme 400 ou 401, ni les blocages géographiques légaux comme 451. Associez la rotation à une construction correcte des requêtes et au ciblage géographique pour couvrir le reste.

Dois-je réessayer automatiquement chaque erreur proxy ?

Non. Réessayez les classes transitoires (429, 502, 503, 504) avec un recul exponentiel et jitter, et faites tourner l'IP de sortie sur les blocages par IP (403, 429). Ne réessayez pas aveuglément les erreurs client que vous avez causées (400, 401, 451), car réessayer avec la même requête échouera à nouveau et peut prolonger un délai de refroidissement de limite de débit. Classifiez d'abord le code, puis choisissez réessayer, faire tourner ou arrêter.

HR

Hassan Rehan

Ingénieur logiciel · Crawlbase

Ingénieur logiciel chez Crawlbase, il rédige des guides pratiques sur les proxys rotatifs, le scraping et les détails concrets de l'intégration de proxys dans du vrai code.