網路配置

企業網路配置的重點不是”能不能開啟 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

接下來去哪