Windows下SSH掉线重连与会话持久化实战指南

AngstEssenSeele·2026-09-05·阅读 23 GEO检测（免费）

SSH掉线重连keepalive

|难度：普通|阅读约 36 分钟

超长干货：实战解读 Windows 下 SSH 掉线重连与会话持久化

讲真，做了这么多年运维和开发，最让人抓狂的场景之一，就是你正盯着 SSH 终端里跑一个长任务，比如编译、部署、导数据，结果屏幕突然一卡，接着提示 Connection closed by remote host。那一刻的感觉，基本等于煮了三个小时的汤，锅翻了。尤其是用 Windows 自带终端或者 PowerShell 连 Linux 服务器时，断线几乎是家常便饭。

这篇内容我总结了多年在 Windows 平台下折腾 SSH 的完整经验，包括掉线原因分析、keepalive 配置、自动重连的多种方案、以及远端 tmux 会话保持的终极解法。文章会覆盖从 Windows 自带的 OpenSSH 客户端，到 WSL、PowerShell、批处理脚本，再到 VSCode Remote-SSH、MobaXterm 等常见工具的配置技巧。适合被 SSH 断线折磨过的开发者、运维新人，以及想在 Windows 上获得更稳定远程工作体验的老手。我尽量用大白话把原理和操作都讲透，你照着抄就能用。

1. 为什么 SSH 老掉线？先搞清楚问题出在哪一层

1.1 掉线的三个高频场景

先说结论，SSH 连接被断开，绝大多数情况下不是 SSH 协议本身的问题，而是底层链路或者对端策略导致的。我把这些年遇到的情况归纳成三类，你对号入座一下。

第一类是空闲超时被服务端踢掉。这是最常见的，你开着终端去倒杯水、开个会，回来发现已经断了。原因通常是服务器上的 sshd 配置了 ClientAliveInterval 和 ClientAliveCountMax，这个组合的意思是如果 N 秒内没收到客户端的心跳，并且连续 M 次都没收到，就直接断开连接，释放资源。很多云主机默认或者运维同学出于安全考虑都会设置这个，通常空闲 5 到 15 分钟就会踢人。

第二类是 NAT 会话超时导致链路中断。这个在办公室网络、家庭宽带下尤其明显。你的电脑通过路由器上网，路由器维护一个 NAT 映射表，TCP 连接如果长时间没有数据包经过，路由器会认为这个连接已经死亡，直接把这个映射从表里清掉。后续你再发数据包，对端服务器根本收不到，因为中间的路由器已经不认这条通路了。NAT 超时时间因设备而异，有的只有 60 秒，有的能有 30 分钟。

第三类是网络波动导致的 TCP 重连失败。比如 Wi-Fi 信号不稳、切网、网线松动，或者移动办公时切换网络。这种属于物理链路层的临时故障，TCP 栈会尝试重传，但如果重传超时次数到了，连接同样会挂掉。

1.2 理解 TCP 连接和 SSH 会话的关系

要彻底解决掉线问题，你得先理解一个概念：SSH 会话是构建在 TCP 连接之上的。TCP 连接本质上是一个状态机，对于已经建立的长连接，双方并不需要持续发送数据来维持它。问题是，连接两端的中间设备（路由器、防火墙、负载均衡等）都有各自的空闲超时策略，它们看到一条连接长时间不活动，就会主动把它回收。

这就好比你租了个停车位，车一直停着但人一直不来，停车场管理员可能就会把车位给别的车用。TCP 连接也是一样的道理，中间设备不知道你还需不需要这条连接，它的规则就是资源有限，空闲太久就回收。

搞清楚这个原理，解决方案的路径就清晰了。无非就是两条路：一是让连接保持活跃，定期发心跳包，告诉中间设备和服务器“我还活着”；二是做好断线后的自动重连，反正 SSH 支持重新认证，断了再连就是。再进一步，如果你担心断线导致正在跑的任务中断，那就需要结合 tmux 这类会话保持工具，让任务跑在远端，不和你的 SSH 连接绑定。

