网站故障排查全流程：从网络到数据库的定位方法
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /138d91a9c909.html
📄
线上网站突然打不开、页面白屏或接口超时，先别急着重启服务。顺着用户请求进入服务器的路径，从网络、资源、应用到数据库逐层排查，往往比乱试更有效。下面这套排查顺序能帮你快速缩小范围，尽早恢复线上业务。
1. 先确认网络链路与域名解析是否正常
网站访问异常时，第一步要做的是判断问题出在用户端还是服务端。一个简单的验证办法是换网络环境访问：用手机流量代替办公网络试一试，如果恢复正常，多半是本地网络缓存或代理设置问题；如果只有某些地区或特定运营商的用户反馈无法访问，则要重点检查链路拥塞或 DNS 解析是否已全网生效。
1.1 核对 DNS 解析记录与实际指向
在命令行执行 nslookup 你的域名，把返回的 IP 和服务器真实公网地址做对比。如果解析为空或指向已废弃的旧 IP，说明域名控制台上的 A 记录或 CNAME 设置有误。注意，修改 DNS 后全球生效需要一定时间，从几分钟到几小时不等。同时也要检查 CDN 节点状态，避免部分区域回源请求一直失败。
1.2 测试端口连通性并检查防火墙
能 ping 通服务器但网页无法打开，大概率是端口没放开。云服务器安全组和系统内部防火墙都要放行 80 和 443 端口。本地执行 telnet 服务器IP 443，如果连接超时，就能基本确定是防火墙拦截或上游运营商限制。这时优先查看安全组入站规则，再排查 iptables 等本地策略。
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，需要结合日志来定位。先查看 Nginx 的错误日志和访问日志，确认是静态资源问题还是后端服务异常；再检查应用自身的日志输出，比如 PHP-FPM 的 error_log、Java 服务的异常堆栈等，通常能在这里找到具体报错原因。
3.1 检查服务进程存活与端口监听
用 ps aux | grep 服务名 确认进程是否还在运行，再用 netstat -tlnp 核对服务端口是否正常监听。进程意外退出时，查看系统日志如 dmesg 或 journalctl，看是否因内存溢出被杀掉。曾经遇到过 PHP-FPM 进程全部挂掉导致网站白屏的情况，重启服务后短时间内仍反复崩溃，最后发现是某个插件内存泄漏所致，升级后恢复正常。
3.2 关注慢请求与超时配置
接口响应缓慢但服务未宕机，要关注超时设置。Nginx 的 proxy_read_timeout、PHP 的 max_execution_time 等参数设置过小，会导致后端处理较慢的请求被提前断开。查看访问日志中响应时间较长的请求，针对性优化对应的接口或调大超时时间，能减少大量超时类报错。
4. 核对数据库状态与慢查询
应用层没问题但接口仍报错，下一步就该检查数据库。数据库连接数打满、锁等待严重或慢查询堆积，都会让接口响应极慢甚至直接失败。登录数据库后，先看当前连接数和运行状态，再分析慢查询日志，找到拖垮性能的 SQL 语句。
4.1 检查连接数与锁等待情况
执行 show processlist; 查看当前会话，如果大量连接处于 Sleep 或 Locked 状态，说明连接池或锁机制出了问题。连接数打满时，适当调大数据库最大连接数只能临时缓解，根本上要检查应用是否有连接泄漏。遇到锁等待时，找到持有锁的事务并分析是否可以优化事务长度，避免长期占用资源。
4.2 分析慢查询并优化索引
开启慢查询日志，找出执行时间超过阈值的 SQL。常见问题是查询条件字段缺少索引，导致全表扫描。例如某订单查询接口响应超过 5 秒，给 order_no 字段加上普通索引后，响应缩短到几十毫秒。定期用 explain 验证查询计划，能有效预防此类性能问题。
5. 常见问题
5.1 网站打不开，ping 得通但浏览器显示无法连接，可能是什么原因？
最常见的是端口未放行，检查云安全组和服务器防火墙是否开放了 80/443。其次是服务进程未监听端口，用 netstat 确认服务状态。还有一种情况是本地浏览器缓存或代理设置异常，可以换设备或清除缓存再试。
5.2 所有接口都返回 502 Bad Gateway，问题出在哪里？
502 表示 Nginx 无法从后端获取有效响应。优先检查后端服务进程是否存活，比如 PHP-FPM 或 Java 服务是否挂掉。如果进程正常，再看是否达到进程数或连接数上限，调大相关配置或重启服务通常能暂时解决。持续出现 502 时要深入排查后端应用的稳定性。
5.3 数据库 CPU 使用率居高不下，应该怎么处理？
先通过慢查询日志找出耗时最长的 SQL，配合 explain 分析执行计划，重点看是否有全表扫描或未走索引的情况。其次检查是否存在大量短连接频繁建立，适当调大连接池并复用连接。若确认是业务增长导致的负载上升，考虑读写分离或引入缓存来分担压力。
6. 总结
网站故障排查说到底是按顺序缩小范围：先确认网络和解析，再看服务器资源，然后查应用日志，最后排查数据库。每一步都有明确的验证工具和判断标准，按流程走能节省大量时间。建议把这些检查点整理成排查清单，遇到问题时逐项对照执行。同时平时做好日志归档和监控告警，很多故障在影响用户之前就能提前发现。
