服务器频繁掉线怎么排查？从网络、负载到应用逐层定位
服务器频繁掉线，先不要急着重装系统或换机房。
掉线只是现象，常见根因分布在三个层面：网络链路不稳定、服务器资源耗尽、应用连接数或防火墙策略异常。
下面按从外到内的顺序给出排查步骤，每一步都有对应的命令和判断依据，新手照着执行也能缩小范围。
先确认掉线的表现和范围
动手前先记录清楚：掉线时是 SSH 完全断开、网站打不开但 SSH 正常，还是只有某个端口不通。
同时确认影响范围——是所有访客都受影响，还是只有你本地连不上。
如果只有你本地连不上，优先检查本地网络和运营商；
如果多地同时反馈，问题大概率在服务器侧。
可以在服务器上执行 uptime 和 who 看是否发生重启，执行 last reboot 查看重启记录，确认掉线是否伴随系统重启。
网络层：用 mtr 判断丢包发生在哪一跳
在服务器上安装 mtr（CentOS 用 yum install mtr -y，
Debian/Ubuntu 用 apt install mtr -y），
然后对你的公网 IP 或目标用户 IP 做持续测试：
mtr -r -c 50 你的公网IP重点看两个指标：最后一跳的丢包率和延迟抖动。
中间某跳丢包但后续跳不丢，通常是该节点限速，不影响实际连接；
最后一跳持续丢包才说明问题出在服务器出口或回程链路。
如果丢包集中在运营商出口，联系服务商并提供 mtr 报告；
如果最后一跳丢包但服务器本地 ping 127.0.0.1 正常，检查网卡和带宽是否跑满。
带宽跑满也会表现为“掉线”。
用 iftop 或 nload 观察实时流量，如果出口带宽长期接近上限，先排查是否有异常进程或攻击流量。
系统层：检查负载、内存和日志
登录服务器后依次执行：
uptime
free -h
df -huptime 的负载值持续高于 CPU 核心数，说明系统过载；free -h 中 available 接近 0 且 swap 使用量高，可能存在内存耗尽导致 OOM Killer 杀掉进程。
用 dmesg -T | grep -i oom 查看是否有 OOM 记录，有的话需要调整应用内存或增加内存。
系统日志是掉线排查的关键。
CentOS 查看 /var/log/messages，Ubuntu/Debian 查看 /var/log/syslog，用 tail -f 实时观察掉线时刻的记录。
常见线索包括网卡 down/up、内核报错、磁盘只读等。
如果日志中出现 eth0: link down 之类的记录，重点检查网卡和机房链路。
应用层：连接数和防火墙别忽略
SSH 能连但网站打不开，问题往往在应用层。
先检查 Web 服务状态：systemctl status nginx 或 systemctl status httpd，确认进程是否在运行。
再看连接数是否达到上限：
ss -s
ss -ant | awk '{print $1}' | sort | uniq -c如果 TIME_WAIT 或 ESTABLISHED 数量异常高，可能是连接数耗尽或遭遇扫描。
检查防火墙规则是否误封了正常 IP：iptables -L -n 或 firewall-cmd --list-all。
云服务器还要确认安全组规则没有变动。
应用日志同样重要。
Nginx 的 error.log、PHP 的 php-fpm.log、数据库的慢查询日志，都可能记录掉线前的异常。
重点找 connection reset、timeout、too many connections 这类关键词。
修复后如何验证
调整参数或更换线路后，不要立刻认为问题解决。
建议连续观察 24 小时：用 mtr -r -c 100 复查丢包是否消失，用监控工具记录负载和带宽曲线，确认掉线不再复现。
如果是连接数问题，调大 nginx.conf 中的 worker_connections 或系统 ulimit -n 后，用 ss -s 观察连接数是否稳定在阈值以下。
最后提醒一点：掉线原因可能不止一个，排查时按网络、系统、应用的顺序逐层排除，每次只改一个变量并记录结果，避免同时调整多处导致无法判断哪一步生效。
常见疑问
重启服务器能解决掉线吗？
重启只能临时恢复，不能消除根因。
如果重启后短时间内再次掉线，说明问题仍在，需要按上面的步骤查日志和链路。
云服务器控制台显示运行中，但 SSH 连不上，是什么原因？
控制台状态只反映虚拟机进程，不代表网络和系统可用。
优先检查安全组、防火墙和系统负载，再用 VNC 登录控制台查看系统日志。
掉线时网站能打开但很慢，算掉线吗？
这属于性能问题而非完全断连，排查思路类似，重点看带宽、CPU 和数据库连接，不要只盯着网络丢包。
