网站故障排查顺序：从网络链路到数据库的实用步骤
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /1d6ce417f785.html
📄
当线上网站突然白屏、加载缓慢，或者接口频繁报错时，很多人会下意识刷新页面或者直接重启服务，但这样做往往治标不治本。更有效的做法是顺着一次请求从用户端到服务器的流转路径，逐层检查网络链路、服务器资源、应用服务和数据库配置。理清排查顺序，按步骤操作，能帮你更快定位问题根源，恢复线上业务。
1. 先确认网络链路与域名解析是否正常
网站打不开时，第一步不是登录服务器操作，而是先判断问题到底出在用户端还是服务端。一个很实用的验证办法是换个网络环境试试：用手机流量代替公司宽带访问，如果恢复正常，那多半是本地网络缓存或路由器设置的问题；如果只有某个区域或某家运营商的用户反馈无法访问，就要重点检查链路拥塞和域名解析是否还没在全网生效。
1.1 核对 DNS 解析记录与服务器地址
在电脑或服务器终端执行 nslookup 你的域名，把解析出来的 IP 地址和服务器真实公网 IP 对比一下。如果解析结果为空，或者指向了一个早就停用的旧地址，说明 DNS 控制台上的 A 记录或 CNAME 设置有误。要特别留意的是，修改 DNS 记录后全球生效不是瞬间完成的，可能需要几分钟到几小时。同时，如果用了 CDN 加速，也要确认边缘节点是否正常，避免某些地区的用户请求回源时一直失败。
1.2 测试端口连通性和防火墙放行规则
服务器能 ping 通但网页打不开，最常见的原因是端口没有对外开放。云服务商的安全组和服务器系统自带的防火墙（如 iptables）都要同时放行 80 和 443 端口。你可以在本机执行 telnet 服务器IP 443，如果提示连接超时，基本能锁定是防火墙拦截或上游运营商限制。这时候优先检查云控制台的安全组入站规则，然后再看服务器本地的防火墙配置。
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 错误日志（一般是 /var/log/nginx/error.log）和应用自身的日志文件，能直接看到具体的报错堆栈或异常信息。
3.1 排查 PHP-FPM 或应用进程是否异常
对于使用 PHP 的站点，执行 ps aux | grep php-fpm 可以查看进程数量和状态。如果发现子进程全部处于繁忙状态，且长时间不释放，很可能是有慢请求卡住了。这种情况可以调大 php-fpm 的 request_terminate_timeout 并在代码层面定位慢脚本，同时考虑增加进程数上限。对于 Java 或 Node.js 应用，则要检查 JVM 堆内存或进程的 GC 情况，必要时重启应用服务看问题是否能够恢复。
3.2 通过 access log 识别异常请求模式
访问日志里藏着很多线索。比如同一时间点某个接口的请求量突然暴增，或者大量请求集中在同一个 URL 上并且返回状态码 502、504，都值得警惕。你可以用 awk 或 tail -f 实时观察日志，也可以把日志导出后用可视化工具分析。比如在日志中发现大量 User-Agent 为空的请求，基本可以判断是脚本刷接口，应该考虑在 Nginx 层面加规则拦截。
4. 审查数据库连接、慢查询与锁等待
如果请求已经在处理，但响应速度很慢，很大可能瓶颈在数据库。连接数满了、慢查询堆积、或者表被锁住，都会让接口等待时间拉长，最终表现为页面超时。进入 MySQL 命令行执行 SHOW PROCESSLIST;，可以直接看到当前正在执行的 SQL 语句和状态，快速判断是否存在大量 Waiting for table lock 或者长时间的查询。
4.1 定位并优化耗时长的慢查询
开启慢查询日志（在 my.cnf 中配置 slow_query_log=ON 和 long_query_time=2）后，找到执行时间超过 2 秒的语句，然后用 EXPLAIN 分析执行计划，看看是否走了索引。比如一个查询条件里的字段没有建立索引，全表扫描在高数据量下会非常耗时，补上合适的索引往往能显著提速。需要注意的是，索引也不是越多越好，写多读少的场景要谨慎加索引。
4.2 检查连接数与 InnoDB 锁状态
执行 SHOW VARIABLES LIKE 'max_connections'; 查看最大连接数，再对照当前连接数判断是否达到了上限。如果经常报 too many connections 错误，就说明连接池配置偏小，需要调高并考虑应用层连接复用。另外用 SHOW ENGINE INNODB STATUS; 可以查看事务锁的情况，如果发现大量锁等待，通常是某个事务长事务未提交，把它找出来结束掉，阻塞就能解除。
5. 常见问题
5.1 网站偶发白屏，刷新一下又能打开，是什么原因？
这种情况多半与应用进程不稳定或缓存失效有关。可以查看应用日志是否记录到了内存溢出或未捕获的异常，同时检查 PHP-FPM 或应用进程是否有过重启记录。另外，如果使用了 CDN，部分回源请求失败也会导致间歇性白屏，需要在 CDN 控制台查看回源成功率。
5.2 排查时先重启服务还是先看日志？
原则上先看日志再决定是否重启，尤其是生产环境。重启服务会清空进程内存中的诊断信息，导致问题难以追溯。如果怀疑服务已经异常无法工作，可以先临时重启恢复业务，但之后一定要通过日志找到根本原因，避免问题再次发生。
5.3 数据库 CPU 占用高，但慢查询日志里没什么记录，怎么办？
慢查询日志没记录不代表没有问题。可能是慢查询阈值设置过高，可以把 long_query_time 临时调低到 1 秒或 0.5 秒观察一段时间。此外，还要检查是不是有大量并发短查询消耗 CPU，用 SHOW GLOBAL STATUS LIKE 'Questions'; 对比每秒查询数，如果是频繁的简单查询，就要考虑在应用层加缓存来降低数据库压力。
6. 结语
排查网站故障时，与其东敲一下西碰一下，不如按照"网络链路 → 服务器资源 → 应用日志 → 数据库"的路径逐层确认。每排查完一个层面，如果没发现异常，就尽快进入下一层，避免在无意义的操作上浪费时间。建议平时就把上述排查命令整理成一份清单，在出问题时按步骤操作，并在故障解决后记录原因和处理过程，下次再遇到类似问题就能快速找到突破口。
