网站打不开的排查步骤：按请求链路逐层定位故障点
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /9024fd293643.html
📄
网站突然打不开，很多人第一反应是刷新页面或者直接重启服务器，但这样做往往治标不治本。更高效的办法是按用户请求从浏览器到服务器再到数据库的完整流转路径，逐层排查。这套从外到内的定位思路，能帮你快速判断故障到底出在哪个环节，避免做无用功。
1. 先查网络层：域名解析和链路是否顺畅
发现网站无法访问，先别急着登录服务器。首要任务是区分问题出在用户端还是服务端。最简单的验证方法是切换网络环境，比如用手机流量访问。如果流量下访问正常，多半是本地路由器缓存或DNS设置有误；如果只有特定地区或某运营商用户打不开，则要考虑链路拥堵或域名解析尚未在全球生效。
1.1 核对域名解析记录
在电脑命令行输入nslookup 你的域名，检查返回的IP是否与服务器当前实际公网地址一致。若解析为空或指向旧IP，说明域名管理后台的A记录或CNAME配置有误。注意修改DNS后存在生效延迟，通常需数分钟至数小时。若网站启用了CDN，还需登录CDN控制台检查节点状态，不少故障源于回源失败。
1.2 测试端口连通性与防火墙规则
服务器能ping通但网页打不开，大概率是端口被拦截。需同时确认云服务商安全组规则和服务器本地防火墙是否放行80及443端口。本地执行telnet 服务器IP 443，若连接超时，基本可判定防火墙拦截。此时应先去云控制台检查安全组入方向规则，再回服务器查看iptables或firewalld配置，顺序不可颠倒。
2. 再看服务器层：资源耗尽往往拖垮一切
页面响应极慢或请求大面积超时，通常与服务器资源被耗尽有关。CPU持续满载、内存不足、磁盘空间告急或带宽被占满，都会导致服务响应异常。登录服务器后，依次执行top、free -h、df -h三条命令，即可快速掌握系统负载、内存余量和磁盘占用概况。
2.1 定位消耗资源的异常进程
在top界面按下P键，按CPU占用率排序进程，查看排名靠前的程序。常见资源消耗源包括：服务器被入侵植入的挖矿程序、数据库缺少索引导致的慢查询堆积，以及恶意爬虫的频繁抓取。配合查看Nginx或Apache访问日志，确认异常请求的来源IP和URL。例如发现某接口每秒被请求数百次，可临时封禁来源IP或增加频率限制，压力通常能迅速缓解。
2.2 警惕磁盘写满与swap过度使用
磁盘使用率超过80%就需警惕。会话文件、运行日志或临时目录一旦写满，应用无法正常写入缓存，网站常直接返回500错误。清理过期日志和临时文件通常即可释放空间。内存方面，若free -h显示swap分区读写频繁，说明物理内存严重不足，系统不断在内存与磁盘间换页，性能大幅下降。此时应优先优化应用内存开销，或考虑扩容配置。
3. 接着查应用层：进程存活不代表业务正常
资源充足、端口开放，但网站仍报错，就需要聚焦应用本身了。进程存在不代表功能正常，比如Nginx和PHP-FPM都在运行，但PHP-FPM的工作进程可能已全部阻塞。查看nginx -t验证配置语法，检查PHP-FPM的slow log定位卡顿脚本，这些都能帮助判断应用层异常。
3.1 检查服务进程状态与日志
使用systemctl status nginx或ps aux | grep php-fpm确认服务是否为running状态。若处于failed，可尝试启动并查看错误日志，如tail -f /var/log/nginx/error.log。常见问题包括配置文件语法错误、端口被复用、启动用户权限不足等。发现报错后按提示修正，再平滑重启服务。
3.2 查看应用日志定位报错代码
应用层故障最直接的线索在日志中。以PHP项目为例，查看runtime/log下的日志文件，往往能看到具体的异常信息或堆栈。例如出现"SQLSTATE[HY000]"通常指数据库连接失败，需转向数据库层排查。日志中若频繁出现某个接口的超时记录，也需要单独分析该接口的代码实现。
4. 最后查数据层：慢查询与连接数超限
网络、服务器、应用都正常，但页面仍无法加载或数据不显示，问题很可能出在数据库。数据库连接数耗尽、慢查询阻塞，或表损坏都会导致查询超时，进而拖垮整个网站。此时需要登录数据库进行专项检查。
4.1 检查数据库连接数与进程列表
执行show processlist;查看当前数据库连接状态。若大量连接处于Sleep状态，说明连接池配置过高或应用未及时释放连接；若有多个查询状态为Locked，则可能因慢SQL持锁过长。临时方案是kill掉异常进程，根本解决需优化SQL语句或增加索引。
4.2 排查慢查询与表结构问题
开启慢查询日志，例如在MySQL中设置set global slow_query_log=on;，记录执行时间超过阈值的SQL。许多网站故障来自未加索引的全表扫描，或复杂联合查询。建议为高频查询字段添加索引，并定期使用check table检查表健康状态，修复可能损坏的InnoDB表。
5. 常见问题
5.1 网站前一天还能访问，今天突然打不开了，大概率是什么原因？
优先怀疑三个方向：一是域名到期未续费或DNS配置被修改；二是服务器因资源耗尽（如磁盘写满）自动宕机；三是云服务商安全策略变更，拦截了入站流量。按网络层-服务器层顺序排查，通常能快速定位。
5.2 网站在本地打不开，换手机流量却正常，是什么情况？
这种现象基本确定为本地网络问题，常见原因是本地路由器DNS缓存了旧的解析结果。可尝试清空DNS缓存（Windows执行ipconfig/flushdns），或在路由器设置中更换公共DNS如114.114.114.114。若仍然无效，考虑宽带运营商存在临时劫持或链路故障。
5.3 重启服务器后网站恢复了，但几天后再次故障，如何根治？
重启只是暂时释放了被占用的资源，根本原因未消除。应利用故障期间留下的系统日志和监控数据，分析资源消耗峰值来自哪些进程或访问请求。若为恶意爬虫，可配置访问频率限制；若为代码内存泄漏，需修复代码逻辑；若为磁盘日志增长过快，则设置日志轮转策略。
6. 总结
系统化的排查路线按三个顺序展开：先网络后服务器、先资源后应用、先进程后数据库。无论故障表象如何，保持从外到内、从粗到细的思路，逐步缩小范围，绝大多数网站打不开的问题都能在较短时间定位。建议日常做好基础监控，比如磁盘使用率、CPU负载、数据库慢查询数的告警，很多故障在用户感知前就能提前发现并解决。遇到问题时不慌不重启，按路径排查才是最高效的处理方式。