需要模型API调用？免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。

2. 客户端 keepalive 配置：让连接保持活跃的正确姿势

2.1 ServerAliveInterval 和 ServerAliveCountMax 到底怎么工作

Windows 自带的 OpenSSH 客户端，其实是支持 keepalive 配置的，只是很多人没去改过。配置文件在用户目录下的 .ssh\config 文件里，如果没有就自己建一个。

核心参数有两个。ServerAliveInterval 表示客户端每隔多少秒向服务器发送一个 keepalive 心跳包（实际是加密的通道请求），单位是秒。ServerAliveCountMax 表示如果连续多少次没有收到服务器对心跳的响应，客户端就判定连接失效并主动断开。默认值一般是 0 和 3，也就是完全不发心跳。

举个例子，你设置：

code复制ServerAliveInterval 30
ServerAliveCountMax 3

意思是每 30 秒发一个心跳，如果连续 3 次（90 秒内）都没有得到服务器响应，客户端就认为这条连接已经死了，自己断开。这样你就不用在屏幕前干等着，触发重连脚本就行。

为什么要关心这两个参数的搭配？因为如果只设置 ServerAliveInterval 而不设置 ServerAliveCountMax，虽然默认值是 3，但建议显式写出来，方便排查时一眼看明白。另外要注意，心跳包里包含的是加密的通道请求，不是裸的 TCP ACK，所以它能穿透大多数 NAT 设备，让路由器认为连接一直是活跃的。

2.2 Windows 下 ssh_config 的具体配置方法

在 Windows 上，ssh 配置文件的路径是 C:\Users\你的用户名\.ssh\config。如果没有 .ssh 目录，就先打开 PowerShell 执行一次 ssh-keygen 或者直接 mkdir .ssh 创建。

用记事本或者 VSCode 打开配置文件，添加如下内容：

code复制Host myserver
    HostName 192.168.1.100
    User root
    ServerAliveInterval 30
    ServerAliveCountMax 3
    TCPKeepAlive yes
    ConnectTimeout 10

这里我解释一下每个字段的作用。Host 是别名，你以后直接 ssh myserver 就能连接，不用打完整 IP。HostName 是服务器地址。User 是登录用户名。ServerAliveInterval 和 ServerAliveCountMax 是保活关键。TCPKeepAlive yes 表示同时开启 TCP 层 keepalive，这个通常默认就是开的，但写上更稳妥。ConnectTimeout 是连接超时时间，单位秒，避免因为网络问题卡在输入密码那一步。

配置保存后，不需要重启任何服务，下次 ssh myserver 就生效了。你可以用 ssh -v myserver 查看调试信息，里面会显示 Authenticated to 192.168.1.100 之类的输出，但不会直接显示 keepalive 包发送的记录。想验证是否生效，可以开着连接不动，观察服务器端 sshd_config 的日志，或者等 30 秒后用抓包工具看有没有小包发出去。

2.3 服务端 sshd 配置对比：哪边设置更合适？

既然提到了服务端，这里把两边的配置逻辑做个对比。服务端 sshd_config 有两个参数：ClientAliveInterval 和 ClientAliveCountMax。注意这里的名字是 Client 开头，含义是“服务端检查客户端是否存活”，和客户端的 ServerAliveInterval 方向相反。

配置项	所在端	含义	推荐值
ClientAliveInterval	sshd_config（服务端）	服务端每隔多少秒向客户端发心跳请求	60~120
ClientAliveCountMax	sshd_config（服务端）	服务端连续多少次收不到客户端响应则断开	3
ServerAliveInterval	ssh_config（客户端）	客户端每隔多少秒向服务端发心跳请求	20~60
ServerAliveCountMax	ssh_config（客户端）	客户端连续多少次收不到服务端响应则断开	3

