Cursor Unternehmens-Proxy-Konfiguration: Vollständige Anleitung von HTTP_PROXY bis Zertifikatsimport

Sie klicken auf Send – im Cursor-Agent-Panel erscheint Network error. Der globale Proxy ist aktiv, trotzdem keine Verbindung?

Die Antwort liegt im Netzwerkstack von Electron v25+: Cursor, VS Code und das Betriebssystem nutzen jeweils eigene Proxy-Konfigurationen, die nicht automatisch zusammenpassen. Dieser Artikel führt die Unternehmens-Proxy-Konfiguration Schritt für Schritt durch: HTTP_PROXY-Umgebungsvariablen, settings.json, HTTP/2-Kompatibilität, SSL-Zertifikatsimport und Anygress-Transparenzproxy. Windows, Mac und WSL2 sind abgedeckt.

Warum erbt Cursor den System-Proxy nicht?

Cursor basiert auf Electron v25+. Der Netzwerkstack entspricht Chrome und übernimmt weder Betriebssystem- noch Elternprozess-Proxy-Einstellungen automatisch. Anders als VS Code – das den System-Proxy lesen kann – braucht Cursor eine eigene Konfiguration.

Umgebungsvariablen erschweren das zusätzlich: Sie setzen export HTTP_PROXY=... im Terminal und starten Cursor über Dock oder Desktop-Symbol – die Variable wird nicht übergeben. Erst ein Start mit dem cursor-Befehl aus demselben Terminal wirkt.

Die zuverlässigste Methode im Unternehmensnetzwerk: Cursor settings.json direkt anpassen.

Was sagt die offizielle Dokumentation?

Laut Network Configuration von Cursor gibt es drei Proxy-Pfade für Unternehmens-Deployments:

1. Umgebungsvariablen: HTTP_PROXY, HTTPS_PROXY, NO_PROXY (nur bei Terminal-Start wirksam)
2. settings.json: http.proxy, http.proxySupport, http.proxyStrictSSL
3. Startparameter: --proxy-server, --proxy-auto-detect, --disable-http2

Jede Methode hat ihren Einsatzbereich – im Folgenden im Detail.

HTTP_PROXY-Umgebungsvariablen konfigurieren

Umgebungsvariablen sind am leichtesten – vorausgesetzt, Cursor wird aus einem konfigurierten Terminal gestartet.

Windows PowerShell

# Proxy setzen (mit Authentifizierung)
$env:HTTP_PROXY = "http://username:password@proxy.company.com:8080"
$env:HTTPS_PROXY = "http://username:password@proxy.company.com:8080"

# Lokale Adressen ohne Proxy
$env:NO_PROXY = "localhost,127.0.0.1,.internal.corp"

# Cursor aus demselben Terminal starten
cursor

macOS / Linux

# Bash/Zsh
export HTTP_PROXY="http://username:password@proxy.company.com:8080"
export HTTPS_PROXY="http://username:password@proxy.company.com:8080"
export NO_PROXY="localhost,127.0.0.1,.internal.corp"

# Cursor starten
cursor

WSL2 – Besonderheiten

WSL2 hat eine eigene virtuelle Netzwerkkarte und liegt nicht im selben Subnetz wie der Windows-Host. Windows-Proxy-Einstellungen werden nicht automatisch nach WSL2 synchronisiert.

🔥 Verschwende keine Monate für ungenutzte Produkte! Teste deine SaaS-Nutzenversprechen mit Adsterra bei kleinem Budget →

Jetzt testen →Anzeige

Eine Möglichkeit ist das Tool graftcp für transparentes TCP-Proxying:

# graftcp installieren
sudo apt install graftcp

# Proxy-Adresse konfigurieren (graftcp.conf)
proxy_addr = "192.168.1.100:7890"  # Proxy-Adresse des Windows-Hosts

# Cursor mit graftcp starten
graftcp cursor

Typische Fallstricke:

• Start über Dock/Desktop-Symbol → Umgebungsvariablen greifen nicht
• Nur HTTP_PROXY, kein HTTPS_PROXY → Cursor-API-Anfragen (alles HTTPS) laufen nicht über den Proxy
• .internal.corp fehlt in NO_PROXY → interne Dienste gehen ebenfalls über den Proxy und werden langsamer

Wer nicht jedes Mal aus dem Terminal starten will, ist mit settings.json besser bedient.

settings.json-Proxy-Konfiguration (empfohlene Methode)

Cursor öffnen, Cmd+Shift+P (Mac) oder Ctrl+Shift+P (Windows) drücken und Preferences: Open User Settings (JSON) eingeben.

In settings.json folgende Einträge ergänzen:

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

Felder im Überblick:

Neustart erforderlich.

Nach Änderungen an settings.json Cursor vollständig schließen und neu öffnen. Ein Fenster-Refresh (Cmd+R) lädt die Netzwerkkonfiguration nicht neu.

Windows-Verknüpfung mit Startparametern:

Alternativ zu settings.json können Startparameter in der Verknüpfung stehen:

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

Wirkung wie settings.json, gilt bei jedem Start ohne separaten Neustart der Konfiguration.

HTTP/2-Inkompatibilität und Lösungen

Die Cursor-Agent-Funktion nutzt HTTP/2 mit bidirektionalem Streaming. Echtzeit-Chat, Code-Vervollständigung und Mehr-Runden-Dialoge hängen an HTTP/2-Langverbindungen und Stream-Push.

Das Problem: Viele Unternehmens-Proxies unterstützen HTTP/2 nicht.

SSL-Inspektions-Proxies wie Zscaler oder Netskope verarbeiten nur HTTP/1.1. HTTP/2-Anfragen von Cursor werden am Proxy abgeschnitten, liefern fehlerhafte Antworten oder laufen ins Timeout.

