网站打不开怎么排查？由外到内逐层定位故障根源
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /a4b390e01684.html
📄
网站突然打不开，或者页面加载慢得让人失去耐心，很多人的第一反应是重启服务器或者刷新几次页面。但这样做往往治标不治本。更要紧的是，网站故障极少是单一原因造成的，从用户浏览器到服务器数据库，中间隔着网络、域名、防火墙、应用服务等多个环节。与其瞎猜，不如按照由外至内、逐层排查的思路，一步步收窄范围，把问题根源找出来，这样恢复速度反而更快。
1. 先从访问入口排查网络与域名解析问题
网站访问不了，先别急着登服务器。第一步应该确认故障到底出在谁身上——是你自己的网络，还是公共的域名解析环节。建议先切换网络做对比测试，比如关掉WiFi用手机流量访问同一网址，或者请不同城市的朋友帮忙打开看看。如果换网络后访问正常，问题基本出在本机缓存或本地网络；如果只有特定地区用户打不开，那大概率是运营商网络波动，或者DNS缓存还没同步。
1.1 核对DNS解析返回的IP地址
在本地电脑打开命令行，用nslookup你的域名或dig你的域名，查看返回的IP地址，再和服务器实际公网IP比对。解析结果为空，或者指向一个很旧的IP，通常是域名A记录被误修改，或是TTL值设置过长导致新记录迟迟不生效。这时候需要登录域名注册商后台，逐一检查解析记录。如果网站用了CDN加速，还要确认回源配置是否正常，因为部分区域的访问异常，往往是CDN边缘节点缓存了过期的源站数据，需要刷新缓存甚至提交工单让CDN运营商协助处理。
1.2 检查端口连通性和安全组放行规则
经常遇到的尴尬情况是：服务器能ping通，但浏览器就是打不开网页。这通常是防火墙或云安全组把Web端口拦住了。如果服务器在阿里云、腾讯云等平台上，登录控制台，查看安全组入方向规则，确认80和443端口已经放行。本地也可以用telnet服务器IP 443这样一条命令测试端口通不通，如果连接超时或者直接被拒绝，基本可以断定是安全策略拦截。若确认云安全组没问题，还需考虑IDC机房是否对特定端口做了额外限制，这时可以临时把服务端口改成8080等非常用端口反向验证，就能判断是不是机房层面的限制。
2. 深入检查服务器资源与运行进程
端口通、域名解析也对，但页面加载极慢或者频繁超时，下一步就要看看服务器是不是已经"累趴"了。CPU长期打满、内存告急、磁盘分区写满、带宽被占尽，任何一种情况都会让新请求在队列里排队等待，用户端感受到的就是卡顿甚至超时。用top查看CPU和内存、free -h查看真实内存余量、df -h查看磁盘占用，这三条命令能快速告诉你资源瓶颈在哪个方向。
2.1 揪出消耗资源的异常进程
在top界面按大写P键，让进程按CPU占用率排序，重点看排在最前面的几个进程是否眼熟。常见的资源大户有这三种：服务器被植入挖矿木马、数据库慢查询不断堆积、或者某个爬虫脚本没做访问频率限制在疯狂抓取。把进程列表和Web访问日志放在一起看，能进一步确认是哪个URL或哪个来源IP引发的。比如某个API接口被外部脚本高频调用，导致PHP-FPM进程数量暴涨，日志里会清楚记录那个IP的每次请求，直接在防火墙封掉这个IP就能快速止损。
2.2 清理磁盘空间与缓解内存压力
磁盘使用率超过80%就应该立刻行动。日志文件、临时上传目录或Session存储目录被写满后，程序没法写入新数据，网站就会直接抛出500错误。建议优先清理过期日志和临时缓存，同时为日志配置按天或按大小轮转的策略，避免单个文件无限增长。内存不足的问题更隐蔽，系统会用Swap分区硬撑，表现为性能断崖式下降。可以查看是否有内存泄漏的Java或Node进程，必要时调整JVM堆内存参数，或者把PHP-FPM的进程管理方式改为按实际并发量动态调整，限制内存占用上限。
3. 聚焦Web服务配置与应用日志
服务器资源和网络都没问题，故障大概率出在Web服务本身，比如Nginx、Apache或者IIS的配置文件被改错，进程意外退出，或者站点目录权限错误导致无法读取文件。此时最重要的是看错误日志，而不是反复重启服务。Nginx的错误日志通常记录在/var/log/nginx/error.log，Apache则在/var/log/apache2/error.log（Debian/Ubuntu）或/var/log/httpd/error_log（CentOS）。日志里通常会有明确的报错信息，比如配置文件语法错误、端口被占用、或访问文件权限不足。
3.1 用配置文件语法检查命令快速定位
改完配置后，不要直接重启服务，先执行语法检查。Nginx用nginx -t，Apache用apachectl configtest或httpd -t，如果配置存在问题，命令会直接告诉你错误出现在第几行。之前遇到过一个线上故障，网站突然全部返回404，排查半天发现是配置里location匹配规则少了一个斜杠，导致所有请求都没匹配到正确的站点目录。这类低级错误，靠眼睛很难发现，但语法检查工具能帮你快速圈定范围。
3.2 查看应用日志判断业务层故障
如果Web服务日志里没有异常，但接口大量报错，就要打开应用层面的日志。比如Java应用看catalina.out，PHP应用看php-fpm.log或框架自带的日志文件。应用日志里往往有完整的堆栈信息，能直接指明是数据库连不上、Redis超时、还是第三方接口调用失败。值得留意的是，要分清哪些错误是故障根因，哪些只是连带反应。比如数据库连接池耗尽，应用日志里可能同时出现大量数据库超时和大量接口500，但根因只有一个，就是连接池配置过小或数据库负载过高。
4. 深入数据层排查数据库与缓存问题
前面所有环节都正常，但页面数据加载不出来，或者部分功能报错，问题很可能在数据库或缓存层。数据库连接数打满、慢查询堆积、主从复制中断，都能让网站呈现出"半瘫痪"状态——首页能打开，但登录、搜索等功能全部异常。
4.1 快速判断数据库是否响应正常
在服务器上直接连数据库执行一条最简单的查询，比如SELECT 1，如果这条命令都卡住或报错，说明数据库本身状态异常。如果数据库能正常连接，再查看show processlist;，看看是否有大量查询处于Locked或Copy to tmp table状态。慢查询日志也是重要线索——开启慢查询日志后，把执行时间超过2秒的SQL语句收集起来，逐一分析索引使用情况。常见情况是一条SQL没走索引导致全表扫描，把数据库CPU跑满，其他所有请求都在排队。解决办法是给相关字段添加普通索引或者复合索引。
4.2 检查Redis等缓存服务的连接与内存策略
很多网站依赖Redis缓存热门数据。如果Redis宕机或者内存满了导致淘汰策略触发频繁，应用会不断回源查数据库，数据库压力陡增，最终拖垮整个系统。检查Redis用redis-cli INFO命令，重点看used_memory和maxmemory的比值。如果内存使用率超过80%，建议排查哪些key占用了大量空间，调整key的过期时间，或者升级内存规格。另一个常见问题是连接数过高，比如connected_clients数值远大于平时，可能是代码里有连接未释放的Bug。
5. 常见问题
5.1 网站间歇性打不开，刷新几次能好，是什么原因？
这通常是负载均衡或CDN层面有多台后端节点，其中某一台节点出现故障或响应超时。请求被轮询到故障节点时访问异常，切换到正常节点时又能打开。建议登录负载均衡控制台，查看后端服务器健康检查状态，把不健康的节点摘除并检查其日志。
5.2 服务器CPU不忙、内存够用，但网站还是慢，问题在哪？
可能是带宽被占满，或者存在外部接口调用超时。用iftop或sar -n DEV 1查看实时网卡流量，确认是否接近带宽上限。另外，如果页面里嵌入了某个第三方统计脚本或外部字体，而对方服务响应慢，浏览器也会一直等待。用浏览器开发者工具的Network面板查看是哪个请求耗时最长。
5.3 电脑能打开公司网站，但手机用流量打不开，是不是被屏蔽了？
不一定。更常见的是手机端DNS解析到了旧IP，或者本地运营商DNS缓存了错误解析结果。建议在手机端把WiFi关闭，仅用流量打开，若依然不行，把手机DNS改为114.114.114.114或223.5.5.5再测试一次。若改完DNS正常，说明是运营商DNS缓存问题，可等待自动更新或在域名服务商适当缩短TTL值。
6. 总结
网站故障排查最大的忌讳就是盲目重启和凭感觉乱试。记住这个顺序：先看访问入口网络和解析，再查服务器资源和端口，然后检查Web服务配置与日志，最后深入数据库和缓存层。每排查一层就排除一类可能，范围就会迅速收窄。建议把本文涉及的排查命令整理成一份自检清单，打印贴在工作台旁。故障发生时按清单逐项走一遍，大多数问题都能在十分钟内定位到根因。