如果两边都设置了，连接会非常稳定，因为任何一端都在定期探活。但如果服务端你说了不算（比如公司统一管理的服务器），那就只能在自己的客户端配置上下功夫。我的建议是，客户端 ServerAliveInterval 设成 30 秒是比较稳妥的选择，既能及时感知连接死亡，又不会因为太频繁而浪费带宽。

需要注意的一点是，服务端的 ClientAliveInterval 如果设得比较短，比如 30 秒，而你的客户端没有发送心跳，那服务端到点就会踢人。这种情况下，客户端打开 keepalive 并不一定能阻止服务端踢你，因为服务端要的是客户端对它的心跳请求的响应。但是当你设置了 ServerAliveInterval，客户端会定期发数据包，这会让 TCP 连接保持活跃，也能让服务端认为连接还在使用中，实际上能解决大部分空闲踢人的场景。

3. 断线自动重连：轮询、脚本和现成工具的三种思路

3.1 批处理死循环：最简单直接的保底方案

keepalive 只能让连接更不容易断，但不能保证不断。真正的保险是断线后能自动重新连接。最简单粗暴的方案，就是写个批处理死循环。

新建一个 reconnect.bat 文件，写入：

bat复制@echo off
title SSH Auto Reconnect
:loop
echo [%date% %time%] Connecting to myserver...
ssh myserver
echo [%date% %time%] Connection lost. Reconnecting in 5 seconds...
timeout /t 5 /nobreak >nul
goto loop

这段脚本的逻辑非常简单：执行 ssh myserver，这个命令是阻塞的，会一直运行到你手动退出或者连接断开。连接断开后，脚本会打印一条日志，然后等待 5 秒，再回到 :loop 标签重新连接。你按 Ctrl+C 可以终止整个循环，或者按 Ctrl+D 在 SSH 会话内退出，但会直接执行后面的断开重连逻辑，所以想完全退出脚本的话，用 Ctrl+C 按两次。

实测下来，这个方案在大部分场景下都能用，尤其是你只是需要保持一个终端窗口在线，不害怕任务中断的情况。缺点是它不保存会话状态，如果连接断开时你正在跑一个任务，任务会随着连接断开而被终止（除非用了 tmux，后面会说）。

3.2 PowerShell 增强版：带日志和重试上限

批处理毕竟太朴素，想记录日志、限制重试次数、甚至在重连后自动执行一些命令，建议用 PowerShell 写一个稍微复杂一点的脚本：

powershell复制$hostName = "myserver"
$maxRetries = 10
$retryCount = 0

while ($retryCount -lt $maxRetries) {
    Write-Host "[$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')] Connecting to $hostName..."
    ssh $hostName
    if ($LASTEXITCODE -eq 0) {
        Write-Host "[$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')] Session exited normally."
        break
    }
    $retryCount++
    Write-Host "[$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss')] Connection lost (exit code $LASTEXITCODE). Retry $retryCount/$maxRetries in 5s..."
    Start-Sleep -Seconds 5
}

这个脚本会把每次连接和断开的时间戳写到控制台，同时记录重试次数，超过上限就退出，避免无限循环下去。注意 $LASTEXITCODE 在 SSH 正常退出时返回的是 0，断线通常是 255 或者其他非零值。如果你手动在 SSH 会话里输入 exit 正常退出，脚本就不会重连了。这是故意的，因为大部分情况下，正常退出代表你已经干完活了，不需要再连回去。

如果你想在断线重连后自动执行某个命令，比如重新进入一个 tmux 会话，可以把 ssh 命令改成 ssh $hostName -t "tmux attach -t work || tmux new -s work"。-t 参数强制分配伪终端，才能运行 tmux 这种交互式程序。

3.3 现成工具的会话保持功能：MobaXterm 和 Tabby

如果你不想自己写脚本，或者觉得命令行黑窗口太朴素，那用带图形界面的 SSH 客户端是一个更舒服的选择。Windows 上常见的有 MobaXterm、Tabby、FinalShell 等，它们都内置了会话保持和自动重连的选项。

