Sommaire de l'article

Imaginez : vous ouvrez un terminal, vous tapez une commande d'installation de paquet, et en réponse, silence ou erreur de connexion. Souvent, la raison est que l'accès au réseau ne passe que par un serveur proxy, et le système ne le sait pas. Ce guide vous apprendra à configurer le proxy partout où c'est nécessaire sous Linux et dans le CI.

Introduction : ce que vous allez obtenir et à qui ce guide s'adresse

À la fin de ce guide, vous saurez configurer le proxy dans le terminal Linux et dans les systèmes d'intégration continue en toute confiance. Vous comprendrez comment fonctionnent les variables d'environnement, comment construire correctement l'URL du proxy, et comment faire passer tout l'arsenal d'outils du développeur à travers le proxy.

Ce que vous obtiendrez exactement :

  • Une configuration fonctionnelle du proxy dans la session terminal en cours.
  • Une configuration permanente qui survivra au redémarrage.
  • Une configuration correcte pour apt, dnf, git, npm, pip, curl, wget, Docker.
  • Des pipelines CI qui fonctionnent dans GitHub Actions et GitLab Runner.
  • La compréhension de la façon de vérifier que le trafic passe bien par le proxy.
  • Les compétences pour stocker en toute sécurité le mot de passe du proxy.

À qui s'adresse ce guide : aux administrateurs système débutants, aux développeurs et aux ingénieurs DevOps qui travaillent dans un environnement avec un proxy d'entreprise. Il y a aussi des éléments pour les avancés : les subtilités de systemd, ProxyCommand pour SSH et le masquage des secrets dans le CI.

Ce que vous devez savoir à l'avance : vous devez savoir ouvrir un terminal, taper des commandes et comprendre ce qu'est un fichier et un dossier. Tout le reste est expliqué en cours de route dans un langage simple.

Temps nécessaire : la configuration de base prendra environ 15 minutes. Le parcours complet du guide avec la configuration de tous les outils et du CI – environ 60 à 90 minutes. Ne vous précipitez pas, il vaut mieux faire les choses avec réflexion.

Conseil : gardez ce guide ouvert dans une fenêtre séparée et exécutez les commandes une par une. Ainsi, vous ne manquerez aucune étape importante.

Préparation préliminaire : adresse, port, identifiant et URL correcte du proxy

Avant de configurer quoi que ce soit, vous devez rassembler les informations sur votre serveur proxy. Sans elles, il est impossible d'aller plus loin.

Où trouver les données du proxy

Généralement, le proxy est fourni par l'une des parties suivantes :

  • L'administrateur système de l'entreprise – si vous travaillez dans un réseau d'entreprise. Demandez-lui l'adresse, le port et les données d'authentification.
  • Un service de location de proxy – dans votre compte personnel, il y a généralement une section avec les paramètres d'accès.
  • Votre propre serveur – si vous avez monté un proxy vous-même, vous connaissez les données.

Vous avez besoin de quatre éléments : l'adresse (host), le port (port), l'identifiant (username) et le mot de passe (password). Parfois, l'identifiant et le mot de passe ne sont pas nécessaires – le proxy est alors sans authentification.

Comment construire l'URL du proxy

Le proxy est spécifié sous forme d'une chaîne unique – une URL. Le format général est le suivant :

schéma://identifiant:motdepasse@adresse:port

Prenons un exemple. Supposons que l'adresse du proxy soit proxy.example.com, le port 3128, l'identifiant ivan, le mot de passe secret123. L'URL ressemblera alors à :

http://ivan:secret123@proxy.example.com:3128

Si l'authentification n'est pas nécessaire, l'URL est plus simple :

http://proxy.example.com:3128

À propos du schéma : le plus souvent, on utilise le schéma http même pour accéder à des sites HTTPS. C'est normal – le schéma désigne ici le protocole de communication avec le proxy lui-même, pas avec le site cible. Parfois, on rencontre des proxies avec le schéma https ou socks5.

Pourquoi les caractères spéciaux dans le mot de passe doivent être encodés

C'est l'une des causes les plus fréquentes d'erreurs mystérieuses. Si le mot de passe contient des caractères spéciaux comme @, :, /, #, ?, ils cassent l'analyse de l'URL. Par exemple, le symbole @ sépare les données d'authentification de l'adresse. S'il se trouve dans le mot de passe, le système s'embrouille et ne comprend pas où se termine le mot de passe et où commence l'adresse.

La solution est l'encodage en pourcentage (percent-encoding). Chaque caractère problématique est remplacé par un signe de pourcentage et son code en hexadécimal.

Les remplacements principaux :

  • Le symbole @ devient %40
  • Le symbole : devient %3A
  • Le symbole / devient %2F
  • Le symbole # devient %23
  • Le symbole ? devient %3F
  • Le symbole espace devient %20
  • Le symbole % devient %25

Exemple : si le mot de passe est p@ss:word, alors dans l'URL il doit ressembler à p%40ss%3Aword. L'URL complète sera alors :

