407 Proxy Authentication Required : signification et correction

Vous recevez un HTTP 407 d'un proxy ? Voyez ce que signifie Proxy Authentication Required, puis vérifiez les identifiants, la liste d'autorisation d'IP et les caractères spéciaux du mot de passe.

Vous avez configuré un proxy, envoyé une requête, et reçu 407 Proxy Authentication Required au lieu d'une page. Ce guide s'adresse à quiconque utilise un proxy payant dans un navigateur, un scraper ou un script et a besoin de comprendre pourquoi le proxy continue de le rejeter. Nous parcourons les causes dans l'ordre où elles apparaissent le plus souvent. Top Proxy compare des services de proxy ; nous ne vendons pas d'IP et nous ne distribuons pas d'identifiants gratuits, donc chaque exemple ci-dessous utilise des valeurs placeholder.

01Ce que signifie 407 Proxy Authentication Required#

HTTP 407 est un défi d'authentification proxy. MDN le décrit comme une requête qui a échoué parce qu'elle « lacks valid authentication credentials for the proxy server » (MDN, 407). Le statut est défini dans la RFC 9110, section 15.5.8.

L'échange se déroule ainsi. Le proxy répond 407 et un en-tête Proxy-Authenticate qui nomme le schéma attendu, par exemple :

HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm="proxy"

Le client est alors censé répéter la requête avec un en-tête Proxy-Authorization qui porte les identifiants. Cela veut dire qu'un seul 407 n'est pas automatiquement un échec : certains clients envoient la première requête sans identifiants, reçoivent le défi, puis réessayent avec. Le problème, c'est un 407 qui continue de revenir après que le client a répondu au défi, ou un client qui n'y répond jamais.

Il est utile de séparer 407 de son sosie, 401 :

Un 401 veut en général dire que la destination veut son propre login. C'est un indice, pas une preuve, que votre login proxy a marché. De même, un 407 vous dit quel type d'authentification a été défié, mais le code de statut seul ne prouve pas jusqu'où la requête a voyagé. N'importe quel intermédiaire sur le chemin peut renvoyer 407, y compris un proxy d'entreprise devant celui que vous avez configuré. Si la réponse ne ressemble pas à celle de votre fournisseur, vérifiez si votre réseau route d'abord le trafic par un autre proxy.

Certains clients n'affichent pas du tout le numéro. Un navigateur peut ouvrir une boîte de login pour le proxy, et une bibliothèque peut lever une erreur qui mentionne un tunnel échoué et 407. La cause est la même.

02Les causes fréquentes en un coup d'œil#

La plupart des 407 persistants se ramènent à une courte liste de problèmes. Servez-vous de ce tableau pour choisir par où commencer, puis lisez la section correspondante.

Les fournisseurs traitent les forfaits expirés de façons différentes : certains renvoient 407, d'autres une autre erreur ou une connexion fermée, donc traitez la dernière ligne comme un point à écarter.

03Vérifier d'abord l'identifiant et le mot de passe#

La cause la plus fréquente est la plus simple : le proxy n'a pas reçu les identifiants qu'il attendait. Parcourez ces points dans l'ordre.

1. Recopiez les identifiants à neuf. Prenez l'identifiant et le mot de passe du proxy dans le tableau de bord du fournisseur, pas dans une vieille note. Beaucoup de fournisseurs émettent des identifiants proxy distincts, différents du login du tableau de bord.
2. Surveillez les espaces parasites. Un espace ou un saut de ligne collé avec le mot de passe est invisible, mais rend les identifiants faux.
3. Reconstruisez l'identifiant s'il porte des options. Beaucoup de fournisseurs résidentiels et mobiles encodent le ciblage dans l'identifiant, comme un code pays ou un jeton de session. La syntaxe est propre au fournisseur ; un séparateur faux ou une valeur non prise en charge peut mener à un login rejeté. Utilisez le format de la documentation de votre fournisseur plutôt qu'un format copié d'un autre service.
4. Confirmez que l'hôte et le port correspondent aux identifiants. Certains fournisseurs utilisent des passerelles ou des ports différents selon les produits, et les identifiants de l'un peuvent ne pas marcher sur l'autre.
5. Confirmez comment le client s'authentifie. Certaines applications n'ont pas de champ identifiant ou mot de passe. Elles peuvent encore s'authentifier par les réglages système ou une méthode négociée, comme celles des réseaux d'entreprise, ou ne prendre les identifiants en charge que pour certains types de proxy. Consultez la documentation du client sur les méthodes d'authentification proxy prises en charge avant de supposer qu'il peut ou ne peut pas répondre au défi.

