网站打不开？按请求链路从网络到数据库逐层排查
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /6dbdef6ab7d5.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. 深入应用层：进程存活不代表服务可用
资源指标正常、端口也在监听，但网站依然报错，这时需要将注意力转向应用本身。进程在线只能说明程序未被杀掉，接口是否能正常响应则需要进一步验证。先查看Web服务的错误日志，比如Nginx的error.log或Tomcat的catalina.out，通常能直接找到异常堆栈或提示信息。同时，检查应用依赖的中间件是否正常，包括Redis、消息队列等服务的连接状态，很多隐性故障就藏在这些关联组件中。
3.1 验证应用依赖的服务是否就绪
一个常见的排查手段是直接在服务器上执行curl -I http://127.0.0.1，看本机访问能否返回正常状态码。如果本机访问返回200，而外部访问失败，问题多半在网络层；如果本机也报错，则问题出在应用或依赖组件上。依次确认数据库连接池是否耗尽、外部接口的调用超时设置是否过短，这些都是影响应用稳定性的常见因素。
4. 最后排查数据层：数据库是网站的心脏
当应用层日志无明显异常，但页面交互频繁报错时，就要把目光投向数据库。数据库连接数被打满、慢查询堆积、主从延迟过大或磁盘空间不足，都可能导致网站无法正常读写数据。登录数据库执行show processlist;，查看当前正在运行的会话状态，重点观察是否有大量State为Copy to tmp table或Sending data的查询。
4.1 识别慢查询与连接数瓶颈
开启数据库的慢查询日志，观察执行时间超过阈值的SQL语句。常见的诱因包括：未建索引的大表全扫描、一次查询关联过多数据表、统计类SQL在业务高峰期运行等。此外，检查当前连接数与max_connections上限之间的差距，如果连接数长期逼近上限，说明应用层存在连接泄漏，需要检查代码中的连接管理逻辑。一个实用的避坑建议是：对核心查询表定期执行EXPLAIN分析执行计划，发现全表扫描后及时补充复合索引。
4.2 关注主从同步与锁等待
如果架构采用了主从复制，务必检查从库的同步状态。主库压力过大或binlog堆积，都会让从库落后主库大量数据，导致应用读取到过期数据或直接超时。另外，数据库的锁等待也是隐蔽故障源，一个长时间未提交的事务可能阻塞大批后续操作，此时可在processlist中看到大量Waiting for table metadata lock的会话，需要找到源头事务并酌情终止。
5. 常见问题
5.1 网站打不开，先重启服务器有用吗
草率重启往往治标不治本，还可能让故障现场消失。某些临时性问题重启后确实恢复了，但资源耗尽类故障通常会在短时间内复发。正确的做法是先按上述层级做基础排查，收集必要的日志和监控数据，再决定是否需要重启。
5.2 为什么手机能访问，电脑却打不开网站
多数情况下是本地DNS缓存或路由器设置出了问题。手机通常走运营商DNS，而电脑可能使用了自定义DNS或受本地hosts文件影响。建议在电脑上执行ipconfig /flushdns清空DNS缓存，并检查hosts文件中是否有该域名的旧映射记录。
5.3 只能通过IP访问，域名打不开是怎么回事
这种现象高度指向域名解析配置异常。先确认域名注册商处的解析记录是否还在且指向正确，再检查ICP备案是否处于正常状态，备案被取消会导致域名无法解析到国内服务器。若域名有使用于CDN，同时要排除CDN平台侧的调度异常。
6. 结语
网站故障排查没有神秘捷径，核心在于遵循用户请求的完整链路逐层筛查，并维护好各环节的日志与监控数据。建议在日常运维中提前做好三件事：为服务器和数据库配置基础告警、定期检查磁盘和连接数余量、对慢查询保持常态化治理。养成这些习惯后，即使网站突然打不开，你也能从容地按顺序缩小范围，快速恢复服务。
