防止ssh断开服务器进程

2026-01-28 23:26:52 栏目：最新资讯 2 阅读

在锁屏或长时间不操作时，导致VS Code SSH连接断开的主要原因是网络中的防火墙或路由器会关闭长时间空闲的连接。你可以通过配置“心跳包”和让后台进程独立运行这两种方法来解决。

下面我将分别介绍这两种方案的具体操作。

方案一：配置SSH心跳保活（推荐）

此方案通过让SSH客户端或服务器定期发送“心跳包”来保持连接活跃，操作简单且对多数用户有效。配置分为客户端和服务器端。

配置位置	关键参数	作用说明	推荐值参考
本地SSH客户端 (`~/.ssh/config`)	`ServerAliveInterval`	客户端每隔多久（秒）向服务器发送一次心跳包。	30-60秒
	`ServerAliveCountMax`	连续多少次心跳无响应后断开连接。	3次或设为极大值（如9999）
远程服务器 (`/etc/ssh/sshd_config`)	`ClientAliveInterval`	服务器端每隔多久（秒）检测一次客户端是否活跃。	60秒
	`ClientAliveCountMax`	服务器端允许客户端无响应的最大次数。	3次或极大值

📝 配置方法

配置客户端：编辑你本地电脑上的SSH配置文件 ~/.ssh/config（如没有可新建）。你可以针对特定服务器或所有服务器（用 Host *）进行配置。示例如下：

bash
```
# 对所有服务器生效
Host *
    ServerAliveInterval 60
    ServerAliveCountMax 3
```
配置服务器端（需服务器权限）：登录远程服务器，编辑 /etc/ssh/sshd_config 文件，添加上表中的参数，并重启SSH服务（例如 sudo systemctl restart sshd）。

方案二：使用终端复用工具（最可靠）

如果心跳保活仍不能解决问题，或你希望在连接断开时保证程序持续运行，最根本的解决方案是使用终端复用工具（如 screen 或 tmux）。

这种方法的核心是将程序运行在一个独立的、与SSH连接无关的后台会话中。即使你的电脑锁屏或VS Code断开，程序也会在服务器上继续执行。

📝 如何使用 Screen
下面以常用的 screen 工具为例，介绍基本操作：

安装：在远程服务器上运行 sudo apt-get install screen 或相应系统的安装命令。
创建新会话：运行 screen -S your_session_name，这将开启一个新的虚拟终端。
在会话中运行程序：在这个新终端里正常启动你的程序。
分离会话：按下 Ctrl+A，松开后按 D 键，即可将会话“挂起”到后台，程序会继续运行。你的终端会显示 [detached]。
恢复会话：当你需要查看程序输出时，运行 screen -r your_session_name 即可重新接入该会话。

其他可选的辅助措施

启用VS Code的自动重连：在VS Code的设置中，可以搜索并开启 remote.autoReconnect 选项。
清理残余进程：如果异常断开后无法重新连接，可能是因为旧的 vscode-server 进程残留在服务器上。可以执行命令 Kill VS Code Server on Host 来清理。

总结与建议

总的来说，你可以参考以下决策表来选择最适合你的方案：

你的需求场景	建议方案	原因
仅想保持VS Code连接不断开	首选“配置SSH心跳保活”	配置简单，对大多数因网络空闲造成的断开有效。
要运行长时间任务（如模型训练）	必须使用 `screen` 或 `tmux`	这是最可靠的解决方案，能保证任务在任何网络波动下都不会中断。
仍无法连接，或频繁出现验证错误	在VS Code中执行 `Kill VS Code Server on Host`	此操作可以清理服务器上的旧进程，解决因进程残留导致的连接故障。

希望这些方法能帮助你解决锁屏断开连接的问题！如果你能告诉我你主要用远程连接来做什么（比如是普通编程，还是需要运行不能中断的长期任务），我可以给你更具体的建议。

如何知道我的your_session_name

当你使用 screen 时，记住或找到 your_session_name（会话名）很简单，这里有几个常用方法：

1. 创建时立即命名（最推荐）

在创建会话时，直接使用 -S 参数指定一个好记的名字。

bash

screen -S train_session  # 创建一个名为 "train_session" 的会话
screen -S web_project    # 创建一个名为 "web_project" 的会话

养成这个习惯是一劳永逸的解决方案。

2. 忘记名字后如何查看

如果你忘记了名字，或者接手了别人的会话，可以使用以下命令来列出当前服务器上所有存在的 screen 会话：

bash

screen -ls

这条命令会输出类似下面的信息，清晰地显示了会话ID和会话名：

bash

There are screens on:
        12345.train_session   (Detached)
        67890.web_project     (Detached)
        11111.pts-1.server    (Attached)

12345.train_session：这里，12345 是会话ID，train_session 就是你设置的会话名。
(Detached) 表示会话在后台运行。
(Attached) 表示会话正在被某个终端使用。

3. 如何恢复会话

拿到会话名或ID后，就可以恢复会话了，下面是三种恢复方法：