http://ivan:p%40ss%3Aword@proxy.example.com:3128

Conseil : pour encoder rapidement un mot de passe, utilisez la commande python3 -c "import urllib.parse, sys; print(urllib.parse.quote(sys.argv[1], safe=''))" 'votre_mot_de_passe'. Elle produira une chaîne prête à être insérée dans l'URL.

⚠️ Attention : ne saisissez jamais un mot de passe réel directement dans la ligne de commande sur un ordinateur partagé – il finira dans l'historique. Nous parlerons de la saisie sécurisée séparément à la fin du guide.

✅ Vérification : vous devez avoir en main une ou plusieurs URL de proxy construites, où tous les caractères spéciaux du mot de passe sont encodés. Notez-les dans un endroit sûr, de préférence dans un gestionnaire de mots de passe.

Notions de base : variables d'environnement, casse et format de NO_PROXY

Pour que la configuration ne soit pas magique, examinons trois notions fondamentales. Cela prendra cinq minutes mais vous fera gagner des heures de débogage.

Que sont les variables d'environnement

Une variable d'environnement est une valeur nommée que le système d'exploitation conserve en mémoire et transmet aux programmes lancés. Imaginez cela comme un mot que le système montre à chaque nouveau programme : voici l'adresse du proxy, utilise-la.

De nombreux utilitaires réseau sous Linux lisent des variables spéciales au démarrage et, s'ils les trouvent, dirigent automatiquement le trafic via le proxy. Les plus importantes sont :

  • HTTP_PROXY – proxy pour les requêtes HTTP non chiffrées.
  • HTTPS_PROXY – proxy pour les requêtes HTTPS chiffrées.
  • NO_PROXY – liste des adresses à contacter directement, en contournant le proxy.
  • FTP_PROXY – proxy pour le protocole FTP, rarement utilisé de nos jours.
  • ALL_PROXY – proxy pour tous les protocoles à la fois, souvent utilisé pour socks.

La différence entre http_proxy et HTTP_PROXY selon la casse

C'est un point subtil mais important. Linux distingue la casse des lettres, donc http_proxy et HTTP_PROXY sont formellement deux variables différentes. Différents programmes lisent différentes variantes.

Historiquement, la situation est la suivante :

  • L'utilitaire curl lit à la fois les versions minuscules et majuscules, mais la version minuscule http_proxy a une particularité de sécurité – la version majuscule HTTP_PROXY est ignorée par curl dans un environnement CGI pour éviter les attaques.
  • L'utilitaire wget préfère traditionnellement les noms en minuscules.
  • De nombreux programmes dans différents langages lisent les versions majuscules.

Conclusion pratique : pour ne pas avoir à deviner, définissez les deux versions – minuscule et majuscule. C'est la stratégie la plus fiable, que nous utiliserons.

Le format de NO_PROXY et pourquoi il ne comprend pas le CIDR

La variable NO_PROXY contient une liste séparée par des virgules des adresses à contacter directement. C'est crucial pour les ressources internes : bases de données, services locaux, métadonnées du cloud.

Exemple de valeur correcte :

localhost,127.0.0.1,.example.com,.internal,169.254.169.254

Notez le point avant example.com. Le point signifie que tous les sous-domaines sont concernés : api.example.com, git.example.com, etc.

⚠️ Attention : NO_PROXY ne comprend généralement pas la notation CIDR ni les masques de sous-réseau. Une écriture comme 10.0.0.0/8 ne fonctionnera pas dans la plupart des outils. Certaines versions récentes des bibliothèques le supportent, mais on ne peut pas s'y fier. Listez explicitement les adresses spécifiques et les suffixes de domaine.

De plus, NO_PROXY ne supporte généralement pas les astérisques comme motif universel. N'écrivez pas *.example.com – utilisez un point au début : .example.com.

Conseil : ajoutez toujours à NO_PROXY l'adresse localhost et 127.0.0.1. Sinon, les requêtes locales passeront par le proxy et, très probablement, échoueront.

✅ Vérification : vous comprenez à quoi servent HTTP_PROXY, HTTPS_PROXY et NO_PROXY, vous connaissez la différence de casse et vous vous souvenez que NO_PROXY n'aime pas le CIDR. Vous pouvez maintenant passer à la pratique.

Étape 1 : activer le proxy dans la session en cours et vérifier avec curl

Objectif de l'étape : apprendre à activer rapidement le proxy dans un terminal ouvert et vérifier qu'il fonctionne. Ces réglages ne vivent que jusqu'à la fermeture de la fenêtre du terminal – idéal pour un test.

Définir les variables avec export

La commande export crée une variable d'environnement dans la session en cours. Exécutez les commandes suivantes en remplaçant par votre URL de proxy.

  1. Ouvrez un terminal.
  2. Tapez la commande pour HTTP : export http_proxy="http://ivan:secret123@proxy.example.com:3128"
  3. Tapez la commande pour HTTPS : export https_proxy="http://ivan:secret123@proxy.example.com:3128"
  4. Dupliquez en majuscule : export HTTP_PROXY="$http_proxy"
  5. Encore une fois : export HTTPS_PROXY="$https_proxy"
  6. Définissez les exceptions : export no_proxy="localhost,127.0.0.1,.example.com"
  7. Dupliquez : export NO_PROXY="$no_proxy"