Pour voir ce qui se passe sur le fil, curl est un test rapide. Avec des valeurs placeholder :

curl -q -v --noproxy '' --connect-timeout 10 --max-time 30 \
  --proxy http://proxy.example.net:8000 \
  --proxy-user 'USERNAME:PASSWORD' \
  https://example.com/

-q doit venir en premier ; il fait ignorer à curl tout défaut .curlrc qui pourrait changer le test. --noproxy '' remplace un réglage NO_PROXY qui enverrait autrement la requête autour du proxy, et les deux délais gardent le test borné. Le drapeau -v imprime les en-têtes de requête et de réponse, pour que vous voyiez le 407 avec l'en-tête Proxy-Authenticate du proxy et, pour beaucoup de méthodes, si curl y a répondu. curl utilise Basic comme méthode d'authentification proxy par défaut, et --proxy-anyauth lui dit de choisir une méthode adaptée si le proxy en demande une autre (manuel curl).

Deux précautions. La sortie verbeuse peut contenir des identifiants encodés, des cookies et des jetons, donc masquez Proxy-Authorization, Cookie et toute valeur de jeton avant de partager un journal. Et un mot de passe tapé sur la ligne de commande peut finir dans l'historique du shell et est brièvement visible dans la liste des processus, comme le prévient le manuel curl ; développer une variable d'environnement dans l'argument ne change pas cela. Pour tout ce qui dépasse un test jetable, utilisez la saisie d'identifiants protégée de votre outil, par exemple un fichier de config que vous seul pouvez lire.

Ce test garde la vérification TLS normale. Vous n'avez pas besoin de -k ni d'un interrupteur « insecure » pour déboguer un 407 ; désactiver la vérification ne corrige pas l'authentification proxy et ne fait que cacher de vrais problèmes.

04Liste d'autorisation d'IP et IP externe qui a changé#

Beaucoup de fournisseurs proposent une autre façon de s'authentifier : vous enregistrez votre adresse IP publique, et le proxy accepte les connexions qui en viennent sans mot de passe. Certains fournisseurs laissent aussi combiner cela avec identifiant et mot de passe, ou appliquer des méthodes différentes par point d'accès. La liste d'autorisation a un mode de panne qui produit exactement le rejet « ça marchait hier ». Selon le fournisseur, ce rejet peut être un 407, un 403, une connexion coupée, ou une autre erreur.

Le proxy voit l'IP d'où vient votre connexion, pas l'adresse que votre ordinateur affiche sur sa propre carte réseau. Cette IP source dépend de votre chemin vers le proxy :

• Les connexions domicile et mobile reçoivent souvent une nouvelle IP publique après un redémarrage de routeur, une reconnexion, ou simplement avec le temps.
• Le NAT et le NAT de niveau opérateur font que le fournisseur voit l'adresse publique partagée, pas votre adresse locale 192.168.x.x ou 10.x.x.x.
• Un VPN, un réseau d'entreprise ou un autre proxy devant le fournisseur change l'IP source en la sortie de ce réseau.
• IPv4 contre IPv6. Si vous avez mis une adresse IPv4 en liste d'autorisation mais que votre connexion atteint le fournisseur en IPv6, ou l'inverse, le proxy peut ne pas vous reconnaître. Cela s'applique selon que la passerelle du fournisseur accepte IPv6.

Pour vérifier, ouvrez Mon IP avec le proxy désactivé dans ce navigateur et comparez l'adresse affichée avec la liste d'autorisation de votre fournisseur. La page montre l'IP de cette seule requête depuis ce seul navigateur. Si votre script tourne sur un serveur, dans un conteneur, ou à travers un VPN, son IP source peut différer : vérifiez donc depuis la même machine et le même chemin réseau que le client qui échoue.

