Cursor 连不上、请求超时：官方 network 排查页的分支怎么走

在公司网络里用 Cursor，最难受的不是彻底连不上——彻底连不上你至少知道去找网络组。难受的是它半死不活：补全偶尔出得来，对话发出去转很久然后超时，换个网就好了。这种时候人会本能地怀疑账号、怀疑订阅、怀疑是不是被限流了，然后在错误的方向上耗掉一下午。

Cursor 官方把这类问题拆在两页里：cursor.com/help/troubleshooting/network（面向个人使用者的问答式排查）和 cursor.com/docs/enterprise/network-configuration（面向企业网络管理员的配置说明）。这两页的分支不完全重合，甚至在同一件事上口径不太一样。下面按「现象 → 怎么确认 → 文档给的处置 → 怎么验证 → 什么情况说明不是这个原因」走一遍。

一、现象长什么样

官方文档里能对上号的现象大致是这几类：AI 功能停止工作、请求超时或变慢、agent 相关能力报错、更新拉不下来、DNS 报错、以及一条特定的 “suspicious activity” 提示。企业网络配置页写得更直接：当 Cursor 的流量经过 Secure Web Gateways（SWG）、SSL 检查或 DLP 时，「often causes timeouts, slowness, or errors when using Cursor’s Agent capabilities」，并且文档自述这是企业客户最常见的部署阻碍之一。

注意这里的因果方向：文档说的是「超时、变慢、报错」，不是「直接断开」。所以「时好时坏」恰恰在这条分支的射程里，不该被排除。

二、怎么确认是网络这一层的问题

第一个动作：跑官方自带的诊断

help 页写明的入口是 Cursor Settings > Network > Run Diagnostics，文档描述它「tests your connection to Cursor’s servers and identifies issues affecting AI features or updates」。这是成本最低的一步，先跑它，再决定要不要动 curl。

至于诊断结果长什么样、报哪些项，官方文档没有说明这一点，我们也没有对它做过实测，这里不做任何描述。

第二个动作：三条 curl 连通性测试

企业网络配置页给了三条命令，明说是「simulate the requests Cursor makes to backend services」。以下命令原样抄自官方文档，我们没有实际执行过。

测基本连通性，看证书是谁签的：

curl -v https://api2.cursor.sh |& grep -C1 issuer:

文档写明的判读方式是：应当看到 Amazon RSA；如果看到的是你的代理厂商（文档举的例子是 Zscaler），说明 SSL 检查正在生效。这一条是整个排查里信息量最大的——它把「我们公司到底有没有做 SSL 中间人」这个通常要问网络组才知道的事，变成了一条你自己就能跑的命令。

测 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 @- \
  https://api2.cursor.sh/aiserver.v1.HealthService/StreamSSE

判读方式：输出应当在 5 秒内一行一行出现；如果是憋满 5 秒后一次性全吐出来，说明你的代理在缓冲流式响应。

测 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 - \
  https://api2.cursor.sh/aiserver.v1.HealthService/StreamBidi

判读方式：输出应当每秒出现一次；如果被缓冲了 5 秒，说明你的代理不支持 HTTP/2 双向流。

Windows 侧要多绕一步。 上面三条命令用的是 POSIX shell 语法：|&、echo -ne、( ... ) 形式的子 shell 与管道。官方文档把它们标为 bash，没有给 Windows 的等价写法。在 Windows 上想照原样跑，实际可行的做法是放进 Git Bash 或 WSL 里执行；PowerShell 里的 curl 默认是 Invoke-WebRequest 的别名，参数语义不同，直接粘贴会失败。这一段是通用的命令行常识，不是 Cursor 官方文档的内容，写在这里只是为了让 Windows 读者别把 shell 报错误判成网络故障。

三、文档给出的处置

分支 A：代理不支持 HTTP/2 流式

这里有一处两页口径不一致，值得单独点出来。

• help 页写的是手动开关：Cursor 用 HTTP/2 做流式响应，某些企业代理（文档点名 Zscaler）会拦 HTTP/2；处置是到 Cursor Settings > Network 把 HTTP Compatibility Mode 设为 HTTP/1.1，然后重启 Cursor。
• 企业网络配置页写的是自动回退：如果遇到流式问题，Cursor 会自动回退到 HTTP/1.1 的 Server-Sent Events（SSE）模式，文档自述这个回退「was specifically designed to work with Zscaler and similar proxies」，并且「happens transparently」。