以 MobaXterm 为例，新建会话时，在“远程主机”设置里有“SSH keepalive”选项，可以设置发送心跳包的间隔，比如每 30 秒发送一次。它还支持断线自动重连，勾选“Reconnect if connection lost”就行。Tabby 的设置里也有类似功能，在“连接”选项卡中可以找到 keepalive 区间设置，还可以设置断线后自动重连的次数。

这些工具的好处是配置全在 GUI 里，所见即所得，适合不喜欢折腾命令行的人。缺点是它们底层还是调用的 OpenSSH 或者自家的 SSH 实现，keepalive 机制的差别不大。如果你在原生 OpenSSH 客户端里配置好了，效果是一样的。我个人习惯是命令行和 GUI 结合，日常快速操作用命令行，需要保存多个复杂会话或者看文件传输进度时用 GUI 工具。

3.4 WSL 里用 autossh：最接近 Linux 原生的体验

有些朋友在 Windows 上装了 WSL（Windows Subsystem for Linux），那我强烈推荐直接在 WSL 里用 autossh。这个工具是 Linux 生态里专门做 SSH 自动重连和会话保持的，非常成熟。它的原理是启动一个 SSH 进程，然后定期检查这个进程是否存活，同时通过一个额外的端口来探测连接是否正常，如果发现断线，自动启动新的 SSH 进程。

在 Ubuntu/Debian 的 WSL 里安装：

bash复制sudo apt update
sudo apt install autossh

使用方式：

bash复制autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -N -L 8080:localhost:80 myserver

-M 0 表示关闭 autossh 自带的监听端口探测功能，使用 SSH 自身的 keepalive，这是最常见的配置方式。-N 表示不执行远程命令，只做端口转发；如果你只是要开个远程 shell，不要加 -N，直接：

bash复制autossh -M 0 -f -T myserver

这个命令会在后台运行 autossh，配合 WSL 的 systemd 或者 crontab，可以实现开机自启、无人值守的 SSH 隧道。如果你愿意，也可以在 WSL 里配置 ssh alias 来简化命令，但这就是另一个话题了。

WSL 方案的好处是，你的操作习惯和 Linux 完全一致，脚本可以直接复用，而且 WSL 对网络的兼容性很好，不稳定的话还可以用 wsl --shutdown 重启整个子系统。

4. 会话持久化：让任务跑在远端，断了也不怕

4.1 tmux 和 screen：远端会话管理的核心武器

keepalive 和自动重连解决的是连接本身的问题，但如果你正在跑的是一条长任务，比如 make、pip install、rsync、git clone，连接一断，任务可能就跟着挂了。原因是这些进程是 SSH 会话的子进程，会话断开时，SIGHUP 信号会发给它们，默认行为就是终止。

所以，真正的会话持久化要靠 tmux 或 screen 这类终端复用器。它们能在服务器上开一个独立的会话，你的 SSH 连接只是依附在这个会话之上的一个“窗口”，连接断了，tmux 会话还在服务器上继续跑。下次连上，重新 attach 回去就行。

在 WSL 或者任何 Linux 服务器上安装 tmux：

bash复制sudo apt install tmux
# 或者 yum install tmux

创建一个新的 tmux 会话：

bash复制tmux new -s work

在这个会话里运行你的任务。然后直接关掉或者断开 SSH 连接，tmux 会话都会在服务器上继续运行。下次连接后：

bash复制tmux attach -t work

就能看到任务还在跑，输出也还保留着，就像你从未离开过一样。

如果你已经用了 tmux，再配合前面的自动重连脚本，那基本上就是无敌的组合。连接断了自动连回来，连回来自动 attach 到原来的 tmux 会话，整个过程你可能都感受不到断过线。

4.2 Windows 侧的会话持久化思路

很多人以为只有 Linux 服务器才能用 tmux，其实 Windows 上也可以借助 WSL 或者 Cygwin 跑 tmux。更推荐的做法是，在 Windows 本机侧不需要做会话持久化，因为你的开发任务基本都是跑在远端的。你只需要保证本地 SSH 客户端能稳定重连，以及远端有 tmux 兜底，就足够了。

