网站打不开怎么办？从网络到应用的故障排查顺序
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /e7e15e726ab5.html
📄
网站出现白屏、加载缓慢或者接口反复报错时，很多人第一反应是拼命刷新页面或者直接重启服务器。这些操作往往解决不了实际问题，反而可能浪费宝贵的恢复时间。正确的处理思路是沿着用户请求的路径，从最外层的网络链路开始，逐层向内部排查，依次检查域名解析、服务器资源、应用服务和数据库状态。掌握这套排查顺序，能帮你更快定位故障根源。
1. 排查网络链路和域名解析问题
当网站无法访问时，不要立刻登录服务器折腾，先要判断问题究竟出在用户端还是服务端。换一个网络环境测试是最直接的办法，比如用手机流量代替办公网络访问。如果恢复正常，那多半是本地网络缓存或设备设置引起的；如果只有某些地区或特定运营商的用户打不开，就要考虑链路拥塞或解析记录还没完全同步。
1.1 检查解析记录是否正确指向服务器
在电脑命令行输入nslookup 你的域名，把显示的 IP 地址和服务器真实公网 IP 核对一下。如果解析结果为空，或者指向了一个已废弃的旧地址，通常说明域名控制台里的 A 记录或 CNAME 配置出了问题。改完解析后要注意，全球生效需要时间，短则几分钟，长可能要到几个小时。同时别忘了确认 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 错误日志和应用自身的运行日志，关注日志里记录的异常堆栈和报错码。如果应用进程已经挂了，检查是不是触发了 OOM（内存溢出）被系统杀掉，这时候一般重启能暂时缓解，但根治还需要修复代码里可能存在的内存泄漏。
3.1 关注应用进程和上层服务状态
使用 systemctl status 或 ps aux 确认应用进程是否正常运行，还要检查依赖的上层服务，比如 Nginx 反代到后端时，后端服务有没有启动。如果服务显示正在运行但响应依然异常，可以用 curl -I 你的域名 看 HTTP 状态码，帮助缩小问题范围。例如返回 502 说明网关和后端不通，返回 504 则通常意味着后端处理超时。
4. 检查数据库连接和查询性能
很多线上故障的最终根源都在数据库。接口响应慢、登录状态写入失败，以及部分页面超时，都和数据库连接池耗尽或慢查询有关。登录数据库执行 show processlist; 查看当前连接状态，观察是否有大量连接处于长时间等待或锁定状态。数据库的 CPU 和内存占用同样要关注，堆积的慢查询往往是元凶。
对于慢查询，开启慢查询日志并分析执行计划，是优化的关键一步。例如某条查询语句没有走索引，数据量大了以后就会拖垮一切，这时只需要合理添加索引就能大幅提速。除此之外，数据库连接池设置过小也会导致请求排队，需要根据并发量调整连接数上限，并确保应用端能正确释放连接。
5. 常见问题
5.1 网站时好时坏，不稳定是什么原因？
这种情况通常指向资源瓶颈或配置问题，比如内存不足触发频繁 GC、单台服务器连接数达到上限，或是定时任务和业务高峰争抢资源。建议记录故障发生的时间点，和服务器日志、监控曲线进行对照分析，往往能发现规律。
5.2 CDN 开启后网站打不开如何排查？
先确认 CDN 节点是否正常，可用浏览器直接访问源站 IP 测试排除。如果源站正常而 CDN 异常，多和域名配置有关，例如源站地址填错、HTTPS 证书不匹配或缓存规则设置不当。此外，检查 CDN 回源 HOST 是否和源站绑定的域名一致，避免回源时域名解析错误。
5.3 重启服务后短暂恢复但很快又出问题怎么办？
重启只能暂时缓解症状，无法根除问题。如果重启后很快复发，多半是代码存在内存泄漏、连接未关闭或者数据量持续增长导致查询变慢。应尽快查看重启前后的日志和监控数据，找到触发故障的真实条件，并对代码和配置做针对性调整。
6. 总结
网站故障排查本质上是一个从外到内、层层聚焦的过程。按网络链路、服务器资源、应用服务和数据库的顺序排查，能有效避免走弯路。强烈建议平时就搭建基础监控，记录服务器负载和关键日志，这样故障发生时你能更快确定问题范围，缩短网站不可用的时间。记住每次故障后做好复盘记录，常见问题的排查经验会越来越丰富。
