← Retour au blog
RUENZHESARPTDEFRJAKOITTRIDVIFAHI

Proxies pour GitLab : comment configurer l'accès pour l'équipe et les pipelines CI/CD sans interruptions

GitLab est bloqué ou inaccessible dans votre région ? Nous expliquons comment configurer un proxy pour GitLab afin que toute l'équipe puisse travailler sans interruptions et que les pipelines CI/CD ne tombent pas.

📅19 juillet 2026
```html

GitLab est une plateforme populaire pour le stockage de code et la gestion des processus DevOps, utilisée par des milliers d'équipes à travers le monde. Mais que faire si l'accès à GitLab est bloqué au niveau du fournisseur, du réseau d'entreprise ou d'un pays entier ? Et encore pire — lorsque le pipeline CI/CD échoue au milieu de la nuit simplement parce que le runner ne peut pas accéder au dépôt.

Dans cet article, nous allons examiner comment configurer un proxy pour GitLab au niveau du client Git, du GitLab Runner et du serveur d'entreprise — afin que toute l'équipe fonctionne de manière stable depuis n'importe quel endroit du monde.

Pourquoi un proxy pour GitLab : scénarios réels

Avant de configurer un proxy, il est important de comprendre quel problème vous essayez de résoudre. Les situations varient, et cela influence le choix du type de proxy et la méthode de connexion.

Scénario 1 : GitLab bloqué par le fournisseur ou au niveau du pays

Dans certains pays et réseaux d'entreprise, l'accès à gitlab.com est restreint. Un développeur ouvre le terminal, tape git pull — et obtient un timeout. Le proxy fonctionne ici comme un intermédiaire : le trafic ne va pas directement sur gitlab.com, mais passe par un serveur intermédiaire dans un pays où il n'y a pas de restrictions.

Scénario 2 : Équipe distribuée dans différents pays

Imaginez : une partie de l'équipe travaille depuis la Russie, une autre depuis le Kazakhstan, et une autre depuis l'Europe. Chacun a des conditions réseau différentes, des restrictions différentes. Pour que tout le monde travaille de manière stable et à la même vitesse, les entreprises déploient un serveur proxy d'entreprise, par lequel tout le trafic vers GitLab passe par un canal unique.

Scénario 3 : Le runner CI/CD ne peut pas accéder aux dépendances externes

GitLab Runner lance un pipeline, et à l'étape npm install ou pip install, tout échoue — parce que le serveur sur lequel le runner fonctionne est dans un réseau fermé sans accès direct à Internet. Le proxy permet au runner d'obtenir des dépendances externes sans ouvrir un accès complet à Internet pour tout le serveur.

Scénario 4 : GitLab auto-hébergé derrière un pare-feu d'entreprise

L'entreprise maintient son propre serveur GitLab dans un réseau interne. Les développeurs en télétravail doivent s'y connecter. Au lieu d'utiliser un VPN pour tout le trafic, il est possible de configurer un proxy uniquement pour le trafic GitLab — c'est plus rapide et plus simple à administrer.

Scénario 5 : Surveillance et audit du trafic

Les grandes entreprises dirigent tout le trafic vers les dépôts via un proxy d'entreprise afin de journaliser l'activité, de contrôler qui pousse quoi, et de bloquer les opérations indésirables. C'est une exigence de sécurité, et non un contournement des blocages.

Il est important de comprendre avant la configuration :

Un proxy pour GitLab peut être nécessaire à trois niveaux simultanément : sur la machine du développeur (client Git), sur le serveur avec GitLab Runner (CI/CD), et sur le serveur GitLab lui-même (s'il est auto-hébergé). Chaque niveau est configuré séparément.

Quel type de proxy convient à GitLab

GitLab fonctionne sur les protocoles HTTPS et SSH. Cela détermine immédiatement quels types de proxies sont applicables et lesquels ne le sont pas. Examinons les options.

Type de proxy Protocole Convient à GitLab Quand utiliser
Proxy HTTP/HTTPS HTTP, HTTPS ✓ Oui Git over HTTPS, interface web de GitLab
Proxy SOCKS5 TCP (tous) ✓ Oui (meilleure option) Git over HTTPS et SSH, CI/CD
Proxy SOCKS4 TCP ~ Partiellement Seulement si SOCKS5 n'est pas disponible
Proxy transparent HTTP ✗ Non Ne convient pas — ne contourne pas les blocages

Pour travailler avec GitLab, le choix optimal est SOCKS5. Il fonctionne au niveau TCP, donc il proxy aussi bien les connexions HTTPS (interface web, git clone via HTTPS) que les connexions SSH (git push/pull via SSH sur le port 22 ou 443).

Proxies résidentiels vs de centres de données pour GitLab

Tout dépend de la tâche. Si l'objectif est de contourner un blocage par GeoIP ou d'obtenir une IP stable pour l'authentification, des proxies de centres de données conviendront — ils sont plus rapides, moins chers et offrent une faible latence, ce qui est critique lors du travail avec de grands dépôts.

Si votre IP d'entreprise est sur la liste noire de GitLab (ce qui peut arriver lors de scans agressifs ou après des incidents de sécurité), envisagez des proxies résidentiels — leurs adresses IP appartiennent à de véritables utilisateurs domestiques et sont très rarement bloquées par les plateformes.

Configuration du proxy pour le client Git (globalement)

C'est le scénario le plus courant : un développeur sur sa machine ne peut pas se connecter à GitLab. La configuration se fait via la configuration de Git lui-même — une seule fois, et cela fonctionne pour tous les dépôts.

Option A : Proxy HTTPS pour Git

Si vous travaillez avec GitLab via HTTPS (l'adresse du dépôt commence par https://), exécutez dans le terminal : 

# Configurer le proxy HTTP globalement
git config --global http.proxy http://VOTRE_PROXY_IP:PORT

# Si le proxy nécessite une authentification
git config --global http.proxy http://LOGIN:MOTDEPASSE@VOTRE_PROXY_IP:PORT

# Pour un proxy SOCKS5 (recommandé)
git config --global http.proxy socks5://VOTRE_PROXY_IP:PORT

# Vérifier que la configuration a été appliquée
git config --global --get http.proxy

Option B : Proxy uniquement pour gitlab.com (n'affecte pas d'autres dépôts)

Si vous ne souhaitez pas que le proxy soit appliqué à toutes les opérations Git (par exemple, GitHub ou Bitbucket fonctionnent normalement), vous pouvez configurer le proxy uniquement pour un domaine spécifique : 

# Proxy uniquement pour gitlab.com
git config --global http.https://gitlab.com.proxy socks5://VOTRE_PROXY_IP:PORT

# Ou pour votre GitLab auto-hébergé
git config --global http.https://git.votreentreprise.com.proxy socks5://VOTRE_PROXY_IP:PORT

Option C : SSH via proxy (pour ceux qui travaillent en SSH)

Si vous clonez des dépôts via SSH ([email protected]:...), la configuration du proxy se fait dans le fichier de configuration SSH, et non dans Git. Ouvrez le fichier ~/.ssh/config et ajoutez : 

# Pour Linux/macOS — via nc (netcat)
Host gitlab.com
    HostName gitlab.com
    User git
    ProxyCommand nc -X 5 -x VOTRE_PROXY_IP:PORT %h %p

# Pour Windows — via connect.exe (Git for Windows)
Host gitlab.com
    HostName gitlab.com
    User git
    ProxyCommand connect -S VOTRE_PROXY_IP:PORT %h %p

Après la configuration, vérifiez la connexion avec la commande ssh -T [email protected]. Si tout est correctement configuré, vous verrez un message de bienvenue de GitLab.

Comment désactiver le proxy lorsqu'il n'est plus nécessaire

# Supprimer le proxy global
git config --global --unset http.proxy

# Supprimer le proxy pour un domaine spécifique
git config --global --unset http.https://gitlab.com.proxy

Proxy pour GitLab Runner et pipelines CI/CD

GitLab Runner est un agent qui exécute des tâches à partir de .gitlab-ci.yml. Si le runner se trouve dans un réseau fermé ou sur un serveur avec un accès Internet limité, il est nécessaire de configurer le proxy séparément. Les paramètres du client Git du développeur ne seront pas utiles ici — le runner fonctionne sur une autre machine.

Méthode 1 : Variables d'environnement dans la configuration du runner

Ouvrez le fichier de configuration de GitLab Runner (généralement /etc/gitlab-runner/config.toml) et ajoutez des variables d'environnement dans la section [runners.env] : 

[[runners]]
  name = "mon-runner"
  url = "https://gitlab.com/"
  token = "VOTRE_TOKEN"
  executor = "shell"
  environment = [
    "HTTP_PROXY=http://VOTRE_PROXY_IP:PORT",
    "HTTPS_PROXY=http://VOTRE_PROXY_IP:PORT",
    "NO_PROXY=localhost,127.0.0.1,votre-domaine-interne.com"
  ]

Après avoir modifié la configuration, redémarrez le runner : sudo gitlab-runner restart

Méthode 2 : Variables dans .gitlab-ci.yml (au niveau du pipeline)

Si vous n'êtes pas l'administrateur du runner ou si vous souhaitez configurer le proxy uniquement pour un projet spécifique, ajoutez les variables directement dans le fichier du pipeline : 

variables:
  HTTP_PROXY: "http://VOTRE_PROXY_IP:PORT"
  HTTPS_PROXY: "http://VOTRE_PROXY_IP:PORT"
  NO_PROXY: "localhost,127.0.0.1,.internal.company.com"

stages:
  - build
  - test
  - deploy

build:
  stage: build
  script:
    - npm install   # maintenant ça passera par le proxy
    - npm run build

Méthode 3 : Variables dans les paramètres du projet GitLab (sans commit dans le dépôt)

La meilleure méthode pour les données sensibles (proxy avec authentification) : allez dans Settings → CI/CD → Variables de votre projet et ajoutez les variables HTTP_PROXY, HTTPS_PROXY, NO_PROXY comme variables protégées (masked). Elles seront automatiquement disponibles dans tous les pipelines, mais ne seront pas visibles dans les logs.

À propos de NO_PROXY — n'oubliez pas !

La variable NO_PROXY est cruciale. Vous devez y ajouter tous les domaines internes et IP auxquels le runner doit se connecter directement, en contournant le proxy. Sinon, le runner essaiera d'accéder même aux services internes via le proxy — et le pipeline échouera.

Proxy pour l'exécuteur Docker

Si le runner utilise l'exécuteur Docker, les conteneurs n'héritent pas par défaut des paramètres proxy de l'hôte. Il faut soit ajouter les variables dans config.toml dans la section [runners.docker], soit créer un fichier /etc/systemd/system/docker.service.d/proxy.conf sur l'hôte avec le runner : 

[Service]
Environment="HTTP_PROXY=http://VOTRE_PROXY_IP:PORT"
Environment="HTTPS_PROXY=http://VOTRE_PROXY_IP:PORT"
Environment="NO_PROXY=localhost,127.0.0.1"

Après cela : sudo systemctl daemon-reload && sudo systemctl restart docker

Proxy pour le serveur GitLab auto-hébergé

Si vous administrez votre propre serveur GitLab (installé via Omnibus ou Helm), le proxy est nécessaire pour que GitLab puisse accéder aux services externes : envoyer des notifications, se connecter à des systèmes CI externes, télécharger des avatars d'utilisateurs, s'intégrer avec Jira ou Slack.

Configuration dans gitlab.rb (installation Omnibus)

Ouvrez le fichier /etc/gitlab/gitlab.rb et ajoutez ou décommentez les lignes suivantes : 

# Proxy pour GitLab (Omnibus)
gitlab_rails['env'] = {
  "http_proxy" => "http://VOTRE_PROXY_IP:PORT",
  "https_proxy" => "http://VOTRE_PROXY_IP:PORT",
  "no_proxy" => "localhost,127.0.0.1,VOTRE_DOMAINE_INTERNE"
}

# Si le proxy nécessite une authentification :
gitlab_rails['env'] = {
  "http_proxy" => "http://LOGIN:MOTDEPASSE@VOTRE_PROXY_IP:PORT",
  "https_proxy" => "http://LOGIN:MOTDEPASSE@VOTRE_PROXY_IP:PORT",
  "no_proxy" => "localhost,127.0.0.1"
}

Après avoir modifié la configuration, appliquez les paramètres : sudo gitlab-ctl reconfigure

Configuration des connexions sortantes via l'Admin Area

Dans GitLab 15.0+, il est possible de configurer le proxy directement via l'interface web : allez dans Admin Area → Settings → Network → Outbound requests. Ici, vous pouvez spécifier un proxy pour les webhooks sortants et limiter les plages d'IP auxquelles GitLab peut accéder. Cela est utile pour la sécurité — cela empêche les attaques SSRF via des webhooks.

Organisation de l'accès pour toute l'équipe via un proxy

Lorsqu'il est nécessaire d'assurer un accès stable à GitLab pour une équipe de 5 à 50 personnes, la configuration individuelle sur chaque machine n'est pas la meilleure approche. Examinons des solutions plus évolutives.

Approche 1 : Serveur proxy d'entreprise

Un serveur proxy unique (par exemple, Squid ou 3proxy) avec accès à Internet est déployé. Tous les développeurs configurent Git pour utiliser ce serveur. Avantages : gestion centralisée, point de contrôle unique, possibilité de journaliser le trafic. Inconvénient : le serveur devient un point de défaillance unique.

Approche 2 : Miroir (mirror) du dépôt

GitLab prend en charge le mirroring des dépôts. Vous pouvez configurer un GitLab auto-hébergé dans un réseau interne comme miroir de gitlab.com. Les développeurs travaillent avec le serveur interne, qui se synchronise avec l'externe via le proxy. Cela réduit la dépendance à la qualité de la connexion proxy pour chaque développeur.

Approche 3 : Configuration automatique via dotfiles ou script d'onboarding

Pour les équipes où chaque développeur configure son environnement lui-même, il est pratique de créer un script d'onboarding qui écrit automatiquement les paramètres Git nécessaires. Le script est stocké dans un dépôt d'entreprise et est exécuté lors de la configuration d'un nouveau poste de travail. 

#!/bin/bash
# setup-git-proxy.sh — à exécuter lors de la configuration d'un nouveau poste de travail

PROXY_HOST="proxy.entreprise.com"
PROXY_PORT="3128"

echo "Configuration du proxy Git pour accéder à GitLab..."
git config --global http.https://gitlab.com.proxy "socks5://${PROXY_HOST}:${PROXY_PORT}"
git config --global http.sslVerify true
echo "C'est fait ! Vérifiez : git config --global --list | grep proxy"

Liste de contrôle pour le déploiement en équipe

  • Déterminer si un proxy est nécessaire au niveau des développeurs, des runners ou du serveur GitLab (ou des trois)
  • Choisir le type de proxy : SOCKS5 pour une compatibilité maximale
  • Configurer NO_PROXY pour tous les domaines et services internes
  • Vérifier le fonctionnement des clés SSH via le proxy (étape distincte !)
  • Documenter les paramètres dans le wiki d'entreprise
  • Créer un script d'onboarding pour les nouveaux employés
  • Configurer la surveillance de la disponibilité du serveur proxy

Problèmes fréquents et solutions

Même après une configuration correcte, parfois quelque chose ne va pas. Voici les problèmes les plus courants et comment les diagnostiquer.

Problème 1 : Problème de certificat SSL : impossible d'obtenir le certificat de l'émetteur local

Cette erreur se produit lorsque le serveur proxy (en particulier d'entreprise) effectue une inspection SSL — remplaçant le certificat de GitLab par le sien. Git ne fait pas confiance à ce certificat. Solution : ajouter le certificat racine d'entreprise aux certificats de confiance. 

# Solution temporaire (pour débogage, pas pour la production !)
git config --global http.sslVerify false

# Solution correcte : ajouter le certificat d'entreprise
git config --global http.sslCAInfo /chemin/vers/corporate-ca-bundle.crt

Problème 2 : Le proxy fonctionne pour HTTPS, mais SSH ne fonctionne pas

C'est une situation classique : vous avez configuré http.proxy dans Git, le clonage HTTPS fonctionne, mais les opérations SSH échouent toujours. La raison : le trafic SSH ne passe pas par le proxy HTTP. Vous devez configurer séparément ~/.ssh/config comme décrit dans la section sur le client Git.

Alternative : passer à l'utilisation de GitLab via HTTPS au lieu de SSH. Pour cela, modifiez l'URL distante : 

# Vérifier l'URL distante actuelle
git remote -v

# Changer de SSH à HTTPS
git remote set-url origin https://gitlab.com/username/repo.git

Problème 3 : Le pipeline CI/CD se bloque à l'étape de clonage du dépôt

Le runner clone le dépôt directement depuis GitLab, en utilisant un token. Si le runner est derrière un proxy, ce clonage doit également passer par le proxy. Assurez-vous que les variables HTTP_PROXY et HTTPS_PROXY sont définies dans config.toml, et non seulement dans .gitlab-ci.yml — les variables du fichier CI s'appliquent après le clonage, et non avant.

Problème 4 : Le proxy fonctionne, mais très lentement

Si les opérations push/pull fonctionnent, mais prennent 5 à 10 fois plus de temps que d'habitude, le problème peut résider dans la bande passante du serveur proxy ou dans sa localisation géographique. Pour travailler avec de grands dépôts (100+ Mo), il est important de choisir un proxy avec une faible latence et une haute bande passante. Les proxies de centres de données sont préférables aux proxies résidentiels dans ce cas — ils offrent un canal plus stable.

Problème 5 : L'authentification via le proxy nécessite une saisie répétée du mot de passe

Si le proxy nécessite une authentification de base, et que Git demande le mot de passe à chaque fois, configurez le helper d'identifiants : 

# macOS — utiliser le trousseau
git config --global credential.helper osxkeychain

# Windows — utiliser le Gestionnaire d'identifiants Windows
git config --global credential.helper manager

# Linux — mettre en cache pendant 1 heure
git config --global credential.helper "cache --timeout=3600"

Comment diagnostiquer rapidement un problème de proxy :

Utilisez GIT_TRACE=1 GIT_CURL_VERBOSE=1 git clone https://gitlab.com/... — cela affichera un log détaillé de toutes les requêtes et réponses HTTP, y compris les informations sur le proxy.

Conclusion et recommandations

La configuration d'un proxy pour GitLab est une tâche qui doit être réalisée à plusieurs niveaux simultanément. Pour un développeur sur sa machine de travail, il suffit d'ajouter quelques lignes dans la configuration de Git ou SSH. Pour CI/CD, il faut ajouter des variables d'environnement dans la configuration du runner ou les paramètres du projet. Et pour un GitLab auto-hébergé — mettre à jour gitlab.rb et reconstruire la configuration.

Les principales règles qui aideront à éviter la plupart des problèmes :

  • Utilisez SOCKS5 — il fonctionne à la fois avec HTTPS et SSH
  • Configurez toujours NO_PROXY pour les services internes
  • Ne désactivez pas la vérification SSL en production — ajoutez le certificat d'entreprise
  • Pour CI/CD, configurez le proxy dans config.toml, et pas seulement dans .gitlab-ci.yml
  • Documentez les paramètres — un nouveau développeur dans l'équipe vous remerciera

Si vous recherchez un proxy fiable pour organiser un accès stable à GitLab depuis n'importe où dans le monde, nous vous recommandons d'envisager des proxies de centres de données — ils offrent une vitesse de transmission élevée et une faible latence, ce qui est particulièrement important lors du travail avec de grands dépôts et des pipelines CI/CD intensifs. Pour les équipes qui attachent une grande importance à l'anonymat maximal ou au contournement des blocages GeoIP, des proxies résidentiels avec des IP de véritables utilisateurs domestiques conviendront.

```