但有一种情况例外：你在 Windows 侧通过 SSH 隧道做端口转发（比如 VSCode Remote-SSH、远程调试、数据库连接），如果这条隧道断了，本地应用程序也会跟着断。这时候处理方式有两种。一种是用 OpenSSH 客户端的 -o ExitOnForwardFailure=yes 防止端口转发失效的情况下 SSH 仍然保持连接；另一种是用 autossh 之类的工具守护隧道，断了自动重连，本地服务就能一直保持可用。

4.3 密钥认证：自动重连的前提条件

前面提到的自动重连脚本，如果每次重连都要手动输密码，那就没法真正实现无人值守了。所以 ssh-keygen 生成密钥对并用 ssh-copy-id 把公钥拷贝到服务器上，是必须做的一步。

在 Windows 的 PowerShell 或 WSL 里执行：

bash复制ssh-keygen -t ed25519 -C "your_email@example.com"

一路回车，生成默认的密钥对。然后拷贝公钥到服务器：

bash复制ssh-copy-id user@hostname

如果没有 ssh-copy-id（Windows 原生没有），可以手动把 C:\Users\你的用户名\.ssh\id_ed25519.pub 的内容追加到服务器的 ~/.ssh/authorized_keys 文件里。服务器端还需要确保 ~/.ssh 目录权限是 700，authorized_keys 文件权限是 600，否则 sshd 会拒绝使用公钥认证。

配好密钥后，ssh myserver 直接就能登录，不需要密码。这样自动重连脚本才能真正做到断线后自动连回去，不再需要你坐在电脑前输密码。

4.4 结合 VSCode Remote-SSH 的实战配置

VSCode 的 Remote-SSH 扩展是很多人开发的主力工具，它的掉线处理逻辑其实和 ssh 命令行差不多。在 VSCode 的设置里搜索 remote.SSH.remotePlatform，确认你连的是 Linux。然后打开 settings.json，添加：

json复制{
    "remote.SSH.showLoginTerminal": true,
    "remote.SSH.useLocalServer": false,
    "remote.SSH.maxReconnectionAttempts": 10
}

remote.SSH.useLocalServer 这个参数需要注意，如果设为 true，VSCode 会启动一个本地服务器来管理 SSH 连接，掉线后重连可能会更平滑，但偶尔也会出现连接卡死的问题。我一般建议 false，让 VSCode 每次都走标准的 SSH 连接流程，配合系统 ssh_config 里的 keepalive 配置，稳定性已经足够。

如果你在 VSCode 里跑远程 Jupyter Notebook 或者调试任务，建议还是先在远端开一个 tmux 会话跑核心任务，再用 VSCode 连接上去。这样 VSCode 掉线了，任务照样在 tmux 里跑，不会影响结果。

5. 常见问题与排查技巧实录

5.1 配置了 keepalive 还是断，怎么办？

如果你已经设置了 ServerAliveInterval 30，但还是会断，先别急着把锅甩给网络。有几个排查方向。第一，检查服务端的 ClientAliveInterval 是否配置得更短，比如 10 秒，那服务端可能在客户端心跳间隔内就认为连接死了。这种情况你只能把客户端的 ServerAliveInterval 调得更短，比如 10 秒。第二，检查中间网络的防火墙是否对 SSH 协议本身做了限制，虽然少见，但有些企业防火墙会针对长连接的 idle 状态做强制回收，TCP keepalive 和 SSH keepalive 都拦不住。这种情况只能配合隧道软件或者换端口解决，但我这里不做具体推荐。第三，确认你的网络不是通过代理或者负载均衡中转，有些代理服务器会缓冲连接，导致你的心跳发送不出去或者被丢弃。

5.2 自动重连脚本循环太快，被服务器封 IP？