La construction "$http_proxy" insère la valeur de la variable minuscule déjà définie, pour ne pas avoir à retaper l'URL.

Conseil : notez que toute l'URL est entourée de guillemets doubles. Cela protège contre une interprétation incorrecte des caractères spéciaux par votre shell bash.

Vérifier avec curl

Maintenant, vérifions que les variables sont lues. L'utilitaire curl est parfait pour cela.

  1. Vérifiez que la variable est définie : echo $http_proxy – vous devriez voir votre URL.
  2. Effectuez une requête avec sortie détaillée : curl -v http://example.com
  3. Dans la sortie, cherchez une ligne mentionnant Connected to proxy.example.com – cela signifie que curl est passé par le proxy.

Si l'authentification est correcte et que le proxy est accessible, vous obtiendrez une page HTML en réponse. Si vous voyez une erreur 407, le problème vient de l'identifiant ou du mot de passe – retournez à la section sur l'encodage du mot de passe.

Conseil : le drapeau -v (verbose) affiche les détails de la connexion. C'est votre principal outil de débogage du proxy. Sans lui, vous ne verrez pas où va exactement la requête.

Pour désactiver le proxy dans la session en cours, utilisez la commande unset : unset http_proxy https_proxy HTTP_PROXY HTTPS_PROXY no_proxy NO_PROXY. Toutes les variables disparaîtront.

✅ Vérification : la commande curl -v http://example.com montre une connexion via votre serveur proxy et retourne le contenu de la page. Si oui, la première étape est réussie.

Étape 2 : rendre la configuration permanente

Objectif de l'étape : faire en sorte que le proxy s'active automatiquement à chaque connexion et survive au redémarrage. Il y a plusieurs niveaux, choisissez celui qui convient.

Option A : uniquement pour votre utilisateur avec ~/.bashrc

Le fichier ~/.bashrc est exécuté à chaque ouverture d'un terminal interactif sous votre utilisateur. C'est l'option la plus sûre – vous ne touchez pas aux autres utilisateurs du système.

  1. Ouvrez le fichier avec un éditeur : nano ~/.bashrc
  2. Descendez tout en bas du fichier.
  3. Ajoutez les mêmes lignes export que dans l'Étape 1.
  4. Enregistrez le fichier : appuyez sur Ctrl+O, puis Entrée, puis Ctrl+X pour quitter.
  5. Appliquez les modifications sans redémarrer : source ~/.bashrc

Conseil : avant de modifier, faites une copie de sauvegarde avec la commande cp ~/.bashrc ~/.bashrc.backup. Si quelque chose ne va pas, vous pourrez facilement restaurer l'original.

Option B : pour tout le système via /etc/environment

Le fichier /etc/environment définit les variables pour tous les utilisateurs et fonctionne même en dehors de bash. Le format ici est particulier : sans le mot export, simplement NOM=valeur.

  1. Ouvrez le fichier avec les droits administrateur : sudo nano /etc/environment
  2. Ajoutez des lignes sans export, par exemple : http_proxy="http://ivan:secret123@proxy.example.com:3128"
  3. Ajoutez de même https_proxy, HTTP_PROXY, HTTPS_PROXY, no_proxy, NO_PROXY.
  4. Enregistrez et quittez.
  5. Pour appliquer, déconnectez-vous et reconnectez-vous, ou redémarrez.

Option C : via /etc/profile.d

Une méthode système plus flexible consiste à créer un script séparé dans le dossier /etc/profile.d. Tous les fichiers .sh qui s'y trouvent sont exécutés à la connexion.

  1. Créez le fichier : sudo nano /etc/profile.d/proxy.sh
  2. À l'intérieur, utilisez les commandes export normales, comme dans l'Étape 1.
  3. Enregistrez le fichier.
  4. Rendez-le exécutable : sudo chmod +x /etc/profile.d/proxy.sh

Cette méthode est plus pratique que /etc/environment car elle supporte une syntaxe shell complète.

Option D : pour les services système via un drop-in systemd

Attention, c'est un point important. Les services en arrière-plan gérés par systemd ne lisent pas votre ~/.bashrc et ignorent souvent /etc/environment. Ils nécessitent une approche séparée – un fichier drop-in.

Supposons que vous ayez besoin qu'un service spécifique, par exemple some-service, fonctionne via le proxy.

  1. Créez le répertoire drop-in et le fichier avec la commande : sudo systemctl edit some-service
  2. Un éditeur s'ouvrira. Saisissez le bloc de configuration.
  3. Dans la section [Service], ajoutez des lignes comme Environment="HTTP_PROXY=http://ivan:secret123@proxy.example.com:3128"
  4. Ajoutez des lignes Environment similaires pour HTTPS_PROXY et NO_PROXY.
  5. Enregistrez le fichier.
  6. Rechargez la configuration : sudo systemctl daemon-reload
  7. Redémarrez le service : sudo systemctl restart some-service

