La page intranet qui s’affiche dans le navigateur prouve seulement que le proxy fonctionne pour le navigateur, pas pour npm ni Maven. Chaque client lit sa propre configuration, et un réseau joignable uniquement par VPN ajoute une seconde question : si le client atteint le proxy. Commencez par le code de statut, puis suivez la chaîne de configuration de l’outil qui a échoué. C’est pourquoi un client fonctionne alors que son voisin échoue.

Ce qu’un 407 prouve vraiment

Un 407 Proxy Authentication Required vient du proxy, pas du registre ni du dépôt. Le client a atteint le proxy et celui-ci a refusé la requête, généralement parce que les identifiants manquaient, étaient mal formés ou n’étaient pas acceptés pour cette destination.

Un délai dépassé raconte autre chose : mauvaise adresse de proxy, aucune route vers le proxy avant l’établissement du tunnel, ou une entrée d’exclusion absente pour un hôte interne. Lisez le texte de l’erreur avant de changer les identifiants.

Vérifiez l’hôte, le port, le schéma d’authentification et si le nom d’utilisateur exige un préfixe de domaine. Vérifiez ensuite si l’outil lit cette valeur dans un fichier, une variable d’environnement ou les deux. Un nom qualifié par domaine est une cause fréquente de 407, tout comme un mot de passe stocké avec un encodage erroné.

npm lit sa propre chaîne de configuration

npm accepte les clés proxy et https-proxy dans un .npmrc utilisateur ou de projet. Indiquez le schéma, car les valeurs sont des URL, et encodez les caractères réservés du mot de passe pour qu’une arobase ne coupe pas la valeur.

proxy=http://proxy.example.com:8080
https-proxy=http://proxy.example.com:8080
strict-ssl=true

Avec npm config list, vous voyez quel fichier a fourni chaque valeur effective. Une exportation de shell comme npm_config_proxy peut remplacer le fichier, et un .npmrc de projet contenant un mot de passe personnel ne doit jamais être commité. Affichez le chemin source avec la valeur.

Laissez strict-ssl activé. Un proxy qui inspecte TLS peut exiger le CA d’entreprise dans le magasin de confiance ; désactiver la vérification pour contourner l’erreur masque le vrai problème de confiance.

Maven sépare les proxys des miroirs

Maven lit les proxys et les miroirs dans le fichier de paramètres de l’utilisateur, pas dans le pom du projet. Placez les proxys propres au réseau et les miroirs du dépôt interne dans ~/.m2/settings.xml, et laissez les déclarations publiques dans le projet.

Le bloc proxy exige un id, un indicateur d’activation, le protocole, l’hôte et le port, ainsi qu’une entrée nonProxyHosts pour le dépôt interne. Gardez ces champs dans le fichier utilisateur, pas dans le pom, pour qu’un changement de réseau ne réécrive pas le build de toute l’équipe.

Ajoutez le dépôt interne à nonProxyHosts pour que Maven s’y connecte directement. Sans cette entrée, le proxy devient une étape inutile et la panne ressemble à une coupure du dépôt. L’entrée de miroir pointe vers le dépôt interne et ne remplace pas le réglage du proxy.

Ceux qui changent de réseau peuvent tenir un fichier de paramètres par réseau et choisir la bonne copie au démarrage du shell. Modifier un seul fichier à la main à chaque changement transforme un portable qui fonctionne en ticket de support.

VS Code et les conteneurs de développement ont des espaces de noms distincts

VS Code lit http.proxy dans les paramètres utilisateur ou d’espace de travail, schéma et port compris. Cela couvre les requêtes de l’éditeur vers les extensions et la place de marché, mais ne configure ni un terminal ni un conteneur lancé depuis l’éditeur. Vérifiez la portée du réglage autant que la valeur. Un réglage d’espace de travail peut remplacer celui de l’utilisateur pour un projet.

Un conteneur de développement a son propre espace de noms réseau. Il n’hérite ni des variables de proxy de l’hôte ni de sa route VPN, d’où l’échec possible d’un appel à la place de marché dans le conteneur alors que le même appel fonctionne sur l’hôte.

Donnez ces variables au conteneur, ou donnez-lui son propre résolveur et sa route. Quand les noms se résolvent à l’intérieur mais que le proxy ne répond jamais, la pièce manquante est généralement la route, pas l’adresse.

Listes d’exclusion et priorité de l’environnement

Ajoutez la passerelle VPN, les registres internes et les suffixes DNS privés à la liste d’exclusion. Si le client tente de joindre la passerelle via le proxy avant l’existence du tunnel, la connexion échoue d’une manière qui ressemble à une panne du proxy. Testez cette exclusion tunnel coupé.

Variables d’environnement et fichiers peuvent se contredire. Lancez le vidage de configuration de l’outil, pas celui du shell, et comparez les valeurs. Une variable dupliquée en minuscules, une valeur ancienne dans un shell parent ou un fichier de projet peuvent l’emporter sur le réglage que vous venez de modifier.

En CI, passez le proxy comme variable secrète et testez l’installation d’un paquet dans la même image. Un 407 dans un conteneur signifie souvent que la variable y est simplement absente, alors que le shell de l’hôte la possède.

Notez l’hôte, le port, les suffixes d’exclusion et le fichier ou la variable qui les fournit pour chaque outil. Quand un client renvoie 407 et qu’un autre fonctionne, cette note transforme la comparaison de quatre configurations en une vérification courte.

Articles similaires