SSH 频繁断连的系统化排查:先列排除清单,别重复试错
775 字
4 分钟
SSH 频繁断连的系统化排查:先列排除清单,别重复试错
一个让人抓狂的场景:SSH 连上几分钟就断,天天断。网上搜一圈,答案五花八门——调 keepalive、换客户端、看带宽、查丢包……挨个试了一遍,全都没用。
问题不在这些解法,在于没有用系统化排除法,而是凭感觉乱试。
正确的打开方式:列排除清单
先别动手改配置,把候选变量全列出来,然后逐项排除,每次只动一个变量。
第一轮:先排除”软件配置”层(改动成本低)
| 候选 | 排除方法 | 结果 |
|---|---|---|
| 服务器资源 | 看内存 / CPU / 磁盘 | ❌ 正常 |
| SSH 配置 | 服务端加存活探测(如 ClientAliveInterval) | ❌ 仍断 |
| 客户端软件 | 换一个客户端(A 换成 B) | ❌ 仍断 |
| 带宽限制 | 检查有没有流量整形 / 限速规则 | ❌ 移除后带宽恢复但连接仍断 |
| 丢包 | ping 长期监控 | ❌ 0% 丢包、延迟正常 |
这一轮排除了五个常见嫌疑,说明问题不在服务器和软件配置。
第二轮:锁定”网络路径”层(剩下的候选)
排除掉软件层之后,剩下的候选都指向网络路径的某个环节:
- ⚠️ 双网络环境(有线 + WiFi 同时开)导致路由切换
- ⚠️ 本地路由器 NAT 表空闲回收
- ⚠️ ISP 中间设备 TCP 空闲连接回收
- ⚠️ 网卡硬件 / 驱动问题
其中”双网络同时开”嫌疑最大——两个网卡并存时,系统可能在切换默认路由,SSH 长连接经不起切换。
验证方法同样是一变量一改:拔掉有线只用 WiFi 跑 25 分钟,连接稳定了;但这只是单次观察,还需要长周期确认。
三个排查纪律
1. 每次只动一个变量。 同时改 keepalive + 换客户端 + 调带宽,断连了就不知道是谁的功劳。
2. 记录每次尝试的效果。 一张表格(日期 / 尝试 / 效果),几轮下来哪些排除过一目了然,避免重复试错。
3. 先排除便宜假设,再动贵的。 改配置、换客户端便宜,换网络环境、换硬件贵。先排便宜的。
一个更深的教训
排查到最后,很多”SSH 断连”其实是网络空闲回收——运营商 / 路由器对长时间空闲的 TCP 连接做回收。这类问题的共性特征是:
- 不是”断”,是”一段时间不用就死”
- 高峰期活跃时反而不掉
- 客户端和服务端配置都”看起来没问题”
如果你遇到的是这个模式,方向就不是调 SSH 配置,而是看网络路径上谁在回收空闲连接。
结论
SSH 断连这类”配置看着都对但就是不行”的问题,最大的敌人是病急乱投医。
先列排除清单,每次只动一个变量,记录效果,先便宜后贵。
系统化的排除,比灵机一动的十个”偏方”都有效。
支持与分享
如果这篇文章对你有帮助,欢迎分享给更多人或打赏支持!
SSH 频繁断连的系统化排查:先列排除清单,别重复试错
https://heaven-1314.github.io/posts/ssh-drop-systematic-debug/相关文章智能推荐
1
定时任务凌晨配置白天跑?先查时区
工程实践守护进程内置的定时任务如果用 UTC 解析 cron,配置的"凌晨低峰"实际会在北京时间上午 10 点跑——正好撞高峰。
2
SMB 网络盘上的 Git 锁文件:一个网络文件系统引发的坑
工程实践把 Git 仓库放在 SMB 网络盘上,断网抖动后 Git 全部操作卡死——.git 目录里残留了删不掉的锁文件。
3
Windows 网络盘的"双幽灵"事故:换盘符不是容灾
架构映射网络盘断开后,加了第二个"备用盘符",结果 Explorer 显示两个断开的幽灵盘,越修越乱。根因是把盘符名当成了独立故障域。
4
个人服务器的日常运维清单:磁盘、内存、服务、安全
运维个人跑业务服务器的日常检查清单——磁盘红线、内存尖峰、常驻服务、安全规则、清理动作,以及三条用挂一次换来的教训。
5
nginx 子路径部署的隐形炸弹:绝对路径怎么把页面变白屏
运维应用部署到 nginx 子路径下页面全白,根因往往是应用内部用了绝对路径,被 nginx 的 catch-all 静默吞掉。200 但内容是错的,比 404 更隐蔽。
随机文章随机推荐







