Cursor 补全卡顿，先别急着怪网络，分三段定位
Cursor 的 Tab 补全灰字出现得慢、停顿明显，或者干脆没反应，是很多开发者的日常烦恼。Cursor 补全卡顿的原因可以分成三段：本地编辑器自己的资源占用、到 Cursor 服务器的网络通路，以及补全请求本身的上下文和设置。三段的处理方法完全不同，混在一起排查很容易白忙一场。本文按这个顺序给出定位方法，涉及的菜单名称、设置项和域名都对照 Cursor 官方文档核对，查阅日期为 2026 年 9 月 20 日；Cursor 版本更新频繁，界面可能有出入，找不到时请以你本机的设置页面为准。
先说明一个前提：官方文档里没有给出 Tab 补全延迟的标准数值，所以本文不会给「多少毫秒算正常」的结论，而是教你在自己的环境里做对照记录，用自己的数据判断。
第一段：本地资源占用，先排除编辑器自己的问题
补全卡顿如果同时伴随打字掉帧、风扇狂转、窗口切换变慢，问题多半在本地。这一段不需要任何网络知识，用系统自带的活动监视器（macOS）、任务管理器（Windows）或者 top 命令，观察 Cursor 相关进程的 CPU 和内存占用即可。
为什么索引现在更可能吃本地资源而不是网络
官方文档中关于代码库搜索的说明有一个值得注意的变化：Cursor 现在使用名为 Instant Grep 的自研搜索引擎，文档明确写到，它在你的机器上构建并查询索引，运行时不需要额外配置；同时文档说明 Cursor 不会为构建搜索索引而上传文件路径或代码，也不会为搜索存储代码库的向量嵌入。也就是说，如果你还沿用「索引会占用网络带宽」的旧印象，方向就错了。在大型仓库里，索引更可能表现为本机的磁盘读写和 CPU 占用。具体到你的仓库，可以先在一个很小的目录里复现卡顿，再回到大仓库对比，两边差距明显就说明与仓库规模有关。
怎么判断是不是其他扩展造成的卡顿
Cursor 基于 VS Code 体系，第三方扩展可能与内置补全互相干扰。判断方法很简单：先禁用所有非必要扩展，重启后在同一段代码里再试一次补全。如果卡顿消失，再逐个启用扩展缩小范围。同时安装了其他补全类扩展时尤其要先排除，两个补全来源同时工作，既浪费资源，也可能让建议的显示时机变得不稳定。
第二段：网络通路，用官方诊断工具拿数据
本地没有异常、卡顿又集中在补全出现的那一刻，就轮到网络。官方文档给出的入口是：Cursor Settings，进入 Network，点击 Run Diagnostics。它会测试与 Cursor 服务器的连通情况，并列出影响 AI 功能的问题，比自己猜测要可靠得多。
HTTP 兼容模式怎么改
官方排障文档提到，如果在公司代理后面使用时 AI 功能失败，可能是 HTTP/2 被拦截导致。处理办法是在 Cursor Settings 的 Network 页面，把 HTTP Compatibility Mode 改为 HTTP/1.1，然后重启应用。这个改动只解决协议层面的兼容问题，对线路本身的稳定性没有帮助，所以改完后要对比前后感受，不要把它当成万能方案。
需要放行哪些域名
使用防火墙或代理白名单的环境，需要确保以下域名允许出站访问：*.cursor.sh、*.cursor-cdn.com、*.cursorapi.com、*.cursorvm.com 以及 *.*.cursorvm.com。任何一个被拦截，都可能表现为补全偶尔失败或者响应特别慢。拿到诊断工具列出的具体主机名之后，可以直接用下面的命令测量到这些主机的连接耗时：
curl -sS -o /dev/null -w "%{http_code} %{time_connect} %{time_appconnect}\n" https://诊断结果中的主机名命令中的主机名需要换成诊断结果里出现的实际名称，返回任何 HTTP 状态码都说明能连上，重点看 time_connect 和 time_appconnect 两个耗时。
断开 VPN 之后为什么补全还是异常
官方文档提醒，断开 VPN 之后，建议完整重启一次 Cursor，以清除继承下来的 DNS 设置；如果问题持续，再检查系统的解析配置。很多人只是关闭了窗口而没有退出进程，结果 DNS 状态依然是旧的。
第三段：补全请求本身，用隔离测试缩小范围
官方文档说明，Tab 的建议基于你最近的编辑、周围的代码以及 linter 报错，并且可以通过窗口右下角的状态指示器对补全进行暂停、全局关闭或者按文件类型关闭，更细的选项在 Cursor Settings 的 Tab 页面。这些信息给了我们一个思路：补全延迟可能与当前文件的内容、语言服务的状态有关，不一定全是网络问题。
隔离测试的做法是准备一个只有几十行的空白小项目，在里面反复触发补全。如果小项目里补全很快，而大项目里很慢，问题多半在本地资源或者项目本身的语言服务；如果小项目里也慢，回到第二段检查网络。再用不同的文件类型各测几次，可以排除某个语言插件拖慢了整体。
用了 Remote SSH 时，网络问题出在哪一端
官方文档特别说明：使用 Remote SSH 时，AI 请求是从你的本地机器发往 Cursor 服务器的，而不是从远程主机发出。所以检查网络时，测的应该是本地这台电脑的出口，而不是远程服务器的网络。如果远程连接本身经常断开，文档建议监控远程系统的资源，并适当加大 SSH 的保活间隔。
判断表与自测记录法
| 现象 | 更可能的一段 | 优先动作 |
|---|---|---|
| 打字掉帧，风扇转，大仓库才明显 | 本地资源 | 看进程占用，对比小目录，逐个禁用扩展 |
| Run Diagnostics 报告有失败项 | 网络通路 | 按诊断结果处理，试 HTTP/1.1 兼容模式，核对放行域名 |
| 诊断全部通过，但补全时快时慢 | 线路稳定性 | 多时段记录 curl 耗时和补全延迟 |
| 小项目快，大项目慢 | 本地资源或语言服务 | 检查仓库规模和忽略规则，排查其他扩展 |
| Remote SSH 下 AI 慢 | 本地出口而非远程主机 | 测本地网络，同时检查 SSH 保活设置 |
补全延迟没有现成的官方指标，可以自己做一个简单的记录：在同一个小项目里，每个时段各触发 20 次补全，用屏幕录制逐帧数出从停止输入到灰字出现的时间，记下中位数和最大值，同时记录当时的 time_connect。分别在办公网络和手机热点下各做一轮。如果最大值集中出现在某个时段或某个网络，说明线路稳定性才是瓶颈。这种情况下可以给开发机换一条更稳定的出口，NasaCode 针对 Cursor、Claude Code 和 IDE 场景做了直连优化，并带有 AI 智能路由；效果如何，仍以你自己的前后对照记录为准。
小结
补全卡顿先看本地资源，再用 Run Diagnostics 检查网络，最后用小项目做隔离测试，三段各自有明确的判断标准。菜单名称和设置项以 2026 年 9 月 20 日查阅的官方文档为准，Cursor 更新后请重新核对。
延伸阅读