La directive Environment définit la variable spécifiquement pour ce service. C'est la seule manière correcte pour les services systemd.

⚠️ Attention : sur RHEL, CentOS, Fedora et AlmaLinux, les chemins et les outils sont les mêmes – systemd fonctionne de manière identique. Les différences apparaîtront plus tard, dans la section sur les gestionnaires de paquets.

✅ Vérification : ouvrez un nouveau terminal (pas celui où vous avez fait export manuellement) et exécutez echo $http_proxy. Si vous voyez votre URL, la configuration permanente fonctionne.

Étape 3 : configurer les gestionnaires de paquets et les utilitaires individuellement

Objectif de l'étape : de nombreux outils ne lisent pas les variables d'environnement ou ont leurs propres fichiers de configuration. Configurons chacun séparément pour que rien ne tombe en panne.

apt sur Ubuntu et Debian

Le gestionnaire de paquets apt est souvent lancé via sudo et peut ne pas voir vos variables. Il est plus fiable de définir le proxy dans son propre fichier de configuration.

  1. Créez le fichier : sudo nano /etc/apt/apt.conf.d/95proxies
  2. Ajoutez la ligne : Acquire::http::Proxy "http://ivan:secret123@proxy.example.com:3128";
  3. Ajoutez la ligne pour HTTPS : Acquire::https::Proxy "http://ivan:secret123@proxy.example.com:3128";
  4. Enregistrez le fichier.
  5. Vérifiez : sudo apt update

Notez le point-virgule à la fin de chaque ligne – c'est un élément obligatoire de la syntaxe d'apt.

dnf et yum sur RHEL, Fedora, AlmaLinux

Sur les systèmes de la famille RHEL, on utilise dnf et yum à la place d'apt. Le proxy est défini dans le fichier de configuration principal.

  1. Ouvrez le fichier : sudo nano /etc/dnf/dnf.conf (pour les anciens systèmes /etc/yum.conf)
  2. Dans la section [main], ajoutez la ligne : proxy=http://proxy.example.com:3128
  3. Si l'authentification est nécessaire, ajoutez séparément : proxy_username=ivan et proxy_password=secret123
  4. Enregistrez le fichier.
  5. Vérifiez : sudo dnf makecache

Dans dnf, l'identifiant et le mot de passe sont plus faciles à définir avec des directives séparées, plutôt qu'à l'intérieur de l'URL.

npm via .npmrc

  1. Définissez le proxy avec la commande : npm config set proxy "http://ivan:secret123@proxy.example.com:3128"
  2. Définissez pour HTTPS : npm config set https-proxy "http://ivan:secret123@proxy.example.com:3128"
  3. Les paramètres seront écrits automatiquement dans le fichier ~/.npmrc.
  4. Vérifiez : npm config get proxy

pip via pip.conf

  1. Créez le répertoire : mkdir -p ~/.config/pip
  2. Ouvrez le fichier : nano ~/.config/pip/pip.conf
  3. Ajoutez la section [global] et la ligne proxy = http://ivan:secret123@proxy.example.com:3128
  4. Enregistrez le fichier.
  5. Vérifiez en installant un paquet : pip install requests

Alternativement, vous pouvez spécifier le proxy directement dans la commande : pip install requests --proxy http://proxy.example.com:3128

git via http.proxy

  1. Définissez globalement : git config --global http.proxy "http://ivan:secret123@proxy.example.com:3128"
  2. Si nécessaire, séparément pour HTTPS : git config --global https.proxy "http://ivan:secret123@proxy.example.com:3128"
  3. Vérifiez : git config --global --get http.proxy

Pour supprimer le paramètre : git config --global --unset http.proxy

git via SSH avec ProxyCommand

Si vous clonez des dépôts via SSH (adresse du type git@github.com), la configuration http.proxy n'aidera pas – SSH est un protocole différent. Ici, il faut utiliser ProxyCommand.

  1. Ouvrez le fichier : nano ~/.ssh/config
  2. Ajoutez un bloc pour l'hôte concerné : ligne Host github.com, puis en retrait la ligne ProxyCommand nc -X connect -x proxy.example.com:3128 %h %p
  3. Enregistrez le fichier.
  4. Installez l'utilitaire netcat s'il n'est pas présent : sudo apt install netcat-openbsd sur Ubuntu, sudo dnf install nmap-ncat sur RHEL.

Ici, %h et %p sont automatiquement remplacés par l'hôte et le port de destination. Le drapeau -X connect indique à netcat d'utiliser un proxy HTTP.

curl via .curlrc

  1. Ouvrez le fichier : nano ~/.curlrc
  2. Ajoutez la ligne : proxy = "http://ivan:secret123@proxy.example.com:3128"
  3. Enregistrez le fichier.

Maintenant, curl utilisera le proxy en permanence, même sans variables d'environnement.

