1. 卡在 Waiting for server log 到底卡在哪一环Cursor 和 VS Code 的 Remote-SSH 并不是「SSH 连上就完事」。它其实分两段第一段是本地 ssh 客户端把 TCP 连接建起来第二段是在远端拉起一个叫cursor-serverVS Code 叫vscode-server的常驻服务本地再通过一条隧道跟这个服务通信。你看到的Waiting for server log卡的是第二段——SSH 通了但远端 server 进程没起来或者起来了但没把日志吐出来。这个报错最迷惑人的地方在于终端里ssh userhost明明能登进去密码也对~/.ssh/config看着也没毛病可 Cursor 就是转圈。原因基本落在三类远端 server 进程堆积把端口/锁占死、远端目录权限或缓存损坏、登录 shell 里的环境变量Conda、nvm、自定义 PATH把 server 启动脚本带崩。多用户共用服务器时还要多一层——你分不清哪些进程是自己的误杀别人的会出事。这篇按「先确认 SSH 层没问题 → 定位并清理自己的 server 进程 → 修缓存和权限 → 处理环境干扰 → 重新拉起并验证」的顺序走每一步都给可复制的命令和预期输出。适合谁用 Cursor / VS Code Remote-SSH 连 Linux 服务器、卡在 server log、反复重连无效、后台还堆了一堆进程的人。全程只动当前用户的东西不影响同机其他账号。先说清楚一个判断原则只要终端能 ssh 进去问题就 100% 在远端 server 侧不要去改本地网络、不要重装 Cursor、不要怀疑防火墙。我见过太多人一卡死就去折腾本地方向从一开始就错了。2. 先分清 SSH 层和 server 层别乱改配置排查第一步永远是分层。Remote-SSH 的链路是本地 Cursor → 本地 ssh 进程 → 远端 sshd → 远端登录 shell → 远端 cursor-server 进程 → 本地隧道回连。Waiting for server log出现在最后一跳所以前面几跳必须先证明是好的。打开本地终端不是 Cursor 里的终端是系统终端直接连ssh -v useryour-server-ip-v会打印握手细节。你要确认的是能拿到密码提示或密钥认证成功、能进到 shell、whoami返回的是你自己。如果这一步就失败那跟 Cursor 无关先修 SSH 本身端口、密钥、~/.ssh/config的 Host 段。如果这一步秒进记下这个事实后面所有操作都在远端做。接着在远端确认登录 shell 干净不干净。很多人卡死是因为.bashrc/.bash_profile里有一堆自动激活逻辑server 启动脚本是非交互式执行的遇到conda activate报错就整个挂住ssh useryour-server-ip bash -lc echo SHELL_OK; which node; echo PATH$PATH如果这条命令卡住超过 10 秒或者输出里夹着一堆 Conda 报错那基本锁定是环境干扰。正常应该秒回SHELL_OK和 node 路径。再确认远端有没有残留的 server 进程。注意一定要按当前用户过滤多用户机器上直接pkill cursor会误伤别人# 看所有 cursor 相关进程排除 grep 自己 ps -ef | grep -i cursor | grep -v grep # 只看当前用户的推荐UID 用 id -u 拿 pgrep -u $(id -u) -af cursor-a会把完整命令行打出来-f匹配整条命令。如果输出里有一大串cursor-server、cli、node进程而且时间戳横跨好几次重连那就是典型的进程堆积——每次卡死你关窗口进程没退下一次又拉一个新的越堆越多最后谁也起不来。顺手看一眼 server 目录和日志ls -ld ~/.cursor-server ls -la ~/.cursor-server/.cli-*.log 2/dev/null tail -n 50 ~/.cursor-server/.cli-*.log 2/dev/null日志为空是常见现象别慌。空日志通常意味着 CLI 进程在写日志之前就崩了或者目录权限不对写不进去。ls -ld看权限正常应该是drwx------或drwxrwxr-x且 owner 是你自己。如果 owner 变成了 root比如之前用 sudo 跑过那 server 以你的身份启动时写不进去直接卡死。到这一步你已经能判断出是「进程堆积」「权限/缓存损坏」还是「环境干扰」了。下面按顺序处理。3. 可复制的清理与配置片段这一节给的是能直接粘贴的配置和命令。核心原则只动当前用户的进程和目录。先安全清理当前用户的残留进程。用xargs -r保证没有匹配进程时不会报错# 终止当前用户所有 cursor 相关进程 pgrep -u $(id -u) -f cursor | xargs -r kill -9 # 验证无输出即清理干净 pgrep -u $(id -u) -af cursor如果kill -9之后还有残留少数情况进程处于 D 状态等几秒再查一次。确认干净后清掉远端 server 缓存目录。这个目录是当前用户专属的删了 Cursor 下次连接会自动重新下载rm -rf ~/.cursor-server本地缓存也可以顺手清一下避免旧配置干扰可选# macOS rm -rf ~/Library/Application\ Support/Cursor/CachedData # Linux rm -rf ~/.config/Cursor/CachedData然后是本地 Cursor 的 Remote-SSH 设置。打开settings.jsonCmd/Ctrl Shift P→Preferences: Open User Settings (JSON)加上这几项{ remote.SSH.connectTimeout: 120, remote.SSH.useLocalServer: false, remote.SSH.showLoginTerminal: true, remote.SSH.enableRemoteCommand: false, remote.SSH.logLevel: debug }connectTimeout从默认 15 秒拉到 120给慢服务器留足启动时间useLocalServer: false让连接走标准 ssh 流程绕开本地 server 复用带来的状态残留showLoginTerminal: true会在连接时弹一个终端你能实时看到 server 启动输出卡在哪一步一目了然logLevel: debug把 Remote-SSH 的日志级别调高出问题时有据可查。如果你用的是 TaoToken 这类统一网关来管理模型调用本地~/.cursor/mcp.json或项目里的配置也要保证 Base URL、Key、Model ID 三件套齐全否则 Cursor 在远端拉起后调模型会二次卡住。一个可复制的 MCP 配置片段长这样{ mcpServers: { taotoken: { url: https://taotoken.net/api, headers: { Authorization: Bearer YOUR_API_KEY } } } }注意url用https://taotoken.net/api不要带多余路径。Key 去控制台生成别硬编码进会提交到 git 的文件里。环境干扰这块如果确认是 Conda 自动激活导致的临时禁用conda deactivate想永久关掉自动激活先备份再删掉.bashrc里的 conda init 段cp ~/.bashrc ~/.bashrc.bak sed -i.bak /conda init/d ~/.bashrc source ~/.bashrc改完再跑一次第 2 节那条bash -lc验证命令确认秒回、无报错。这一步做完环境层面的坑基本填平了。4. 重新连接并验证 server 真的起来了清理和配置改完后彻底退出 Cursor不是关窗口是Cmd/Ctrl Q完全退出再重开。执行Remote-SSH: Connect to Host输入主机。这时候因为showLoginTerminal开着你会看到一个终端窗口滚动输出重点看这几行Downloading server...或Installing server...说明在重新拉 server正常。Server listening on ...server 起来了隧道即将建立。如果卡在Downloading很久是网络到远端下载源慢不是故障等就行。连接成功后在远端终端里验证 server 进程确实在跑pgrep -u $(id -u) -af cursor-server应该能看到一条cursor-server主进程而不是之前那种几十条堆积。再看日志有没有正常写入ls -la ~/.cursor-server/.cli-*.log tail -n 20 ~/.cursor-server/.cli-*.log这次日志应该有内容了能看到 server 启动、端口绑定、扩展主机就绪的记录。如果日志还是空的但连接成功了说明 server 走了另一条日志路径用find找一下find ~/.cursor-server -name *.log -mmin -10-mmin -10找最近 10 分钟改过的日志文件能快速定位当前这次连接写到了哪。最后做一个端到端验证在远端工作区里打开一个终端跑一条命令确认 shell 环境正常再触发一次模型调用比如让 Cursor 补全一段代码确认 TaoToken 网关这条链路也通。如果补全正常返回说明从 SSH → server → 扩展主机 → 模型调用整条链路都活了。验证模型是否正常可以直接在对话里问一句让它返回当前时间能秒回就说明网关通。这一步别跳过很多人 server 起来了但模型调用超时误以为是连接问题其实是 Key 或 Base URL 配错了。5. 常见报错对照401、proxy failed、reading choices、OAuth排查时你大概率会撞上下面几个报错逐个对照。401 Unauthorized出现在模型调用阶段不是 SSH 阶段。说明 Key 无效或没带上。检查Authorization: Bearer头有没有拼错Key 有没有过期Base URL 是不是写成了带尾斜杠的https://taotoken.net/api/有些客户端对尾斜杠敏感。去控制台重新生成一个 Key 换上。local proxy failed/Failed to connect to local server本地 Cursor 的代理进程没起来或者端口被占。先完全退出 Cursor检查有没有残留的本地进程ps -ef | grep -i cursor | grep -v grep有就清掉再重开。如果还不行把remote.SSH.useLocalServer设成false第 3 节已经加了绕开本地 server 复用。Error reading choices/reading choices相关通常是模型返回体解析失败多半是 Base URL 指错了端点或者网关返回了非预期格式。确认url是https://taotoken.net/apiModel ID 填的是网关支持的模型名。Model ID 写错也会报这个。OAuth/authentication failedCursor 账号登录态过期或者远端 server 拿不到本地凭证。先在本地 Cursor 里退出账号重新登录再重连远端。如果用的是 API Key 模式而非账号登录检查 Key 是否配在了正确的位置用户级 settings 还是项目级。CodeError(AsyncPipeFailed(Os { code: 2, kind: Not Found }))远端 server 二进制缺失或路径不对本质是缓存损坏。回到第 3 节rm -rf ~/.cursor-server后重连让它重新下载。Waiting for server log依旧卡死但进程干净检查远端磁盘空间和 inodedf -h ~ df -i ~磁盘满或 inode 耗尽时server 写不了文件表现就是静默卡死。清一下自己的临时文件和大日志。对照完这些基本能覆盖 90% 的卡死场景。剩下 10% 多半是服务器负载太高load 8 那种server 启动慢把connectTimeout拉到 120 甚至 180耐心等。6. 把连接链路和模型链路一起管起来远程开发卡死这件事本质是「链路太长、环节太多」。SSH 一层、server 一层、扩展主机一层、模型调用又一层任何一层出问题都表现为「连不上」。所以排查思路永远是分层定位而不是一上来就重装。日常习惯上连接失败时先别急着关窗口重连——先开个终端把当前用户的 cursor 进程清掉再重连。多用户共用服务器时定期pgrep -u $(id -u) -af cursor看一眼自己的残留别让它堆着占资源。Conda、nvm 这类会改 PATH 的工具如果不需要默认激活就永久关掉自动激活能省掉一大类玄学问题。模型调用这条链路建议用统一的网关来管Base URL、Key、Model ID 集中配置换模型或换 Key 时只改一处不用在每个项目里翻。TaoToken 的接入文档里有各客户端的配置示例模型对话可以直接在网页里验证 Key 是否可用长期跑编码和 Agent 任务的话用 Coding Plan 更省心。API Key 在控制台生成接入细节看文档遇到连接类报错优先查 API Keys 和接入文档这两处基本都能对上号。最后留一个我踩过的坑有次卡死排查了两小时最后发现是远端~/.cursor-server的 owner 被之前一次sudo cursor操作改成了 root普通用户启动时写不进去日志全空。ls -ld一看 owner 不对chown -R $(id -u):$(id -g) ~/.cursor-server改回来秒连。所以权限这一项永远别跳过。
1. 卡在 Waiting for server log 到底卡在哪一环Cursor 和 VS Code 的 Remote-SSH 并不是「SSH 连上就完事」。它其实分两段第一段是本地 ssh 客户端把 TCP 连接建起来第二段是在远端拉起一个叫cursor-serverVS Code 叫vscode-server的常驻服务本地再通过一条隧道跟这个服务通信。你看到的Waiting for server log卡的是第二段——SSH 通了但远端 server 进程没起来或者起来了但没把日志吐出来。这个报错最迷惑人的地方在于终端里ssh userhost明明能登进去密码也对~/.ssh/config看着也没毛病可 Cursor 就是转圈。原因基本落在三类远端 server 进程堆积把端口/锁占死、远端目录权限或缓存损坏、登录 shell 里的环境变量Conda、nvm、自定义 PATH把 server 启动脚本带崩。多用户共用服务器时还要多一层——你分不清哪些进程是自己的误杀别人的会出事。这篇按「先确认 SSH 层没问题 → 定位并清理自己的 server 进程 → 修缓存和权限 → 处理环境干扰 → 重新拉起并验证」的顺序走每一步都给可复制的命令和预期输出。适合谁用 Cursor / VS Code Remote-SSH 连 Linux 服务器、卡在 server log、反复重连无效、后台还堆了一堆进程的人。全程只动当前用户的东西不影响同机其他账号。先说清楚一个判断原则只要终端能 ssh 进去问题就 100% 在远端 server 侧不要去改本地网络、不要重装 Cursor、不要怀疑防火墙。我见过太多人一卡死就去折腾本地方向从一开始就错了。2. 先分清 SSH 层和 server 层别乱改配置排查第一步永远是分层。Remote-SSH 的链路是本地 Cursor → 本地 ssh 进程 → 远端 sshd → 远端登录 shell → 远端 cursor-server 进程 → 本地隧道回连。Waiting for server log出现在最后一跳所以前面几跳必须先证明是好的。打开本地终端不是 Cursor 里的终端是系统终端直接连ssh -v useryour-server-ip-v会打印握手细节。你要确认的是能拿到密码提示或密钥认证成功、能进到 shell、whoami返回的是你自己。如果这一步就失败那跟 Cursor 无关先修 SSH 本身端口、密钥、~/.ssh/config的 Host 段。如果这一步秒进记下这个事实后面所有操作都在远端做。接着在远端确认登录 shell 干净不干净。很多人卡死是因为.bashrc/.bash_profile里有一堆自动激活逻辑server 启动脚本是非交互式执行的遇到conda activate报错就整个挂住ssh useryour-server-ip bash -lc echo SHELL_OK; which node; echo PATH$PATH如果这条命令卡住超过 10 秒或者输出里夹着一堆 Conda 报错那基本锁定是环境干扰。正常应该秒回SHELL_OK和 node 路径。再确认远端有没有残留的 server 进程。注意一定要按当前用户过滤多用户机器上直接pkill cursor会误伤别人# 看所有 cursor 相关进程排除 grep 自己 ps -ef | grep -i cursor | grep -v grep # 只看当前用户的推荐UID 用 id -u 拿 pgrep -u $(id -u) -af cursor-a会把完整命令行打出来-f匹配整条命令。如果输出里有一大串cursor-server、cli、node进程而且时间戳横跨好几次重连那就是典型的进程堆积——每次卡死你关窗口进程没退下一次又拉一个新的越堆越多最后谁也起不来。顺手看一眼 server 目录和日志ls -ld ~/.cursor-server ls -la ~/.cursor-server/.cli-*.log 2/dev/null tail -n 50 ~/.cursor-server/.cli-*.log 2/dev/null日志为空是常见现象别慌。空日志通常意味着 CLI 进程在写日志之前就崩了或者目录权限不对写不进去。ls -ld看权限正常应该是drwx------或drwxrwxr-x且 owner 是你自己。如果 owner 变成了 root比如之前用 sudo 跑过那 server 以你的身份启动时写不进去直接卡死。到这一步你已经能判断出是「进程堆积」「权限/缓存损坏」还是「环境干扰」了。下面按顺序处理。3. 可复制的清理与配置片段这一节给的是能直接粘贴的配置和命令。核心原则只动当前用户的进程和目录。先安全清理当前用户的残留进程。用xargs -r保证没有匹配进程时不会报错# 终止当前用户所有 cursor 相关进程 pgrep -u $(id -u) -f cursor | xargs -r kill -9 # 验证无输出即清理干净 pgrep -u $(id -u) -af cursor如果kill -9之后还有残留少数情况进程处于 D 状态等几秒再查一次。确认干净后清掉远端 server 缓存目录。这个目录是当前用户专属的删了 Cursor 下次连接会自动重新下载rm -rf ~/.cursor-server本地缓存也可以顺手清一下避免旧配置干扰可选# macOS rm -rf ~/Library/Application\ Support/Cursor/CachedData # Linux rm -rf ~/.config/Cursor/CachedData然后是本地 Cursor 的 Remote-SSH 设置。打开settings.jsonCmd/Ctrl Shift P→Preferences: Open User Settings (JSON)加上这几项{ remote.SSH.connectTimeout: 120, remote.SSH.useLocalServer: false, remote.SSH.showLoginTerminal: true, remote.SSH.enableRemoteCommand: false, remote.SSH.logLevel: debug }connectTimeout从默认 15 秒拉到 120给慢服务器留足启动时间useLocalServer: false让连接走标准 ssh 流程绕开本地 server 复用带来的状态残留showLoginTerminal: true会在连接时弹一个终端你能实时看到 server 启动输出卡在哪一步一目了然logLevel: debug把 Remote-SSH 的日志级别调高出问题时有据可查。如果你用的是 TaoToken 这类统一网关来管理模型调用本地~/.cursor/mcp.json或项目里的配置也要保证 Base URL、Key、Model ID 三件套齐全否则 Cursor 在远端拉起后调模型会二次卡住。一个可复制的 MCP 配置片段长这样{ mcpServers: { taotoken: { url: https://taotoken.net/api, headers: { Authorization: Bearer YOUR_API_KEY } } } }注意url用https://taotoken.net/api不要带多余路径。Key 去控制台生成别硬编码进会提交到 git 的文件里。环境干扰这块如果确认是 Conda 自动激活导致的临时禁用conda deactivate想永久关掉自动激活先备份再删掉.bashrc里的 conda init 段cp ~/.bashrc ~/.bashrc.bak sed -i.bak /conda init/d ~/.bashrc source ~/.bashrc改完再跑一次第 2 节那条bash -lc验证命令确认秒回、无报错。这一步做完环境层面的坑基本填平了。4. 重新连接并验证 server 真的起来了清理和配置改完后彻底退出 Cursor不是关窗口是Cmd/Ctrl Q完全退出再重开。执行Remote-SSH: Connect to Host输入主机。这时候因为showLoginTerminal开着你会看到一个终端窗口滚动输出重点看这几行Downloading server...或Installing server...说明在重新拉 server正常。Server listening on ...server 起来了隧道即将建立。如果卡在Downloading很久是网络到远端下载源慢不是故障等就行。连接成功后在远端终端里验证 server 进程确实在跑pgrep -u $(id -u) -af cursor-server应该能看到一条cursor-server主进程而不是之前那种几十条堆积。再看日志有没有正常写入ls -la ~/.cursor-server/.cli-*.log tail -n 20 ~/.cursor-server/.cli-*.log这次日志应该有内容了能看到 server 启动、端口绑定、扩展主机就绪的记录。如果日志还是空的但连接成功了说明 server 走了另一条日志路径用find找一下find ~/.cursor-server -name *.log -mmin -10-mmin -10找最近 10 分钟改过的日志文件能快速定位当前这次连接写到了哪。最后做一个端到端验证在远端工作区里打开一个终端跑一条命令确认 shell 环境正常再触发一次模型调用比如让 Cursor 补全一段代码确认 TaoToken 网关这条链路也通。如果补全正常返回说明从 SSH → server → 扩展主机 → 模型调用整条链路都活了。验证模型是否正常可以直接在对话里问一句让它返回当前时间能秒回就说明网关通。这一步别跳过很多人 server 起来了但模型调用超时误以为是连接问题其实是 Key 或 Base URL 配错了。5. 常见报错对照401、proxy failed、reading choices、OAuth排查时你大概率会撞上下面几个报错逐个对照。401 Unauthorized出现在模型调用阶段不是 SSH 阶段。说明 Key 无效或没带上。检查Authorization: Bearer头有没有拼错Key 有没有过期Base URL 是不是写成了带尾斜杠的https://taotoken.net/api/有些客户端对尾斜杠敏感。去控制台重新生成一个 Key 换上。local proxy failed/Failed to connect to local server本地 Cursor 的代理进程没起来或者端口被占。先完全退出 Cursor检查有没有残留的本地进程ps -ef | grep -i cursor | grep -v grep有就清掉再重开。如果还不行把remote.SSH.useLocalServer设成false第 3 节已经加了绕开本地 server 复用。Error reading choices/reading choices相关通常是模型返回体解析失败多半是 Base URL 指错了端点或者网关返回了非预期格式。确认url是https://taotoken.net/apiModel ID 填的是网关支持的模型名。Model ID 写错也会报这个。OAuth/authentication failedCursor 账号登录态过期或者远端 server 拿不到本地凭证。先在本地 Cursor 里退出账号重新登录再重连远端。如果用的是 API Key 模式而非账号登录检查 Key 是否配在了正确的位置用户级 settings 还是项目级。CodeError(AsyncPipeFailed(Os { code: 2, kind: Not Found }))远端 server 二进制缺失或路径不对本质是缓存损坏。回到第 3 节rm -rf ~/.cursor-server后重连让它重新下载。Waiting for server log依旧卡死但进程干净检查远端磁盘空间和 inodedf -h ~ df -i ~磁盘满或 inode 耗尽时server 写不了文件表现就是静默卡死。清一下自己的临时文件和大日志。对照完这些基本能覆盖 90% 的卡死场景。剩下 10% 多半是服务器负载太高load 8 那种server 启动慢把connectTimeout拉到 120 甚至 180耐心等。6. 把连接链路和模型链路一起管起来远程开发卡死这件事本质是「链路太长、环节太多」。SSH 一层、server 一层、扩展主机一层、模型调用又一层任何一层出问题都表现为「连不上」。所以排查思路永远是分层定位而不是一上来就重装。日常习惯上连接失败时先别急着关窗口重连——先开个终端把当前用户的 cursor 进程清掉再重连。多用户共用服务器时定期pgrep -u $(id -u) -af cursor看一眼自己的残留别让它堆着占资源。Conda、nvm 这类会改 PATH 的工具如果不需要默认激活就永久关掉自动激活能省掉一大类玄学问题。模型调用这条链路建议用统一的网关来管Base URL、Key、Model ID 集中配置换模型或换 Key 时只改一处不用在每个项目里翻。TaoToken 的接入文档里有各客户端的配置示例模型对话可以直接在网页里验证 Key 是否可用长期跑编码和 Agent 任务的话用 Coding Plan 更省心。API Key 在控制台生成接入细节看文档遇到连接类报错优先查 API Keys 和接入文档这两处基本都能对上号。最后留一个我踩过的坑有次卡死排查了两小时最后发现是远端~/.cursor-server的 owner 被之前一次sudo cursor操作改成了 root普通用户启动时写不进去日志全空。ls -ld一看 owner 不对chown -R $(id -u):$(id -g) ~/.cursor-server改回来秒连。所以权限这一项永远别跳过。
![VR毕设别急着“一键生成”：从Unity漫游系统到论文定稿，AI工具可以这样搭把手 [特殊字符]](http://pic.xiahunao.cn/yaotu/VR毕设别急着“一键生成”：从Unity漫游系统到论文定稿，AI工具可以这样搭把手 [特殊字符])
