Proxies résidentiels

Erreurs courantes des proxies résidentiels et comment les corriger

Chaque échec de proxy correspond à l'un des huit schémas, et le code de statut indique généralement lequel. Commencez ici, identifiez le symptôme, puis passez à la solution.

Matt Brown

Matt Brown

31 août 2026 · 9 min de lecture

Les problèmes de proxy semblent variés quand on est en plein dedans, mais ils sont en réalité assez répétitifs. Presque tout ce qui peut mal tourner se range dans huit schémas, et dans la plupart des cas, la réponse elle-même vous indique lequel vous observez. Ceci est l’index : trouvez votre symptôme, obtenez la cause probable et la correction immédiate, puis suivez le lien quand vous avez besoin de la version longue.

Le tableau rapide

SymptômeSignifie généralementPremière chose à faire
407 Proxy Authentication RequiredIdentifiants incorrects, ou un flag mal formé dans le nom d’utilisateurTester le nom d’utilisateur nu, sans flags
502 Bad GatewayAucune adresse ne correspondait à votre filtre à ce moment-làÉlargir le filtre
509 Bandwidth Limit ExceededAllocation du plan épuisée, dépassement désactivéVérifier le portefeuille et le plan
Connexion refusée ou blocageVous n’avez jamais atteint la gatewaync -vz p.shifter.io 443
TimeoutsLenteur de la cible, filtre trop strict, ou votre propre concurrenceSéparer le temps de connexion du temps de lecture
403 ou une page de challengeLa cible a rejeté l’identité, pas le proxyRetirer la session, vérifier les headers
200 avec un contenu erroné ou videUn blocage discret, ou la mauvaise localeValider le corps, vérifier les signaux géo
Même IP à chaque requêtePresque toujours une réutilisation de connexion dans votre clientTester avec des processus séparés

407 : authentification rejetée

La gateway a refusé vos identifiants, ce qui signifie que votre trafic l’a bien atteinte et que la connectivité est correcte.

Trois causes expliquent presque tous les cas : une faute de frappe dans les identifiants, un flag mal formé dans le nom d’utilisateur étendu, ou un mot de passe qui a été renouvelé dans le panel alors qu’une ancienne copie est encore déployée quelque part. La deuxième est la moins évidente, car une valeur non reconnue comme country-uk au lieu de country-gb rend l’ensemble du nom d’utilisateur impossible à analyser, ce qui est donc signalé comme un échec d’authentification plutôt qu’une erreur de ciblage.

Le diagnostic est toujours le même : retirer tous les flags et tester d’abord le nom d’utilisateur nu. Si cela fonctionne, le problème vient des flags et vous les rajoutez un par un. Si cela échoue, recopiez le mot de passe depuis le panel. Détails complets dans corriger les erreurs 407 et d’identifiants.

Ne réessayez jamais après un 407. C’est définitif, et une boucle de nouvelles tentatives contre cette erreur consomme de la bande passante tout en ressemblant, de l’extérieur, à du credential stuffing.

502 : rien ne correspondait à votre filtre

Vos identifiants ont été acceptés, puis aucune adresse n’était disponible pour la combinaison demandée. C’est un problème de ciblage, pas une panne.

Cela apparaît généralement quand un filtre est très étroit, une petite ville, un ASN spécifique, ou une combinaison des deux, et c’est plus probable aux heures où le pool local est réduit, puisque la disponibilité suit l’activité humaine. Élargissez le filtre, passez de la ville à la région ou au pays, ou supprimez la correspondance stricte pour que la gateway se rabatte sur un pool plus large. Si vous vous appuyez délibérément sur une correspondance stricte, cette erreur montre que le système fonctionne comme prévu. Contexte dans disponibilité par pays.

509 : plus de bande passante

L’allocation du plan est épuisée et le dépassement n’est pas activé, donc les requêtes s’arrêtent. Rien ne cloche du côté de la connexion ou de la configuration. Ajoutez des fonds pour activer le dépassement, ou attendez la réinitialisation du cycle, et si cela se produit régulièrement, le plan est sous-dimensionné, une question de prévision traitée dans estimer la bande passante mensuelle.

Connexion refusée, ou une requête qui bloque indéfiniment

Vous ne parlez pas du tout à la gateway. Deux causes habituelles : vous pointez vers un hôte historique basé sur un port plutôt que vers p.shifter.io:443, ou votre propre réseau bloque le trafic sortant sur ce port.

Testez la connectivité brute avant de faire des suppositions sur le proxy :

nc -vz p.shifter.io 443

Si cela échoue, c’est un problème de sortie réseau (egress) ou de pare-feu de votre côté. Si cela réussit mais que les requêtes échouent encore, vous entrez dans le chemin d’authentification évoqué plus haut.

Timeouts

La catégorie la plus ambiguë, car plusieurs problèmes différents produisent le même symptôme. L’étape la plus utile est de séparer le temps de connexion du temps total, car ils pointent dans des directions opposées :

curl -o /dev/null -s -w "connect: %{time_connect}s  total: %{time_total}s\n" \
  -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://example.com

