你有没有遇到过这种情况：在服务器上用SSH跑一个耗时很长的程序，比如数据备份、软件编译或者模型训练，结果网络一波动SSH连接断了，程序也跟着中断，前功尽弃。这确实让人头疼，但解决起来并不复杂。核心思路就是让进程与当前SSH会话“脱钩”，独立运行。下面介绍几种常用方法，从简单到强大。

方法一：使用 `nohup` —— 最基础的“脱钩”命令

`nohup` 是“no hang up”的缩写，它的作用就是让命令忽略挂断信号，即使终端关闭，进程也能继续运行。

基本用法非常简单：

nohup 你的命令 &

例如，要运行一个Python脚本：

nohup python3 train_model.py &

这里的 `&` 符号表示让命令在后台立即执行。

关键点解析：

1.  输出重定向：`nohup` 默认会将命令的所有输出（包括标准输出和标准错误）重定向到当前目录下一个名为 `nohup.out` 的文件中。如果当前目录不可写，则会重定向到 `$HOME/nohup.out`。你可以自定义输出文件：

nohup python3 train_model.py > training.log 2>&1 &

`> training.log` 将标准输出重定向到`training.log`，`2>&1` 表示将标准错误也合并到标准输出，即都写入同一个日志文件。

2.  进程查看与管理：命令在后台运行后，会返回一个进程ID。记下这个PID非常重要，因为你需要用它来管理进程。

查看进程：使用 `ps` 或 `jobs -l`（仅限当前会话）查看。

终止进程：如果程序卡住或想停止，使用 `kill PID` 命令（如 `kill 12345`）。

3.  重新连接后查看：当你重新SSH登录服务器，如果需要查看进程，可以用 `ps aux | grep train_model` 来查找。

这样简单直接，无需额外工具，所有Linux系统都自带。但是只有一个终端“窗口”，如果程序需要交互（比如进入一个命令行界面），或者你想在运行中查看其输出，`nohup` 就不太方便了。

方法二：使用终端复用器（`screen` 或 `tmux`）—— 真正的“会话管理”

终端复用器就像给你的SSH会话开了多个“虚拟窗口”，并且这些窗口可以随时脱离、重连，完全不受网络连接的影响。

使用 `screen`（较经典），启动一个新会话：

screen -S my_session

`-S` 给会话起个名字（如`my_session`），便于后续找回。

在会话中工作：此时你已进入一个全新的虚拟终端，可以像平常一样运行你的长任务，例如 `python3 train_model.py`。

脱离会话：按 `Ctrl + A`，然后按 `D`（Detach）。你会看到提示“detached”。现在可以安全地关闭SSH连接了，程序会在`screen`会话中继续运行。

恢复会话：重新登录后，使用以下命令找回：

screen -ls          # 列出所有存在的会话

screen -r my_session # 恢复名为my_session的会话

彻底结束：在恢复的会话中，正常退出（比如输入`exit`或按`Ctrl+D`），该`screen`会话就会被删除。

使用 `tmux`（更现代，功能更强）

`tmux` 是 `screen` 的增强版，操作逻辑相似但更强大。

启动新会话：

tmux new -s my_work

脱离会话：按 `Ctrl + B`，然后按 `D`。

恢复会话：

tmux ls             # 列出会话

tmux attach -t my_work # 恢复

在`tmux`内：你可以按 `Ctrl+B` 后按 `%` 垂直分屏，按 `"` 水平分屏，用 `Ctrl+B` 加方向键在分屏间切换，管理多个任务非常高效。

功能强大，可以管理多个“窗口”和“分屏”，随时可以脱离和重连，完美解决交互问题。需要额外安装（部分系统可能未预装），有一组需要记忆的快捷键。

方法三：将进程转为系统服务（`systemd`）—— 最专业的管理方式

对于需要长期运行、稳定可靠的后台服务（如Web服务器、自定义守护进程），最好的方法是将其配置为系统的服务，由 `systemd` 来管理。这样它可以开机自启，崩溃后自动重启，还能方便地用统一的命令查看日志和状态。

创建一个自定义服务的步骤：

创建服务配置文件。例如，为你的脚本创建一个服务：

sudo nano /etc/systemd/system/my_train.service

编写服务配置。编辑文件，写入类似以下内容：

ini

[Unit]

Description=My Model Training Service

After=network.target

[Service]

Type=simple

User=your_username  # 用哪个用户运行，建议用非root用户

WorkingDirectory=/path/to/your/script

ExecStart=/usr/bin/python3 /path/to/your/script/train_model.py

Restart=on-failure  # 失败时自动重启

StandardOutput=journal

StandardError=journal

[Install]

WantedBy=multi-user.target

`Description`：服务描述。

`User`：指定运行用户，增强安全性。

`ExecStart`：指定要运行的命令的绝对路径。

`Restart`：定义重启策略。

启用并启动服务：

sudo systemctl daemon-reload  # 重载配置

sudo systemctl start my_train # 启动服务

sudo systemctl enable my_train # 设置开机自启

管理服务：

sudo systemctl status my_train # 查看状态和最近日志

sudo systemctl stop my_train   # 停止服务

sudo systemctl restart my_train # 重启服务

sudo journalctl -u my_train -f # 持续查看该服务的日志

功能最完善，适合生产环境，具备完整的生命周期管理、日志集成和自愈能力。但是配置相对复杂，需要`root`权限，更适合需要持久化运行的核心服务。

总结与选择建议

运行一个简单的、一次性的后台脚本：用 `nohup 命令 &` 最快捷。

进行需要交互或观察的长时间任务（如编译、数据迁移）：使用 `tmux` 或 `screen`。它们提供了完整的虚拟终端环境，是最灵活通用的选择。

部署一个需要持续运行、高可靠性的后台服务：将其配置为 `systemd` 服务。

进阶技巧：你可以组合使用。例如，在 `tmux` 会话中启动和管理多个程序，而其中最核心的服务进程，最终可以通过 `systemd` 来固化。

最后，无论用哪种方法，养成一些好习惯很重要：给你的进程起有意义的名称（会话名、服务名），记录关键的进程ID（PID），并确保程序的输出被妥善记录到日志文件中，这样你才能在断开重连后，依然能清晰地掌控任务的运行状态。掌握了这些方法，网络波动就再也不会打断你的重要工作了。