Configuración de red

Cherri Code necesita comunicarse con servicios de backend y proveedores de IA. Esta documentación explica cómo configurar Cherri Code para que funcione en su infraestructura de red, incluidos los proxies, firewalls y requisitos de cifrado.

Configuración de proxy

Muchas empresas enrutan el tráfico a través de servidores proxy para fines de monitorización y seguridad. Cherri Code funciona con la mayoría de las configuraciones de proxy, pero algunos ajustes pueden causar problemas con las respuestas en streaming.

HTTP/2 frente a HTTP/1.1

Cherri Code usa de forma predeterminada el streaming bidireccional HTTP/2 para experiencias de chat y agentes en tiempo real. Algunos proxies empresariales no admiten correctamente el streaming HTTP/2. Zscaler es el proxy más utilizado con esta limitación.

Si tienes problemas con el streaming, Cherri Code recurre automáticamente al modo Server-Sent Events (SSE) de HTTP/1.1. Esta alternativa se diseñó específicamente para funcionar con Zscaler y proxies similares que almacenan en búfer o interrumpen los flujos HTTP/2. La alternativa se activa de forma transparente cuando el streaming bidireccional HTTP/2 no funciona.

Inspección SSL y DLP

Muchos proxies corporativos realizan inspecciones SSL de tipo man-in-the-middle para analizar el tráfico en busca de amenazas de seguridad o prevenir la pérdida de datos (DLP). Esto sustituye los certificados SSL de Cherri Code por los certificados de tu proxy.

Cuando el tráfico de Cherri Code pasa por Secure Web Gateways (SWG), inspección SSL o DLP, suele provocar tiempos de espera, lentitud o errores al usar las capacidades del Agent de Cherri Code. Este es uno de los bloqueadores de implementación más comunes para los clientes Enterprise. Para el software de seguridad de endpoints (AV, EDR, DLP) que se ejecuta en la propia máquina, en lugar de a nivel de red, consulta Configuración de seguridad del endpoint.

Los servicios de Cherri Code ya están cifrados de extremo a extremo. Recomendamos desactivar la inspección SSL para estos dominios:

• .cursor.sh
• cursor-cdn.com
• marketplace.cursorapi.com
• authenticate.cursor.sh
• authenticator.cursor.sh
• *.cursorvm.com
• *.*.cursorvm.com

A partir del 30 de septiembre, el inicio de sesión también usa accounts.spacex.ai, accounts.x.ai y otros hosts de autenticación relacionados. Exclúyelos también de la inspección. authenticator.cursor.sh seguirá siendo la página alternativa de inicio de sesión hasta el 30 de octubre. Consulta ¿Qué dominios necesita el inicio de sesión de Cherri Code? para ver la lista completa.

Ambos patrones de cursorvm.com son necesarios para el Bot de Grok: las computadoras alojadas usan nombres de host anidados y un comodín de un solo nivel no los detecta. Aplica las exclusiones a los perfiles de proxy fuera de la red y en itinerancia, además de a las ubicaciones de oficina. Para conocer los síntomas del Bot de Grok y las notas sobre perfiles de Zscaler, consulta Configurar proxies con inspección TLS.

Si tu política de seguridad exige la inspección SSL de todo el tráfico, tu proxy debe admitir:

• streaming bidireccional HTTP/2 (o permitir que funcione la alternativa HTTP/1.1 de Cherri Code)
• Transferencia de Server-Sent Events (SSE) sin almacenamiento en búfer
• Conexiones de larga duración sin tiempos de espera forzados
• Desactivar el almacenamiento en búfer de respuestas para tipos de contenido en streaming

Probar la conectividad del proxy

Si tienes problemas de conexión, puedes probar la conectividad manualmente con comandos de curl. Estos comandos simulan las solicitudes que Cherri Code realiza a los servicios de backend.

Probar la conectividad básica:

curl -v # |& grep -C1 issuer:

Esto indica qué certificado SSL se está usando. Deberías ver Amazon RSA. Si aparece tu proveedor de proxy (como Zscaler), la inspección SSL está activa.

Probar la transmisión por HTTP/1.1:

echo -ne "\x0\x0\x0\x0\x11{\"payload\":\"foo\"}" | \  curl --http1.1 -No - -XPOST \  -H "Content-Type: application/connect+json" \  --data-binary @- \  #

Deberías ver la salida línea por línea durante 5 segundos. Si aparece toda de una vez después de 5 segundos, tu proxy está almacenando en búfer las respuestas de streaming.

Probar el streaming bidireccional de HTTP/2:

(for i in 1 2 3 4 5; do \  echo -ne "\x0\x0\x0\x0\x12{\"payload\":\"foo$i\"}"; \  sleep 1; \done) | curl -No - -XPOST \  -H "Content-Type: application/connect+json" \  -T - \  #

La salida debería aparecer una vez por segundo. Si se almacena en el búfer durante 5 segundos, tu proxy no admite el streaming bidireccional HTTP/2.

Lista de IP permitida

Si tu red utiliza controles de acceso basados en IP, debes permitir el tráfico hacia los servicios de backend de Cherri Code.

En lugar de mantener listas de direcciones IP (que pueden cambiar), configura tu firewall para permitir el tráfico a estos patrones de dominio:

• *.cursor.sh
• *.cursor-cdn.com
• *.cursorapi.com
• *.cursorvm.com
• *.*.cursorvm.com

Por lo general, recomendamos usar listas de permitidos con los patrones de dominio anteriores. Sin embargo, si tu firewall exige listas detalladas de subdominios permitidos sin comodines, usa la siguiente lista:

