Dépannage réseau Cursor Proxy : proxy, diagnostic et correctif HTTP/2

Un petit cercle tourne depuis cinq minutes en bas à droite de l’éditeur Cursor. Vous étiez en plein code, l’IA coupe soudain avec « Network request failed ». Vous basculez sur le navigateur : YouTube est fluide, ping Google affiche 20 ms de latence.

Le lendemain, sur le réseau d’entreprise, l’IT a empilé les proxys et Cursor refuse de démarrer. Les logs affichent ERR_HTTP2_PROTOCOL_ERROR, ECONNREFUSED, certificate verify failed — chaque message est familier, mais ensemble ils ne racontent rien de clair.

J’ai passé trois jours à parcourir GitHub Issues, Discord et des « solutions ultimes » douteuses, pour finir par comprendre : les problèmes réseau de Cursor ne viennent pas d’une seule cause, mais de quatre pièges qui se cumulent — proxy, HTTP/2, certificats et DNS.

Cet article a été revu en juin 2026 selon la doc officielle Cursor : commencez par Cursor Settings > Network et son outil de diagnostic, puis traitez proxy, mode compatibilité HTTP/2, certificats et DNS. Ne touchez pas aux paramètres de lancement au hasard : laissez d’abord le diagnostic vous indiquer où est le problème.

Un point souvent oublié, à garder en tête dès maintenant : beaucoup saisissent la bonne adresse de proxy et Cursor refuse quand même de se connecter. La raison est que http.proxySupport vaut override par défaut. Dans ce mode, Cursor n’utilise que le http.proxy du settings.json et ignore le proxy système ; or sur une installation neuve, cette valeur est vide. Une section dédiée y revient plus bas.

Ne modifiez pas tout de suite : trois étapes pour localiser le problème

Face à un souci réseau, beaucoup changent le proxy, suppriment des certificats ou réinstallent — sans résultat, avec un environnement plus confus.

Mon conseil : prenez cinq minutes pour identifier la source.

Étape 1 : Cursor ou votre réseau ?

Ouvrez un terminal et lancez trois commandes :

# Test réseau de base
ping api.openai.com

# Test résolution DNS
nslookup api.openai.com

# Test connexion HTTPS
curl -I https://api.openai.com

Si ping passe mais curl échoue, c’est très probablement le proxy ou les certificats. Si même ping échoue, le problème est en amont, pas dans Cursor.

Étape 2 : lire les logs d’erreur Cursor

Beaucoup sautent cette étape, pourtant les logs sont explicites.

• Windows : %APPDATA%\Cursor\logs\main.log
• macOS : ~/Library/Application Support/Cursor/logs/main.log
• Linux : ~/.config/Cursor/logs/main.log

Ouvrez le fichier et cherchez ERROR ou WARN. Erreurs fréquentes :

• ECONNREFUSED → proxy mal configuré ou serveur proxy indisponible
• ERR_HTTP2_PROTOCOL_ERROR → incompatibilité HTTP/2 (le plus piégeux)
• certificate verify failed → problème de certificat SSL
• ETIMEDOUT → délai dépassé, DNS lent ou accès bloqué

Étape 3 : le proxy Cursor est-il actif ?

Cursor repose sur Electron : sa config proxy ne suit pas automatiquement le proxy système. Pour tester :

1. Ouvrez les réglages Cursor (Ctrl+, ou Cmd+,)
2. Recherchez proxy
3. Vérifiez si http.proxy et https.proxy sont vides

S’ils le sont alors qu’un proxy local tourne (Clash, V2Ray, Shadowsocks), Cursor ne passe pas par le proxy — normal qu’il échoue.

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

Commencer →Pub

Quatre façons de configurer le proxy (l’une vous conviendra)

Le proxy est la cause n°1 des pannes réseau Cursor. Peu savent que Cursor supporte quatre modes, chacun pour un contexte différent.

Avant de configurer un proxy, vérifiez une chose : proxySupport est-il sur override ?

Si votre proxy local (Clash / V2Ray) tourne, que le navigateur passe sans souci mais que Cursor ne se connecte toujours pas, ne saisissez pas une adresse trop vite. Cursor hérite de VS Code un réglage http.proxySupport avec quatre modes :

• off : aucun proxy
• on : lit toujours le proxy système
• fallback : regarde d’abord http.proxy dans settings.json, puis bascule sur le proxy système s’il est vide
• override : n’utilise que le http.proxy du settings.json et ignore le proxy système

Le piège est là : http.proxySupport vaut override par défaut, et http.proxy est vide par défaut. Cumulés, Cursor ne lit ni votre adresse (il n’y en a pas) ni le proxy système ; il se connecte à nu, donc la connexion et les requêtes IA échouent.

