网站打不开怎么办？从网络到数据库的排查顺序清单
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /696d4104da42.html
📄
遇到网站突然变慢或完全无法访问时，与其反复刷新页面、重启服务器，不如沿着一条清晰的路径逐层检查。用户访问网站的完整链路，是从浏览器发出请求，经过域名解析、网络传输，到达服务器系统，再进入应用代码，最后才落到数据库。按照这个顺序从外往里检查，能快速把故障范围缩小到某一个具体环节，减少无效操作。
1. 先分辨网络与域名解析是否正常
不要急着登录服务器，先判断问题出在客户端环境还是域名解析环节。最简单的办法是切换网络做对比：把办公Wi-Fi换成手机热点，或者请不同地区的同事同时访问同一个网址。如果只有你自己的网络打不开，而别人的网络访问正常，那基本可以排除服务器端问题，重点检查本地路由器或运营商线路。
1.1 核对域名解析出的IP是否准确
在本地命令行执行nslookup 你的域名或dig 你的域名，查看解析结果里的IP地址，再和服务器实际的公网IP比对。如果发现解析出的IP是旧地址、空值或者指向了不相关的服务器，说明域名记录被误改或DNS缓存出了问题。此时应登录域名注册商后台，逐条核对A记录、CNAME记录，同时留意CDN的CNAME指向是否有变化。如果只有部分地区打不开，多半是TTL设置太长，各地DNS节点还在使用旧缓存，耐心等待全球生效即可。
1.2 验证端口能否正常连通
另一种常见情况是域名能解析、ping也通，但浏览器就是打不开网页。这时很可能被防火墙或安全组拦截了端口。在命令行输入telnet 服务器IP 80或telnet 服务器IP 443，若提示无法连接或超时，就去云服务商控制台检查安全组的入方向规则，确保HTTP端口（80）和HTTPS端口（443）已经放行。某些企业网络或运营商也会屏蔽非标准端口，遇到这种问题换个网络测试，或改用443端口访问，往往能快速确认。
2. 登录服务器检查系统资源消耗
网络链路通畅但请求到达服务器后迟迟没有响应，就要把关注点放到系统资源上。CPU长时间满载、内存耗尽、磁盘写满或带宽被打满，都会让请求在队列里排队，最终表现为页面加载极慢或直接超时。登录服务器后，第一时间查看整体负载情况，再定位具体进程。
2.1 用top命令找出谁在消耗CPU
执行top并按大写P键让进程按CPU占用率排序，看看排在最前面的是哪些程序。除了业务进程本身，常见的高占用罪魁祸首有三类：被植入的挖矿程序、恶意采集爬虫、以及执行效率极差的数据库查询。判断进程身份时可以配合Web服务器访问日志，搜索同一来源IP的请求频率。比如发现某个IP每分钟请求数百次登录接口，日志里必然有大量记录，直接在防火墙层封禁该IP即可。
2.2 关注磁盘剩余空间和交换分区
磁盘使用率超过80%就应该警惕，超过90%则风险极高。日志文件、临时目录、Session文件被写满后，网站将无法创建任何新文件，前端会集中报500错误。养成定期清理过期日志的习惯，并单独为/var/log这样的目录划分独立分区，能有效防止满盘拖垮整个服务。内存方面，执行free -h查看，如果swap持续被大量占用，说明物理内存已经供不应求，此时要么升级内存配置，要么从应用代码上减少内存占用。
3. 查看应用日志与进程运行状态
确认服务器资源充足之后，排查焦点就转移到应用自身。登录Web服务所在机器，先查看应用进程是否存在、是否处于异常退出状态，随后打开应用的运行日志检索错误堆栈。多数情况下，一条明确的异常信息就能直接指明故障位置，比如文件权限不足、依赖组件缺失、接口超时等，比盲目修改配置有效得多。
如果日志里的报错不明确，可以考虑临时调高日志级别，把SQL执行记录、每个接口的响应耗时、以及调用第三方服务的日志都打印出来。通过比对耗时分布，很快就能定位到究竟是哪个外部调用拖慢了整体响应。典型的案例是，某个页面本身处理很快，但每次都同步调用一个响应耗时5秒的外部支付查询接口，整个页面的加载时间自然被拉长。
4. 检查数据库连接与慢查询记录
应用日志一切正常，但接口依然超时，此时要考虑数据库层面的问题。首先确认数据库连接数是否已满——很多报错信息里会出现类似“too many connections”的字样，这说明应用创建的连接没有被正确释放。一方面要检查数据库的最大连接数配置，另一方面要核查应用代码是否有连接池泄漏。另一个常见瓶颈是慢查询，大量耗时数秒的SQL语句长期占用数据库资源，让正常请求也排不上队。
开启数据库的慢查询日志，把执行时间超过1秒的语句全部记录下来。逐一分析这些慢语句，看看是否缺少索引、查询条件是否写法不当，或者表数据量是否已经庞大到需要分表。一个真实案例是，某列表页查询时对日期字段使用LIKE '%2024%'这样的写法，导致全表扫描，加上索引后查询耗时从2秒降到了50毫秒。优化SQL往往比盲目加服务器配置成本更低、效果更持久。
5. 常见问题
5.1 网站打不开时，应该先重启服务器吗？
不建议第一时间重启服务器。重启虽然能暂时释放资源、结束异常进程，但根本原因没有消除，故障很快还会重演。正确做法是先按网络、系统、应用、数据库的顺序逐层排查，找到真正的触发点再动手处理。
5.2 ping通就代表网络没问题吗？
不是。ping使用的是ICMP协议，而网页访问依赖TCP协议的80或443端口。很多服务器出于安全策略会禁ping，但网页访问正常；反之，ping通了也不代表端口一定开放。判断网络是否通畅，要用telnet或curl测试具体端口才可靠。
5.3 排查了所有环节还是找不到原因怎么办？
如果上面所有环节都检查过仍然没有结论，可以尝试在访问链路的关键节点采集抓包数据，例如用tcpdump在服务器网卡上抓取80端口的流量，查看请求是否到达服务器、应答是否正常返回。这一步能确认问题是否出在公网传输链路上，必要时联系云服务商或运营商协助核查。
6. 总结
网站故障排查，核心思路就是沿着用户请求的完整链路，从最外层的网络解析开始，逐步向内检查服务器资源、应用代码和数据库状态。按照这套顺序操作，每一步都有明确的判断标准，既不会漏掉关键环节，也避免在无效方向上反复折腾。建议把这份排查清单保存下来，在遇到实际故障时按步骤执行，并养成记录每次故障原因和处理过程的习惯，长期积累下来，你处理同类问题的速度会越来越快。