wget via .wgetrc

  1. Ouvrez le fichier : nano ~/.wgetrc
  2. Ajoutez les lignes : http_proxy = http://proxy.example.com:3128 et https_proxy = http://proxy.example.com:3128
  3. Ajoutez use_proxy = on
  4. Enregistrez le fichier.

composer pour PHP

Composer lit la variable d'environnement HTTP_PROXY, donc une configuration séparée n'est souvent pas nécessaire. Si vous voulez la définir explicitement, utilisez la variable au moment du lancement : HTTP_PROXY=http://proxy.example.com:3128 composer install

Go et GOPROXY : un avertissement important

⚠️ Attention : la variable GOPROXY n'est PAS un serveur proxy dans notre sens. Il ne faut pas les confondre. GOPROXY indique un miroir de modules Go – un service d'où sont téléchargées les bibliothèques. C'est l'adresse d'un dépôt, pas d'un proxy réseau.

Pour que Go accède à Internet via votre proxy habituel, utilisez les variables HTTP_PROXY et HTTPS_PROXY standard. Et laissez GOPROXY avec sa valeur par défaut, sauf si vous avez une tâche spécifique de changer de miroir de modules.

Conseil : retenez la règle : si le nom d'une variable contient le mot PROXY, cela ne signifie pas forcément qu'elle concerne votre proxy réseau. GOPROXY, npm registry et autres sont liés aux sources de paquets.

✅ Vérification : effectuez une opération de test avec chaque outil configuré : sudo apt update, npm install, git ls-remote, etc. Tous doivent réussir à joindre le réseau.

Étape 4 : configurer Docker et Kubernetes

Objectif de l'étape : Docker est un cas particulier. Il a trois endroits différents pour configurer le proxy, et les confondre est une erreur typique. Examinons chacun.

Emplacement 1 : le démon Docker via un drop-in systemd

Cette configuration est nécessaire pour que Docker lui-même puisse télécharger des images depuis le registre. Le démon Docker est géré par systemd, donc nous utilisons le mécanisme drop-in déjà connu.

  1. Créez le répertoire : sudo mkdir -p /etc/systemd/system/docker.service.d
  2. Créez le fichier : sudo nano /etc/systemd/system/docker.service.d/proxy.conf
  3. Ajoutez la section [Service].
  4. Ajoutez la ligne Environment="HTTP_PROXY=http://proxy.example.com:3128"
  5. Ajoutez des lignes similaires pour HTTPS_PROXY et NO_PROXY.
  6. Rechargez la configuration : sudo systemctl daemon-reload
  7. Redémarrez Docker : sudo systemctl restart docker

Vous pouvez vérifier avec la commande : sudo systemctl show --property=Environment docker

Emplacement 2 : la construction d'image via build-arg

Lors de la construction d'une image, les commandes à l'intérieur du Dockerfile (par exemple apt install) s'exécutent dans un environnement isolé qui ne voit pas le proxy de l'hôte. Le proxy doit être passé explicitement.

  1. Dans le Dockerfile, ajoutez les instructions ARG http_proxy et ARG https_proxy avant les commandes RUN.
  2. Construisez l'image en passant les arguments : docker build --build-arg http_proxy=http://proxy.example.com:3128 --build-arg https_proxy=http://proxy.example.com:3128 -t monimage .

⚠️ Attention : n'inscrivez pas le mot de passe du proxy directement dans le Dockerfile avec l'instruction ENV. Il resterait dans les couches de l'image, et quiconque obtiendrait l'image verrait le mot de passe. Utilisez plutôt build-arg, ou mieux, un proxy sans mot de passe pour la construction.

Emplacement 3 : les conteneurs au lancement via ~/.docker/config.json

Pour que les conteneurs lancés reçoivent automatiquement les variables de proxy, configurez le fichier de configuration client de Docker.

  1. Ouvrez le fichier : nano ~/.docker/config.json
  2. Ajoutez le bloc proxies avec la section default.
  3. À l'intérieur, spécifiez httpProxy, httpsProxy et noProxy avec leurs valeurs.
  4. Enregistrez le fichier.

Maintenant, à chaque docker run, les variables seront automatiquement transmises à l'intérieur du conteneur.

Variables dans le manifeste Kubernetes

Dans Kubernetes, le proxy est défini via des variables d'environnement dans la spécification du conteneur. Dans la section env du manifeste Pod ou Deployment, ajoutez des éléments avec name HTTP_PROXY, HTTPS_PROXY, NO_PROXY et les value correspondantes.

Conseil : les valeurs secrètes dans Kubernetes doivent être stockées dans un objet Secret et liées via valueFrom, plutôt que d'écrire le mot de passe directement dans le manifeste. Ainsi, le mot de passe ne se retrouvera pas dans le système de contrôle de version.

✅ Vérification : exécutez docker pull hello-world – l'image doit se télécharger. Ensuite, docker run --rm alpine env | grep -i proxy – vous verrez les variables transmises à l'intérieur du conteneur.

