网站打不开怎么排查？从网络到代码的故障定位全流程
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6a001b005b35.html
📄
网站出现白屏、加载超时或直接无法访问时，盲目刷新页面或重启服务往往收效甚微。更高效的做法是沿着网络、服务器、应用、数据库这条链路逐层排查，每一步都用命令或日志来确定问题是否出在某一层，从而迅速缩小范围，减少业务中断带来的损失。
1. 从用户侧与网络链路开始筛查
访问异常未必是服务器的责任。在动手检查服务器之前，先要区分是普遍故障还是个例。让同事在不同网络环境下访问，或直接用手机4G/5G流量试一次，会得到很有价值的判断依据。如果换网络后访问恢复正常，基本可以锁定是本地网络、路由器或设备DNS缓存引发了问题。而如果只有特定地区访问失败，则要考虑运营商线路或CDN节点异常。
1.1 验证域名解析结果
在本地命令行执行nslookup 你的域名或dig 你的域名，比ping命令能提供更准确的解析详情。重点确认返回的A记录或CNAME是否指向当前服务器IP。若解析结果仍为旧地址，说明修改后尚未全球生效，或TTL缓存时间过长；若返回空记录，则需登录域名服务商后台检查记录是否被误删或暂停。使用nslookup 你的域名 8.8.8.8还能对比不同DNS服务器的解析一致性，判断是否存在解析污染。
1.2 检查端口连通与安全策略
域名解析正常但仍打不开网页，下一步要测试端口的连通性。在命令行执行telnet 你的服务器IP 80或telnet 你的服务器IP 443，能顺利连接则端口通畅。若提示连接超时或被拒绝，需要检查云服务商控制台的安全组是否放行了对应端口，同时确认服务器系统防火墙（如ufw、firewalld）没有拒绝入站请求。许多宕机事故的根源就是安全组在配置调整时意外移除了HTTP规则。
2. 排查服务器资源与运行状态
排除网络因素后，将注意力转向服务器本身。CPU跑满、内存耗尽或磁盘空间为零，都会让Web服务拒绝新请求，表现为长时间无响应或通过负载均衡返回502状态码。登录服务器后，依次执行uptime、free -h、df -h三组命令，可以快速掌握系统负载、内存余量和磁盘使用率这三项核心指标。
2.1 梳理占用资源的主要进程
执行top并按CPU列排序，能直接看到消耗最高的进程名称和PID。常见的异常情况包括：被入侵后植入的挖矿进程伪装为系统服务名、数据库查询缺少索引导致CPU持续满载、日志切割脚本失效令单进程内存失控。借助lsof -p PID查看该进程打开的文件与网络连接，可以进一步确认它是否属于正常业务组件，必要时直接kill后再观察资源是否回落。
2.2 留意磁盘与内存的连锁影响
磁盘使用率超过85%是危险信号。日志文件、临时目录或上传目录写满后，应用无法写会话或缓存，网站会大面积报500错误。此时清理两周前的Nginx和PHP日志往往能立刻缓解。内存方面，可以用cat /proc/meminfo | grep SwapTotal确认swap配置，用free -h观察swap使用量。若swap长期处于高占用，说明物理内存已明显不足，与其反复重启服务，不如考虑增加内存容量或限制工作进程数。
3. 深入应用层查看错误日志
服务器资源充裕、端口正常，页面却白屏或部分功能报错，问题就出在应用代码层面。开启浏览器开发者工具，切换至Network标签页并刷新页面，先看主请求的HTTP状态码。500代表服务器执行代码时抛出未捕获异常，502多是网关与后端通信失败，504则是上游服务响应耗时超过阈值。结合这些状态码，再到应用日志目录中寻找具体堆栈信息，例如PHP项目的runtime/logs目录，或Node.js项目通过PM2管理的日志输出，按时间倒序查看最近的ERROR级别记录，定位报错文件与行号。
如果日志中同时出现大量数据库连接超时的错误，那么瓶颈可能并不在前端代码，而在数据层。登录数据库客户端执行SHOW PROCESSLIST;查看当前活跃查询，关注长时间处于Locked或Sending data状态的会话。优化措施包括：为高频查询的字段补充索引、用缓存（如Redis）分担读压力、在业务低峰期重建碎片化严重的表。实际操作中，一个缺少索引的订单查询可能拖垮整个业务库，而加上复合索引后，接口响应时间能从数秒降到毫秒级。
4. 验证Web服务与PHP的配置细节
代码正常、数据库正常，但网站依然异常，就要检查Web服务器和语言运行时的配置。Nginx的error.log里会出现常见的配置类报错，比如worker_connections are not enough，这说明并发连接数设置过低，需要调大事件模块中的worker_connections参数；而站点配置中缺少index index.php指令，会导致访问根路径时直接返回403或目录列表。对于PHP-FPM环境，执行php-fpm -t可先行验证配置语法，确认无误后再平滑重启。
另一个容易踩坑的地方是伪静态规则。启用URL重写后若忘记在Nginx配置中加入对应location规则，会导致所有二级页面全部404。判断方法是：访问首页正常，访问任意内页报404，且页面指向的是默认404页面而非框架自定义错误页，此时需对比网站根目录下与配置中的rewrite规则是否一致。养成每次修改配置后先备份再刷新的习惯，能避免因笔误让新配置在重启时直接生效并拖垮站点。
5. 常见问题
5.1 网站报502 Bad Gateway通常是什么原因？
502表示网关收到了无效响应，常见诱因是PHP-FPM进程池已满、后端服务意外崩溃或FastCGI超时时间设置过短。先重启PHP-FPM服务观察是否恢复，再检查php-fpm日志确认进程退出原因。若并发量较高，可适当调大pm.max_children和request_terminate_timeout参数。
5.2 HTTPS站点能打开但HTTP无法访问怎么办？
优先检查Web服务器配置中是否将80端口请求强制重定向到了443端口。另外确认安全组是否同时放行了80和443两个入方向端口。有些云厂商的备案要求会拦截未备案域名的80端口访问，此时仅限443访问，需要核实域名备案状态。
5.3 网站间歇性打不开，过几分钟又恢复正常，这是为何？
间歇性故障多半指向资源周期性耗尽或定时任务冲突。观察每次故障发生时的时间点，检查是否有cron任务在整点运行大型批处理；也可以查看监控图表，看CPU或内存是否在故障时段出现尖峰。数据库连接池耗尽也可能造成同样现象，需要调整连接数上限并增加连接复用。
6. 结语
网站故障排查的关键在于把问题分层处理，而不是在东奔西跑中浪费时间。建议平时就建立一套运维文档，记录服务器IP、安全组规则、日志路径和常用命令。排查时按照网络、资源、应用、数据、配置的顺序逐项验证，每一步留下明确的判断记录。为了减少下一次故障的排查时间，可以在服务器上部署简单的资源监控脚本，当CPU超85%或磁盘空间低于10%时自动发送告警，做到未雨绸缪。