Le correctif est simple : ouvrez les réglages (Ctrl+,), recherchez proxy support, passez Http: Proxy Support de override à on ou fallback, puis relancez Cursor. Si vous voulez seulement que Cursor suive le proxy système, ce seul changement suffit souvent ; les quatre méthodes ci-dessous sont pour qui veut un contrôle plus fin.

Méthode 1 : adresse proxy dans les réglages (la plus simple)

Cas : vous avez une adresse de proxy explicite (ex. proxy HTTP fourni par l’entreprise).

Étapes :

1. Ouvrez les réglages Cursor
2. Recherchez proxy
3. Renseignez http.proxy : http://127.0.0.1:7890 (adresse et port adaptés)

Points d’attention :

• Authentification : http://username:[email protected]:7890
• Renseignez aussi https.proxy, sinon seul HTTP passe par le proxy
• Clash utilise souvent le port 7890, V2Ray 10808 — vérifiez le vôtre

Méthode 2 : variables d’environnement (lancement en ligne de commande)

Cas : vous lancez Cursor depuis le terminal ou changez de proxy temporairement.

Windows (PowerShell) :

$env:HTTP_PROXY="http://127.0.0.1:7890"
$env:HTTPS_PROXY="http://127.0.0.1:7890"
cursor

macOS/Linux :

export HTTP_PROXY=http://127.0.0.1:7890
export HTTPS_PROXY=http://127.0.0.1:7890
cursor

Avantage : pas de pollution globale ; effet limité à la session terminal.

Méthode 3 : détection automatique du proxy système (entreprise)

Cas : l’IT a configuré un fichier PAC ou un proxy transparent.

Cursor peut lire le proxy système, mais c’est désactivé par défaut :

1. Trouvez la config de lancement Cursor

   • Windows : clic droit raccourci → Propriétés → Cible
   • macOS : éditez /Applications/Cursor.app/Contents/Info.plist

2. Ajoutez l’argument : --proxy-auto-detect

Cursor lira alors la configuration proxy du système sans saisie manuelle.

Méthode 4 : ignorer les erreurs de certificat (déconseillé, mais efficace)

Cas : le proxy d’entreprise fait du déchiffrement HTTPS (MITM) et la validation échoue.

Avertissement : cela réduit la sécurité — usage temporaire uniquement !

Argument : --ignore-certificate-errors

Commande complète (Windows) :

& "C:\Users\VotreNomUtilisateur\AppData\Local\Programs\Cursor\Cursor.exe" --ignore-certificate-errors

Cursor ne valide plus les certificats SSL — contournement fréquent en entreprise. Dernier recours, à éviter si possible.

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

Obtenir -15 % →Pub

Le piège HTTP/2 : pourquoi le navigateur marche et pas Cursor ?

Symptôme : le navigateur accède à l’API OpenAI, curl répond, mais Cursor affiche ERR_HTTP2_PROTOCOL_ERROR.

Ne blamez pas tout de suite un bug de version. Procédure plus sûre : confirmer un souci HTTP/2 via le diagnostic Network de Cursor, puis tester en HTTP/1.1.

Priorité : mode compatibilité HTTP/2 dans les réglages Cursor

1. Ouvrez les réglages Cursor
2. Section Network
3. Lancez Run Diagnostics
4. Si le diagnostic ou les logs pointent HTTP/2, activez Disable HTTP/2 ou mettez HTTP Compatibility Mode sur HTTP/1.1
5. Quittez complètement Cursor puis relancez (pas seulement fermer la fenêtre)

Pour éviter d’ouvrir le panneau à chaque fois, définissez-le directement dans settings.json :

{
  "cursor.general.disableHttp2": true
}

C’est une clé officiellement prise en charge, au même effet que l’option Disable HTTP/2, et elle se place à côté de vos clés proxy. Ne revenez au paramètre de lancement cursor --disable-http2 que sur les versions anciennes qui n’exposent ni l’option ni cette clé.

Changez de DNS : un échec HTTP/2 est parfois un problème de routage

Certaines erreurs HTTP/2 ne viennent pas de Cursor mais du nœud vers lequel votre DNS résout. Quelques fournisseurs DNS résolvent les domaines de l’API Cursor vers un nœud Cloudflare où le handshake échoue, d’où une erreur SSL handshake. Plusieurs utilisateurs du forum officiel rapportent que basculer le DNS système sur Cloudflare (1.1.1.1) ou Google (8.8.8.8) rétablit HTTP/2 directement. Si désactiver HTTP/2 vous ralentit nettement et que vous ne voulez pas rester en HTTP/1.1, changez d’abord de DNS puis réactivez HTTP/2 une fois.

Secours : config du logiciel proxy (ex. Clash)

Ouvrez la config Clash (config.yaml), dans vos règles proxy, ajoutez :