Étape 5 : configurer le proxy dans le CI – GitHub Actions et GitLab Runner

Objectif de l'étape : faire fonctionner les pipelines CI via le proxy, tout en stockant l'accès de manière sécurisée et sans exposer le mot de passe dans les logs.

Stocker l'accès dans les secrets

Règle d'or du CI : n'écrivez jamais le mot de passe du proxy directement dans le fichier YAML du pipeline. Le fichier se trouve dans le dépôt, et tout le monde verra le mot de passe. Utilisez le mécanisme des secrets.

Dans GitHub Actions, les secrets sont ajoutés dans les paramètres du dépôt, section Settings, puis Secrets and variables, puis Actions. Créez un secret nommé PROXY_URL et insérez-y l'URL complète du proxy.

Dans GitLab, les secrets sont appelés CI/CD variables. Ils sont ajoutés dans Settings, puis CI/CD, puis Variables. Assurez-vous de cocher les cases Masked et Protected pour les valeurs sensibles.

Configuration de GitHub Actions

  1. Dans le fichier du pipeline .github/workflows, ajoutez au niveau du job un bloc env.
  2. Définissez HTTP_PROXY avec la valeur du secret via la syntaxe des doubles accolades avec secrets.PROXY_URL.
  3. Faites de même pour HTTPS_PROXY et NO_PROXY.
  4. Ces variables seront disponibles pour toutes les étapes du job.

Configuration de GitLab Runner

Dans GitLab, il y a deux niveaux. Vous pouvez définir les variables dans le fichier .gitlab-ci.yml lui-même avec un bloc variables, ou au niveau du runner dans son fichier de configuration config.toml avec la section environment.

  1. Pour le projet : ajoutez dans .gitlab-ci.yml un bloc variables avec des références aux variables protégées.
  2. Pour tous les projets du runner : ouvrez config.toml du runner et dans la section [[runners]], ajoutez le paramètre environment avec la liste des variables nécessaires.

Masquage du mot de passe dans les logs

Même avec les secrets, le mot de passe peut accidentellement se retrouver dans le log si une commande l'affiche. GitHub Actions masque automatiquement les valeurs des secrets avec des astérisques. Dans GitLab, c'est la case Masked qui s'en charge – mais elle ne fonctionne que si la valeur répond à certaines exigences (pas de caractères spéciaux interdits et longueur suffisante).

⚠️ Attention : évitez les commandes avec le drapeau -v ou echo qui afficheraient l'URL complète du proxy dans le log. Même avec le masquage, il vaut mieux ne pas prendre de risques. Pour le débogage, n'affichez que l'adresse et le port sans l'identifiant ni le mot de passe.

Conseil : stockez l'URL du proxy sans mot de passe intégré, et l'identifiant ainsi que le mot de passe dans des secrets séparés. Ainsi, ils seront plus faciles à masquer et à faire tourner.

✅ Vérification : lancez le pipeline manuellement. L'étape qui effectue une requête réseau (par exemple l'installation des dépendances) doit se terminer avec succès. Le mot de passe ne doit pas être visible dans les logs.

Vérification du résultat : s'assurer que le trafic passe bien par le proxy

Configurer, ce n'est pas assez – il faut prouver que le trafic passe effectivement par le proxy et non directement. Voici une liste de vérifications.

Liste de ce qui doit fonctionner

  • La commande echo $http_proxy dans un nouveau terminal affiche votre URL.
  • curl -v http://example.com montre une ligne Connected to proxy.
  • sudo apt update met à jour les listes de paquets avec succès.
  • git ls-remote vers un dépôt distant fonctionne.
  • docker pull télécharge une image.
  • Le pipeline CI se termine en vert.

Comment tester de manière fiable

La méthode la plus honnête est de connaître l'adresse IP externe que le serveur de destination voit. Effectuez une requête vers un service qui affiche votre IP. Si vous êtes derrière un proxy, vous verrez l'adresse IP du serveur proxy, et non la vôtre.

  1. Effectuez une requête sans proxy : env -u http_proxy -u https_proxy curl -s http://ifconfig.me – vous verrez votre vraie IP.
  2. Effectuez une requête avec proxy : curl -s http://ifconfig.me – vous verrez l'IP du proxy.
  3. Si les deux adresses sont différentes – le proxy fonctionne.

Une autre méthode est de consulter les logs du serveur proxy lui-même, si vous y avez accès. Vos requêtes doivent y apparaître.

Conseil : la commande env -u supprime temporairement une variable pour une seule commande, sans affecter la session. Pratique pour comparer le comportement avec et sans proxy.

✅ Vérification : l'adresse IP avec le proxy est différente de l'adresse directe. C'est une preuve à 100 % que le trafic passe par le proxy.

Erreurs typiques et leurs solutions

Examinons les problèmes fréquents. Format simple : problème, cause, solution.

Problème 1 : sudo n'hérite pas des variables

Cause : sudo efface l'environnement par défaut pour des raisons de sécurité. Vos export n'atteignent pas la commande sous sudo.