这是很早以前踩过的一个坑。用批处理死循环时，如果断开后立刻重连，而且重复了好几次，服务器上的 fail2ban 之类的防暴力破解工具可能会判定这是攻击行为，直接封禁你的 IP。所以重连间隔不要设太短，至少 5 秒以上，最好 10 秒左右。如果服务器管得严，可以在脚本里加一个随机延时，让重连时间不那么规律。

另外，如果开启了密钥认证，重连基本上是瞬时的，不会占用太多服务器资源。但如果密码认证失败一次就重试，服务器日志里会留下大量记录，被安全策略扫到是大概率的事。

5.3 密码粘贴不进去或者输入延迟高

Windows 自带的 conhost 终端对 SSH 的支持有些老毛病，比如粘贴大段内容卡顿、中文乱码等。现在 Windows Terminal 已经成熟了，建议直接用 Windows Terminal 跑 SSH，体验会好很多。在 Windows Terminal 的配置文件里，还可以给每个 profile 指定命令行参数。比如你建一个叫 “Work SSH” 的 profile，命令行填 ssh.exe myserver，再把图标、颜色方案设好，以后点一下就能连上，非常顺滑。

如果你在 VSCode 的集成终端里跑 SSH，发现输入延迟高，有可能是 VSCode 渲染 DOM 的性能问题，关掉一些影响性能的插件，或者直接在 Windows Terminal 里跑，都可以改善。

5.4 用日志定位问题：SSH verbose 模式

遇到连接失败或者意外断开，最直接的排查手段就是打开 verbose 日志：

bash复制ssh -vvv myserver

-v 越多，输出越详细。三层详细的日志里会包含 TCP 连接建立、密钥交换、认证方式协商、keepalive 状态变化等信息。如果连接被服务器断开，日志末尾通常会有 Connection closed by remote host 或者 kex_exchange_identification: Connection closed by remote host 之类的提示，同时会显示断开时的 IP 和端口。

另外，Windows 的事件查看器里也有 SSH 相关的日志，路径是 Applications and Services Logs / OpenSSH / Operational。服务端（Linux）就看 /var/log/auth.log 或 /var/log/secure，里面会有 session closed for user 和 Disconnecting: connection reset by peer 之类的信息，能精确告诉你断开发生在哪个环节。

5.5 实测过的推荐的完整配置组合

最后分享一套我目前用得最顺手的组合，直接照抄即可。

客户端 ~/.ssh/config：

code复制Host prod
    HostName 203.0.113.10
    User admin
    ServerAliveInterval 30
    ServerAliveCountMax 3
    ConnectionAttempts 3
    ConnectTimeout 15
    TCPKeepAlive yes
    IdentityFile ~/.ssh/id_ed25519

服务端 /etc/ssh/sshd_config（你有权限才改）：

code复制ClientAliveInterval 60
ClientAliveCountMax 3
TCPKeepAlive yes

WSL 里跑 tmux + autossh 的启动脚本 /home/user/ssh-tunnel.sh：

bash复制#!/bin/bash
autossh -M 0 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" -f -T prod

Windows 任务计划程序里设一个开机启动，启动这个脚本。这样开机后隧道自动建立，断了自动重连，然后 Windows Terminal 直接 ssh prod 进去后 tmux attach 继续干活，基本感受不到断线的存在。

写在最后的几点体会

玩 SSH 这么多年，我最大的感受是，掉线重连这件事，方案很多，但没有一个方案是银弹，你得根据场景组合着用。keepalive 负责让连接更稳定，自动重连脚本负责兜底，tmux 才是真正保住任务的大腿。三者结合在一起，你才敢在公网环境、移动网络、甚至跨洋连接里放心跑长任务。有一次我在高铁上连着手机热点，靠着这套组合，一个耗时三小时的模型训练任务愣是没用中断过，中途信号断了四次，tmux 里的日志写得清清楚楚，重连后 attach 回去，进度条还在跑。那种感觉，真的比什么都爽。希望这篇经验总结能帮你少踩点坑，多省点时间。