两处白纸黑字放在一起就是：既有自动回退，也有手动开关。至于自动回退在什么条件下没能触发、手动开关和自动回退谁优先，官方文档没有说明这一点，我们也不推断。实践含义只有一条——别因为文档说了「会自动回退」就不去看那个手动开关。

分支 B：SSL 检查 / DLP 拦在中间

第一条 curl 如果看到的是代理厂商的证书，就落到这条分支。文档的建议是：Cursor 的服务本身已经端到端加密，推荐对以下域名禁用 SSL 检查：

SSL 检查建议豁免的域名（企业网络配置页原文）
.cursor.sh
cursor-cdn.com
marketplace.cursorapi.com
authenticate.cursor.sh
authenticator.cursor.sh
*.cursorvm.com
*.*.cursorvm.com

如果你所在组织的安全策略要求对所有流量做 SSL 检查、没有豁免余地，文档列了代理必须满足的四项能力：支持 HTTP/2 双向流（或者保证 Cursor 的 HTTP/1.1 回退能工作）、SSE 透传且不缓冲、长连接不被强制超时、对流式内容类型关闭响应缓冲。这四项是拿去和网络组对话的清单——把它原样发过去，比你自己转述「它需要长连接」有用得多。

分支 C：防火墙没放行

需要放行的范围，两页给的粒度不同，别混用：

• help 页给的是精简版三条：*.cursor.sh（含 authenticate.cursor.sh 与 authenticator.cursor.sh）、*.cursor-cdn.com、*.cursorapi.com（含 marketplace.cursorapi.com）。help 页自己也写了，完整清单去看企业网络配置页。
• 企业网络配置页推荐按域名模式放行（文档理由是 IP 地址列表会变）：*.cursor.sh、*.cursor-cdn.com、*.cursorapi.com、*.cursorvm.com、*.*.cursorvm.com。

对照一下就会发现，help 页那三条里没有 *.cursorvm.com 与 *.*.cursorvm.com。所以如果你照 help 页配完仍有问题，去企业页把清单补齐是有依据的一步。

企业页另外给了一份「防火墙强制要求不带通配符的细粒度子域清单」，逐条标注了用途，其中 api3.cursor.sh、repo42.cursor.sh 以及几个 gcpp.cursor.sh 子域被明确标为 HTTP/2 only。这份清单较长，本文不整体搬运——要用就直接照企业网络配置页原文抄给网络组，别用二手转述。它的价值在于每条子域后面都标了用途（比如 repo42.cursor.sh 标的是代码库索引），所以抄漏哪一条，对应的就是文档标注的那一项用途受影响；至于漏配之后具体报什么错，官方文档没有说明这一点。

分支 D：SSH / 远程连接

help 页在这里给了一个很多人想不到的前提：用 Remote SSH 时，AI 功能跑在你本地机器上，只是通过远程服务器做文件访问。文档给的四步是：

1. 先查本地网络。AI 请求是从本地机器发往 Cursor 服务器的，不是从远程主机发出去的。
2. 确认远程服务器没有内存或 CPU 耗尽，资源耗尽会导致连接掉线。
3. 如果 SSH 连接频繁掉线，在 SSH 配置里加大 keep-alive 间隔：

Host your-server
  ServerAliveInterval 60
  ServerAliveCountMax 3

4. 重连后重启 Cursor，因为掉线的 SSH 会话可能留下残留进程。

第 1 步在排查顺序上很关键：它意味着「远程服务器网络正常」不能证明 AI 请求走得通。反过来，你在跳板机上跑通了 curl，也不代表本机通。

分支 E：VPN 断开后 DNS 解析失败

help 页写明 Cursor 可能继承之前生效的 VPN 的 DNS 设置。处置两步：完全重启 Cursor（不是重新加载窗口），文档说这会清掉继承来的环境变量；仍不行就检查系统 DNS 是否已经回到正常解析器——macOS 跑 scutil --dns，Linux 看 /etc/resolv.conf。

Windows 侧官方文档没有给出对应的检查命令，只写了 macOS 与 Linux 两种。这里不替它补一个，请自行按所在组织的规范核对系统 DNS。

分支 F：“suspicious activity” 提示

help 页写明这条提示出现在请求被作为安全措施拦截时，VPN 有时会触发它。处置顺序是：先关掉 VPN；不行的话，开一个新的 chat、等几分钟再试、或换一种认证方式登录（Google 或 GitHub）。这条分支和前面几条不同——它不是你的网络配置错了，所以不用去动代理和防火墙。

四、处置完怎么验证