Solution : utilisez le drapeau -E pour préserver l'environnement : sudo -E apt update. Ou configurez une conservation permanente via le fichier sudoers. Exécutez sudo visudo et ajoutez la ligne Defaults env_keep += "http_proxy https_proxy HTTP_PROXY HTTPS_PROXY no_proxy NO_PROXY". Après cela, sudo laissera passer ces variables en permanence.

Problème 2 : erreurs de certificats

Cause : certains proxies d'entreprise interceptent le HTTPS et remplacent les certificats par leur propre certificat racine. Le système ne le connaît pas et se plaint d'une connexion non fiable.

Solution : obtenez le certificat racine du proxy auprès de l'administrateur. Sur Ubuntu et Debian, copiez-le dans /usr/local/share/ca-certificates avec l'extension .crt et exécutez sudo update-ca-certificates. Sur RHEL, placez-le dans /etc/pki/ca-trust/source/anchors et exécutez sudo update-ca-trust. Après cela, tous les outils feront confiance au proxy.

Problème 3 : curl fonctionne, apt ne fonctionne pas

Cause : curl lit les variables d'environnement, tandis qu'apt sous sudo ne les voit pas et n'a pas sa propre configuration de proxy.

Solution : configurez le proxy dans /etc/apt/apt.conf.d, comme décrit à l'Étape 3. C'est une configuration distincte des variables d'environnement, et c'est celle dont apt a besoin.

Problème 4 : mot de passe avec caractères spéciaux

Cause : les caractères @, :, / dans un mot de passe non encodé cassent l'analyse de l'URL.

Solution : appliquez le percent-encoding de la section Préparation. Remplacez @ par %40, : par %3A, etc.

Problème 5 : erreur 407 Proxy Authentication Required

Cause : identifiant ou mot de passe incorrect, ou le proxy exige une authentification que vous n'avez pas fournie.

Solution : revérifiez l'identifiant et le mot de passe. Assurez-vous que les données d'authentification sont présentes dans l'URL. Vérifiez l'encodage des caractères spéciaux.

Problème 6 : ressources internes inaccessibles

Cause : les requêtes vers des adresses locales et internes passent par le proxy, qui ne les connaît pas.

Solution : ajoutez ces adresses dans NO_PROXY. N'oubliez pas localhost, 127.0.0.1 et les domaines internes avec un point au début.

Problème 7 : le démon Docker ne voit pas le proxy

Cause : vous avez configuré les variables dans bashrc, mais le démon Docker est géré par systemd et ne les lit pas.

Solution : utilisez le drop-in systemd de l'Étape 4, n'oubliez pas daemon-reload et restart docker.

Problème 8 : les paramètres ne s'appliquent pas

Cause : vous avez édité bashrc mais n'avez pas redémarré le terminal.

Solution : exécutez source ~/.bashrc ou ouvrez une nouvelle fenêtre de terminal.

Fonctionnalités supplémentaires et configurations avancées

Une fois la configuration de base en place, vous pouvez améliorer le confort et la flexibilité.

Fonctions d'interrupteur de proxy

Il est pratique d'ajouter deux fonctions dans ~/.bashrc : proxy_on pour activer et proxy_off pour désactiver. À l'intérieur de proxy_on, placez les commandes export ; à l'intérieur de proxy_off, les commandes unset. Ainsi, le basculement se fait en une seule commande.

Différents proxies pour différentes tâches

Vous pouvez définir un proxy uniquement pour une commande, sans modifier tout l'environnement. Exemple : https_proxy=http://autre:3128 curl https://example.com. La variable n'agit que pour cette commande.

Proxy SOCKS

Si vous avez un proxy de type SOCKS5, utilisez le schéma socks5 dans l'URL et la variable ALL_PROXY. Pour curl, il y a le drapeau --socks5. Notez que tous les utilitaires ne savent pas gérer SOCKS.

Conseil : pour les outils qui ne savent pas du tout gérer le proxy, il existe des wrappers comme proxychains. Mais utilisez-les en connaissance de cause, car ils modifient le comportement des appels réseau du programme.

Tableau récapitulatif des configurations

Gardez ce récapitulatif sous la main. Format : outil — fichier de configuration — variable ou directive.

  • Session shell — temporaire en mémoire — export http_proxy et HTTP_PROXY.
  • Utilisateur — ~/.bashrc — export des variables.
  • Tout le système — /etc/environment — http_proxy sans export.
  • Tout le système — /etc/profile.d/proxy.sh — export des variables.
  • Service systemd — drop-in via systemctl edit — directive Environment.
  • apt (Ubuntu, Debian) — /etc/apt/apt.conf.d/95proxies — Acquire::http::Proxy.
  • dnf, yum (RHEL) — /etc/dnf/dnf.conf — proxy, proxy_username, proxy_password.
  • npm — ~/.npmrc — proxy et https-proxy.
  • pip — ~/.config/pip/pip.conf — proxy dans la section global.
  • git via HTTPS — configuration globale git — http.proxy.
  • git via SSH — ~/.ssh/config — ProxyCommand.
  • curl — ~/.curlrc — proxy.
  • wget — ~/.wgetrc — http_proxy, https_proxy, use_proxy.
  • composer — environnement — HTTP_PROXY.
  • Démon Docker — /etc/systemd/system/docker.service.d/proxy.conf — Environment.
  • Construction Docker — commande build — build-arg http_proxy.
  • Conteneurs Docker — ~/.docker/config.json — bloc proxies.
  • Kubernetes — manifeste Pod — env avec HTTP_PROXY.
  • GitHub Actions — fichier workflow — bloc env avec secrets.
  • GitLab — .gitlab-ci.yml ou config.toml — variables ou environment.

