网站崩了怎么办？从网络到数据库的完整排查思路
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /979a65471755.html
📄
网站页面打不开，接口一直报错，或者访问速度像蜗牛一样慢，这时候比起干着急或者反复重启服务器，更有效的做法是理清思路，沿着用户请求走过的路径，从外面往里面一层层找问题。通常来说，排查顺序是先看网络通不通、域名解析对不对，接着查服务器自身的压力和状态，最后再深入到数据库层。
1. 先看网络链路和域名解析
遇到访问故障，先别急着登录服务器，而是要判断问题出在你这边还是服务器那边。最简单的测试办法，就是用手机流量访问一下试试。如果不换网络还是打不开，而换到移动数据后没问题，那多半是你本地网络的缓存或路由器设置出了岔子。要是只有某个地区或者某家运营商的用户反馈打不开，那就要考虑是不是DNS还没有完全生效，或者线路有拥堵。
1.1 核对域名解析记录
在电脑的命令行里敲下nslookup 你的域名，看清楚返回的IP是不是跟服务器实际的公网地址对得上。如果解析不出结果，或者出来的是一个早就废弃的旧IP，那肯定是域名管理后台的A记录或CNAME配置弄错了。另外别忘了，改了DNS记录不是立刻全球生效的，等上几分钟甚至几个小时都很正常。如果网站接了CDN，还要去CDN后台看看节点状态是不是正常，有些时候就是某个节点回源失败导致那边访问异常。
1.2 检查端口通不通
服务器能ping通，但网页就是打不开，这八成是端口没放行。云服务商的安全组规则和服务器内部的防火墙策略都得检查，80和443端口都要开着。在本地执行telnet 服务器公网IP 443，如果一直连接超时，那基本就是防火墙拦截或者运营商限制的问题了。这时候优先去云控制台看安全组入站规则，然后再看服务器上的iptables或firewalld配置。
2. 检查服务器负载和资源占用
页面反应迟钝，请求一个个排队等着超时，多半是服务器的资源被榨干了。CPU一直满载、内存不够用、磁盘写满、带宽被占满，这些都会让服务响应变得极慢。登录服务器后，建议依次执行top看看负载和CPU、free -h看看内存还剩多少、df -h看看磁盘用了多少，这几个基础命令能帮你快速摸清服务器的整体状况。
2.1 揪出吃资源的进程
在top的输出界面按P键，进程就会按照CPU占用从高到低排序。排名靠前的常常是这几类：被黑客植入的挖矿程序、数据库缺索引导致的慢查询堆积、还有恶意爬虫在疯狂抓取。结合Nginx或Apache的访问日志，能确认这些请求来自哪些IP、在打哪些URL。比如发现某个接口一秒钟被调了几百次，那就可以临时封掉来源IP，或者配置一下请求频率限制，给服务器减减压。
2.2 留意磁盘满和内存交换
磁盘使用率过了80%就该警惕了。会话文件、运行日志或者临时目录一旦写满，应用就没办法正常写缓存了，通常直接给你返回500错误。清理掉过期的日志和临时文件，空间一般就能释放出来。再看内存，如果free -h显示swap交换分区读写非常频繁，说明物理内存已经不够用了，系统一直在内存和磁盘之间来回搬运数据，性能会掉得很厉害。这时候最要紧的是先从轻量级方案着手，比如调整应用的内存参数，或者临时增加swap空间顶一顶。
3. 分析应用日志和进程状态
服务器资源没问题，那就要看应用本身是不是还活着。用systemctl status nginx或者ps aux | grep java这类命令，确认下服务进程是不是在正常运行。有一个常见坑是：进程虽然还在，但已经僵死或者卡住了，表现为CPU占用为0但就是不响应请求。遇到这种情况，直接看应用日志往往比瞎猜更快。
日志文件一般记录在/var/log/目录下，Nginx的access.log和error.log是首先要翻的。具体排查时，可以重点看error.log里的报错堆栈信息，如果是连接超时、内存溢出OOM或者数据库连接池耗尽，日志里通常都会留下线索。举个例子，如果日志里频繁出现"Too many connections"，说明数据库连接数被打满了，那就得去查是不是哪里漏掉了释放连接。
4. 拆解数据库问题和慢查询
网页能打开，但一涉及到查询就特别慢，或者某些功能一直转圈，这时候就得怀疑数据库了。数据库连不上、连接数打满、磁盘满了都会导致服务异常。登录数据库后，先执行show processlist;看看当前有哪些SQL在跑，有没有死锁或者长时间运行的查询。
4.1 找到拖后腿的慢查询
慢查询日志能帮大忙，打开后可以看到那些执行时间很长的SQL语句。看这些语句的时候，重点检查是不是没用上索引，或者是不是一次查了太多数据。比如一个查询语句在user_id字段上没有建索引，数据量一旦上百万，查询就会明显变慢。修复办法就是给相关字段加上合适的索引，或者把复杂的关联查询拆开，分几步来处理。
4.2 确认索引和连接池状态
用explain命令查看SQL的执行计划，就能看出来查询有没有走索引，扫描了多少行。另外也要看一眼连接池的配置，如果设置的max_connections太小，而业务量又上来了，就会出现连接等待超时。调整连接池大小之前，得先确认服务器内存能不能扛得住，别为了加连接数反而把内存撑爆了。
5. 常见问题
5.1 网站时好时坏，刷新几次又好了是怎么回事？
这种情况通常是间歇性故障，要么是服务器负载在某个时间段冲高，要么是数据库连接池偶尔被占满。建议观察下故障发生的时间点是否有规律，配合监控工具看看当时的CPU、内存和数据库连接数变化，一般能找到规律。
5.2 换了浏览器就能打开，原浏览器不行，是网站的问题吗？
大概率不是网站问题，而是浏览器本地缓存了旧的页面或者DNS记录。可以尝试清除浏览器缓存，或者在地址栏加一个随机参数强制绕过缓存，例如在URL末尾加上?t=123这样的参数，就能确定是不是缓存导致的。
5.3 重启服务器之后恢复了，但过几天又出问题，如何根治？
重启只是治标不治本。反复出现同样问题，说明背后有持续性的根因，比如某个进程内存泄漏、定时任务堆积或者索引失效。建议在重启前先抓取当时的系统状态和日志，记录下故障时的监控数据，分析出真正的触发条件，再做针对性的修复。
6. 总结
排查网站访问问题，别一上来就到处乱试，按照从外到内的顺序走一遍：先确认网络和DNS，再查服务器资源，然后看应用日志，最后深入数据库。每一步都用简单的命令验证一下，把可疑的点逐项排除。顺手把这次排查的过程记录下来，包括改了什么配置、当时的日志输出是什么，下次再遇到类似问题，就能更快锁定原因了。