使用场景	命令	说明
用会话名恢复	`screen -r train_session`	最常用，直接使用你创建时起的名字。
用会话ID恢复	`screen -r 12345`	当会话名有重复时，用唯一ID更准确。
如果你只有一个会话	`screen -r`	省略参数，如果有且仅有一个会话，会直接恢复它。

4. 忘记分离（Detach）时怎么办

如果你在 screen 会话中工作，但没有按 Ctrl+A D 分离，而是直接关闭了终端或SSH窗口，会话会变成 (Attached) 状态。这时直接 -r 会失败，提示需要先“夺回”。

解决方法：使用 -d 参数先将其强制分离到后台，再恢复。

bash

screen -d -r train_session
# 或者分两步：
# screen -d train_session  # 先分离
# screen -r train_session  # 再恢复

使用小技巧：简化操作

恢复最近使用的会话：直接运行 screen -r（不带参数）通常可以快速恢复你最后使用的那个会话。
避免忘记名字：在创建时，使用和你项目、任务直接相关的名字，例如 model_training、django_server，这样会非常直观。

核心要点：当你不确定时，随时使用 screen -ls 查看所有会话的列表，这是管理 screen 会话的基石。

希望这些方法能帮你轻松管理会话！如果你在具体操作中遇到其他问题，比如 screen -ls 没有输出，可以告诉我，我再帮你分析可能的原因。

本地关机也可以吗

不可以。 “锁屏”和“本地关机”是完全不同的两种情况，处理方式有根本区别。

简单来说，screen 或 tmux 这类工具只能解决因“SSH连接中断”导致的问题，而无法解决因“本地计算机关机”导致的操作停止。关键差异如下：

场景	发生了什么	对远程服务器的影响	`screen/tmux` 是否有效
本地锁屏/待机/网络波动	SSH隧道（连接）被操作系统或路由器断开。	远程服务器上运行的 `shell` 进程（如Bash）会终止，导致其下的所有命令（如 `python train.py`）也被迫停止。	✅ 完全有效。因为它们让程序运行在独立于SSH连接的后台会话中，连接中断不影响会话。
本地关机/休眠（挂起到硬盘）	整个本地操作系统关闭，你本地的VS Code和SSH客户端进程彻底结束。	你与服务器之间的整个操作会话（包括所有终端和端口转发）都被终结。	❌ 无效。因为 `screen` 会话虽然仍在服务器后台，但其前台交互能力依赖于SSH建立的虚拟终端。本地客户端关机后，这个虚拟终端被销毁，你将无法再通过原有方式直接“恢复”这个会话的交互界面。

“关机后”的真相与解决方案

你可以这样理解：本地关机后，screen 会话就像一个被切断了遥控器和显示器的机器人，它确实还在服务器上埋头工作，但你失去了实时操控和看到它画面的渠道。

针对“需要本地关机”的情况，你有以下两种可靠的选择：

方案一：使用真正的后台任务（首选）

这是最规范、最健壮的做法，适用于运行脚本、模型训练、编译等任务。核心是将程序作为系统守护进程运行，彻底摆脱对终端会话的依赖。

如何操作：
1. 使用 nohup 命令让程序忽略挂断信号，并用 & 放到后台。
  
  bash
```
nohup python your_script.py > output.log 2>&1 &
```
  - > output.log：将程序的标准输出保存到日志文件。
  - 2>&1：将错误输出也重定向到同一个日志文件。
  - &：在后台运行。
2. 运行后，会返回一个 进程ID（PID），记下它。之后你可以用 kill [PID] 来结束进程。
3. 查看运行状态和输出：
  
  bash
```
tail -f output.log    # 实时查看日志
ps aux | grep python  # 查看进程状态
```

方案二：结合使用（针对需要交互的复杂任务）

如果任务中途需要交互（比如需要偶尔输入命令的服务器），可以先启动 screen 会话，然后在 screen 里再用 nohup 启动程序。

SSH登录服务器，启动一个命名清晰的 screen 会话：

bash
```
screen -S my_service
```
在这个 screen 会话里，启动你的后台程序：

bash
```
nohup ./start_server.sh > server.log 2>&1 &
```
现在你可以安全地分离这个 screen 会话（Ctrl+A, D），即使后续本地关机，程序也会在服务器上持续运行。
未来如何管理：
- 查看程序输出：重新登录服务器，用 tail -f server.log 查看日志。
- 需要交互时：重新登录服务器，用 screen -r my_service 恢复会话，此时你就在当初启动程序的那个环境里了。

总结与决策建议

你的需求	推荐方案	关键原因
运行一个无需交互的脚本/任务	`nohup ... &` 后台任务	与终端彻底解耦，是标准的服务器后台运行方式，最稳定可靠。
运行一个可能需要中途查看或简单交互的服务	`screen` + `nohup` 组合	既保证了程序持续运行，又保留了在需要时恢复完整交互环境的能力。
只是短暂离开，本地计算机保持开机	仅用 `screen` 或 `tmux`	完美应对锁屏、睡眠、网络中断等连接问题，恢复工作状态最简单。