FAQ : questions fréquentes sur la configuration du proxy

Faut-il définir à la fois les variables minuscules et majuscules ?

Oui, c'est la stratégie la plus fiable. Différents programmes lisent différentes casses, donc définir les deux versions élimine les surprises.

Pourquoi curl voit le proxy mais pas apt ?

Parce qu'apt sous sudo n'hérite pas des variables d'environnement et a sa propre configuration. Configurez apt séparément via le fichier dans /etc/apt/apt.conf.d.

Comment désactiver temporairement le proxy pour une seule commande ?

Utilisez env -u http_proxy -u https_proxy avant la commande. Cela supprime les variables uniquement pour cette exécution.

Peut-on spécifier un sous-réseau dans NO_PROXY ?

En général, non. NO_PROXY ne comprend pas la notation CIDR de manière fiable. Listez les adresses spécifiques et les suffixes de domaine avec un point au début.

GOPROXY est-il mon serveur proxy ?

Non. GOPROXY indique un miroir de modules Go, pas un proxy réseau. Pour le proxy réseau dans Go, utilisez HTTP_PROXY et HTTPS_PROXY.

Comment stocker le mot de passe du proxy en toute sécurité ?

Dans le CI, utilisez les secrets. Localement, utilisez le fichier .netrc avec les droits 600 ou un gestionnaire de mots de passe. Évitez que le mot de passe se retrouve dans l'historique des commandes.

Pourquoi git via SSH ne passe-t-il pas par http.proxy ?

Parce que SSH est un protocole distinct. Configurez ProxyCommand dans le fichier ~/.ssh/config pour l'hôte concerné.

Que faire en cas d'erreurs de certificat via le proxy ?

Installez le certificat racine du proxy dans le magasin système et mettez à jour la confiance avec la commande update-ca-certificates sur Debian ou update-ca-trust sur RHEL.

Les paramètres dans bashrc ne fonctionnent pas dans une nouvelle session, pourquoi ?

Vous avez peut-être modifié le mauvais fichier, ou vous n'avez pas sauvegardé les modifications, ou vous n'avez pas ouvert un nouveau terminal. Vérifiez avec echo et source.

Comment vérifier que le trafic passe vraiment par le proxy ?

Comparez l'IP externe avec et sans proxy à l'aide de la commande curl vers un service de détermination d'IP. Des adresses différentes confirment le fonctionnement du proxy.

Conclusion : ce que vous avez appris et comment aller plus loin

Félicitations, vous avez parcouru un long chemin. Résumons ce que vous savez maintenant faire.

Vous avez appris à construire une URL de proxy correcte et à encoder les caractères spéciaux dans le mot de passe. Vous maîtrisez les variables HTTP_PROXY, HTTPS_PROXY et NO_PROXY, y compris les subtilités de casse et le format des exceptions. Vous savez activer le proxy dans une session et rendre la configuration permanente de plusieurs façons, y compris avec le drop-in systemd pour les services.

Vous avez configuré le proxy pour tous les outils clés : apt et dnf, npm et pip, git via HTTPS et SSH, curl et wget, composer, et vous avez compris l'importance de la différence avec GOPROXY. Vous maîtrisez les trois emplacements de configuration de Docker et les variables dans Kubernetes. Enfin, vous avez configuré le proxy dans GitHub Actions et GitLab avec un stockage sécurisé des secrets et le masquage du mot de passe.

Que faire ensuite : consolidez vos connaissances avec la pratique. Configurez le proxy sur une machine de test à partir de zéro, en suivant le guide. Créez des fonctions d'interrupteur pour plus de commodité. Étudiez les logs de votre serveur proxy pour voir le trafic de vos propres yeux.

Où aller : la prochaine étape est l'automatisation de la configuration via des outils de gestion de configuration comme Ansible, pour déployer le proxy sur des dizaines de machines en une seule commande. Il est également utile d'approfondir la gestion des certificats et des différents types de proxy.

Conseil : conservez le tableau récapitulatif de ce guide comme aide-mémoire. Il vous fera gagner un temps précieux lorsque vous aurez besoin de vous rappeler rapidement où configurer le proxy pour un outil spécifique.

Vous avez fait un excellent travail. Désormais, le proxy dans le terminal Linux et dans le CI n'a plus de secrets pour vous. Bonne configuration et connexions stables.