Si vous êtes passé d'une liste d'autorisation à un mot de passe, ou l'inverse, vérifiez aussi que le point d'accès que vous utilisez attend la méthode que vous envoyez maintenant.

05Caractères spéciaux dans le mot de passe#

Les mots de passe avec des symboles tels que @, :, /, #, % ou ? sont une source fréquente de 407 qui a l'air aléatoire : les mêmes identifiants marchent dans un outil et échouent dans un autre. Ces caractères ont un sens dans une URL, et beaucoup d'outils prennent le proxy comme une seule URL du type http://user:password@host:port.

Prenez le mot de passe placeholder p@ss:w/rd%#1. Dans une URL de proxy, le @ peut être lu comme la fin des identifiants, et /, # ou % peuvent couper ou corrompre le reste. La façon dont un : littéral dans le mot de passe est traité varie selon les parseurs d'URL. Parce que le comportement des parseurs diffère, la règle sûre est d'encoder en pourcent chaque caractère réservé de l'identifiant et du mot de passe avant de les mettre dans une URL.

La correction dépend de la façon dont l'outil prend les identifiants :

N'encodez pas en pourcent à l'aveugle partout. Si vous encodez un mot de passe puis le tapez dans un champ mot de passe séparé, le proxy reçoit %40 au lieu de @ et le rejette.

curl. Le manuel dit que l'utilisateur et le mot de passe dans la chaîne de proxy sont décodés en URL, donc vous pouvez passer @ comme %40 et un deux-points comme %3a (manuel curl). Avec le mot de passe placeholder ci-dessus :

curl -q --noproxy '' --connect-timeout 10 --max-time 30 \
  --proxy 'http://USERNAME:p%40ss%3Aw%2Frd%25%231@proxy.example.net:8000' \
  https://example.com/

Autrement, gardez l'URL de proxy propre et passez les identifiants à part avec --proxy-user, en quotant la valeur en simples quotes pour que votre shell n'interprète pas des caractères comme $, ! ou #. La même mise en garde d'exposition en ligne de commande ci-dessus s'applique aux deux formes.

Python. Encodez chaque partie avec la bibliothèque standard, puis construisez l'URL :

from urllib.parse import quote
import requests

username = "USERNAME"
password = "p@ss:w/rd%#1"  # placeholder; load the real one from a secret store

proxy = (
    f"http://{quote(username, safe='')}:{quote(password, safe='')}"
    "@proxy.example.net:8000"
)

try:
    response = requests.get(
        "https://example.com/",
        proxies={"http": proxy, "https": proxy},
        timeout=(10, 30),  # connect timeout, read timeout
    )
    print(response.status_code)
except requests.exceptions.ProxyError:
    # Could be a 407 on the tunnel, a refused port, or another proxy failure
    print("Proxy connection failed; check the proxy address, auth, and allowlist.")

quote(..., safe='') transforme le mot de passe placeholder en p%40ss%3Aw%2Frd%25%231, et requests décode l'identifiant et le mot de passe depuis l'URL de proxy avant de construire l'en-tête. Pour une destination HTTPS, le défi proxy se produit pendant l'ouverture du tunnel, donc un 407 y apparaît en général comme un ProxyError avant qu'un objet réponse n'existe. ProxyError n'est pourtant pas spécifique à l'authentification : un port de proxy fermé ou faux le lève aussi, donc le message reste générique. L'exemple imprime ce court message au lieu de l'exception brute, qui peut inclure l'URL de proxy avec les identifiants. Les valeurs de timeout limitent la connexion et l'attente entre lectures ; elles ne plafonnent pas la durée totale de la requête. La vérification des certificats reste allumée (le défaut), et il n'y a pas de boucle de nouvelle tentative : réessayer avec les mêmes identifiants ne corrigera pas un 407.

Ce que nous avons vu dans un test contrôlé

