网站故障排查指南：按步骤定位问题根源
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e473a9685e94.html
📄
网站出现打开缓慢、白屏或是接口报错时，与其反复刷新或频繁重启服务器，不如按顺序逐层排查。故障源头通常集中在网络链路、服务端资源、应用代码和数据库配置几个环节。先理清排查路径，再动手操作，往往能更快恢复线上服务，减少对用户的直接影响。
1. 先筛查网络链路与域名解析状态
站点无法访问时，先从网络层开始检查，不要第一时间就去重启服务器。判断问题出在用户侧还是服务侧，可以通过切换访问方式来验证。用手机流量而非办公网络访问，如果恢复正常，多半是本地网络缓存或设备设置的干扰；若仅某个区域或特定运营商用户反馈打不开，则应重点怀疑链路拥塞或域名解析尚未生效。
1.1 核对解析记录与返回地址
在本地终端输入nslookup 你的域名，确认解析出的 IP 与服务器实际公网地址一致。若解析结果为空或指向已停用的旧 IP，通常是控制台上的 A 记录或 CNAME 配置有出入。改动解析记录后存在全网生效延迟，一般需等待几分钟到几小时不等。也别忘了确认是否因 CDN 节点异常，导致部分地域的回源请求失败。
1.2 测试端口连通性与防火墙规则
能 ping 通服务器却打不开网页，往往不是服务器宕机，而是端口未能对外开放。云服务商的安全组和服务器内部防火墙需同时放行 80 及 443 端口。在本机执行telnet 服务器IP 443，若提示无法连接或超时，基本可锁定为防火墙拦截或 ISP 封禁导致。此时优先检查安全组策略，再核对 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 状态码，问题核心大概率在应用层。打开浏览器开发者工具的 Network 面板，先观察失败请求的 HTTP 状态码：500 表示程序内部异常，502 通常是网关无法连接后端节点，504 则代表后端响应超时。结合状态码，再到对应服务的日志目录里检索异常堆栈。
3.1 分清网关与业务日志的职责
Nginx 的 error.log 记录了转发失败和超时信息，而 PHP-FPM、Tomcat 或 Node.js 的应用日志则保存了具体报错。排查时先看网关日志确认请求是否到达后端，再看应用日志定位是哪一段代码出错。例如，日志中出现"Connection refused"，往往是后端服务进程意外退出或监听端口被占用；出现"Allowed memory size exhausted"，则是 PHP 脚本内存配额设置过低。
3.2 关注慢接口与错误率
如果只是个别接口耗时较长，可在应用日志中开启慢查询记录。像订单提交或登录验证这类写入操作，一旦响应时间超过预期，应立即检查相关外部调用，比如第三方支付回调或短信服务是否出现延迟。判断标准是：接口响应时间较平时高出 3 倍以上，且持续超过 15 分钟，就要当作故障处理，而不是偶发波动。
4. 深入排查数据库连接与慢查询
很多看似是应用性能的问题，根源其实在数据库。连接数耗尽会导致前台直接报"too many connections"；慢查询堆积则会让数据表锁等待变长，拖垮整体响应速度。排查时先看数据库的当前连接数和运行状态，再分析慢查询日志，找出耗时最长的 SQL 语句。
4.1 验证配置与锁定慢查询
登入数据库执行SHOW PROCESSLIST;，查看是否有大量连接处于 Sleep 或 Waiting for lock 状态。若是连接数不够，需调大 max_connections 或检查代码中的连接池是否复用。针对慢查询，执行EXPLAIN查看执行计划，重点看是否有全表扫描或索引失效。例如，对 where 条件中的时间字段加普通索引，常能让查询耗时从秒级降到毫秒级。
4.2 常见隐患与规避做法
频繁使用 SELECT * 且数据量大时，会占用大量 IO；缺少分页的接口，在数据量增长后容易内存溢出。建议为高频查询字段创建复合索引，把涉及事务的写操作拆分到业务低峰期，同时设置合理的连接超时时间。如果数据库长期占用 CPU 超过 70%，除了优化 SQL，还要考虑架构层面是否引入了缓存或读写分离。
5. 常见问题
5.1 网站打不开，该如何自测是哪个环节的问题？
按顺序执行三个动作：先用手机流量访问站点，排除本地网络问题；再在电脑命令行执行 ping 和 nslookup，确认域名解析和 IP 连通性；最后用 telnet 测试 80 和 443 端口是否对外开放。若三者均正常，则把关注点转向服务器负载和应用日志，基本就能定位到具体环节。
5.2 502 和 504 状态码分别代表什么，如何快速修复？
502 表示网关收到了无效响应，通常是后端服务进程崩溃或端口未监听，检查 PHP-FPM、Tomcat 等进程是否在运行，重启后一般可恢复；504 是网关等待后端响应超时，优先查看后端日志中是否有耗时过长的请求，再检查数据库连接或外部 API 调用是否卡住。
5.3 排查网站故障时，应该先看日志还是先重启服务？
建议先收集现场信息再决定是否重启。在重启前，至少用 top 记录 CPU 和内存状态，抓取当时的应用错误日志。重启可能暂时恢复访问，但会丢失重要的现场证据，导致问题反复出现。如果服务已完全不可用，可先重启恢复业务，然后立即分析日志定位根因。
6. 结语
网站故障排查的核心是"先网络、再系统、后应用、终数据库"的顺序，每一步都依赖日志和命令给出的客观证据。建议将上述排查步骤整理成内部手册，并定期对线上服务做健康巡检。遇到故障时保持冷静，按流程逐层确认，绝大多数问题都能在短时间内定位并解决。
