Passer au contenuComment utiliser un proxy avec GitHub Codespaces sur un réseau restreint
Un Codespace GitHub exécute son conteneur de développement dans un environnement hébergé, tandis que le navigateur qui l’affiche fonctionne sur votre propre appareil. Cette distinction est importante : configurer un proxy dans le conteneur peut acheminer les téléchargements de paquets depuis le Codespace, mais ne modifie pas automatiquement la manière dont votre navigateur local accède aux sites web. Pour savoir comment configurer un proxy dans GitHub Codespaces, commencez par identifier le trafic concerné et l’endroit où il est généré.
Si l’installation d’une dépendance échoue derrière un pare-feu d’entreprise, commencez par déterminer quelle connexion est bloquée. La réponse vous indiquera où configurer le proxy et ce que votre organisation doit autoriser, notamment pour utiliser GitHub Codespaces derrière un proxy d’entreprise.
1. Déterminer quel trafic de Codespaces doit passer par le proxy
Notez précisément l’opération qui échoue. L’installation d’un paquet Python avec pip, la récupération d’une dépendance Node.js avec npm ou le téléchargement d’un outil en ligne de commande depuis un terminal sont des requêtes effectuées par des logiciels dans le conteneur de développement. En revanche, un onglet ouvert dans le navigateur de votre ordinateur portable utilise la connexion réseau de cet appareil.
Cette distinction peut vous faire gagner du temps. Si un site ne s’affiche pas dans votre navigateur local, ajouter HTTPS_PROXY au Codespace peut ne rien changer. À l’inverse, si npm install échoue dans le terminal du Codespace, un proxy configuré uniquement sur votre ordinateur portable ne sera peut-être d’aucune aide.
Notez l’outil qui échoue, la destination qu’il tente de joindre et si la requête vient du terminal, d’une extension de l’éditeur ou de votre navigateur local. Par exemple, un échec de pip install concerne le trafic du conteneur ; une page de connexion qui échoue dans votre navigateur local relève du réseau local ou de la configuration du navigateur.
Limitez le périmètre. Faire passer tout le trafic par un proxy alors qu’un seul registre de paquets est bloqué peut entraîner des échecs inutiles, notamment si les services internes doivent rester accessibles directement.
2. Vérifier ce que le proxy de votre organisation autorise
Demandez à votre administrateur réseau le nom d’hôte et le port du proxy, le protocole requis ainsi que le mode d’authentification. Demandez également si le proxy nécessite un nom d’utilisateur et un mot de passe, un certificat client ou une autorité de certification installée dans le conteneur. Ne déduisez pas ces informations des paramètres de proxy utilisés sur un autre appareil.
Demandez quelles destinations sont autorisées pour la tâche concernée. Un gestionnaire de paquets peut devoir accéder à un registre, tandis qu’un programme d’installation peut télécharger des fichiers depuis un autre serveur de publication. Votre administrateur pourra confirmer les noms d’hôte autorisés ; notez-les avant de commencer le dépannage afin de distinguer une destination bloquée d’une adresse de proxy incorrecte.
Vérifiez si l’inspection HTTPS est activée. Dans ce cas, le proxy peut présenter des certificats émis par votre organisation plutôt que par l’autorité de certification publique attendue par l’outil. L’administrateur doit vous fournir le certificat de l’organisation et la procédure d’installation approuvée ; ne copiez pas un certificat depuis un message d’erreur.
Si vous comparez différents types de proxy ou configurez l’accès pour d’autres outils, consultez le guide des bonnes pratiques pour l’authentification par proxy, qui explique comment gérer les identifiants en toute sécurité. Pour une réflexion plus générale sur le routage réseau, consultez notre guide pour choisir un VPN : un VPN et un proxy ne se configurent pas de la même façon dans Codespaces.
3. Configurer les variables de proxy pour le conteneur de développement
De nombreux outils en ligne de commande lisent les variables d’environnement HTTP_PROXY et HTTPS_PROXY. Pour configurer HTTP_PROXY et HTTPS_PROXY dans un Codespace, définissez-les dans l’environnement du conteneur de développement en utilisant l’adresse fournie par votre administrateur. Une valeur type se présente sous la forme http://proxy.example.net:8080, mais utilisez le protocole, le nom d’hôte et le port réellement indiqués par votre organisation.
Définissez NO_PROXY pour les destinations qui doivent contourner le proxy, comme les services internes approuvés ou les adresses locales. Les entrées exactes dépendent de votre réseau et de vos outils. Une valeur trop large peut envoyer des requêtes internes en dehors du chemin prévu ; une valeur trop restrictive peut laisser une requête tenter de joindre directement une destination bloquée.
Pour effectuer un test rapide et temporaire, vous pouvez définir les variables dans une session de terminal avant d’exécuter une commande. Cette méthode permet de vérifier si l’installation d’un paquet fonctionne, mais ne configure pas de manière fiable tous les terminaux ni les futures sessions Codespaces. La syntaxe varie aussi selon le shell ; évitez de coller une URL de proxy contenant des identifiants dans une commande susceptible d’être enregistrée dans l’historique du shell.
Pour configurer le projet de manière reproductible, placez les paramètres non sensibles dans la configuration de conteneur de développement utilisée par le dépôt, par exemple dans une configuration Dev Container adaptée ou un script de configuration. N’incluez pas de mots de passe ni de jetons dans des fichiers suivis par Git. Si vous avez besoin d’un identifiant, utilisez une méthode d’injection de secrets approuvée par votre organisation et vérifiez quels processus peuvent y accéder.
Ne supposez pas que toutes les applications utilisent ces variables. Certains outils lisent leurs variantes en minuscules, d’autres s’appuient sur leurs propres fichiers de configuration, et certains ignorent les variables d’environnement. Testez la commande qui a échoué au lieu de considérer la présence de HTTPS_PROXY comme la preuve que tout le trafic du Codespace passe par le proxy.
4. Conserver les paramètres du proxy après la reconstruction d’un Codespace
Un paramètre saisi dans un terminal peut disparaître à la fermeture de celui-ci ou lors de la reconstruction du Codespace. Pour rendre disponibles les paramètres non sensibles requis par le projet, utilisez une configuration au niveau du dépôt, créée lors de la mise en place du conteneur de développement. Ainsi, un collègue qui ouvre le même projet bénéficiera de la même configuration de base, sans qu’il soit nécessaire de copier un identifiant privé dans le dépôt.
Les paramètres personnels peuvent être plus adaptés si le proxy ne concerne que votre compte ou si la valeur est sensible. Avant d’opter pour cette solution, vérifiez les règles de votre organisation pour Codespaces et les paramètres disponibles : un administrateur peut limiter la configuration personnelle, l’utilisation de secrets ou certaines fonctionnalités des conteneurs de développement.
Après avoir modifié la configuration, reconstruisez le Codespace si le changement concerne la création du conteneur, puis ouvrez un nouveau terminal et vérifiez les variables. Une reconstruction constitue un test utile : si le paramètre du proxy disparaît ensuite, il a probablement été ajouté uniquement au shell précédent et non à une configuration persistante.
Distinguez la configuration partagée des secrets. Un dépôt peut documenter les noms des variables de proxy et le format attendu, mais un véritable mot de passe doit être fourni par un mécanisme de gestion des secrets approuvé. Un commit ordinaire ne risque ainsi pas d’exposer des identifiants à toutes les personnes pouvant consulter l’historique du projet.
5. Faire confiance au certificat du proxy si nécessaire
Si les requêtes HTTPS échouent avec une erreur de vérification de certificat et que votre organisation confirme que l’inspection HTTPS est activée, le conteneur devra peut-être faire confiance à l’autorité de certification de l’organisation. Demandez à l’administrateur le certificat officiel et les instructions d’installation. Ne désactivez jamais la vérification des certificats pour contourner le problème : cela pourrait masquer une interception au lieu de la résoudre.
La procédure d’installation dépend du système d’exploitation et de l’image de base du conteneur. Une image basée sur Debian, Alpine ou un langage particulier peut gérer les bundles de certificats différemment. Vérifiez également si le certificat doit être ajouté lors de la création du conteneur afin qu’il reste disponible après une reconstruction.
Une fois le certificat installé, testez une requête HTTPS classique vers une destination approuvée avec l’outil qui a échoué à l’origine. Si le navigateur fonctionne, mais qu’un client en ligne de commande signale toujours un émetteur non approuvé, ce client utilise peut-être un magasin de certificats distinct ou nécessite son propre paramètre. Avant de modifier la configuration de confiance, demandez à votre administrateur quel fichier de certificat et quel format le conteneur doit utiliser.
6. Tester séparément Git et les outils de développement
Commencez par une requête sans risque vers une destination approuvée par votre administrateur, puis testez le gestionnaire de paquets ou l’outil qui échoue. La réussite d’une commande ne prouve pas que Git, pip, npm et un programme d’installation propre à un langage utilisent tous le proxy de la même manière.
Pour Git, vérifiez si la version installée lit les variables d’environnement du proxy dans votre configuration. Si ce n’est pas le cas, Git peut nécessiter son propre paramétrage du proxy. Évitez d’inscrire un mot de passe directement dans un fichier de configuration Git susceptible d’être validé dans le dépôt ou copié dans des journaux ; utilisez plutôt une méthode d’authentification approuvée par votre organisation.
Pour les gestionnaires de paquets, vérifiez à la fois le paramètre du proxy et le registre configuré. Un gestionnaire de paquets pointant vers un registre interne n’aura peut-être pas besoin de la même destination externe qu’un téléchargement direct, tandis qu’un outil qui récupère une archive de publication peut contacter un autre hôte. Comparez la destination indiquée dans l’erreur à la liste d’autorisations reçue.
Notez les tests réussis et échoués, ainsi que le nom d’hôte concerné. Ces quelques informations donneront à votre administrateur des éléments exploitables — par exemple : « Git accède à l’hôte approuvé, mais le registre de paquets refuse la connexion via le proxy » — plutôt qu’un signalement vague indiquant que Codespaces n’a pas accès à Internet.
7. Diagnostiquer les échecs de connexion sans exposer d’identifiants
Effectuez un test de connectivité sans risque vers une destination approuvée et vérifiez si le résultat indique un problème de résolution DNS, un délai d’attente dépassé, un échec d’authentification auprès du proxy, une destination refusée ou une erreur de validation du certificat. Chaque type d’échec appelle une étape différente. Un délai d’attente dépassé, par exemple, n’est pas la même chose qu’un refus d’authentification.
Vérifiez que le nom d’hôte et le port du proxy correspondent aux valeurs fournies par votre administrateur, et que la variable est bien définie dans la session de terminal où vous lancez le test. Si le proxy exige une authentification, des identifiants manquants ou expirés peuvent bloquer l’accès même si l’adresse est correcte.
Avant de partager la sortie du terminal, supprimez les noms d’utilisateur, mots de passe, jetons et URL contenant des identifiants. Les erreurs de proxy peuvent inclure l’adresse complète de la requête, et l’historique du shell peut conserver les commandes contenant des secrets. Communiquez plutôt le type d’erreur, le nom d’hôte de destination, le nom de l’outil et l’heure de l’échec ; ces informations suffisent souvent à l’équipe réseau pour consulter ses journaux.
Si le proxy fonctionne dans un Codespace, mais pas dans un autre, comparez la configuration de leurs conteneurs, l’image du système d’exploitation, les variables d’environnement et l’installation des certificats. Ne changez qu’un élément à la fois, puis répétez le même test. Vous pourrez ainsi déterminer plus facilement si le problème vient d’une variable manquante, d’une destination bloquée ou d’une différence dans le magasin de certificats.