服务器卡顿是什么原因，网站打不开怎么排查

网站打开慢、服务器无响应，问题不一定出在代码上，更多时候是硬件资源、软件配置、网络链路和数据库查询这四类原因在打架。你问“服务器里有什么原因吗”，说白了就是要从机房那台机器一路排查到你的业务代码，这篇文章直接拆开讲，帮你看清楚瓶颈到底卡在哪一环。

服务器卡顿是什么原因，先查硬件资源四件套

硬件层面的问题最直接,也最容易定位，你去云厂商控制台看监控图表，如果看到下面这几项打满，基本就能锁定了。

CPU使用率飙高

CPU是服务器的“大脑”，当CPU长期跑在90%以上，系统响应就会急剧变慢，常见场景是凌晨的定时任务撞在一起，比如数据备份、日志压缩、报表生成全挤在同一时间点执行，另一个高发原因是程序里出现了死循环，或者某个接口被恶意频繁调用。

内存吃紧开始用Swap

内存不够时,Linux系统会动用Swap分区临时凑合，一旦Swap使用率上去，磁盘读写频率暴增，响应时间会直接翻好几倍，行业共识认为，Swap占用持续超过30%就该考虑加内存了，你可以执行free -h看一眼，如果available数值不到总内存的20%，说明内存压力已经不小。

磁盘IO瓶颈比CPU更隐蔽

很多人忽略磁盘,当数据库频繁写日志、或者大量小文件读写堆积时，磁盘IO等待时间会严重拖慢整个系统，用iostat -x 1看%util，如果这个值经常超过80%，磁盘基本就是罪魁祸首了，老式机械硬盘在随机读写场景下特别吃亏，换成SSD或NVMe云盘立竿见影。

带宽跑满被限速

带宽满不是指你下载东西,而是进出服务器的流量超过了购买的上限，比如服务器在外面被人刷流量、或者备份文件在跨机房传输，都会把入口带宽塞满，用iftop或云厂商的流量监控就能看到实时流量曲线，一旦持续顶在峰值，网页自然打不开。

服务器响应慢的原因，软件配置和数据库是重灾区

硬件没问题,那就进入软件层面，这部分坑最多，也是运维排查的重点。

Web服务器配置没调优

拿Nginx来说,默认配置的worker_processes是auto，worker_connections只有1024，并发上来后，连接队列直接溢出，新请求排队等着，用户感知就是“转圈圈”，业内专家指出，

超过60%的并发瓶颈可以通过调整Nginx的keepalive、gzip和worker连接数缓解，Python的Gunicorn、Java的Tomcat也有类似的线程池参数，默认值在大多数情况下只是“能用”，远谈不上“好用”。

数据库慢查询拖垮整体

另一个极其常见的原因是数据库索引没建好,一个查询扫全表，数据量从十万涨到百万后，耗时就从几十毫秒变成好几秒，你去MySQL里开慢查询日志看看，执行时间超过1秒的SQL语句基本都能抓到，典型的优化动作是：先看执行计划EXPLAIN，确认是不是走了全表扫描，再决定加索引还是改SQL写法。

缓存策略偷懒

Redis用得好的服务器,响应时间能控制在几十毫秒级别，但相当一部分团队把缓存当做“可选优化”，热点数据每次请求都打到数据库上，正常情况是：商品详情、用户信息、配置列表这类高频读数据，必须做成缓存，缓存穿透、缓存击穿、缓存雪崩这三兄弟，每个都能让服务器直接罢工。

网络链路和架构设计，排查服务器故障原因的盲区

你服务器本身一切正常,但用户还是说卡，这时候问题可能出在客户端到你服务器之间的那段路上。

跨地域访问绕路了

服务器放在北京,用户在广州访问，物理距离带来的延迟是不可避免的，如果没有CDN加速，也没有就近接入点，路由跳数多一跳，延迟就多一截，用traceroute命令看路由路径，如果发现走了奇怪的跳点，比如绕到别的城市再回来，那就得考虑加CDN或者选择多线BGP机房。

