网站宕机卡顿怎么办？分层排查快速定位故障源
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6f3f1826957d.html
📄
网站打开慢、页面加载不出来或者接口频繁报错，多数时候并不是服务器“罢工”这么简单。与其反复刷新页面或者盲目重启服务，不如按照网络层、服务器层、应用层和数据库层的顺序，逐层去做“排除法”。这套思路能让排查更有条理，也更容易在几分钟内找到真正的故障源头。
1. 从网络链路和域名解析入手
动手去动服务器之前，先花一两分钟判断问题是不是出在“门口”。最直观的办法就是切换网络环境测试：拿手机断开WiFi用4G/5G流量访问，或者请不同城市的朋友帮忙打开同一个网址。如果换网络后访问正常了，那问题大概率就在本地网络或当前设备上；要是只有某个区域的用户反馈打不开，那就要考虑运营商骨干线路波动或者域名解析在不同地区生效不同步的情况。
1.1 核对域名解析地址是否指向最新服务器
在电脑命令行里用 nslookup 或 dig 命令，查看当前域名解析出来的IP地址，再和服务器实际的公网IP做比对。如果解析出来的IP是旧的或者根本为空，基本可以判断是A记录或CNAME记录被改动过，也可能是TTL设置得太长，很多地方的DNS节点还在用旧缓存。这时候要去域名管理后台把解析记录重新核对一遍，同时检查CDN回源地址有没有跟着更新。特别是刚换过服务器或迁移过机房的情况，旧IP的缓存往往要等很久才会自动失效。
1.2 验证端口连通性和安全组放行规则
有时候 ping 能通，但浏览器就是进不去页面，这时候八成是防火墙或者云安全组把80和443端口挡住了。云服务器用户需要登录控制台，检查入方向规则里是否明确放行了这两个端口。本地可以用 telnet 服务器IP 443 这条命令来测试端口通不通，如果连接超时或者直接被拒绝，问题就锁定在防火墙设置上了。还要注意一些特殊情况，比如某些机房网络对非标准端口有限制，这时候换一个端口或者提交工单给服务商就能解决。
2. 检查服务器资源和进程状态
如果网络链路都没问题，但页面响应依然慢，那就该看看服务器本身是不是已经“跑不动”了。CPU长期在100%附近、内存几乎被耗尽、磁盘写满或者带宽被打满，任何一项都能让请求在队列里排队，最终表现为网站卡顿甚至直接超时。常用的 top、free -h 和 df -h 三个命令，可以快速看出当前系统资源的实时消耗情况，判断瓶颈到底在哪个方向上。
2.1 揪出占用资源异常的进程
在 top 输出里按CPU使用率排序，仔细看看排在前面的是哪些进程。比较常见的情况有三种：一是服务器被植入挖矿程序，CPU飙升却不干正事；二是数据库慢查询越积越多，把资源都耗在无意义的等待上；三是没有做访问频率限制的爬虫脚本在大批量请求。配合Web服务器的访问日志，能查到到底是哪个URL或哪个来源IP贡献了最多的流量。例如某个IP以每秒几十次的频率请求同一个接口，导致PHP进程数暴涨，日志里会清清楚楚留下记录，把这个IP加进黑名单就能立刻恢复。
2.2 留意磁盘空间和内存交换情况
磁盘使用率到了80%就要提高警惕，日志文件、临时目录和Session目录一旦被写满，网站就没办法写入任何新数据，页面会直接抛出500错误。可以把过期日志定期清理，或者做一个日志切割的定时任务，确保磁盘始终留有富余空间。内存方面要关注交换分区的使用情况，如果系统频繁进行内存交换，说明物理内存严重不足，增加内存条或者优化应用的内存占用是更彻底的解法。
3. 深入应用层检查服务日志和代码逻辑
资源和网络都正常，但接口依旧报错，那就要把注意力放到应用本身。先去看Web服务和应用框架的日志文件，出错时的堆栈信息往往直接指明了代码的哪个位置出了问题。不要一开始就怀疑数据库或者第三方服务，先确认应用内部逻辑有没有明显的空指针、超时设置不当或者依赖服务没启动的情况。
3.1 关注慢接口和请求排队现象
应用日志里如果频繁出现执行时间超过一两秒的接口记录，说明代码层面存在性能瓶颈。常见的原因包括死循环、无限递归调用、以及没有加缓存的重复数据库查询。建议给关键接口加一个执行时间的日志输出，这样能定位到具体是哪一段逻辑拖慢了速度。另外也要检查框架配置中的连接超时时间，如果设置得太短，第三方服务稍慢一点就会导致大量请求被直接放弃。
3.2 观察依赖服务是否正常响应
很多网站会调用外部API或内部微服务，这些依赖一旦挂掉，整个页面也会跟着报错。排查时可以用命令行直接请求一下依赖服务的健康检查接口，看看返回码是200还是500。如果依赖服务正常但应用里仍然报错，就要检查配置文件里的服务地址有没有写错，或者密钥是否过期。微服务架构下尤其要注意服务发现机制的注册信息是否更新，注册中心里可能还保留着旧实例的地址。
4. 核对数据库连接与慢查询
当CPU和内存都够用，但页面加载还是特别慢时，十有八九是数据库拖了后腿。数据库连接数被打满、慢查询长时间占用锁，或者某条SQL语句没有走索引，都会让整个网站响应缓慢。
4.1 检查连接池使用率和数据库锁等待
登录数据库管理工具，查看当前活跃连接数和连接池最大上限的对比。如果活跃连接数一直顶着上限，说明应用层可能出现了连接泄漏，每请求一次就多占了一个连接却没有及时释放。同时可以查看是否存在长时间未结束的事务，这类事务会锁住数据表，导致其他查询一直在等待。
4.2 定位并优化慢查询语句
开启数据库慢查询日志，把执行时间超过1秒的SQL语句记录下来，结合 EXPLAIN 分析执行计划，看看有没有走全表扫描。一种常见的做法是给 WHERE 条件里的字段加合适索引，但要注意不要建太多冗余索引，否则写入性能也会下降。对于复杂查询，可以考虑拆分成多次简单查询，或者引入Redis做一层缓存，减少数据库压力。
5. 常见问题
5.1 问题1：更换网络后能访问，是不是说明服务器一定没问题？
不一定。更换网络后能访问，只能说明本机或本地网络没问题，但服务器端的某些故障可能只针对特定来源IP或特定请求方式有影响，比如某条线路的IP被防火墙临时封禁，或者CDN节点对某区域的回源不稳定。建议再做一次端口连通性测试和域名解析核对，才能更放心地把矛头从网络层移开。
5.2 问题2：重启服务器之后网站恢复正常了，还需要继续排查吗？
需要。重启往往只是把症状暂时压下去，比如释放被占满的内存或终止了异常进程，但引发异常的深层原因如果没找到，过几天可能会再次出现。建议重启后立刻查看系统日志和错误日志，关注重启前是否有磁盘写满、内存耗尽或代码死循环的线索，把它记录下来作为下次排查的参考。
5.3 问题3：数据库慢查询日志怎么设置才不影响线上性能？
开启慢查询日志本身会有一点性能开销，但设置得当影响很小。可以把慢查询阈值设置为2秒或3秒，只记录真正异常的SQL，并配合日志轮转定期清理。如果数据库负载特别高，可以使用性能分析工具做短时间采样，而不是长期开启全量日志。
6. 总结
网站故障排查的核心思路就是按层切分、逐段缩小范围，从网络链路开始，再到服务器资源、应用代码，最后落到数据库上。建议在平时就准备好一份自检清单，把常用命令、登录后台、日志路径这些信息记录下来，遇到故障时能够直接拿出来用。另外，尽量把监控工具配好，对CPU、内存、磁盘、响应时间等关键指标做实时告警，很多问题就能在用户察觉之前提前处理掉。