Pour vérifier ces comportements, nous avons lancé Python Requests 2.34.2 sur Python 3.14.4 contre un proxy de test local sur la même machine, avec des identifiants factices (demo avec un mot de passe contenant @, :, /, #, %) et la vérification TLS allumée. Cela montre comment le client et le protocole se comportent, pas les performances d'un fournisseur commercial.

Dans ce test, le helper HTTPProxyAuth a authentifié les requêtes HTTP en clair mais pas le tunnel HTTPS, donc pour le HTTPS placez des identifiants encodés dans l'URL de proxy.

06Vérifier la correction#

Commencez par le vérificateur de proxies. Saisissez les détails du proxy : il se connecte depuis notre serveur et indique si le point d'accès répond. Lisez le résultat avec deux réserves. D'abord, le vérificateur se connecte depuis sa propre IP, pas la vôtre. Si votre fournisseur utilise une liste d'autorisation d'IP et que l'IP du vérificateur n'est pas autorisée, le contrôle peut être rejeté avec un 407, un 403, une connexion coupée, ou une autre erreur, et cela seul ne veut pas dire que votre configuration est cassée. Ensuite, un contrôle réussi montre que le point d'accès a accepté ces identifiants depuis l'emplacement du vérificateur. Cela ne prouve pas que votre navigateur ou votre script route par le proxy.

Pour la seconde partie, lancez le test curl depuis la machine qui a le problème, puis visitez Mon IP à travers le proxy configuré. Comparez l'IP que vous voyez avec l'IP de sortie, la plage ou le point d'accès que votre fournisseur dit que vous devriez obtenir. Une IP différente à elle seule n'est pas la preuve de la bonne route (un VPN la changerait aussi), et une IP inchangée à elle seule ne prouve pas que le proxy a été contourné ; confrontez-la à la sortie attendue et à la route que prend le client. Le pays ou la localisation seuls ne suffisent pas non plus, puisqu'un proxy peut sortir dans votre propre pays.

Si le vérificateur passe mais que votre client reçoit encore 407, regardez ce qui diffère entre les deux chemins : l'IP source et la version d'IP, le point d'accès et le port, la méthode d'authentification, la façon dont le client traite les caractères spéciaux, ou un autre proxy sur votre réseau qui répond en premier.

07Quand il est temps de regarder un autre fournisseur#

Si vous avez écarté les causes ci-dessus et que vous continuez à perdre du temps sur une syntaxe d'identifiant non documentée ou des montages d'identifiants confus, cela peut valoir la peine de comparer des services qui documentent clairement leurs options d'authentification. Vous pouvez parcourir les services de proxies mobiles ou commencer par ces fiches du catalogue. Figurer ici ne veut pas dire que nous les avons testés contre votre client précis.

Bright Data — proxies résidentiels et datacenter4.41442

Bright Data est un grand réseau de proxies pour la collecte de données : IP résidentielles, mobiles, ISP et datacenter dans environ 195 pays. Le trafic résidentiel peut se payer à l'usage sans abonnement, et les adresses datacenter et ISP se vendent par packs dès 10 IP. L'accès résidentiel et mobile exige une vérification d'identité.

10 pays

5,00 $US

par 1 GB

Oxylabs — proxies résidentiels et datacenter4.0771

Oxylabs vend des proxies résidentiels, mobiles, ISP et datacenter sous un seul abonnement mensuel dès $30. Paiements acheteur : cartes, virement, AliPay, PayPal.

10 pays

0,45 $US

par 1 GB

SOAX — proxies résidentiels et mobiles3.8218

SOAX vend des proxies résidentiels et mobiles rotatifs sur un pool de crédits partagé, avec datacenter et ISP dans les mêmes forfaits. Builder commence à $200/mois + TVA (200 crédits) ; le trafic Tier 1 est à $3/GB sur Builder.

85 pays

3,00 $US

par 1 GB

Decodo (Smartproxy) — proxies résidentiels et datacenter4.22118

Decodo (anciennement Smartproxy) vend des proxies résidentiels et datacenter. Résidentiel : $4/GB sans forfait mensuel, ou packs mensuels dès $3.75/GB pour 3 GB. Paiements : cartes, PayPal, Alipay, Google/Apple Pay, crypto (avec limites).

83 pays

0,38 $US

par 1 GB

08FAQ#