Tableau comparatif des trois solutions
Le choix entre miroir Git (site miroir), proxy et miroir auto-hébergé dépend du contexte : fréquence des clones, volume, politique de sécurité et budget. Le tableau ci-dessous résume les critères essentiels pour une décision rapide.
| Critère | Miroir Git (site miroir) | Proxy | Miroir auto-hébergé |
|---|---|---|---|
| Scénario typique | Clone de dépôts publics depuis une région lente ; CI sur un ou peu de nœuds. | Trafic Git déjà routé via proxy ou VPN ; point d’accès unique. | Volume élevé, contrôle total, cohérence des artefacts. |
| Vitesse | Bonne à très bonne si le miroir est proche (réseau ou géographiquement). | Dépend du proxy ; souvent correct si le proxy est bien placé. | Excellente en local ou sur un réseau interne. |
| Stabilité | Dépend du site miroir (souvent bonne). | Dépend du proxy et du réseau. | Maîtrisée (SLA interne). |
| Coût | Faible à nul (public). | Abonnement ou infra existante. | Plus élevé : serveur, bande passante, stockage. |
| Maintenance | Quasi nulle (public). | Fournisseur ou équipe réseau. | Élevée : sync, sauvegardes, monitoring. |
Étapes de configuration d’un miroir Git (site miroir)
Un site miroir remplace l’URL d’origine par une URL plus rapide pour git clone. Trois étapes reproductibles.
Choisir un miroir fiable. Identifier un miroir proche de votre région ou nœud CI (ex. miroirs GitHub/GitLab). Vérifier la fraîcheur et les dépôts disponibles.
Configurer url.insteadOf. Ex. : git config --global url."https://mirror.example.com/".insteadOf "https://github.com/". Adapter l’URL selon la doc du fournisseur.
Tester un clone. Lancer git clone https://github.com/org/repo.git et vérifier que le clone passe par le miroir. En CI, appliquer la même config sur le nœud de build.
Étapes de configuration d’un proxy
Un proxy HTTP ou SOCKS accélère ou sécurise le trafic Git lorsque tout sort par ce proxy. Trois étapes.
Obtenir l’URL du proxy. Récupérer hôte, port et éventuellement identifiants auprès de l’équipe réseau. Ex. http://proxy.company:8080 ou socks5://proxy:1080.
Configurer Git. HTTP/HTTPS : git config --global http.proxy http://proxy.company:8080 et https.proxy idem. SOCKS5 : http.proxy socks5://proxy:1080. Optionnel : HTTP_PROXY / HTTPS_PROXY pour npm, curl.
Vérifier le clone. Exécuter git clone https://github.com/org/repo.git et confirmer que le trafic passe par le proxy. Pour exclure le local : git config --global http.http://localhost.noProxy true.
Miroir auto-hébergé et critères de choix
Un miroir auto-hébergé consiste à maintenir une copie des dépôts sur votre propre infrastructure. C’est pertinent lorsque le volume de clones est élevé et répété (CI, équipes distribuées), que vous avez besoin d’un contrôle total et d’une faible latence, ou que les miroirs publics ou le proxy ne couvrent pas vos besoins (dépôts privés, conformité). En contrepartie, la maintenance est plus lourde : synchronisation régulière (cron + git clone --mirror ou outils dédiés), stockage et surveillance. Recommandation : commencer par un site miroir public ou un proxy si disponible ; n’envisager l’auto-hébergement que si les gains de vitesse ou de conformité le justifient.
Dépannage des échecs courants
Pannes fréquentes et pistes.
- Timeout / connexion lente : augmenter
http.lowSpeedLimitethttp.lowSpeedTime; vérifier miroir ou proxy (ping, curl). - 403 / 404 : vérifier l’URL du miroir et la présence du dépôt ; pour privés, miroir autorisé ou proxy avec auth.
- Certificat SSL :
http.sslVerify falseen dernier recours ; privilégier CA à jour ou proxy avec certificat valide. - Débit faible : vérifier que
url.insteadOfou le proxy s’applique ; tester depuis un nœud proche du miroir (ex. Mac distant même région).
En résumé
En 2026, l’accélération du pull transfrontière pour git clone et la CI repose sur un choix clair entre miroir Git (site miroir), proxy et miroir auto-hébergé. Le tableau comparatif (scénarios, vitesse, stabilité, coût, maintenance) et les étapes de configuration (miroir et proxy, au moins trois par type) permettent de déployer rapidement une solution adaptée. Pour les timeouts et la configuration retry (Git, Homebrew, npm), voir notre FAQ stabilité pull sur Mac distant. En cas d’échec, la section dépannage couvre les erreurs les plus courantes. Pour exécuter vos clones et votre CI sur un environnement stable et proche des miroirs, consultez l’accueil, les tarifs, la page achat ou le blog MacPull. Nous vous invitons à essayer ou à acheter un Mac distant pour accélérer vos pulls et fiabiliser votre CI.
Choisissez votre Mac distant pour clone et CI
Environnement stable, proche des miroirs. Consultez l'accueil, les tarifs ou réservez un Mac sans connexion préalable.