Symptome:

KiloClaw - Managed OpenClaw für Unternehmen: AI-Agent-Orchestrierung und smartes Modell-Routing

Jetzt starten →Anzeige

• Agent-Panel bleibt bei „Thinking…“ stehen
• Code-Vervollständigung funktioniert sporadisch mit Fehlern
• Chat-Modus ok, Agent-Modus zeigt durchgehend Fehler

Lösung: HTTP/2 deaktivieren und auf HTTP/1.1 SSE downgraden.

{
  "cursor.general.disableHttp2": true
}

Oder als Startparameter:

cursor --disable-http2

Danach nutzt Cursor Server-Sent Events (SSE) über HTTP/1.1 für Streaming. SSE ist unidirektional und weniger effizient als bidirektionales HTTP/2, aber deutlich kompatibler.

Detail: Existieren --disable-http2 und disableHttp2 in settings.json gleichzeitig, haben Startparameter Vorrang. Für sicheres Deaktivieren beides setzen.

Laut Cursor Forum löst diese Methode die Agent-Probleme der meisten Unternehmensnutzer. In Cursor http/2 requests don’t go through proxy setting berichten Nutzer, dass der Agent nach Deaktivierung von HTTP/2 wieder normal läuft.

SSL-Zertifikatsimport (Unternehmens-MITM-Inspektion)

Bei SSL-Entschlüsselung ersetzt der Unternehmens-Proxy das Originalzertifikat durch ein Proxy-eigenes. Netskope, Zscaler und ähnliche Lösungen bieten diese Funktion.

Cursor verbindet sich mit cursor.com oder api2.cursor.sh und erhält ein vom Unternehmens-Proxy signiertes Zertifikat statt eines von Let’s Encrypt oder DigiCert. Die Prüfung schlägt fehl, die Verbindung bricht ab.

Symptome:

• TLS handshake timeout
• certificate signature failure
• Agent-Panel zeigt CERT_AUTHORITY_INVALID

Methode 1: Unternehmens-Root-Zertifikat in den System-Zertifikatspeicher importieren (Windows)

1. Win+R drücken, certmgr.msc eingeben
2. Trusted Root Certification Authorities → Certificates aufklappen
3. Rechtsklick → All Tasks → Import
4. Unternehmens-Root-Zertifikat wählen (.cer oder .pem)
5. Cursor neu starten

Das System vertraut dem Unternehmenszertifikat – Cursor ebenfalls.

Methode 2: Zertifikat per Umgebungsvariable angeben (empfohlen)

Cursor unterstützt SSL_CERT_FILE und SSL_CERT_DIR:

# Einzelnes Zertifikat
export SSL_CERT_FILE=/path/to/company-root-ca.pem
cursor

# Zertifikatsverzeichnis
export SSL_CERT_DIR=/etc/ssl/certs
cursor

Flexibler: kein Eingriff in den System-Zertifikatspeicher, wirkt nur für Cursor.

Methode 3: Strenge SSL-Prüfung deaktivieren (nicht empfohlen)

{
  "http.proxyStrictSSL": false
}

Umgeht die Zertifikatsprüfung, senkt aber die Sicherheit. Nur in Testumgebungen; in Produktion nicht empfohlen.

Zertifikatsimport 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

Danach Cursor neu starten.

Alibaba Cloud - Top-Wahl für Entwickler, exklusiv 15 % Rabatt auf Lighthouse-Server

15 % Rabatt sichern →Anzeige

Anygress und cursor-api-proxy (Erweiterte Konfiguration)

In Unternehmensnetzwerken, auf Remote-Servern oder in privaten Netzen reicht Standard-Proxy-Konfiguration oft nicht. Das Open-Source-Projekt cursor-api-proxy (GitHub: anyrobert/cursor-api-proxy) deckt diese Fälle ab.

Kernprinzip:

cursor-api-proxy startet lokal einen Proxy-Dienst und leitet Cursor-API-Anfragen an den echten Server weiter. Dabei sind TLS-Zertifikatsersetzung, Tailscale-Netzwerk-Tunneling und API-Key-Injektion möglich.

Konfigurationsbeispiel:

# Projekt klonen
git clone https://github.com/anyrobert/cursor-api-proxy
cd cursor-api-proxy

# Umgebungsvariablen setzen
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

# Start mit Tailscale TLS
npm start -- --tailscale

In Cursor den Proxy auf diesen Dienst zeigen:

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

Einsatzszenarien:

• Unternehmensnetzwerk blockiert direkten Zugriff auf cursor.com
• Remote-Server ohne öffentlichen Ausgang, Weiterleitung über Tailscale nötig
• Einheitlicher API-Key für mehrere Nutzer
• Private Deployments mit internem Gateway

Aufwändiger als Standard-Proxy, aber flexibel – für Teams mit grundlegenden Ops-Kenntnissen geeignet.

Fazit

Cursor-Proxy im Unternehmensnetzwerk – in dieser Reihenfolge prüfen:

1. Zuerst settings.json – http.proxy + http.proxySupport: "override"
2. HTTP/2 deaktivieren – wenn der Unternehmens-Proxy es nicht unterstützt: disableHttp2: true
3. Zertifikate prüfen – bei TLS handshake timeout oder CERT_AUTHORITY_INVALID Unternehmens-Root-Zertifikat importieren
4. Komplexe Szenarien: cursor-api-proxy – Remote-Server, privates Netz, Tailscale-Tunnel

Häufige Fehler im Überblick:

Nach der Konfiguration Cursor vollständig neu starten – nicht nur das Fenster aktualisieren.