网站故障排查顺序：从网络链路到数据库逐层定位
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /dc2af06e5bd7.html
📄
网站打不开、页面转圈或接口频繁超时，很多人第一反应是刷新页面或者干脆重启服务器，但这样往往治标不治本。想要快速恢复服务，关键是有章法地逐层排查。故障点通常藏在外网链路、服务器状态、应用日志和数据库配置这几层里，按照从外到内的顺序动手，定位会更准，恢复也更快。
1. 从网络链路与域名解析开始查
网站无法访问，先别急着动服务器。首先要分清楚是用户端的问题还是服务端的问题。最简单的方法是换个网络环境试试，比如用手机流量而不是公司Wi-Fi访问。如果换网络后能打开，多半是本地路由器缓存或DNS设置出了岔子；如果只有特定地区或某个运营商的用户打不开，那就要重点考虑链路拥塞或者域名解析还没生效。
1.1 核对域名解析记录是否指向正确
在自己的电脑上打开命令行，输入nslookup 你的域名，看解析出来的IP和服务器公网IP是否一致。如果返回的结果是空的，或者指向一个早就不用的旧IP，通常是云控制台上的A记录或CNAME配置错了。修改解析之后，全球生效需要一点时间，短则十来分钟，长则几小时。同时还要顺便确认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分区读写频繁，说明物理内存严重不足，系统在内存和磁盘之间不断换页，性能会急剧下降。这时候应该优化程序的内存占用，必要时考虑扩容。
3. 翻应用日志与检查后端服务状态
页面白屏、部分功能不可用或直接返回5xx状态码，问题核心大概率在应用层。打开浏览器开发者工具，看具体请求返回的HTTP状态码，是401、403还是500、502，能帮你判断方向。比如502通常是后端服务挂了，而504则意味着网关超时。接着去翻应用日志，比如Java应用的catalina.out或者Python应用的日志文件，重点搜索ERROR和Exception关键字，能看到具体报错栈。别忽视运行进程本身，确认Nginx、PHP-FPM、Tomcat等进程是否还活着，有时候只是进程意外退出，重启一下就能恢复，但更重要的查明为什么退出，否则下次还会出现。
4. 深入数据库层排查慢查询与锁表
网络、服务器和应用日志都查过没有问题，接口却还是慢，这时就要怀疑数据库了。在服务器上执行show processlist;，可以看到当前所有数据库连接和正在执行的SQL语句。如果有大量连接长期停留在Query状态，或出现多个状态为Locked的会话，多半是慢查询堆积或锁等待造成的。
开启慢查询日志是关键一步。在MySQL里把long_query_time设为1秒甚至0.5秒，过一段时间就能收集到耗时较长的SQL语句。拿到这些语句后，用explain查看执行计划，看有没有走全表扫描。常见的缓解办法是给WHERE条件和JOIN字段加上合适的索引；如果用了ORM框架，还要留意是不是产生了N+1查询。另外，外键约束过多或单表数据量太大，也会拖慢写入和读取速度，必要时考虑分表或引入缓存。
5. 常见问题
5.1 网站突然打开很慢，但服务器负载不高，一般是什么原因？
如果系统资源一切正常，优先排查数据库和应用层。最常见的是数据库慢查询，比如热门接口的SQL没走索引，数据量一大就明显变慢。另外Nginx配置的worker进程数太少、PHP-FPM的max_children设置偏小，也会导致并发请求排队，表现就是页面加载缓慢。
5.2 域名能ping通，但浏览器访问提示无法连接，该怎么处理？
ping通只说明网络是通的，无法连接通常是端口问题。先用telnet测一下80或443端口，如果不通，检查云安全组和服务器防火墙是否放行了对应端口。若端口通但访问依旧失败，再看Nginx等服务是否启动、监听地址是否正确。特别注意监听的是IPv4还是IPv6，有些配置错误会导致浏览器连不上。
5.3 重启服务器之后网站恢复了，还需要继续排查吗？
需要，而且必须查清楚根因。重启只是清掉了当前症状，但触发故障的深层原因还留在系统里。比如内存泄漏、磁盘告警、定时任务冲突，这些都不会因为重启自动消失。建议重启前保留当时的dmesg、top快照和应用日志作为现场证据，重启后持续监控资源消耗态势，避免问题复发。
6. 总结
网站出故障时，按链路→服务器→应用→数据库的从外到内顺序排查，能少走很多弯路。平时把常用命令和日志路径整理成一份速查手册，故障时能节省大量时间。遇到恢复后反复出现的问题，一定要深挖根因，并建立监控告警和定期巡检习惯，尽量把隐患消灭在故障爆发之前。
