今天遇到一个比较典型但很容易误判的问题：网站可以正常打开，但是整体变卡。

不是打不开，也不是报错，而是“能访问但很慢”。

首页可以进，后台也可以登录，但点击任何操作都有明显延迟，页面响应不像平时那么流畅。

这种问题如果只看表面，很容易以为是服务器配置不够，但这次排查下来发现，并不是单纯的CPU或内存问题，而是连接数异常和进程堆积共同造成的。

一、问题出现时的表现

这次问题表现比较典型：

网站可以正常访问。

首页加载没有报错。

后台可以登录，但操作延迟明显。

页面点击后有短暂停顿。

SSH登录有轻微延迟。

服务器没有宕机。

没有 502 或 500 报错。

这种情况最容易让人误判为“网络问题”或者“服务器性能不足”，但实际上问题可能在连接层或进程层。

二、第一步：检查服务器整体负载

我先登录服务器查看整体状态。

uptime

结果显示负载有轻微升高，但CPU并没有满载。

继续查看CPU：

top

CPU占用并不高，内存也没有爆满。

这一步基本排除：

不是CPU瓶颈。

不是内存不足。

不是服务器整体宕机。

但有一个现象比较明显：负载比平时高，但CPU没有对应增长。

这种情况通常说明有“等待型问题”。

三、第二步：检查连接数是否异常

网站卡顿但CPU不高，一个常见原因就是连接数过多。

我先查看当前连接情况：

netstat -an | wc -l

然后重点看 ESTABLISHED 连接：

netstat -an | grep ESTABLISHED | wc -l

发现连接数比平时明显偏高。

说明服务器虽然没有崩，但正在处理大量连接。

连接多不一定是攻击，也可能是：

长连接没有释放。

接口请求堆积。

用户请求响应变慢导致连接滞留。

四、第三步：分析连接来源

继续查看具体连接情况：

ss -antp

可以看到部分连接处于：

CLOSE_WAIT。

TIME_WAIT。

ESTABLISHED长时间未释放。

这些状态如果数量过多，就会占用系统资源。

特别是 CLOSE_WAIT 增多，通常说明应用层没有正确关闭连接。

五、第四步：检查进程是否堆积

继续查看进程情况：

ps aux | sort -nrk 3 | head

发现有一些 PHP 进程占用时间较长。

同时还有部分进程数量明显比平时多。

这说明请求没有及时结束，导致进程堆积。

进程堆积后，即使CPU不满，也会导致系统响应变慢。

因为系统在处理的任务太多，但每个任务都没有完全结束。

六、第五步：检查Nginx请求排队情况

我继续查看 Nginx 状态。

systemctl status nginx

服务正常。

再看访问日志：

tail -n 50 /www/wwwlogs/access.log

发现部分请求响应时间明显变长。

说明请求不是失败，而是“在排队等待处理”。

这种情况通常发生在：

PHP进程不够用。

请求执行时间过长。

连接没有及时释放。

七、第六步：定位真正问题原因

综合所有信息后，这次问题的核心原因是：

连接数短时间内增加。

部分请求执行时间变长。

PHP进程未及时释放。

系统出现轻度进程堆积。

负载升高但CPU并不满。

也就是说，这次不是“服务器性能不够”，而是“请求处理效率下降导致的堆积”。

八、实际处理过程

为了恢复系统响应，我做了几个处理步骤。

1. 重启PHP-FPM释放堆积进程

systemctl restart php-fpm

重启后进程立即释放。

2. 清理异常连接

通过观察连接状态，等待 TIME_WAIT 自然释放，同时减少新请求压力。

3. 重启Nginx（必要时）

systemctl restart nginx

用于清理部分卡住的请求队列。

4. 观察负载变化

重启后继续观察：

uptime

负载逐渐下降。

连接数恢复正常。

网站响应恢复流畅。

九、恢复效果

处理完成后：

网站访问恢复正常速度。

后台操作不再卡顿。

SSH连接延迟消失。

连接数恢复平稳。

系统负载回到正常水平。

说明问题确实是短时间连接与进程堆积导致的。

十、这次问题的经验总结

网站“能打开但卡顿”，一般不是大故障，而是以下几类问题：

连接数异常增长。

进程处理不过来。

请求执行时间变长。

应用层没有释放连接。

系统进入“轻度拥堵状态”。

这种问题最容易误判，因为服务器看起来“没挂”。

但实际体验已经明显下降。

十一、后续优化措施

为了避免类似情况再次发生，我做了几个调整：

第一，限制 PHP-FPM 进程数。

第二，优化慢接口执行时间。

第三，减少长时间请求操作。

第四，定期监控连接数变化。

第五，增加日志监控请求耗时。

第六，避免单接口处理过多逻辑。

网站稳定性不仅是服务器配置问题，更是请求处理能力的问题。

写在最后

这次网站卡顿但可以访问的问题，最终不是服务器宕机，也不是资源不足，而是连接数上升和进程堆积导致的“轻度拥堵”。

很多网站问题不是突然坏掉，而是慢慢变慢。

遇到类似情况时，不要只看CPU，要重点看：

连接数。

进程状态。

请求耗时。

负载变化。

很多“卡顿问题”，本质都是系统在排队，而不是系统坏了。