国内 Cursor 断线后来怎样了
Cursor 员工 9 月 25 日回复：北京时间 9 月 23 日上午、主要影响中国电信的连接问题当天已恢复；9 月 24 日工作时间部分国内用户再次变慢，也已恢复。仍看到 Reconnecting 时，把 HTTP Compatibility Mode 改成 HTTP/1.1 并完全重启。
论坛帖从 9 月 23 日开始有人报 Cursor 一直 Reconnecting，并出现 Taking longer than expected。Cursor 员工 Dean Rie 在 9 月 25 日回复：影响中国网络、主要是中国电信的连接问题，发生在北京时间 9 月 23 日上午，当天已经恢复。9 月 24 日工作时间，部分国内用户再次变慢、响应中断，也已经恢复正常。cursor reconnecting 中国 若现在还在转圈，他给的下一步是改传输，不是等状态页再写一行。
员工确认的两段，和帖子里的其他地区
9 月 23 日早上的原帖来自国内用户，报错里还有 “The connection was interrupted repeatedly without saving progress, so the agent stopped to avoid repeating the same work.” 另一位国内用户写，即使用美国 VPN 仍然 Connection failed，并数到失败 10 次。员工没有把 VPN 失败单独定性，只确认了电信线路上的那次中断已经结束。
9 月 26 日有加拿大用户说云端能用、IDE 里没有响应，更新客户端之后恢复。Dean 在 9 月 27 日回复：这通常是客户端和服务器之间的短时网络中断，请求到了，响应流被掐掉，所以看到 Reconnecting。云端走另一条路由，所以云端还能用。更新帮上忙，是因为新版本重新建立了连接，不是因为某一条专门的修复。这条和国内 9 月 23 日的电信中断是两件事。
还在转圈时他写的四步
仍看到 Reconnecting 或 Taking longer than expected：
- 打开 Cursor Settings，快捷键是
Ctrl+Shift+J。 - 进入 Network。
- 把 HTTP Compatibility Mode 设为 HTTP/1.1。
- 完全退出 Cursor 再打开，然后新开一个对话。
9 月 27 日他又把这个现象定义成传输问题：请求到达 Cursor，回到本机的响应流被切断。换成 HTTP/1.1 经常有帮助。代理、证书和诊断项的更长清单见 代理超时怎么排查。若换传输之后仍挂住，他要求从聊天菜单复制 Request ID，并附上 Cursor 版本。
退款他另给了一个入口：用账号邮箱写信到 [email protected]，由另一个团队处理。这句出现在国内用户问退款的回复里，不是连接恢复的条件。
编码被改掉、Kimi 自己停住
原帖作者还说源文件编码被改乱。9 月 28 日他补充：文件是 UTF-8 with BOM，有时没编辑过的 C++ 文件也会被改，一天至少十几次。Dean 在 9 月 25 日已把编码标成正在跟踪的已知问题，并问是 GBK 还是 UTF-8 with BOM。回复里没有修复版本。
9 月 27 日另一位用户说 Kimi K3 的对话会自己停住、没有错误条。员工把这个和 Reconnecting 拆开：前者是回合安静结束，也在跟踪，没有说已经修好。两类看起来都像「卡住」，Request ID 要从对应那一次运行里复制，混在同一条工单里对不上会话。