SSH 连接断线与长会话保活：ServerAliveInterval、tmux 与 mosh 的取舍

远程工作时最让人恼火的不是命令写错，而是会话正跑到一半突然断线：日志停在半路、编辑器里的改动没保存、训练任务随着终端一起消失。很多人第一反应是把保活时间调大，其实断线有三种不同层次，药要对症下药。

先分清是哪一层断了

第一层是网络中间设备超时。家用路由器、公司 NAT、云厂商的负载均衡大多会清理长时间没有流量的 TCP 连接，空闲几分钟到几十分钟不等。第二层是 SSH 本身的空闲策略，服务端可能设置了 ClientAliveInterval，超时就主动断开。第三层是终端关闭：你关掉笔记本、Wi-Fi 切换、电脑休眠，本地 SSH 进程退出，远端前台进程收到 SIGHUP 后跟着退出。只调保活能解决第一层和部分第二层，却救不了第三层。

ServerAliveInterval：让连接别被中间设备清理

这是最常用、成本最低的一招。在本地 ~/.ssh/config 里针对主机写上：

Host myserver
  HostName 203.0.113.10
  ServerAliveInterval 60
  ServerAliveCountMax 3

含义是每 60 秒发一次保活探测，连续 3 次无响应才判定断线。这样连接上始终有流量，NAT 不会因为空闲而回收。注意不要把间隔设得太小，5 秒一次在弱网下反而会因为偶发丢包误判断线；60 秒是比较稳妥的起点，配合 3 次容忍，弱网抖动时不会轻易掉线。

服务端也有对应的一对参数，写在 /etc/ssh/sshd_config 里：ClientAliveInterval 300 表示 300 秒发一次探测，ClientAliveCountMax 0 则表示不主动断开，只做探测。改服务端配置需要重启 sshd，生产机器要先在测试机验证，不要直接在唯一的管理通道上冒险。

tmux：会话与终端解耦

保活只能保连接，保不住终端。tmux 解决的是另一半问题：把会话留在服务器上。登录后先 tmux new -s work，里面再跑长任务；断线后重新登录，tmux attach -t work 就能回到原来的窗口，输出、编辑状态都在。

几个日常够用的命令要记牢：Ctrl-b d 是分离会话，Ctrl-b c 新建窗口，Ctrl-b n 切换窗口，tmux ls 查看所有会话。配合保活使用效果最好：保活减少无意义断线，tmux 兜底断线后的恢复。需要提醒的是，tmux 不是万能的：如果服务器重启、会话被管理员清理，或者你把会话建在了临时容器里，恢复也就无从谈起。长任务仍要把日志重定向到文件，关键步骤做检查点。

mosh：经常换网的人更适合

如果你经常在 Wi-Fi、有线、手机热点之间切换，或者在高铁、咖啡馆这种弱网环境工作，mosh 值得一试。它基于 UDP，能在 IP 变化后自动漫游重连，本地回显也更及时，输入不会因为往返延迟而卡顿。代价是需要服务端安装 mosh，并且放行 UDP 端口范围，某些只允许 22 端口的严格网络里用不了；另外 mosh 本身不转发 X11，也不适合需要严格审计 SSH 直连的场景。

取舍与推荐组合

只在固定网络、短时间操作：ServerAliveInterval 就够了，改动最小。跑长任务、怕断线丢进度：保活加 tmux，这是性价比最高的组合，也是我日常默认的做法。频繁换网、移动办公：mosh 加 tmux，mosh 管连接漫游，tmux 管会话恢复。

最后还有两点容易被忽略。第一，保活不是越频繁越好，也不要用 while true 循环刷屏来保活，那只会制造无意义流量。第二，安全上要收敛：不要为了图方便把 ServerAliveCountMax 设得无限大、把服务端超时全部关掉；离开工位要主动分离会话并锁屏，长会话本身也是一种暴露面。先判断断线层次，再选工具，断线这件事其实没有那么玄。