网站无法访问？一套有序排查步骤快速找出故障点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /cf8a7b6aefbc.html
📄
网站忽然打不开，页面卡在白屏，或者接口一直报错，这时候反复按F5刷新、胡乱重启服务都不是好办法。花点时间理清思路，按步骤来排查，通常会比无头绪地乱试更快找到问题所在。这就像医生看病讲究望闻问切，排查网站故障也得从外到内，一步步缩小范围。
1. 先分清是本地网络问题还是服务器问题
电脑上不了网，网站打不开，第一步千万别先怀疑服务器宕机。不妨先从自己这边找原因：用手机浏览器，关闭WiFi，直接通过4G或5G流量访问网站试试。如果手机能正常打开，那问题多半出在你的电脑、家里WiFi或者本地DNS缓存上。反之，如果手机用流量也打不开，那就可以把注意力完全转移到服务器和程序上。
1.1 验证DNS解析是否正确
DNS解析是把域名翻译成服务器IP地址的过程。如果在本地命令行依次输入ping 你的域名和nslookup 你的域名，就能看到域名当前解析到的IP地址。你需要将这个IP与服务器管理后台显示的服务器公网IP进行比对。若发现结果不一致，或是提示找不到主机，那通常是A记录、CNAME记录配置错误，或是刚刚修改了DNS但尚未在全球完成同步。此时，登录域名注册商的后台，重新核对解析记录的类型和值，就是最直接的解决办法。
1.2 检查端口是否被防火墙拦截
如果你能ping通服务器的IP，但浏览器就是打不开网页，八成是80和443这两个端口没放行。云服务器通常都有安全组和系统防火墙两层防护。你需要登录云服务商控制台，查看安全组规则中是否放行了HTTP和HTTPS流量。同时，在本地用telnet 服务器IP 80这个命令测试一下端口，如果显示连接失败或超时，那问题就已经定位在了防火墙拦截或网络运营商封禁端口上。
2. 观察服务器资源负载和高耗用进程
如果网站表现是加载极慢、请求迟迟得不到响应，那就要警惕服务器资源是否已经耗尽。CPU使用率持续100%、内存占用过高、磁盘写满或带宽跑满，都会让后续请求排队等待服务，用户体验自然是慢如蜗牛。SSH登录服务器后，依次执行top（查看CPU与内存）、free -h（查看内存和Swap分区）、df -h（查看磁盘剩余空间）这三个常用命令，就能快速确定资源瓶颈的大致方向。
2.1 找出占用资源的进程元凶
在top命令的输出窗口中，按下大写P键可以按CPU使用率排序，此时重点关注排在最前面的进程。常见的资源杀手包括：被植入的挖矿木马、执行效率极差的SQL查询循环，以及没有做频率限制的恶意爬虫。为了进一步确认，可以结合Nginx或Apache的访问日志，查看最近时段的高频请求来源IP和URI。比如，某个接口被定时任务疯狂调用，导致PHP进程堆积，那么日志中反复出现的相同IP就是最有力的证据。
2.2 处理磁盘和内存的定时炸弹
磁盘使用率一旦超过80%就需要立刻关注。日志文件和临时目录会把磁盘空间填满，届时程序无法写入会话文件或缓存文件，网站就会直接抛出500错误。这时候，清理过期日志、删除无用的备份压缩包是立竿见影的操作。内存方面，如果free -h中Swap分区的使用率在持续增长，说明物理内存已不够用，系统正在频繁进行磁盘交换，性能自然骤降。调整程序缓存策略、优化数据库查询，或者干脆升级内存，才是长治久安的办法。
3. 阅读应用日志定位代码异常
当网站出现白屏、某个特定功能报错或直接返回500状态码时，怀疑点就要转移到程序本身了。打开浏览器开发者工具（F12），切换到Network面板后重新加载页面，先看第一个失败请求的状态码：500代表服务器端程序抛出了异常，404表示请求的路径不存在，502和504则通常是反向代理配置错误或上游服务超时。明确了状态码，再进入应用日志目录，比如Java项目的logs文件夹、Python项目的var/log目录，按时间倒序找到最新的ERROR记录。
日志中通常含有关键的异常堆栈信息，能够准确指引到出错的代码文件和行号。例如，日志中出现“Allowed memory size of X bytes exhausted”这样的字样，说明PHP脚本内存限制不够；出现“SQLSTATE[HY000] [1045] Access denied”则提示数据库账号密码错误。对照日志逐行排查，远比猜测要高效得多。
4. 核对数据库与运行环境配置
排除代码问题后，需要进一步检查依赖的数据库和服务组件。数据库连接数耗尽、Redis服务意外退出、或者是数据库账号密码在配置文件中被改动了，都会导致接口报错。在服务器上执行systemctl status mysql或ps -ef | grep redis，能快速确认核心服务的存活状态。
4.1 检查数据库连接数和慢查询
登录数据库执行SQL语句查看最大连接数以及当前的活跃连接数。如果连接数已经达到上限，程序就会报“Too many connections”错误。此时可以临时调整max_connections参数应急，但根本措施是开启慢查询日志，找出那些耗时超过2秒的SQL语句，然后通过添加索引或优化写法来解决。连接数异常增长往往和代码中的连接泄漏有关，事后一定要检查持久连接的释放逻辑。
4.2 核实环境变量与配置文件
很多网站故障都源于代码发布后环境不一致。检查应用配置文件中的数据库地址、端口、账号密码，确认是否与当前环境匹配。同时核对PHP版本、Java JDK版本、或Nginx配置中的fastcgi_pass设置是否与启动的服务进程相符。特别提醒：代码从测试环境部署到生产环境时，配置文件中的域名和数据库连接串经常成为漏网之鱼，务必重点检查。
5. 常见问题
5.1 同样一台电脑，为什么有些网站能打开，有些打不开？
这种情况通常属于域名解析异常或站点被隔离。能打开的网站DNS解析正常，打不开的网站可能是因为其DNS解析到了错误的IP、服务器防火墙拒绝了你的IP段，或者是服务器的Web服务配置了只允许特定来源访问的规则。可以先尝试更换公共DNS服务器（如223.5.5.5），若无效则需联系服务器管理员检查防火墙黑白名单。
5.2 网站重启服务后恢复了一小会儿，之后又再次无法访问，是怎么回事？
这类反复发作的问题基本不是偶然故障，而是存在未根治的隐患。最常见的原因是内存泄漏，程序运行一段时间后占用内存持续增长，直到耗尽内存被迫无响应；或者有定时任务在特定时间点产生高IO操作。建议观察服务器监控图表，记录故障发生的时间点是否与定时任务或流量高峰重合，从而缩小排查范围。
5.3 页面报502 Bad Gateway错误，后端服务日志里也查不到任何记录，应该怎么办？
502错误表示网关（如Nginx）无法从上游服务获得有效响应。如果后端应用日志没有记录，说明请求根本没能到达应用层。你需要检查PHP-FPM进程是否存活、监听端口是否正确，以及Nginx配置中fastcgi_pass或proxy_pass指向的地址和端口是否与后端实际监听端口一致。最常见的踩坑点就是：后端服务换了端口，而Nginx配置中的转发规则没同步更新。
6. 总结
面对网站故障，不要慌张，也不必盲目操作。按顺序先查本地网络，再查服务器资源，接着核对程序日志，最后检查依赖服务和配置项。建议在日常运维中，提前准备好一份故障排查手册，记录下各项服务的启动命令、日志文件路径、正常状态下的资源基线值，做到心里有数。
另外，强烈建议启用基础监控告警，至少覆盖CPU、内存、磁盘和关键接口的可用性。当故障再次发生时，监控数据能直接帮你大幅缩小排查范围。对于每一次故障，养成记录时间、现象和解决方法的习惯，这套排查流程会越来越顺手，网站也会运行得越来越稳。
