npm possède des réglages distincts proxy et https-proxy. La différence est la destination demandée. Pour un proxy HTTP ordinaire qui crée des tunnels HTTPS, les deux valeurs peuvent viser le même point http://.

Un .npmrc de projet peut contenir :

proxy=http://203.0.113.10:8080
https-proxy=http://203.0.113.10:8080
noproxy=localhost,127.0.0.1,registry.example.internal

Remplacez le point de documentation par votre proxy ; pour les tests autorisés de registres publics, la liste de proxys HTTP fournit des candidats HTTP. La dernière ligne laisse volontairement le registre interne nommé en accès direct. Ce n’est pas une autre adresse proxy.

Demander à npm d’effectuer une requête

Une installation depuis le cache est un mauvais test de chemin : npm peut déjà disposer de tout ce dont il a besoin. Un ping du registre est une vérification plus légère :

npm ping --registry=https://registry.npmjs.org/

Une exécution réussie montre que cet appel npm a atteint le chemin de ce registre. Elle ne prouve pas que chaque hôte d’archive tarball, dépendance Git ou processus distinct de gestionnaire de paquets utilise le même chemin.

Pour trouver un réglage contradictoire, examinez les valeurs effectives au lieu de modifier immédiatement d’autres fichiers :

npm config get proxy
npm config get https-proxy
npm config get noproxy

Ces commandes peuvent afficher des identifiants s’ils sont intégrés dans une URL. Examinez la sortie localement plutôt que de la coller telle quelle dans un signalement.

Le .npmrc d’un projet n’est pas utilisé pour les installations globales. Si seul npm install -g échoue, vérifiez la configuration effective de cet appel plutôt que de supposer qu’il a lu le fichier du projet.

Vérifier les exclusions avant de changer l’IP

npm fonctionne aussi avec les variables d’environnement proxy, et son réglage noproxy peut provenir de NO_PROXY. Une destination exclue par la configuration effective peut être jointe directement même si une valeur proxy existe. À l’inverse, supprimer une ligne d’un .npmrc ne supprime pas une variable d’environnement héritée.

Traiter les erreurs de certificat séparément

Un proxy d’inspection autorisé peut nécessiter une CA d’organisation à laquelle votre environnement Node/npm ne fait pas encore confiance. npm accepte un fichier CA :

cafile=/path/to/approved-ca-bundle.pem
strict-ssl=true

Utilisez le véritable ensemble approuvé pour cet environnement. Définir strict-ssl=false affaiblit la vérification des certificats ; cela ne remplace pas le choix du bon proxy ou des bons éléments de confiance.

À la fin des tests, retirez les surcharges de projet ajoutées et vérifiez de nouveau les valeurs effectives. Le projet retrouve ainsi sa configuration héritée précédente sans changer les autres projets de la machine.

Articles similaires