DNS解析拖后腿

DNS解析时间也是响应时间的一部分,某些公共DNS解析记录TTL设置太短，或者域名解析服务商本身不稳定，会导致用户每次访问都要重新查询，你可以用dig命令看看解析耗时，正常应该在几十毫秒内，超过100毫秒就该考虑换DNS服务商，或者检查下有没有被解析劫持。

单机架构天然扛不住突发流量

一台服务器撑所有业务,这在早期没问题，但当用户量上来，单机Nginx、单机MySQL、单机Redis这些“单点”任何一环挂了，整个服务就瘫痪，架构层面起码要做到：应用服务器多开一台做负载均衡，数据库做主从分离，Redis做哨兵集群。

手把手排查：一步步定位服务器变慢的元凶

别一上来就重启大法,按下面的步骤走，半小时内能定位大部分问题。

第一步，看整体性能指标

登录服务器,依次执行这套命令看全局状态：

• uptime：看过去1分钟、5分钟、15分钟的负载均值，如果1分钟数值比15分钟高很多，说明负载正在上升
• top：按CPU和内存排序，找出占用最高的进程，记下PID
• free -h：确认内存总量、已用、可用和Swap情况
• df -h：确认磁盘分区空间是否还剩20%以上，满盘会让很多服务直接拒绝写入

第二步，盯住磁盘IO和网络

如果前三项都没问题,就看IO和网络：

• iostat -x 1 3：观察%util和await，这两个值偏高代表磁盘在超负荷运转
• ss -s：看当前TCP连接数，如果出现大量TIME_WAIT状态，说明短连接请求太多
• sar -n DEV 1 3：看网卡进出的字节数和丢包率

第三步，检查应用日志

硬件和系统层面排除了,就到应用的日志目录里翻报错：

• Nginx错误日志：通常路径是/var/log/nginx/error.log
• Tomcat或Gunicorn的日志：看有没有OutOfMemoryError或者Too many open files
• 应用自身日志：看有没有频繁的TimeoutException、Connection refused等关键字

第四步，针对性模拟验证

你自己用curl模拟一下并发请求,感觉一下到底有多慢：

curl -w "连接耗时:%{time_connect}s 请求总耗时:%{time_total}s" -o /dev/null -s http://你的域名

对比本地网络环境直接用IP访问,如果IP访问快很多，那就是DNS或域名解析的问题，如果IP访问也慢，那就回到前面几步继续排查服务器自身。

服务器故障原因有哪些方面，帮你整理成一张速查表

Q&A：关于服务器故障原因，你还想问这几个问题

服务器CPU使用率100%但看不出哪个进程高，是什么原因

这种现象大概率是软中断导致的，常见于网卡流量过大或频繁的进程上下文切换，用top按数字键1看每个CPU核心的使用情况，再用cat /proc/softirqs对比各CPU的中断次数分布，解决办法通常是把网卡多队列打开，让多个CPU核心分布处理中断，或者检查是否有DDoS攻击流量进来。

服务器内存明明够用，为何还会出现卡顿

内存够用不代表没有内存碎片或文件缓存占用过大,Linux默认会把空闲内存用作页缓存（buff/cache），这是正常的，但如果free -h显示available已经很低，加上Swap分区开始被使用，系统就会因为频繁换页而变慢，此时排查重点应该是某个进程是否存在内存泄漏，可以用smem -k按进程真实内存排序，找出增长异常的那个进程。

如何判断服务器问题是硬件还是代码引起的

做个对照实验：直接访问服务器上的静态文件，比如一张图片或一个HTML页面，如果静态文件访问速度正常，说明网络和Web服务器没问题，大概率是业务代码或者数据库查询逻辑拖后腿，如果静态文件都慢，再回头看硬件资源监控，八成是CPU、内存或磁盘IO先出了问题。

服务器变慢不是玄学,所有故障都会在监控数据里留下线索，从硬件资源四条线查起，再深入软件配置和数据库层，最后记得扫一眼网络链路，你会发现所谓的神秘原因基本都藏在这几层里。