Cursor 一直转圈而不报错，说明请求发出去了但响应回不来——连接处于「半通」状态。四个高发挂起点按命中率排：HTTP/2 长流被代理链路吞掉（设置中 Disable HTTP/2 立即验证）；代理链路 TCP 通但流式响应断（换专线节点）；免费档慢速请求在高峰期排队（等待或升级，不是故障）；上下文太大导致请求超重（新开对话、缩小引用范围）。与报错类故障不同，转圈问题九成出在「流」而不是「连接」上。
目录
「转圈」是一种特殊的故障形态
报错 = 连接失败；转圈 = 连接成功但流式响应挂起。Cursor 的 AI 回复是逐 token 流回的长响应，任何一个环节把「流」掐断而不关闭连接，界面就只能永远转圈。所以排查目标不是「连不连得上」，而是「流为什么断」。
明确报错的情况走另一条路径：Cursor 网络连接失败怎么办。
四个静默挂起点
1. HTTP/2 长流被代理吞掉（命中率最高）
部分代理协议栈对 HTTP/2 的长响应流处理有缺陷：握手成功、请求发出、然后无限沉默。
验证 / 修复：Cursor 设置搜索 http2 → 勾选 Disable HTTP/2 → 重启 Cursor → 重发请求。一分钟见分晓，命中即根治。
2. 线路丢包掐断流式响应
晚高峰中转线路丢包时，长响应流很容易中途死掉，而短请求（登录、列表加载）不受影响——于是「能登录、能看到模型列表、就是回答转圈」。
验证：是否集中在 20:00–23:00？ping -c 100 节点丢包是否 > 1%？（背景见 晚高峰速度慢怎么办）
修复：换 IEPL / IPLC 专线节点并固定，选择方法见 Cursor 用什么节点比较稳定。
3. 慢速队列（不是故障）
免费额度用尽后的慢速请求（slow requests）在高峰期排队。识别特征：转圈但最终总能出结果、非高峰时段明显变快。这是产品设计，网络排查到此为止——要么等，要么升级订阅。
4. 请求过重
超长对话、@codebase 全库引用、大文件粘贴都会让请求体膨胀，在一般线路上超时率陡增。缓解：新开对话、精确 @ 单个文件、把大任务拆小。
排查决策树
一直转圈
├─ 所有请求都转 → 关 HTTP/2 → 好了？根治
│ └─ 没好 → 查代理层（TUN）→ 查节点丢包
├─ 只在晚上转 → 线路丢包 → 换专线节点
├─ 慢速请求转、高级请求快 → 队列排队，非故障
└─ 只有长对话转 → 请求过重 → 新开对话、缩小上下文底层环境（TUN、固定节点、域名分流）的完整配置见 Cursor 在国内怎么用；只有特定模型转圈的情况见 Cursor Claude / GPT 模型无法使用怎么办。
常见问题
转圈和报错有什么本质区别？
报错说明连接失败得干脆，问题多在代理与可达性；转圈说明 TCP 连上了但流式响应传不回来，问题多在 HTTP/2 兼容、丢包或服务端排队。两者排查路径不同。
为什么关掉 HTTP/2 就好了？
模型响应是长时间的流式传输，部分代理实现对 HTTP/2 的长流支持有缺陷——连接保持着，数据却不再流动。回退到 HTTP/1.1 后流式路径更简单，兼容性大幅提升。
免费版转圈很久是坏了吗？
不一定。免费档的慢速请求在高峰期进入队列，等待几十秒到几分钟是设计行为。判别方法：同一时间发一条高级请求（若有额度），快速返回就说明网络没问题。
长对话越来越容易转圈是什么原因？
上下文随对话累积，请求体越来越大，在丢包线路上超时概率随之上升。新开对话、用 @ 精确引用文件而不是整个代码库，能明显缓解。