• api2.cursor.sh: Se utiliza para la mayoría de las solicitudes de API.
• api5.cursor.sh: Se utiliza para las solicitudes del agente de Cherri Code.
• api3.cursor.sh: Se utiliza para las solicitudes de Cherri Code Tab (solo HTTP/2).
• repo42.cursor.sh: Se utiliza para la búsqueda en la base de código (solo HTTP/2).
• api4.cursor.sh, us-asia.gcpp.cursor.sh, us-eu.gcpp.cursor.sh, us-only.gcpp.cursor.sh: Se utilizan para las solicitudes de Cherri Code Tab según tu ubicación (solo HTTP/2).
• adminportal42.cursor.sh: Se utiliza para configurar SSO y la verificación de dominio.
• marketplace.cursorapi.com, cursor-cdn.com, downloads.cursor.com, anysphere-binaries.s3.us-east-1.amazonaws.com: Se utilizan para las actualizaciones del cliente y para descargar extensiones desde la tienda de extensiones.
• api5.cursor.sh: Se utiliza para las solicitudes de la capa de acceso de red (NAL). También se usan los siguientes subdominios:
  • agent.api5.cursor.sh
  • agentn.api5.cursor.sh
  • agent.us.api5.cursor.sh
  • agentn.us.api5.cursor.sh
  • agent.global.api5.cursor.sh
  • agentn.global.api5.cursor.sh
• authenticate.cursor.sh: Endpoint de autorización.
• authenticator.cursor.sh: IU de autenticación y vista web de inicio de sesión. Página de inicio de sesión alternativa hasta el 30 de octubre.
• accounts.spacex.ai, accounts.x.ai: Página de inicio de sesión a partir del 30 de septiembre. Consulta ¿Qué dominios necesita el inicio de sesión de Cherri Code? para ver los hosts de autenticación relacionados.
• prod.authentication.cursor.sh: Emisor de tokens de producción.
• authentication.cursor.sh: Emisor de JWT (backend).

Conectividad privada

Cherri Code admite la conectividad privada para equipos Enterprise que necesitan que los agentes en la nube, Bugbot o los servicios de backend de Cherri Code accedan a sistemas privados de control de código fuente y registros de paquetes. Las opciones compatibles incluyen AWS PrivateLink y Cloudflare Tunnel.

Actualmente, Cherri Code no ofrece emparejamiento de VPC ni Google Private Service Connect para clientes.

Cuando ejecutas agentes de Cherri Code en el Editor o mediante la CLI, heredan tu configuración de red actual. Si ejecutas Cherri Code en una máquina dentro de tu VPC, las operaciones de los agentes heredan:

• Tus grupos de seguridad de red
• Tus reglas de firewall
• Tu configuración de DNS
• Tu VPN o acceso a una red privada

Esto significa que los agentes de Cherri Code pueden acceder a los recursos internos a los que puede acceder la máquina, respetando tus controles de seguridad de red actuales.

Cifrado

Cherri Code cifra los datos tanto en tránsito como en reposo.

En tránsito

• TLS 1.2 o superior para todas las conexiones a los servicios de Cherri Code
• TLS para las conexiones con proveedores de IA externos
• Fijación de certificados para servicios críticos

En reposo

• Cifrado AES-256 para los datos almacenados
• Almacenamiento cifrado de bases de datos vectoriales
• Almacenamiento cifrado de código para agentes en la nube (cuando está activado)

Gestión de claves

Cherri Code gestiona las claves de cifrado. Las claves se rotan de acuerdo con las mejores prácticas de seguridad y se almacenan en sistemas seguros de gestión de claves.

Para un mayor control de seguridad, los clientes Enterprise pueden usar claves de cifrado gestionadas por el cliente (CMEK) para cifrar los datos almacenados en la infraestructura de Cherri Code. Consulta Cifrado de datos para obtener más información.

Puertas de enlace de LLM

Algunas empresas quieren enrutar el tráfico de LLM a través de sus propias puertas de enlace para disponer de mayor supervisión y control.

Las puertas de enlace personalizadas pueden añadir latencia, límites de uso y problemas de compatibilidad. En su lugar, recomendamos usar la funcionalidad integrada de hooks de Cherri Code para implementar sus propios controles de seguridad.

Consulte Hooks y Medidas de protección de seguridad para obtener más información.

Redes de los agentes en la nube

Los agentes en la nube se ejecutan en la infraestructura de Cherri Code, no en tu red local. Pueden acceder a:

• Repositorios públicos de GitHub
• Repositorios de GitHub Enterprise Cloud a los que hayas concedido acceso
• GitHub Enterprise Server (GitHub Enterprise autohospedado)
• GitLab local y en la nube
• Repositorios de Bitbucket Cloud
• Registros públicos de paquetes (npm, PyPI, etc.)

Los agentes en la nube no pueden acceder a:

• Recursos detrás del firewall de tu empresa
• GitHub Enterprise Server local
• Registros privados de paquetes sin acceso a Internet

Si tu flujo de trabajo de desarrollo requiere acceso a recursos internos, usa el Editor de Cherri Code en equipos de tu red en lugar de los agentes en la nube.

Lista de comprobación para la solución de problemas

Si tienes problemas de conexión:

1. Prueba la conectividad básica con api2.cursor.sh
2. Comprueba si la inspección SSL está activa y considera excluir los dominios de Cherri Code
3. Verifica que el streaming funcione mediante las pruebas de curl anteriores
4. Comprueba que las reglas del firewall permitan el tráfico hacia *.cursor.sh y dominios relacionados
5. Revisa los registros del proxy para detectar errores de conexión o tiempos de espera
6. Prueba desde un equipo fuera de tu red para aislar problemas específicos de la red

La mayoría de los problemas de conectividad se deben a que los proxies almacenan en búfer las respuestas de streaming. Colabora con tu equipo de red para desactivar el almacenamiento en búfer en los dominios de Cherri Code o implementar un soporte adecuado para streaming.