远程连接成功后频繁掉线：按断开时机排查
本篇适用于已经登录SSH或远程桌面，使用一会儿后断开、反复重连的情况。先保存断开时间、时区和客户端完整提示；首次连接就超时或认证失败时，先按登录错误排查。
先区分断开的范围与时机
| 现象 | 先记录和检查什么 |
|---|---|
| 每次空闲相近时长后断开 | 记录不操作多久会断，核对客户端、服务器会话时限及出口设备的会话策略。 |
| 执行某个任务或负载升高时断开 | 记录具体操作及对应时间，保存CPU、内存、磁盘和该程序日志。 |
| 同一时刻多个会话或业务都断开 | 检查实例运行时间、系统和服务重启记录，再对照不同网络的结果。 |
| 只有一个设备或来源网络会断 | 记录客户端名称、版本和网络；用另一设备或网络连接同一IP、同一端口对照。 |
断开后，记录是否能立即重新登录，以及另一项原本已运行的服务是否仍可用。新连接成功只能说明复测当时可以建立连接，不能证明刚才的会话没有异常。
核对系统是否真的重启
Windows可在任务管理器“性能→CPU”查看运行时间；Linux可结合启动记录和日志核对。运行时间重新开始时，继续查看异常重启文档；没有重启证据时，先检查对应远程服务和会话。不要仅因远程窗口关闭就认定整台服务器重启。
SSH：查看断开时段的服务记录
在仍可用的管理连接或产品实际提供的控制台内检查。以下命令在使用systemd的Linux服务器上执行，以Debian／Ubuntu常见的ssh服务为例：
systemctl status ssh --no-pager
sudo journalctl -u ssh --since "30 minutes ago" --no-pager其他发行版可能使用sshd，应替换成实际服务名称。status显示的当前状态与journalctl中断开前后的重启、退出和认证记录需要一起看；“30 minutes ago”表示最近30分钟，故障不在此范围内时改为对应时间。没有日志不能直接判为正常，还需确认服务名、日志保留和时间是否正确。
固定空闲时长后断开，继续核对现有SSH和客户端的会话、保活配置；先记录原值与管理要求。保活只能帮助部分空闲会话，不能修复实际丢包、服务退出或系统重启。
RDP：区分会话断开与用户注销
在Windows服务器事件查看器的“应用程序和服务日志→Microsoft→Windows”下，查看TerminalServices-LocalSessionManager及TerminalServices-RemoteConnectionManager的可用日志，按断开时刻筛选。保存事件内容和客户端错误，区分会话断开、重新连接、注销以及相关服务重启。再核对已有会话时限和用户登录策略，不先关闭网络级别身份验证。
用同一时段的网络与资源作对照
保留原条件，用有线连接或手机热点访问同一实例，记录断开是否仍出现。服务器同时采集资源：Windows使用任务管理器或资源监视器；Linux按资源排查文档采样。若只有画面卡顿而没有断开，进入RDP画面排查；若多个业务也变差，再做延迟与丢包对照。
仍反复断开时，提交工单附产品ID、当前IP和端口、本地客户端及网络、断开与恢复时间、可重现间隔、系统是否重启、日志片段及资源记录。隐藏密码、令牌和无关用户信息，先保存现场，再安排必要恢复。