网络配置

企业网络配置的重点不是”能不能打开 Cursor”，而是代理、DLP（Data Loss Prevention，数据防泄漏）、SSL inspection（SSL 流量检查，企业代理拆开 HTTPS 看明文做安全审计）、防火墙和 streaming（流式传输）是否会破坏 Agent 的实时响应与长连接。

1. 一句话判断

Cursor 需要和后端服务、模型供应商、扩展市场、认证服务通信。企业代理如果缓冲 streaming、强制 SSL inspection 或中断长连接，最先坏的通常是 chat、Agent 和 CLI 体验。

网络验收要和安全团队一起做，而不是让开发者各自排障。

2. 需要放行的域名

官方建议不要维护固定 IP 列表，因为 IP 可能变化。防火墙和代理应按域名模式放行：

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

对 SSL inspection 和 DLP，官方还明确建议排除这些域名：

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

如果公司安全策略要求所有流量都做 SSL inspection，就必须确保代理支持 streaming、SSE passthrough、长连接和不缓冲 streaming content types。

3. HTTP/2、SSE 和代理缓冲

Cursor 默认使用 HTTP/2 bidirectional streaming，支撑实时 chat 和 Agent 体验。部分企业代理不能正确处理 HTTP/2 streaming，官方点名 Zscaler 是常见限制来源。

Cursor 会在 HTTP/2 不可用时透明 fallback 到 HTTP/1.1 Server-Sent Events。这能兼容一部分会 buffer 或破坏 HTTP/2 stream 的代理，但不能替代网络侧正确配置。

上线前要测两类情况：

• 响应是否逐行出现，而不是 5 秒后一次性吐出。
• 长连接是否被代理、DLP 或 SWG 强行断开。

4. 代理连通性测试

先测试证书链。正常情况下应该看到 Amazon RSA；如果看到 Zscaler 或其他代理证书，说明 SSL inspection 正在介入。

API="https://api2.cursor.sh"
curl -v "$API" 2>&1 | grep -C1 issuer:

再测 HTTP/1.1 SSE。输出应该在 5 秒内逐行出现，如果集中出现，说明代理在缓冲 streaming。

API="https://api2.cursor.sh"
SSE="$API/aiserver.v1.HealthService/StreamSSE"
CT="Content-Type: application/connect+json"

printf '\x0\x0\x0\x0\x11{"payload":"foo"}' | \
  curl --http1.1 -No - -XPOST \
  -H "$CT" \
  --data-binary @- \
  "$SSE"

最后测 HTTP/2 bidirectional streaming。理想状态是每秒返回一次。

API="https://api2.cursor.sh"
BIDI="$API/aiserver.v1.HealthService/StreamBidi"
CT="Content-Type: application/connect+json"

for i in 1 2 3 4 5; do
  printf '\x0\x0\x0\x0\x12{"payload":"foo%s"}' "$i"
  sleep 1
done | curl -No - -XPOST -H "$CT" -T - "$BIDI"

5. VPC 与内部资源边界

官方文档说明 Cursor 目前不提供 VPC（Virtual Private Cloud，虚拟私有云）peering 或 private connectivity。

但本地编辑器和 CLI 运行在你的企业设备上，会继承这台机器已有的网络环境：

• network security groups。
• firewall rules。
• DNS configuration。
• VPN 或 private network access。

这意味着本地 Cursor Agent 能访问用户机器本来就能访问的内部资源。它不是额外打洞，而是继承当前机器权限。

6. Cloud Agents 网络边界

Cloud Agents 运行在 Cursor 基础设施里，不在你的企业内网里。

官方说明 Cloud Agents 可以访问：

• public GitHub repositories。
• 授权过的 GitHub Enterprise Cloud repositories。
• on-prem 和 cloud-based GitLab / Bitbucket。
• public package registries，例如 npm、PyPI。

Cloud Agents 不能访问：

• 公司防火墙后的资源。
• on-premises GitHub Enterprise Server。
• 没有互联网访问的 private package registries。

如果任务需要企业内网、VPN、私有 registry 或内部 API，优先使用企业设备上的 Cursor editor 或 CLI，而不是 Cloud Agents。

7. LLM gateway 和 BYOK 风险

有些企业希望把 LLM 流量转到自有 gateway。官方建议优先用 Cursor Hooks 实现安全控制，因为自定义 gateway 会带来延迟、限流和兼容问题。

还要注意：官方 Zero Data Retention policy 不适用于你自己的 API keys。使用 BYOK 时，数据处理会受你选择的模型供应商政策约束。

所以网络层不要单独做决策，必须和模型治理一起定：

• 是否允许 BYOK。
• 是否需要禁用个人 API keys。
• 是否用 Hooks 做 DLP、审计和阻断。
• 自有 gateway 是否能处理 streaming 和长连接。

8. 商业级验收

• 企业代理放行官方域名，且不依赖固定 IP。
• Cursor 关键域名已从 SSL inspection 中排除，或代理已验证支持 streaming。
• HTTP/1.1 SSE 和 HTTP/2 bidirectional streaming 均通过测试。
• Agent 长任务不会被代理超时中断。
• Cloud Agents 是否能访问所需仓库、registry 和依赖来源已经实测。
• 内网任务明确走本地 editor / CLI，不误用 Cloud Agents。
• BYOK、自有 LLM gateway、DLP、Hooks 的责任边界写清楚。

9. 常见失败点

• 只测网页登录，不测 Agent streaming。
• 防火墙只按 IP 放行，后续 IP 变化导致全员故障。
• SSL inspection 导致证书替换、超时和 Agent 卡顿。
• 代理缓冲 SSE，用户看到的是“模型很慢”而不是网络问题。
• 让 Cloud Agents 处理需要内网、VPN 或私有 registry 的任务。
• 使用自有 API keys 后仍按 Cursor ZDR 承诺回答安全审查。

官方来源

• https://cursor.com/docs/enterprise/network-configuration.md
• https://cursor.com/docs/enterprise/privacy-and-data-governance.md
• https://cursor.com/docs/enterprise/llm-safety-and-controls.md
• https://cursor.com/docs/account/teams/dashboard.md

接下来去哪