Configuration du proxy réseau d'entreprise pour Cursor : guide complet de HTTP_PROXY à l'importation de certificats

Vous cliquez sur Send, et le panneau Agent de Cursor affiche Network error. Le proxy global est pourtant activé — pourquoi la connexion échoue-t-elle ?

La réponse se trouve dans la pile réseau d’Electron v25+ : Cursor, VS Code et le système d’exploitation utilisent chacun leur propre configuration proxy, sans lien entre eux. Cet article reprend la configuration du proxy réseau d’entreprise de bout en bout : variables HTTP_PROXY, configuration dans settings.json, compatibilité HTTP/2, importation de certificats SSL et proxy transparent Anygress. Windows, Mac et WSL2 sont couverts.

Pourquoi Cursor n’hérite-t-il pas du proxy système ?

Cursor repose sur Electron v25+. Sa pile réseau, identique à celle de Chrome, n’hérite pas automatiquement des paramètres proxy du système d’exploitation ou du processus parent. Contrairement à VS Code, qui peut lire le proxy système, Cursor exige sa propre configuration.

Les variables d’environnement compliquent encore les choses. Vous faites export HTTP_PROXY=... dans le terminal, puis lancez Cursor depuis le Dock ou une icône de bureau — la variable n’est jamais transmise. Elle ne prend effet que si vous lancez la commande cursor depuis ce même terminal.

La méthode la plus fiable en réseau d’entreprise : modifier directement le settings.json de Cursor.

Que dit la documentation officielle ?

Selon la documentation Network Configuration de Cursor, trois voies de configuration proxy existent en déploiement d’entreprise :

1. Variables d’environnement : HTTP_PROXY, HTTPS_PROXY, NO_PROXY (efficaces uniquement au lancement depuis le terminal)
2. settings.json : http.proxy, http.proxySupport, http.proxyStrictSSL
3. Arguments de lancement : --proxy-server, --proxy-auto-detect, --disable-http2

Chaque méthode a son contexte d’usage ; nous les détaillons ci-dessous.

Configuration des variables HTTP_PROXY

Les variables d’environnement sont la méthode la plus légère, à condition que Cursor soit lancé depuis un terminal déjà configuré.

Windows PowerShell

# Configurer le proxy (avec authentification)
$env:HTTP_PROXY = "http://username:[email protected]:8080"
$env:HTTPS_PROXY = "http://username:[email protected]:8080"

# Adresses locales sans proxy
$env:NO_PROXY = "localhost,127.0.0.1,.internal.corp"

# Lancer Cursor depuis ce même terminal
cursor

macOS / Linux

# Bash/Zsh
export HTTP_PROXY="http://username:[email protected]:8080"
export HTTPS_PROXY="http://username:[email protected]:8080"
export NO_PROXY="localhost,127.0.0.1,.internal.corp"

# Lancer Cursor
cursor

Cas particulier WSL2

WSL2 dispose d’une carte réseau virtuelle indépendante, sur un sous-réseau différent de l’hôte Windows. Les paramètres proxy de Windows ne se synchronisent pas automatiquement dans WSL2.

Railway - Plateforme de déploiement moderne, sans opérations complexes, en ligne en quelques minutes

Commencer →Pub

Une solution consiste à utiliser l’outil graftcp comme proxy TCP transparent :

# Installer graftcp
sudo apt install graftcp

# Configurer l'adresse proxy (graftcp.conf)
proxy_addr = "192.168.1.100:7890"  # Adresse proxy de l'hôte Windows

# Lancer Cursor via graftcp
graftcp cursor

Quelques pièges :

• Lancement depuis le Dock ou une icône de bureau → les variables d’environnement ne s’appliquent pas
• HTTP_PROXY défini sans HTTPS_PROXY → les requêtes API Cursor (toutes en HTTPS) ne passent pas par le proxy
• .internal.corp absent de NO_PROXY → les services internes passent aussi par le proxy et ralentissent inutilement

