网站打不开怎么排查？从域名到数据库逐层定位故
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /3a39badd5fbb.html
📄
网站打不开、页面转圈或接口报错，很多人第一反应是刷新几次或重启服务器，但往往治标不治本。正确的做法是顺着用户请求经过的路径，从外到内逐层检查：先看域名解析和网络能不能通，再看服务器资源是否够用，接着查应用与Web服务状态，最后才轮到数据库。按这个顺序排查，能少走很多弯路。
1. 先查网络链路与域名解析是否正常
遇到访问异常，先别急着登录服务器，要判断问题到底出在用户那边还是服务端。最快的方法：用手机流量访问一下网站。如果流量能开、WiFi打不开，多半是本地WiFi路由器缓存或DNS设置有毛病；要是所有人、所有网络都打不开，那问题基本就在服务器或域名配置上。
1.1 核对DNS解析记录与回源地址
在电脑命令行输入nslookup 你的域名，看看解析出来的IP是不是服务器当前用的公网地址。如果返回空结果，或者解析到一个已经不用了的旧IP，说明域名解析记录（A记录或CNAME）改错了。特别注意，DNS修改后全球生效需要时间，别刚改完就断定没生效。另外，如果网站套了CDN，记得去CDN控制台看看节点状态，有些地区打不开可能是某个CDN节点回源失败。
1.2 测试端口连通性与防火墙规则
服务器能ping通，但网页就是打不开，绝大多数情况是端口没放行。云服务器的安全组和服务器内部防火墙（比如firewalld或iptables）都得同时放行80和443端口。本机执行telnet 服务器IP 443，如果超时连不上，基本就是防火墙拦截了。优先去云控制台检查安全组入站规则，再回服务器查本地防火墙配置，别顺序搞反了。
2. 检查服务器负载与资源是否被耗尽
页面响应特别慢、请求大量超时，往往是服务器资源扛不住了。CPU跑满、内存不足、磁盘写满、带宽被占光，任何一个都够让网站瘫痪。登录服务器后，依次跑三条命令：top看CPU和负载，free -h看内存余量，df -h看磁盘使用率。这一套组合拳能快速判断服务器整体健康状况。
2.1 揪出消耗资源的异常进程
在top界面按P键，让进程按CPU占用从高到低排列，重点看前几名都是什么程序。常见的坑有三类：服务器被种了挖矿木马、数据库缺索引导致慢查询堆积、恶意爬虫疯狂刷接口。配合Nginx或Apache的访问日志，能看出来异常请求来自哪些IP、打了哪些路径。比如某个API每秒被调用几百次，直接临时封掉来源IP，或者在上游加个请求频率限制，先把压力降下来。
2.2 警惕磁盘写满和内存交换波动
磁盘使用率超过80%就要警觉了。日志文件、session临时目录如果被写满，应用没法写入缓存，页面常常直接报500错误。优先清理旧日志和临时文件，能快速腾出空间。内存方面，如果free -h显示swap交换区读写很频繁，说明物理内存已经见底，系统一直在内存和磁盘之间来回换页，性能断崖式下跌。这种情况要么加内存，要么先找出哪个应用内存泄漏，重启见效后再彻底处理。
3. 梳理Web服务与应用日志线索
网络通、资源够，但网站依然异常，就得把目光转到应用层。Web服务（Nginx、Apache）和应用框架（比如PHP-FPM、Tomcat、Node.js）是否正常启动，配置有没有被改动，日志里有没有关键报错，这些都要逐一确认。
3.1 对照错误码缩小排查范围
不同HTTP状态码对应的排查方向完全不同：502 Bad Gateway通常是后端服务挂了或超时，重点看PHP-FPM或Tomcat进程；504 Gateway Timeout多半是上游响应太慢，查慢请求和外部接口调用；403 Forbidden检查文件权限或WAF拦截规则；404则看路由配置或伪静态规则有没有丢。根据错误码对症下药，比盲目翻日志高效得多。
3.2 善用访问日志与错误日志对照
把Web访问日志和应用的错误日志放在一起对比看，能发现很多隐藏线索。例如访问日志里某个URL返回500，对应错误日志里往往有具体的异常堆栈或数据库连接失败信息。注意日志的时间戳精度，把时间线对齐，才能准确还原故障发生前后的完整过程。日志量大的时候，用grep配合关键词过滤（比如"ERROR"、"timeout"）能快速锁定问题点。
4. 深入数据库连接与查询性能瓶颈
所有环节都正常，但接口仍然超时或报错，问题很可能出在数据库。数据库连接数被打满、慢查询堆积、死锁频繁，都会让整个应用跟着卡死。
4.1 确认连接数与最大连接限制
如果应用报错提示"Too many connections"或类似的连接数超限，说明数据库连接池太小或连接没有被及时释放。先查数据库当前连接数（MySQL里执行SHOW STATUS LIKE 'Threads_connected'），再对比配置文件里的max_connections上限。临时调大上限能应急，但根本解法是检查应用代码里连接有没有正确关闭，以及连接池参数是否合理。
4.2 定位慢查询与缺失索引
数据库慢查询日志是排查性能问题的重要依据。开启慢查询日志（MySQL设置slow_query_log并设定阈值，比如超过1秒就记录），过一会儿查看记录，找出耗时最长的SQL语句。常见的优化手段包括：给WHERE条件和JOIN字段加索引、避免SELECT *、为高频查询优化表结构。有时一条SQL没走索引，就能拖垮整个数据库，导致所有页面都变慢。检查执行计划（MySQL里用EXPLAIN），确认关键查询是否命中了索引。
5. 常见问题
5.1 网站间歇性打不开，一会儿好一会儿坏，是什么原因？
这种"时好时坏"的情况，优先怀疑两类原因：一是服务器资源接近临界值，比如内存或CPU偶尔被占满，导致请求随机超时；二是数据库连接数在高峰时段被耗尽，低谷时又恢复正常。建议持续监控资源曲线和错误日志，找出规律性的触发条件。
5.2 换了新服务器后，网站就访问不了，怎么处理？
换服务器后访问不了，九成是域名解析还指向旧IP。先确认新服务器IP，再检查域名管理后台的A记录是否已更新，同时注意DNS缓存和生效时间。另外别忽略新服务器的安全组和防火墙，很多新机器默认没放行80/443端口，刚开机的服务器一定要先把端口规则配置好。
5.3 重启服务器后网站恢复正常，但过几天又出问题，如何根治？
重启只能暂时缓解症状，掩盖不了根本问题。常见根源包括：应用存在内存泄漏，进程长时间运行后占用内存持续攀升；日志文件或临时目录不断膨胀，最终写满磁盘；某些脚本或定时任务会逐渐耗尽资源。建议搭建基础监控（比如使用crontab配合简单脚本记录CPU、内存、磁盘），把故障发生前的资源数据留存下来，才能找到真正的元凶。
6. 结语
网站无法访问的排查，核心思路是"由外到内、层层排除"：先确认网络和DNS通不通，再检查服务器资源是否够用，然后审查Web服务和应用日志，最后深入数据库层面找原因。建议平时把常用的排查命令和服务器配置变更记录整理成文档，故障发生时能节省大量时间。遇到问题先冷静定位，不要盲目重启，找到根源才能真正解决问题。