企业网络配置页末尾给了一份 troubleshooting checklist，共六步，可以直接当验收单用：测到 api2.cursor.sh 的基本连通性、确认 SSL 检查是否生效并考虑排除 Cursor 域名、用上面的 curl 测试确认流式可用、检查防火墙规则放行了 *.cursor.sh 及相关域名、翻代理日志找连接错误与超时、以及从网络外的一台机器上测一次以隔离出是不是网络特有的问题。

验证的顺序建议倒过来对：第一条 curl 的 issuer 从代理厂商变回 Amazon RSA，说明豁免生效了；第二、三条 curl 从「憋 5 秒一次性吐」变成「逐行 / 每秒出现」，说明缓冲问题解决了。别拿「对话能出字了」当验证依据——它时好时坏，本来就是这类问题的特征。

文档最后一句结论写得很直白：多数连通性问题源自代理缓冲流式响应，建议和网络团队一起对 Cursor 域名关闭缓冲，或实现正确的流式支持。

五、什么情况说明不是这个原因

这一步比前面都重要，否则你会一直在网络这一层打转：

• 三条 curl 全部符合预期判读（证书是 Amazon RSA、HTTP/1.1 逐行出、HTTP/2 每秒出），说明代理与防火墙这一层没有拦你，再去调代理配置就是白费功夫。

• 换到公司网络外的机器仍然复现——这正是 checklist 第六步的用意，从网外测一次是用来隔离「是不是网络特有问题」的。网外也复现，就不是本文这几条分支。

• 提示的是 “suspicious activity”：文档把它归为安全措施拦截，处置是关 VPN、新开 chat、换登录方式，不是改防火墙。

• 拦你的东西装在本机上，而不在网络这一层：企业网络配置页在讲 SSL 检查时专门分了一句——跑在机器本身上的终端安全软件（文中列的是 AV、EDR、DLP）另有一页《Endpoint Security Configuration》来讲，不在这一页的范围里。所以如果本机装着这类软件，上面这些代理与防火墙的动作可能全做对了也没用，得换那一页去查。

• 你用的是 Cloud Agent，要访问的是内网资源：企业网络配置页写明 Cloud Agents 跑在 Cursor 的基础设施上而非你的本地网络，它不能访问企业防火墙后的资源、本地部署的 GitHub Enterprise Server、以及没有公网出口的私有包仓库；文档给的建议是这种情况改用装在你网络内机器上的 Cursor 编辑器。这类「访问不到内网」不是配置错了，是架构边界。

  顺带指出该页自身的一处措辞冲突：可访问清单里写了 “GitHub Enterprise Server (self-hosted GitHub Enterprise)“，而紧接着的不可访问清单里又写了 “On-premises GitHub Enterprise Server”。这两条摆在一起是矛盾的，具体以哪条为准，官方文档没有进一步说明，涉及这个场景请直接找官方确认，我们不做推断。

• 你在走自建 LLM 网关：该页写明自定义网关可能引入额外延迟、限流与兼容性问题，官方给的替代建议是用 Cursor 内置的 hooks 实现自己的安全控制；同时明确写了 Zero Data Retention 策略在使用你自己的 API key 时不适用，数据处理受你所选 AI 供应商的隐私政策约束。这类问题的根不在防火墙。

• 你在找 VPC peering 或 Google Private Service Connect：文档写明目前不提供这两者，私有连通性支持的选项是 AWS PrivateLink 与 Cloudflare Tunnel，且限定在 Enterprise 团队需要 Cloud Agents、Bugbot 或 Cursor 后端服务访问私有源码系统与包仓库的场景。查不到的能力就是查不到，不用继续折腾网络配置。

还有一条容易被忽略的前提：企业网络配置页写明，在编辑器里或通过 CLI 跑的 Cursor agent 会继承你现有的网络配置——网络安全组、防火墙规则、DNS 配置、VPN 或私有网络访问。所以同一台机器上你自己能 curl 通的内网地址，agent 也能到；反过来，你 curl 不通的，agent 也不会有特权。排查内网访问失败时，先在同一台机器上手动验证一次，能省掉一整轮猜测。

---

本文依据 Cursor 官方文档（cursor.com/docs 与 cursor.com/help）于 2026-08-18 的公开内容整理。 该产品闭源，本文只复述官方文档写明的机制，不推断其内部实现； 我们没有对文中涉及的功能做过实测，因此不涉及界面外观、操作手感与运行速度的任何描述。 该产品迭代频繁，文中涉及的设置项与命令随版本变动，请以官方文档最新内容为准。 本文不涉及订阅价格、额度与模型清单，相关信息请以官方定价与模型说明页为准。

安全与合规相关做法请结合自身环境评估，本文不构成安全方案建议。