Si vous ne voulez pas lancer Cursor depuis le terminal à chaque fois, la configuration via settings.json est plus pratique.

Configuration proxy dans settings.json (méthode recommandée)

Ouvrez Cursor, appuyez sur Cmd+Shift+P (Mac) ou Ctrl+Shift+P (Windows), puis saisissez Preferences: Open User Settings (JSON).

Ajoutez les entrées suivantes dans settings.json :

{
  "http.proxy": "http://username:[email protected]:8080",
  "http.proxySupport": "override",
  "http.proxyStrictSSL": false,
  "http.noProxy": ["localhost", "127.0.0.1", "*.internal.corp"],
  "cursor.general.disableHttp2": true,
  "cursor.general.disableHttp1SSE": true
}

Explication champ par champ :

Redémarrage obligatoire.

Après modification de settings.json, fermez complètement Cursor puis rouvrez-le. Un simple rafraîchissement de fenêtre (Cmd+R) ne recharge pas la configuration réseau.

Arguments de raccourci Windows :

Si vous ne souhaitez pas modifier settings.json, ajoutez des arguments au raccourci :

cursor.exe --proxy-server="http://proxy.company.com:8080" --proxy-auto-detect --disable-http2

Cette approche est équivalente à settings.json et s’applique à chaque lancement, sans redémarrage supplémentaire.

Incompatibilité HTTP/2 et solutions

Les fonctionnalités Agent de Cursor reposent sur HTTP/2 et le streaming bidirectionnel. Chat en temps réel, complétion de code et dialogues multi-tours dépendent tous des connexions longues et du flux HTTP/2.

Le problème : de nombreux proxies d’entreprise ne prennent pas en charge HTTP/2.

Les proxies d’inspection SSL comme Zscaler ou Netskope ne gèrent que HTTP/1.1. Les requêtes HTTP/2 de Cursor arrivent au proxy, sont tronquées, renvoient des données corrompues ou expirent directement.

Symptômes :

Alibaba Cloud - Choix n°1 des développeurs, 15 % de réduction exclusive sur Lighthouse

Obtenir -15 % →Pub

• Le panneau Agent reste bloqué sur « Thinking… »
• La complétion de code fonctionne par intermittence ou renvoie des erreurs
• Le mode Chat fonctionne, le mode Agent affiche tout en rouge

Solution : désactiver HTTP/2 pour forcer Cursor à basculer vers HTTP/1.1 SSE.

{
  "cursor.general.disableHttp2": true
}

Ou via argument de lancement :

cursor --disable-http2

Après désactivation, Cursor utilise les Server-Sent Events (SSE) en HTTP/1.1 pour le streaming. Le SSE est unidirectionnel, moins performant que le flux bidirectionnel HTTP/2, mais bien plus compatible.

Un détail : si --disable-http2 et disableHttp2 dans settings.json coexistent, l’argument de lancement prime. Pour garantir la désactivation de HTTP/2, configurez les deux.

D’après les retours du forum Cursor, cette méthode résout la majorité des problèmes Agent en entreprise. Un utilisateur a signalé sur Cursor http/2 requests don’t go through proxy setting que l’Agent fonctionnait à nouveau après désactivation de HTTP/2.

Importation de certificats SSL (inspection SSL d’entreprise)

Lors d’un déchiffrement SSL, le proxy d’entreprise remplace le certificat d’origine par le sien. Netskope, Zscaler et d’autres offrent cette fonctionnalité.

Cursor se connecte à cursor.com ou api2.cursor.sh, reçoit un certificat signé par le proxy d’entreprise — et non par Let’s Encrypt ou DigiCert. La validation échoue, la connexion est coupée.

Symptômes :

• TLS handshake timeout
• certificate signature failure
• Le panneau Agent affiche CERT_AUTHORITY_INVALID

Méthode 1 : importer le certificat racine d’entreprise (Windows)

