【vs code(cursor) ssh连不上服务器（4）】Cursor远程连接服务器卡死（Waiting for server log）故障排查全流程

系列文章目录

• 【vs code(cursor) ssh连不上服务器】但是 Terminal 可以连上，问题解决 ✅
  • 方法1，重新设置 config
• 【vs code(cursor) ssh连不上服务器（2）】但是 Terminal 可以连上，问题解决 ✅
  • 方法2， 延长 ConnectTimeout
• 此外，还尝试了（3）改 ssh path，（4）与服务器的 vs code 版本不一致，等卸载后重新下载低版本 vs code 方法都不奏效时。
• 【vs code(cursor) ssh连不上服务器（3）】无法连接到远程扩展主机服务器 (错误: CodeError(AsyncPipeFailed(Os { code: 2, kind: NotF

---

提示：写完文章后，目录可以自动生成，如何生成可参考右边的帮助文档

文章目录

• 系列文章目录
• 查看所有与cursor相关的进程（排除grep自身进程）
• 查看当前用户的cursor进程（筛选当前用户UID）
• 查看目录权限
• 批量终止当前用户的所有cursor进程（安全无影响）
• 验证清理结果（无输出即清理完成）
• 删除当前用户的Cursor远程服务目录
• 可选：清理Cursor本地缓存（避免残留配置干扰）
• 方式1：临时禁用（本次登录生效）
• 方式2：永久禁用（避免下次登录自动激活，可选）

---

Cursor远程连接服务器卡死（Waiting for server log）故障排查全流程

在使用Cursor通过Remote SSH连接Linux服务器时，经常会遇到「Waiting for server log」卡死的问题，反复重连仍无法解决，后台还会堆积大量相关进程。本文结合实际排查场景，梳理完整的故障定位、分析及解决流程，适用于多用户共用服务器、环境存在干扰（如Conda）的常见场景，供大家参考复用。

一、故障现象

1. 本地Cursor通过Remote SSH连接目标服务器，输入密码后验证通过，却一直卡在「Waiting for server log」界面，无法进入远程工作区；

2. 多次关闭窗口、重新连接后，故障依旧，且服务器后台出现大量与Cursor相关的进程；

3. 查看Cursor远程服务日志文件（.cursor-server/.cli-xxx.log），发现日志为空，无法通过日志定位直接错误。

补充服务器基础信息（排查参考）：Ubuntu 24.04.4 LTS系统，存在多用户共用，系统负载较高（load值8+），内存使用率正常，Swap使用率30%左右。

二、排查思路与步骤

排查核心逻辑：先确认SSH连接是否正常 → 定位Cursor进程异常 → 排查权限/环境/缓存问题 → 逐步清理修复，全程避免影响其他用户。

步骤1：确认SSH连接有效性

首先排除SSH连接本身的问题，通过终端直接SSH登录服务器，验证连接是否正常：

ssh 目标服务器IP/主机名

若能正常登录，说明SSH连接无异常，故障聚焦于Cursor远程服务本身；若无法登录，需先排查SSH配置、防火墙、端口（22端口）等基础问题。

本次排查中，终端SSH可正常登录，排除SSH层面故障。

步骤2：查看Cursor相关进程，区分用户进程

服务器多用户共用时，需先区分当前用户与其他用户的Cursor进程，避免误操作影响他人。通过以下命令查看所有Cursor相关进程：

查看所有与cursor相关的进程（排除grep自身进程）

ps -ef | grep cursor | grep -v grep

查看当前用户的cursor进程（筛选当前用户UID）

pgrep -u 当前用户UID -f cursor

排查发现：当前用户后台堆积了大量Cursor进程（包括CLI进程、终端集成进程），而其他用户的Cursor进程正常运行，说明故障是当前用户的进程堆积导致，与其他用户无关。

步骤3：排查Cursor日志与目录权限

Cursor远程服务会生成日志文件（路径：~/.cursor-server/.cli-xxx.log），用于记录启动过程中的错误，但本次排查中日志为空，进一步分析可能原因：

1. 日志文件无法写入（权限不足）；

2. Cursor远程CLI进程启动瞬间崩溃，未来得及写入日志。

先检查Cursor远程服务目录（~/.cursor-server）的权限：

查看目录权限

ls -ld ~/.cursor-server

本次排查中，目录权限为drwxrwxr-x，所属用户与当前用户一致，权限正常，排除权限导致的日志无法写入问题，确定故障为Cursor进程启动异常。

步骤4：分析进程堆积与启动异常原因

结合排查结果，梳理出进程堆积及启动异常的核心原因：

1. 多次重连导致进程堆积：每次连接卡死时，关闭窗口未彻底终止后台进程，反复重连后，旧进程残留，新进程无法正常启动，形成"堆积堵死"；

2. 环境干扰（Conda自动激活）：当前用户登录后自动激活Conda基础环境，环境变量被修改，导致Cursor远程CLI进程启动时依赖库路径异常，启动失败并卡死；

3. 服务器负载较高：系统负载偏高，Cursor远程服务占用资源较大，进一步加剧进程启动失败和卡死概率。

三、解决方案（分步骤执行，安全无影响）

核心原则：只操作当前用户的进程和目录，不影响其他用户，彻底清理残留，修复环境干扰。

步骤1：安全清理当前用户的Cursor残留进程

仅筛选当前用户的Cursor进程，批量终止，避免误杀其他用户进程：

批量终止当前用户的所有cursor进程（安全无影响）

pgrep -u 当前用户UID -f cursor | xargs -r kill -9

验证清理结果（无输出即清理完成）

pgrep -u 当前用户UID -f cursor

步骤2：清理Cursor远程服务缓存目录

~/.cursor-server目录是当前用户专属的Cursor远程服务缓存目录，包含二进制文件、配置文件等，删除后不影响其他用户，可彻底清理残留：

删除当前用户的Cursor远程服务目录

rm -rf ~/.cursor-server

可选：清理Cursor本地缓存（避免残留配置干扰）

rm -rf ~/.cursor

步骤3：规避环境干扰（Conda自动激活）

临时禁用Conda自动激活，避免环境变量干扰Cursor进程启动，两种方式可选：

方式1：临时禁用（本次登录生效）

conda deactivate

方式2：永久禁用（避免下次登录自动激活，可选）

sed -i.bak '/conda init/d' ~/.bashrc

source ~/.bashrc

步骤4：重新连接Cursor

1. 关闭本地Cursor所有窗口，彻底退出Cursor；

2. 重新打开Cursor，执行「Remote SSH: Connect to Host...」，输入服务器信息和密码；

3. 此时Cursor会自动重新下载、安装适配服务器的远程CLI组件，无需手动干预，等待连接完成即可。

步骤5：补充系统依赖（可选，针对启动失败场景）

若重新连接后仍启动失败，可能是服务器缺少Cursor远程服务必需的系统依赖，Ubuntu系统可执行以下命令安装：

sudo apt update && sudo apt install -y

libx11-6 libxkbfile1 libsecret-1-0 libnss3

libgbm1 libasound2 libatk1.0-0 libatk-bridge2.0-0

四、优化建议（避免后续再次出现）

1. 连接失败时，先清理进程再重连：避免直接关闭窗口，先通过终端终止当前用户的Cursor进程，再重新连接；

2. 优化Cursor远程SSH设置：在本地Cursor中修改设置，减少进程卡死概率：

{

"remote.SSH.enableRemoteCommand": false,

"remote.SSH.useLocalServer": false,

"remote.SSH.connectTimeout": 120,

"remote.SSH.showLoginTerminal": true

}

3. 合理管理Conda环境：若无需默认激活Conda，可永久禁用自动激活，避免环境干扰；

4. 定期清理残留进程：多用户共用服务器时，定期检查并清理自身的残留进程，避免占用过多资源。

五、总结

本次Cursor远程连接卡死故障，核心原因是「进程堆积+环境干扰」，并非服务器本身或SSH配置问题。排查时需优先区分用户进程，避免影响他人，再通过"清理进程→清理缓存→规避环境干扰→重新连接"的流程，即可快速解决问题。

此类故障在多用户共用服务器、频繁重连、存在环境变量干扰（如Conda、虚拟环境）的场景中非常常见，掌握本文排查流程，可快速定位并解决，提升远程开发效率。