Réglages de proxy de VS Code pour les extensions, la CLI et les programmes de terminal

Un identifiant proxy mémorisé dans VS Code peut coexister avec un téléchargement échoué dans le terminal ou dans une extension. Identifiez l'opération et le processus qui effectue la requête en échec avant de modifier le compte enregistré.

Réseau de base de l'éditeur

La prise en charge de base du proxy dans VS Code vient de Chromium et suit normalement les paramètres réseau du système. Elle accepte les schémas de proxy HTTP authentifié courants et peut mémoriser les identifiants dans le magasin d'identifiants du système d'exploitation. Ce magasin n'est pas automatiquement une source de compte pour chaque programme lancé par l'éditeur.

Si le compte mémorisé est rejeté, vérifiez le point de terminaison et la méthode annoncée. Les réglages de certificat ne fournissent pas l'authentification manquante.

Extensions et requêtes de la CLI

VS Code documente des réglages hérités comme http.proxy pour les scénarios d'extension et de CLI. Vérifiez la version de l'éditeur et l'interface réseau propre à l'extension : elle peut utiliser une autre bibliothèque, lancer un exécutable ou s'exécuter dans un autre environnement.

Programmes du terminal intégré

npm, Git, pip et d'autres commandes utilisent leurs propres réglages de proxy pris en charge. Inspectez l'environnement réel du processus. Un terminal existant peut conserver d'anciennes variables, et un terminal distant peut s'exécuter sur une autre machine.

L'accès à la place de marché et la livraison des artefacts d'extension peuvent utiliser des hôtes différents. Conservez le nom d'hôte de la requête en échec ; une requête réussie sur le catalogue ou à la connexion ne prouve pas que les artefacts sont joignables.

Signalez l'opération, l'emplacement du processus, le point de terminaison du proxy et la première étape en échec, sans secrets. Ces observations localisent un 407, une erreur TLS ou un hôte de livraison injoignable dans le client qui le possède.