Erreurs courantes des proxies résidentiels et comment les corriger

Les problèmes de proxy semblent variés quand on est en plein dedans, alors qu’ils sont en réalité assez répétitifs. Presque tout ce qui peut mal tourner relève de neuf 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 plus longue.

Le tableau rapide

Symptôme	Signifie généralement	Première chose à faire	À réessayer ?
407 Proxy Authentication Required	Identifiants incorrects, ou un flag mal formé dans le nom d’utilisateur	Tester le nom d’utilisateur nu, sans flags	Jamais
502 Bad Gateway	Aucune adresse ne correspondait à votre filtre à ce moment-là	Élargir le filtre	Seulement après élargissement
509 Bandwidth Limit Exceeded	Allocation du plan épuisée, dépassement désactivé	Vérifier le portefeuille et le plan	Non
Connexion refusée ou blocage	Vous n’avez jamais atteint la gateway	nc -vz p.shifter.io 443	Non, régler d’abord la connectivité
Timeouts	Lenteur de la cible, filtre trop strict, ou votre propre concurrence	Séparer le temps de connexion du temps de lecture	Oui, avec un recul progressif
403 ou page de challenge	La cible a rejeté l’identité, pas le proxy	Retirer la session, vérifier les headers	Pas sur la même session
429 Too Many Requests	La cible limite votre fréquence de requêtes	Respecter Retry-After, puis ralentir	Oui, après avoir attendu
200 avec un contenu erroné ou vide	Un blocage discret, ou la mauvaise locale	Valider le corps, vérifier les signaux géo	Pas avant d’avoir corrigé la cause
Même IP à chaque requête	Presque toujours une réutilisation de connexion dans votre client	Tester avec des processus séparés	Non applicable

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.

429 : trop de requêtes

La cible vous limite en fréquence. Comme pour une 403, cela provient de la cible plutôt que de la gateway, donc vos identifiants et votre connexion sont corrects. Cela signifie que les requêtes arrivent plus vite que la cible n’en accepte d’un seul visiteur, d’une seule session ou d’un seul réseau.

Ralentissez plutôt que de réessayer immédiatement. Si la réponse porte un en-tête Retry-After, attendez au moins ce délai avant la prochaine requête vers cette cible. Sinon, reculez de manière exponentielle, réduisez la concurrence pour cette cible, et répartissez les requêtes sur plus de sessions plutôt que d’en pousser davantage sur une seule. Réessayer une 429 au même rythme transforme une limite temporaire en blocage. La méthode de cadencement se trouve dans le guide sur la limitation de débit lié dans la section 403 ci-dessus.

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 http://ip-info.com/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.

Dans un navigateur : ERR_PROXY_CONNECTION_FAILED et ERR_TUNNEL_CONNECTION_FAILED

Les navigateurs masquent souvent le code de statut du proxy derrière leurs propres noms d’erreur. Deux couvrent la plupart des cas.

• ERR_PROXY_CONNECTION_FAILED signifie que le navigateur n’a pas pu atteindre le proxy du tout. Traitez-le comme une connexion refusée ci-dessus : vérifiez que l’hôte est p.shifter.io et le port 443, puis vérifiez si votre réseau, pare-feu ou antivirus bloque la connexion.
• ERR_TUNNEL_CONNECTION_FAILED signifie que le navigateur a atteint le proxy, mais que le proxy n’a pas ouvert le tunnel vers le site. C’est généralement une 407 (identifiants ou flag mal formé) ou une 502 (rien ne correspondait à votre filtre), donc testez d’abord le nom d’utilisateur nu, comme dans la section 407.

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.

Questions fréquentes

L’essentiel à retenir

Neuf 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. Une 403 ou un challenge, c’est la cible qui vous refuse, donc changez d’identité puis cherchez pourquoi. Une 429, c’est la cible qui vous demande de ralentir, donc respectez Retry-After et réduisez le rythme. 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 réellement 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.