1. Appuyez sur Win+R, saisissez certmgr.msc
2. Développez Trusted Root Certification Authorities → Certificates
3. Clic droit → All Tasks → Import
4. Sélectionnez le fichier de certificat racine d’entreprise (.cer ou .pem)
5. Redémarrez Cursor une fois l’import terminé

Le système fait confiance au certificat d’entreprise ; Cursor en hérite.

Méthode 2 : variables d’environnement pour spécifier le certificat (recommandé)

Cursor prend en charge les variables SSL_CERT_FILE et SSL_CERT_DIR :

# Certificat unique
export SSL_CERT_FILE=/path/to/company-root-ca.pem
cursor

# Répertoire de certificats
export SSL_CERT_DIR=/etc/ssl/certs
cursor

Cette approche est plus flexible : elle ne modifie pas le magasin système et ne s’applique qu’à Cursor.

Méthode 3 : désactiver la validation SSL stricte (déconseillé)

{
  "http.proxyStrictSSL": false
}

Cela contourne la validation des certificats, au détriment de la sécurité. Réservé aux environnements de test ; déconseillé en production.

Importation de certificats Mac / Linux :

# Debian/Ubuntu
sudo cp company-root-ca.pem /usr/local/share/ca-certificates/
sudo update-ca-certificates

# macOS
sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain company-root-ca.pem

Redémarrez Cursor après l’importation.

KiloClaw - OpenClaw managé pour l’entreprise : orchestration d’agents IA et routage intelligent

Commencer →Pub

Anygress et cursor-api-proxy (configuration avancée)

Réseau d’entreprise, serveurs distants, réseaux privés : la configuration proxy standard ne suffit pas toujours. Le projet open source cursor-api-proxy (GitHub : anyrobert/cursor-api-proxy) est conçu pour ces cas.

Principe :

cursor-api-proxy démarre un service proxy local qui relaie les requêtes API de Cursor vers les serveurs réels. Il peut remplacer les certificats TLS, traverser un réseau Tailscale ou injecter des clés API en cours de route.

Exemple de configuration :

# Cloner le projet
git clone https://github.com/anyrobert/cursor-api-proxy
cd cursor-api-proxy

# Configurer les variables d'environnement
export CURSOR_BRIDGE_TLS_CERT=./macbook.tail4048eb.ts.net.crt
export CURSOR_BRIDGE_TLS_KEY=./macbook.tail4048eb.ts.net.key
export CURSOR_BRIDGE_API_KEY=your-secret-key
export CURSOR_PROXY_URL=http://127.0.0.1:8765

# Démarrer (avec TLS Tailscale)
npm start -- --tailscale

Puis pointez le proxy de Cursor vers ce service :

{
  "http.proxy": "http://127.0.0.1:8765"
}

Cas d’usage :

• Le réseau d’entreprise interdit l’accès direct à cursor.com
• Un serveur distant n’a pas de sortie Internet publique et doit transiter par Tailscale
• Injection d’une clé API unique partagée entre plusieurs utilisateurs
• Déploiement privé où les requêtes API passent par une passerelle interne

Cette méthode est plus complexe qu’un proxy standard, mais bien plus flexible. Adaptée aux équipes disposant de compétences ops.

Conclusion

Pour configurer le proxy Cursor en réseau d’entreprise, suivez cet ordre de diagnostic :

1. Commencez par settings.json — http.proxy + http.proxySupport: "override"
2. Désactivez HTTP/2 — si le proxy d’entreprise ne le prend pas en charge, ajoutez disableHttp2: true
3. Vérifiez les certificats — en cas de TLS handshake timeout ou CERT_AUTHORITY_INVALID, importez le certificat racine d’entreprise
4. Pour les cas complexes, utilisez cursor-api-proxy — serveurs distants, réseaux privés, traversée Tailscale

Tableau de correspondance des erreurs courantes :

Une fois la configuration terminée, redémarrez complètement Cursor — ne vous contentez pas de rafraîchir la fenêtre.