Configuración de proxy de red corporativa en Cursor: de HTTP_PROXY a importación de certificados

Pulsas Send y el panel Agent de Cursor muestra Network error. Tienes el proxy global activo, ¿por qué sigue sin conectar?

La respuesta está en la pila de red de Electron v25+: Cursor, VS Code y el sistema operativo usan configuraciones de proxy distintas que no se comparten. Esta guía repasa la configuración de proxy en red corporativa de principio a fin: variables HTTP_PROXY, settings.json, compatibilidad con HTTP/2, importación de certificados SSL y proxy transparente Anygress. Cubre Windows, Mac y WSL2.

¿Por qué Cursor no hereda el proxy del sistema?

Cursor se construye sobre Electron v25+. Su pila de red, igual que la de Chrome, no hereda automáticamente la configuración de proxy del sistema operativo ni del proceso padre. A diferencia de VS Code — que sí lee el proxy del sistema —, Cursor necesita su propia configuración.

Lo complica aún más el tema de las variables de entorno. Si haces export HTTP_PROXY=... en la terminal y luego abres Cursor desde el Dock o un icono de escritorio, esa variable no se transmite. Solo funciona si lanzas cursor desde la misma terminal.

En red corporativa, el método más fiable es editar directamente el settings.json de Cursor.

¿Qué dice la documentación oficial?

Según la documentación de Network Configuration de Cursor, en despliegues corporativos hay tres vías de configuración de proxy:

1. Variables de entorno: HTTP_PROXY, HTTPS_PROXY, NO_PROXY (solo efectivas al arrancar desde terminal)
2. settings.json: http.proxy, http.proxySupport, http.proxyStrictSSL
3. Argumentos de arranque: --proxy-server, --proxy-auto-detect, --disable-http2

Cada método tiene su escenario; más adelante los detallamos uno a uno.

Configuración con variables HTTP_PROXY

Las variables de entorno son la opción más ligera, pero con una condición: Cursor debe arrancarse desde una terminal donde ya estén configuradas.

Windows PowerShell

# Configurar proxy (con autenticación)
$env:HTTP_PROXY = "http://username:[email protected]:8080"
$env:HTTPS_PROXY = "http://username:[email protected]:8080"

# Direcciones locales sin proxy
$env:NO_PROXY = "localhost,127.0.0.1,.internal.corp"

# Iniciar Cursor desde la misma 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"

# Iniciar Cursor
cursor

Caso especial WSL2

WSL2 tiene una tarjeta de red virtual propia y no comparte subred con el host Windows. La configuración de proxy de Windows no se sincroniza automáticamente dentro de WSL2.

Vultr - Servidor cloud NVMe de alto rendimiento, 32 ubicaciones globales, despliegue Docker con un clic

Ver precios →Anuncio

Una opción es usar graftcp como proxy TCP transparente:

# Instalar graftcp
sudo apt install graftcp

# Configurar dirección del proxy (graftcp.conf)
proxy_addr = "192.168.1.100:7890"  # Dirección del proxy en el host Windows

# Iniciar Cursor con graftcp
graftcp cursor

Errores típicos:

• Arrancar desde Dock/icono de escritorio → las variables de entorno no surten efecto
• Definir solo HTTP_PROXY sin HTTPS_PROXY → las peticiones a la API de Cursor (todas HTTPS) no pasan por el proxy
• Olvidar .internal.corp en NO_PROXY → el tráfico interno también pasa por el proxy y se ralentiza

Si no quieres arrancar siempre desde terminal, settings.json es más cómodo.

Configuración de proxy en settings.json (método recomendado)

Abre Cursor, pulsa Cmd+Shift+P (Mac) o Ctrl+Shift+P (Windows) e introduce Preferences: Open User Settings (JSON).

Añade estas entradas en 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
}

Explicación campo a campo:

Reinicio obligatorio.

Tras modificar settings.json hay que cerrar Cursor por completo y volver a abrirlo. Recargar la ventana (Cmd+R) no vuelve a cargar la configuración de red.

Argumentos de acceso directo en Windows:

Si prefieres no tocar settings.json, puedes añadir parámetros al acceso directo:

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

Es equivalente a settings.json, pero se aplica en cada arranque sin reinicio adicional.

Incompatibilidad con HTTP/2 y soluciones

El Agent de Cursor depende de HTTP/2 para streaming bidireccional. Chat en tiempo real, autocompletado y conversaciones multironda usan conexiones largas y push por flujo de HTTP/2.

El problema: muchos proxies corporativos no soportan HTTP/2.

Proxies de inspección SSL como Zscaler o Netskope solo manejan HTTP/1.1. Las peticiones HTTP/2 de Cursor llegan al proxy y se truncan, devuelven datos corruptos o agotan el tiempo de espera.