Une connexion lente pointe vers le chemin du proxy ou un filtre trop strict rendant la sélection d’adresse lente. Une connexion rapide avec un total lent indique que la cible est lente, ce qui n’est pas quelque chose qu’un changement de proxy résout. Vérifiez aussi si vos timeouts sont simplement calibrés pour une latence datacenter, car les connexions résidentielles sont légitimement plus lentes et un timeout de deux secondes échouera constamment pour des raisons qui ne sont pas des erreurs. Le diagnostic complet se trouve dans pourquoi les requêtes expirent, et les options de réglage dans réduire la latence.

403, captchas et pages de challenge

Ceux-ci viennent de la cible, pas du proxy, ce qui signifie que l’authentification et la connectivité ont toutes deux fonctionné. La cible a examiné la requête et l’a refusée.

La réponse immédiate est de retirer cette session et d’en prendre une nouvelle plutôt que de réessayer sur la même identité. La réponse durable est de comprendre pourquoi, et l’ordre de probabilité est d’abord le rythme, puis la forme de la requête, puis le comportement, puis la qualité de l’adresse. Ralentir corrige plus de cas que n’importe quoi d’autre, selon limitation de débit et throttling, et si le rythme est défendable, le suspect suivant est les headers et le user agent qui se contredisent. Le plan de récupération se trouve dans que faire quand vos IP sont bannies.

Un 200 qui n’est pas ce que vous vouliez

L’échec le plus coûteux, car rien ne semble anormal. Une page de challenge, un ensemble de résultats vide, une liste tronquée, ou une page régionale générique peuvent tous arriver avec un statut de succès, et un pipeline qui compte les codes de statut les enregistrera comme des données.

Si le contenu est erroné plutôt qu’absent, suspectez la géographie avant tout : un header Accept-Language qui contredit votre pays de sortie, ou une fuite DNS résolvant les noms d’hôte depuis votre emplacement plutôt que celui du proxy, produisent tous deux un contenu plausible mais pour le mauvais marché. Voir faire correspondre géo, fuseau horaire et locale et prévenir les fuites DNS.

Si le contenu est un challenge ou un stub, traitez-le comme un blocage, selon détecter un contenu bloqué ou factice. Dans tous les cas, la leçon est la même : validez le corps avant de compter une réponse comme un succès, sinon aucune de vos surveillances n’a de sens.

La même adresse à chaque requête

La rotation semble cassée et ne l’est presque jamais. La cause habituelle est que votre client HTTP réutilise une seule connexion, et l’adresse de sortie est choisie à l’établissement de la connexion plutôt que par requête envoyée à travers elle.

Testez d’abord avec des processus séparés :

for i in 1 2 3; do
  curl -s -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/json | head -c 60; echo
done

Si cela tourne mais que votre application ne le fait pas, la cause est le pooling de connexions dans votre client. Si rien ne tourne, vérifiez la présence d’un flag sid dans le nom d’utilisateur demandant une session persistante, et confirmez que l’adresse que vous voyez n’est pas simplement la vôtre, ce qui signifierait que le proxy n’est pas du tout appliqué. Causes complètes dans l’IP ne tourne pas.

Erreurs TLS et de certificat

Moins fréquentes, et généralement environnementales. Une bibliothèque TLS obsolète rejetant la suite de chiffrement de la gateway, ou un middlebox d’entreprise brisant la chaîne de confiance. Mettez d’abord à jour la bibliothèque client. Désactiver la vérification du certificat fera disparaître l’erreur et ne doit servir qu’à confirmer le diagnostic, jamais dans quoi que ce soit que vous mettez en production.

Un ordre général d’opérations

Quand quelque chose casse et que vous ne savez pas par où commencer : confirmez la connectivité brute, puis testez les identifiants nus sans flags, puis rajoutez les flags un par un, puis vérifiez si la réponse est véritablement ce que vous avez demandé plutôt que de faire confiance au code de statut. Cette séquence isole la couche en quelques minutes, et c’est la même séquence que le symptôme soit un code d’erreur ou des données qui semblent subtilement fausses.

Pour tout ce qui est continu plutôt qu’aigu, l’instrumentation qui détecte ces problèmes avant que vous ne les remarquiez manuellement se trouve dans surveiller la santé du proxy à grande échelle.

L’essentiel à retenir

Huit schémas couvrent presque tout. Le 407 est un problème d’identifiants ou de flag mal formé et ne vaut jamais la peine d’être réessayé. Le 502 est un filtre vide plutôt qu’une panne. Le 509 est une question de bande passante. Une connexion refusée signifie que vous n’avez jamais atteint la gateway. Les timeouts nécessitent de séparer le temps de connexion du temps total avant toute autre chose. Un 403 ou un challenge est la cible qui vous refuse, donc changez d’identité puis comprenez pourquoi. Un 200 avec un contenu erroné est le cas dangereux, et c’est pourquoi la validation du corps n’est pas optionnelle. Et la même adresse à chaque requête est presque toujours une réutilisation de connexion dans votre propre client. Travaillez de la connectivité vers l’extérieur, et vérifiez ce qui est revenu plutôt que ce que prétend le code de statut.

La gateway elle-même est documentée dans comment se connecter, le vocabulaire dans le glossaire, et le produit est les proxies résidentiels avec une tarification au GB.

Prêt à commencer ?

Essayez les proxies résidentiels de Shifter, 205M+ IPs, 195+ pays, à partir de $0.75/GB.

Commencer