网站打不开怎么排查？一套完整的故障定位流
📱 Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko; compatible; ClaudeBot/1.0; +claudebot@anthropic.com)
🔗 /264cab565bda.html
📄
网站突然无法访问，用户反馈接踵而至，这时候最忌讳的就是手忙脚乱地重启服务器。访问异常的原因可能分布在域名解析、网络链路、服务器资源乃至数据库等不同环节。掌握一套有序的排查方法，按顺序缩小范围，才能快速定位问题根源并恢复服务，将对业务的影响控制在最小范围。
1. 先区分问题范围与网络链路
在登录服务器之前，先花一分钟判断故障影响面。是所有人都无法访问，还是仅仅个别用户或特定地区用户打不开？自己的设备遇到问题时，建议先切换网络环境测试，比如关闭Wi-Fi改用手机热点访问，就能立刻区分是本地网络问题还是网站本身故障。如果只有某个区域的用户访问失败，则要重点怀疑CDN节点调度或运营商路由线路。
1.1 核对域名解析结果
域名解析是整个访问链路的第一步，也常是故障源头。打开电脑的命令行工具，输入nslookup 你的域名或ping 你的域名，记录解析出的IP地址，再与服务器实际公网IP进行比对。如果解析结果指向已废弃的旧IP、错误地址或长时间无响应，问题就出在DNS配置上。登录域名管理后台检查A记录、CNAME记录是否填写正确，同时确认最近是否有过生效中的解析变更。若网站接入了CDN，还需登录CDN控制台查看加速节点是否出现异常或回源失败。
1.2 测试服务器端口连通性
当域名解析正确但仍连接失败时，需要验证端口是否真正开放。在命令行中尝试telnet 服务器IP 80或telnet 服务器IP 443，如果连接被拒绝或直接超时，大概率是防火墙或安全组拦截了外部请求。此时应前往云服务商控制台，检查安全组的入方向规则是否放行80和443端口，同时登录服务器内部核查iptables或firewalld的配置，确保没有本地规则将流量挡在门外。
2. 查看服务器资源占用和进程状态
网站响应缓慢、页面时好时坏，往往与服务器资源瓶颈有关。当CPU占用持续饱满、内存耗尽、磁盘写入失败或带宽跑满时，新请求便无法获得正常处理。通过SSH登录服务器，分别执行top、free -m、df -h这三条命令，即可快速了解当前CPU、内存和磁盘的使用概况。
2.1 定位高耗资源的异常进程
在top命令界面按下大写P键，进程将按照CPU占用率自动降序排列，异常占用者一目了然。高CPU或高内存的常见成因包括：服务器被植入挖矿程序、数据库因缺少索引导致全表扫描、某接口被恶意爬虫高频请求。此时建议结合Web访问日志，筛选出访问频次异常高的IP或请求路径，确定问题请求的具体来源。
2.2 处理磁盘和内存告急情况
磁盘使用率超过80%时就需要立即介入处理。Web日志、系统临时文件和过往的备份包是占用空间的大户，它们会写满磁盘，导致程序无法生成缓存或会话文件，网站随即抛出500错误。建议为日志目录配置轮转策略，并定期清理无效的旧备份。内存方面则需留意Swap分区变化，如果swap占用持续攀升，说明物理内存已无法满足业务需求，需要排查应用是否存在内存泄漏，并适当调整PHP-FPM进程数或Java虚拟机堆大小等参数。
3. 检查数据库连接与服务状态
许多应用意外崩溃，根源并不在应用代码，而是出在数据库这一层。当页面出现“数据库连接失败”或抛出相关异常时，排查的重点应放在数据库服务是否存活以及连接参数是否正确。
3.1 确认数据库服务运行情况
使用systemctl status（适用于systemd系统）或ps aux | grep mysql（适用于MySQL类数据库）来判断数据库进程是否健康运行。若进程已退出，查看数据库的错误日志通常能定位到崩溃原因，比如磁盘空间不足、数据文件损坏或内存分配失败。数据库正常启动后，需检查对应的端口监听状态，确保它在本机或内网地址上正常开放。
3.2 核查应用连接配置与连接数上限
数据库服务本身正常，但程序仍无法连接时，就要审视应用侧的配置。检查数据库连接串、用户名密码以及主机地址是否正确，很多故障其实是配置变更后地址写错或密码未同步更新造成的。另外，当连接数达到数据库实例的最大限制时，新的连接请求也会被拒绝，可通过SHOW STATUS LIKE 'Threads_connected'查看当前连接数，结合max_connections参数判断是否接近上限。常见做法是适当调大连接数上限，并检查应用是否有连接泄漏或连接池设置不合理的问题。
4. 排查应用日志与Web服务状态
前几步没有发现问题，故障点很可能落在应用本身或Web服务层。访问日志和错误日志是此阶段最直接的线索来源。
4.1 分析错误日志定位故障点
查看Web服务（如Nginx或Apache）的错误日志，通常位于/var/log/nginx/error.log等路径。重点寻找近期出现的500、502或504状态码。502往往指向PHP进程或后端服务无响应，504则说明网关等待上游响应超时。结合具体错误信息，可以进一步确认是PHP-FPM进程池耗尽、代码执行超时，还是某个上游接口调用卡死。通过加装慢日志记录，还能捕捉到执行时间过长的SQL查询，针对性优化效率低下语句。
4.2 验证Web服务是否正常监听端口
通过ss -lntp或netstat -lntp确认Nginx或Apache是否在80和443端口正常监听。如果端口处于监听状态但页面仍报错，则尝试直接访问本机http://127.0.0.1，借此判断问题是否存在于反向代理转发或防火墙规则中。同时不要忽视SELinux的拦截，在CentOS等系统中，SELinux策略可能阻止Nginx访问后端服务或写入文件目录，通过检查审计日志或临时调整SELinux模式可以快速验证。
5. 常见问题
5.1 网站间歇性打不开，重启后又恢复，这是怎么回事？
这种情况多半指向服务器资源耗尽或应用内存泄漏。可能是PHP-FPM进程数达到上限无法处理新请求，或数据库连接数被占满。建议在问题发生时捕捉top和free -m的输出，对比正常时段的数据，同时检查错误日志中是否集中出现特定时间段的报错，通常能锁定具体是哪个服务扛不住压力。
5.2 DNS解析没有错误，但手机和电脑都打不开网站，下一步怎么办？
如果解析和端口连通性都没有问题，请直接检查服务器本身的负载情况。CPU和内存利用率的瞬时飙升、磁盘写入失败都可能导致服务暂时卡死。此外，检查云平台控制台是否存在安全组变更或带宽限速等操作记录，偶尔的配置调整也会造成整站不可访问。
5.3 网站能打开，但常常出现502或504错误，应该优先排查哪里？
502和504都指向反向代理与后端服务之间的沟通问题。先从后端服务的状态查起，确认PHP-FPM或Java应用是否存活，再查看代理到上游的超时设置是否过短。如果后端进程频繁崩溃，重点检查自身的最大请求数和内存限制，必要时适当调高配置并观察错误日志中的崩溃原因。
6. 总结
网站访问异常虽然令人焦虑，但只要遵循清晰的排查顺序，通常能在短时间内定位问题。当异常发生时，建议先判断影响范围，再依次排查域名解析、端口连通性、服务器资源、数据库状态和应用日志，每一步都做好记录，避免重复操作。平时为服务器配置监控告警、为日志建立定期轮转机制，并保持关键配置的文档备份，这样即便故障再次出现，也能参照固定的流程迅速处理，不至于每次都从零开始。