Síntomas:

Railway - Plataforma de despliegue moderna, sin ops complejas, en producción en minutos

Empezar ahora →Anuncio

• El panel Agent se queda atascado en “Thinking…”
• El autocompletado funciona a ratos y falla otras veces
• El modo Chat va bien; el modo Agent muestra errores

Solución: desactivar HTTP/2 y dejar que Cursor use SSE sobre HTTP/1.1.

{
  "cursor.general.disableHttp2": true
}

O con argumento de arranque:

cursor --disable-http2

Al desactivarlo, Cursor usa Server-Sent Events (SSE) sobre HTTP/1.1 para el streaming. SSE es unidireccional y menos eficiente que el flujo bidireccional de HTTP/2, pero la compatibilidad es mayor.

Un detalle: si coexisten --disable-http2 y disableHttp2 en settings.json, prevalece el argumento de arranque. Para asegurarte de que HTTP/2 queda desactivado, configura ambos.

Según el foro de Cursor, este método resuelve el Agent para la mayoría de usuarios corporativos. En Cursor http/2 requests don’t go through proxy setting varios confirmaron que, tras desactivar HTTP/2, el Agent volvió a la normalidad.

Importación de certificados SSL (inspección corporativa)

Cuando el proxy corporativo descifra SSL, sustituye el certificado original por uno propio. Netskope, Zscaler y similares ofrecen esta función.

Cursor intenta conectar a cursor.com o api2.cursor.sh y recibe un certificado firmado por el proxy, no por Let’s Encrypt o DigiCert. Falla la validación y se corta la conexión.

Síntomas:

• TLS handshake timeout
• certificate signature failure
• El panel Agent muestra CERT_AUTHORITY_INVALID

Método 1: importar el certificado raíz corporativo (Windows)

1. Pulsa Win+R e introduce certmgr.msc
2. Expande Trusted Root Certification Authorities → Certificates
3. Clic derecho → All Tasks → Import
4. Selecciona el archivo del certificado raíz corporativo (.cer o .pem)
5. Reinicia Cursor al terminar

Así el sistema confía en el certificado corporativo y Cursor también.

Método 2: certificado por variable de entorno (recomendado)

Cursor admite SSL_CERT_FILE y SSL_CERT_DIR:

# Certificado único
export SSL_CERT_FILE=/path/to/company-root-ca.pem
cursor

# Directorio de certificados
export SSL_CERT_DIR=/etc/ssl/certs
cursor

Más flexible: no modifica el almacén del sistema y solo afecta a Cursor.

Método 3: desactivar verificación SSL estricta (no recomendado)

{
  "http.proxyStrictSSL": false
}

Evita la validación de certificados, pero reduce la seguridad. Solo en entornos de prueba; no en producción.

Importación en 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

Reinicia Cursor después de importar.

Alibaba Cloud - Opción preferida para desarrolladores, 15 % de descuento exclusivo en Lighthouse

Obtener 15% dto. →Anuncio

Anygress y cursor-api-proxy (configuración avanzada)

En redes corporativas, servidores remotos o redes privadas, la configuración estándar de proxy no basta. El proyecto open source cursor-api-proxy (GitHub: anyrobert/cursor-api-proxy) cubre estos casos.

Principio:

cursor-api-proxy levanta un servicio proxy local que reenvía las peticiones API de Cursor al servidor real. En el camino puede reemplazar certificados TLS, atravesar redes Tailscale o inyectar claves API.

Ejemplo de configuración:

# Clonar el proyecto
git clone https://github.com/anyrobert/cursor-api-proxy
cd cursor-api-proxy

# Variables de entorno
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

# Arranque (con TLS Tailscale)
npm start -- --tailscale

Luego apunta el proxy de Cursor a ese servicio:

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

Escenarios de uso:

• La red corporativa bloquea conexiones directas a cursor.com
• Servidor remoto sin salida a internet, con Tailscale como puente
• Inyectar una API Key unificada (varios usuarios compartidos)
• Despliegue privado con peticiones API por puerta de enlace interna

Más complejo que un proxy estándar, pero mucho más flexible. Adecuado para equipos con cierta capacidad de operaciones.

Conclusión

Para configurar el proxy de Cursor en red corporativa, sigue este orden:

1. Primero settings.json — http.proxy + http.proxySupport: "override"
2. Desactivar HTTP/2 — si el proxy no lo soporta, añade disableHttp2: true
3. Revisar certificados — ante TLS handshake timeout o CERT_AUTHORITY_INVALID, importa el certificado raíz corporativo
4. Escenarios complejos: cursor-api-proxy — servidores remotos, redes privadas, túnel de Tailscale

Errores frecuentes:

Al terminar, reinicia Cursor por completo — no basta con recargar la ventana.