proxies:
  - name: "nom-de-votre-proxy"
    type: http
    server: 127.0.0.1
    port: 7890
    http-version: "1.1"  # forcer HTTP/1.1

Redémarrez Clash et Cursor. Si HTTP/2 n’était qu’un souci de négociation sur la chaîne proxy, cela stabilise souvent les requêtes ; sinon, revenez au rapport de diagnostic et aux logs plutôt qu’empiler les arguments de lancement.

Solution complète en réseau d’entreprise

Le réseau corporate cumule proxy obligatoire, MITM SSL, pare-feu, DNS interne… chaque couche peut bloquer Cursor.

Voici une configuration qui fonctionne en entreprise :

Checklist (dans l’ordre)

1. Obtenir les infos proxy auprès de l’IT

• Adresse et port du proxy (ex. proxy.company.com:8080)
• Authentification requise ou non
• Fichier PAC ou non
• Déchiffrement SSL (si oui, obtenir le certificat racine)

2. Configurer le proxy Cursor

Dans settings.json :

{
  "http.proxy": "http://username:[email protected]:8080",
  "https.proxy": "http://username:[email protected]:8080",
  "http.proxySupport": "override",
  "http.proxyStrictSSL": false,
  "cursor.general.disableHttp2": true
}

Trois remarques : une fois http.proxy saisi à la main, garder http.proxySupport sur override est le plus propre, car Cursor passe alors uniquement par ce proxy d’entreprise. Avec un MITM SSL, http.proxyStrictSSL: false est nécessaire. Et comme les proxys d’entreprise bloquent souvent HTTP/2, mettre cursor.general.disableHttp2 sur true ici vous épargne une étape de dépannage.

3. Importer le certificat racine de l’entreprise

Sans import, Cursor continuera d’afficher certificate verify failed.

Windows :

1. Double-clic sur le fichier racine (.crt ou .cer)
2. « Installer le certificat » → « Ordinateur local » → « Autorités de certification racines de confiance »

macOS :

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

Commencer →Pub

sudo security add-trusted-cert -d -r trustRoot -k /Library/Keychains/System.keychain certificat-racine-entreprise.crt

4. Script de lancement combiné

Créez un script (.bat sous Windows, .sh sous macOS/Linux) :

Windows (start-cursor.bat) :

@echo off
set HTTP_PROXY=http://proxy.company.com:8080
set HTTPS_PROXY=http://proxy.company.com:8080
start "" "C:\Users\VotreNomUtilisateur\AppData\Local\Programs\Cursor\Cursor.exe" --proxy-auto-detect --disable-http2

macOS/Linux (start-cursor.sh) :

#!/bin/bash
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080
/Applications/Cursor.app/Contents/MacOS/Cursor --proxy-auto-detect --disable-http2

Lancez Cursor via ce script, pas via l’icône seule.

5. Tester la connexion

Après démarrage, ouvrez les outils développeur Cursor (Ctrl+Shift+I ou Cmd+Option+I), onglet Network, posez une question à l’IA et vérifiez que les requêtes répondent.

Si ça échoue encore, retournez aux logs (chemins ci-dessus), lisez la dernière erreur et reprenez le dépannage.

Synthèse

En résumé, les problèmes réseau Cursor tiennent à quatre pièges :

1. Proxy ignoré → vérifier d’abord si http.proxySupport est sur override, puis http.proxy et les variables d’environnement
2. Conflit HTTP/2 → d’abord Disable HTTP/2 / HTTP Compatibility Mode: HTTP/1.1 dans Network, changer de DNS si besoin
3. Échec validation SSL → importer la racine ou désactiver temporairement la vérification
4. Restrictions entreprise → combo proxy + certificat + arguments de lancement

J’ai perdu trois jours parce que ces quatre problèmes se superposent : proxy corrigé, HTTP/2 encore en erreur ; HTTP/2 désactivé, certificat en échec ; certificat importé, DNS bloqué… À chaque fois je croyais avoir fini, ce n’était qu’une autre erreur.

Avec l’ordre de cet article, une demi-heure suffit en général.

Dernier conseil : ne négligez pas les logs. À chaque incident, cherchez le dernier ERROR — la réponse est là dans 90 % des cas. Pour les 10 % restants, postez le log sur GitHub Issues ou Discord pour un diagnostic plus rapide.

Les problèmes réseau ne sont pas effrayants ; c’est le bricolage au hasard qui coûte cher. J’espère que cet article vous évitera ces 72 heures.

Documentation officielle et lectures suivantes

• Cursor : réseau, proxy et connexions distantes
• Documentation officielle Cursor
• Cursor Pricing
• Guide des erreurs courantes Cursor
• Guide complet de l’abonnement Cursor Pro
• Guide complet du quota gratuit Cursor