根本原因是服务端或客户端默认关闭保活机制；启用clientaliveinterval（服务端）和serveraliveinterval（客户端）配对配置，可解决99%闲置断连问题。
SSH连接闲置后自动断开，根本原因不是网络不稳定，而是服务端或客户端默认关闭了保活机制。只要配对启用 ClientAliveInterval（服务端）和 ServerAliveInterval（客户端），99% 的“5分钟断开”“10秒闪退”问题都能解决。
服务端配置：改 /etc/ssh/sshd_config 中的 ClientAlive* 参数
这是最常用也最有效的方案，尤其适用于你有服务器 root 权限、且希望所有连接都稳定的情况。
-
ClientAliveInterval必须大于 0，比如设为60表示每 60 秒向客户端发一次心跳包；设太小（如10）反而容易误判断连 -
ClientAliveCountMax默认是3，意思是连续 3 次没收到响应就断开。如果设成0，则禁用该机制（不推荐）；设成10，配合60就是 10 分钟超时 - 务必确认这两行没被注释（即前面不能有
#），修改后必须重启服务：sudo systemctl restart sshd - 注意：某些云厂商（如华为云、腾讯云）的镜像会预设极短的值（如
ClientAliveInterval 10+ClientAliveCountMax 1），直接导致 10 秒断连——先grep ClientAlive /etc/ssh/sshd_config看清现状再改
客户端配置：用 ~/.ssh/config 统一管理个人连接
当你无法改服务端（比如连的是公司跳板机或第三方托管服务器），或者只想让自己的终端生效，就走这条路。
- 编辑
~/.ssh/config，添加以下内容（Host *表示匹配所有主机）：
Host *
ServerAliveInterval 60
ServerAliveCountMax 3
-
ServerAliveInterval是客户端主动发心跳的间隔，单位秒；ServerAliveCountMax是客户端允许自己“发了但没等到回包”的最大次数 - 不要和
ClientAlive*混用在同一端：服务端配了ClientAliveInterval，客户端就不必再配ServerAliveInterval——二者功能重叠，同时开可能引发冗余探测甚至冲突 - 如果只针对某台服务器生效，把
Host *换成具体 HostName，例如：Host prod-server，再下一行写参数
临时调试：命令行加 -o 参数快速验证
改配置前想先确认是否真能解决问题？或者只是连一次远端做紧急操作？直接加参数最省事。
- 运行：
ssh -o ServerAliveInterval=60 -o ServerAliveCountMax=3 user@host - 加
-vvv可看到心跳细节：ssh -o ServerAliveInterval=60 -vvv user@host，等待 60 秒后若出现debug3: send packet: type 80，说明心跳已发出 - 注意：命令行参数优先级最高，会覆盖
~/.ssh/config和系统级/etc/ssh/ssh_config的同名设置 - 别漏掉等号 ——
-o ServerAliveInterval 60（空格）会报错，必须是=
常见陷阱与兼容性提醒
很多问题不是没配，而是配错了位置、配反了方向，或忽略了环境差异。
-
/etc/ssh/sshd_config是服务端配置，控制“服务器怎么对待客户端”；/etc/ssh/ssh_config或~/.ssh/config是客户端配置，控制“本机怎么连接服务器”——文件名差一个字母，作用天壤之别 - macOS 自带的 OpenSSH 客户端完全支持
ServerAliveInterval；但某些旧版嵌入式设备或精简 SSH 客户端（如部分 Android Termux 环境）可能不识别该选项 - 如果用了代理（如
ProxyCommand）、跳转（ProxyJump）或多层隧道，心跳只在最外层 TCP 连接上起作用，内层链路仍可能被中间节点切断 -
TCPKeepAlive yes是底层 TCP 保活开关，现代 OpenSSH 已默认启用，一般无需手动打开；强行开启反而可能和应用层心跳叠加，增加无谓流量
真正难搞的不是配参数，而是分清“谁在发心跳、谁该收心跳、心跳能不能穿过中间设备”。先确认断连时间是否精确（比如固定 10 秒？还是波动很大？），再决定从服务端查起，还是先抓包看心跳是否被防火墙吞掉。
