Chaque requête revient avec 407 Proxy Authentication Required, rien n’atteint la cible, et les identifiants semblent corrects dans le panneau. C’est l’un des tickets de support les plus courants dans cette catégorie de produits, et aussi l’un des plus rapides à résoudre, car le nombre de choses pouvant produire un 407 est restreint et elles peuvent être éliminées dans un ordre fixe.
Voici ce que ce code de statut signifie réellement, les causes à vérifier, l’ordre dans lequel les vérifier, et les erreurs propres au client qui produisent un 407 même lorsque les identifiants sont corrects.
Ce qu’est réellement un 407
Un 407 provient du proxy, pas du site que vous essayez d’atteindre. C’est la manière du proxy de dire que la requête est arrivée sans identifiants acceptables, et c’est l’équivalent, au niveau du proxy, d’un 401 provenant d’un serveur d’origine. Cette distinction compte pour le débogage : un 407 signifie que votre trafic a atteint la passerelle et que la passerelle l’a refusé. La connectivité est bonne. L’authentification ne l’est pas.
Cela signifie aussi que le site cible n’est pas du tout impliqué. Si vous obtenez des 407, rien de ce que vous changerez dans les en-têtes, les user agents, le rendu ou le rythme n’aidera, car votre requête n’a jamais quitté le proxy.
Les trois causes à vérifier en premier
Sur une passerelle où le ciblage s’exprime dans le nom d’utilisateur, presque tous les 407 relèvent de l’une de ces trois causes.
Les identifiants sont incorrects. Une faute de frappe, un espace parasite copié depuis un tableau de bord, ou des identifiants provenant d’un produit différent. Les identifiants proxy ne sont généralement pas les mêmes que votre identifiant de connexion au compte, ce qui est une confusion étonnamment fréquente.
Un indicateur (flag) dans le nom d’utilisateur étendu est mal formé. C’est la cause que les gens manquent, et elle est propre aux passerelles qui encodent le ciblage dans le nom d’utilisateur. Si votre nom d’utilisateur porte des indicateurs de pays, de ville, de session ou de TTL, une valeur non reconnue rend l’ensemble du nom d’utilisateur impossible à analyser, et la passerelle le rejette comme un échec d’authentification plutôt que comme une erreur de ciblage. Un code de pays mal orthographié, un slug de ville dans un mauvais format, un identifiant de session avec des caractères illégaux, ou un ttl sans sid associé, tout cela tombe dans ce cas. Les identifiants sont parfaits ; la chaîne du nom d’utilisateur ne l’est pas.
Le mot de passe a été renouvelé. Si quelqu’un l’a régénéré dans le panneau, chaque client détenant encore l’ancienne valeur renvoie un 407 jusqu’à sa mise à jour. C’est le cas classique où cela fonctionne sur une machine et échoue sur une autre.
L’ordre de diagnostic
Parcourez cette liste et arrêtez-vous dès que cela fonctionne, car l’étape qui résout le problème identifie la cause.
Un : retirez tous les indicateurs et testez les identifiants nus. Cette seule étape sépare un problème d’identifiants d’un problème d’indicateur, et elle doit toujours venir en premier.
# bare username, no targeting flags at all
curl -x customer-USERNAME:PASSWORD@p.shifter.io:443 https://ipinfo.io/jsonSi cela réussit, vos identifiants sont corrects et le défaut se situe dans les indicateurs. S’il renvoie toujours un 407, les identifiants eux-mêmes sont incorrects et aucune correction d’indicateur n’y changera quoi que ce soit.
Deux : rajoutez les indicateurs un par un. D’abord le pays, puis la ville ou l’ASN, puis la session et le TTL. L’indicateur qui réintroduit le 407 est celui qui est mal formé, et vous savez désormais exactement quelle valeur vérifier.
curl -x customer-USERNAME-country-us:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-us-city-new_york:PASSWORD@p.shifter.io:443 https://ipinfo.io/json
curl -x customer-USERNAME-country-us-city-new_york-sid-abc123:PASSWORD@p.shifter.io:443 https://ipinfo.io/jsonFaites attention aux formats : les codes de pays sont des codes ISO à deux lettres, donc uk est une erreur fréquente là où gb est correct. Les slugs de ville utilisent des underscores plutôt que des espaces ou des tirets, comme dans new_york. Et ttl n’est valide qu’accompagné de sid, donc un TTL seul est invalide. La syntaxe complète se trouve dans la documentation sur la passerelle et l’authentification, et les options de ciblage sont couvertes dans le ciblage au niveau de la ville et le ciblage par ASN.
Trois : recopiez le mot de passe depuis le panneau. Si les identifiants nus ont échoué à l’étape un, prenez le mot de passe directement dans le panneau plutôt que dans vos notes ou un fichier de configuration, et vérifiez spécifiquement l’absence d’espace final, de guillemet typographique provenant d’un document, ou d’un collage tronqué.
Quatre : déployez la valeur partout. Si cela fonctionne en local mais pas en production, vous avez une copie obsolète dans une variable d’environnement, un gestionnaire de secrets, une image de conteneur, ou une configuration CI. C’est un problème de déploiement plutôt qu’un problème de proxy.
Erreurs qui ressemblent à un 407 mais qui n’en sont pas
Distinguer ces cas fait gagner beaucoup de temps, car chacun a un correctif différent.
Un 502 sur cette passerelle signifie qu’aucune adresse ne correspondait à votre filtre à ce moment-là. C’est un problème de ciblage, pas un problème d’authentification : vos identifiants ont été acceptés et rien n’était disponible ensuite pour la combinaison demandée. Élargissez le filtre, passez de la ville au pays, ou assouplissez un indicateur de correspondance stricte.
Un 509 signifie que la bande passante du forfait est épuisée avec le dépassement désactivé. L’authentification a réussi ; vous êtes à court de quota. Des conseils de dimensionnement associés se trouvent dans estimer la bande passante mensuelle.
Connexion refusée signifie que vous n’avez jamais atteint la passerelle, généralement parce que vous pointez vers un hôte basé sur un port ancien plutôt que vers le point de terminaison actuel, ou parce que le trafic sortant de votre réseau est bloqué. Testez la connectivité brute avec nc -vz p.shifter.io 443 avant de supposer un problème d’authentification.
Un 403 ou une page de challenge de la cible signifie que l’authentification a parfaitement fonctionné et que le site vous a refusé, ce qui est un problème complètement différent traité dans éviter les blocages.
Erreurs propres au client qui produisent un 407
Parfois, les identifiants et les indicateurs sont tous deux corrects, et c’est le client qui est en tort.
Caractères spéciaux dans le mot de passe. Si le mot de passe contient des caractères significatifs dans une URL, @, :, #, /, ou %, l’intégrer directement dans une URL de proxy casse l’analyse et les identifiants arrivent corrompus. Encodez-le en pourcentage.
import requests
from urllib.parse import quote
user = "customer-USERNAME-country-us"
pwd = quote("p@ss:word/123", safe="") # encode before embedding
PROXY = f"http://{user}:{pwd}@p.shifter.io:443"
r = requests.get("https://ipinfo.io/json",
proxies={"http": PROXY, "https": PROXY}, timeout=15)
print(r.status_code, r.text[:120])Confondre l’authentification proxy avec l’authentification cible. curl -U définit les identifiants du proxy ; -u définit les identifiants pour le site cible. Envoyer vos identifiants proxy dans un en-tête Authorization ne fait rien, car l’authentification proxy circule dans Proxy-Authorization, et la plupart des clients définissent cela pour vous lorsque les identifiants sont dans l’URL du proxy.
Identifiants perdus en HTTPS. Certaines configurations client définissent le proxy uniquement pour HTTP, de sorte que les requêtes simples s’authentifient et les requêtes HTTPS non. Définissez les deux entrées, comme dans l’exemple Python ci-dessus.
Variables d’environnement qui ne sont pas ce que vous pensez. HTTP_PROXY et HTTPS_PROXY définies dans un profil shell, un Dockerfile, ou un runner CI peuvent silencieusement écraser ce que votre code transmet, de sorte qu’une application peut s’authentifier auprès d’une chaîne de proxy complètement différente de celle présente dans votre code source. Affichez la configuration de proxy effective lors du débogage plutôt que de faire confiance au code.
Une bibliothèque qui n’envoie pas d’authentification proxy préventive. Quelques clients HTTP attendent d’être challengés avant d’envoyer les identifiants et gèrent mal le challenge, en particulier avec certaines configurations de tunnel. Si un simple curl fonctionne et pas votre application, la différence se situe dans le client, pas dans la passerelle. Les configurations qui fonctionnent pour les stacks courantes se trouvent dans utiliser des proxies résidentiels avec Python.
Gérer le 407 dans du code de production
Une remarque opérationnelle : un 407 est une erreur définitive, pas transitoire. Le réessayer est inutile, car les identifiants seront tout aussi incorrects à la tentative suivante, et une boucle de nouvelles tentatives face à un échec d’authentification consomme simplement de la bande passante et peut ressembler, de l’extérieur, à un schéma de credential stuffing. Classez-le comme définitif, échouez bruyamment, et alertez, ce qui correspond à la discipline de classification décrite dans tentatives et attente exponentielle.
La rotation des identifiants mérite un plan de déploiement plutôt qu’un simple clic dans le panneau, puisque chaque client détenant l’ancienne valeur commence à échouer au moment de la rotation. Mettez d’abord à jour le gestionnaire de secrets, déployez les clients, puis effectuez la rotation.
En résumé
Un 407 signifie que votre requête a atteint la passerelle et que la passerelle a rejeté les identifiants, donc le site cible n’a aucune importance et la connectivité est prouvée. Testez d’abord les identifiants nus sans indicateurs, car cette seule étape divise le problème en deux, puis rajoutez les indicateurs un par un pour trouver celui qui est mal formé, en gardant à l’esprit qu’un mauvais code de pays ou un TTL sans session rend l’ensemble du nom d’utilisateur impossible à analyser. Recopiez le mot de passe depuis le panneau si le test nu a échoué, et vérifiez les valeurs obsolètes dans les variables d’environnement et les gestionnaires de secrets si cela fonctionne à un endroit et pas à un autre. Écartez les cas similaires : 502 est un filtre vide, 509 est une question de bande passante, connexion refusée est le mauvais hôte, et un 403 provenant du site n’est pas du tout un problème d’authentification. Et ne réessayez jamais un 407.
La référence complète de syntaxe se trouve dans la documentation sur la passerelle et l’authentification, et le produit lui-même est les proxies résidentiels, où les mêmes identifiants fonctionnent sur tous les pays, villes et modes de session avec une tarification au GB.