网站出现ServiceUnavailable是什么原因

你打开网页突然看到Service Unavailable，浏览器里通常跟着503状态码，意思不是域名没了，也不是你网络断了，而是请求已经到达服务器或反向代理，但后端暂时没法把内容交出来。它和404不一样，404是页面不存在，503更像“人还在，但忙不过来或正在缓一口气”。这个提示可能只闪几秒，也可能持续很久，背后原因差别很大。

最常见的一类，是服务器资源被吃满了。比如CPU长时间跑满、内存不够用、磁盘写满，或者文件句柄耗尽。Web服务本身没死，但已经没法处理新请求，反向代理一探活失败，就直接回503。磁盘满特别容易被忽略，日志写不进去、临时文件创建不了、数据库也起不来，表面看是网站打不开，根子却在存储。还有inode用尽，磁盘看着有空间，实际一个文件都建不了。

第二类常见情况是后端应用或进程池扛不住。Nginx、Apache这类反向代理前面收请求，后面交给PHP-FPM、Java应用、Node服务或Python进程处理。如果PHP-FPM的pm.max_children设得偏小，流量一上来子进程全占满，新请求排队超时，Nginx就会返回503。Java应用线程池满、数据库连接池满、容器里OOMKilled，也会让健康检查连续失败，负载均衡把实例摘掉，用户看到的就是服务不可用。数据库慢查询把连接占住，应用看起来还在，实际每个请求都卡在等连接，这种503往往伴随接口超时和日志里的连接池告警。

发布和维护也会造成短时503。代码上线时重启应用、滚动更新时旧实例已停新实例没就绪、配置改错监听端口、健康检查路径写错，都会让流量打到没有准备好的后端。有些站点在维护窗口主动返回503，并带上Retry-After头，告诉搜索引擎和客户端过多久再来，这是正常做法。但如果是配置失误，比如upstream地址写错、SSL证书过期、容器启动命令失败，503就会一直挂着，直到有人发现。

流量突增和攻击也不能忽视。促销活动、热点新闻、爬虫集中抓取，或者CC攻击，都会在短时间内把并发拉高。云服务器自动扩容需要时间，新实例启动、镜像拉取、健康检查通过都要几十秒到几分钟，这期间容量不够，503就会出现。限流和WAF规则配得太严，也可能把正常用户误伤成503。还有CDN回源失败、源站防火墙拦截回源IP、负载均衡健康检查被安全组挡住，都会让边缘节点拿不到内容。

依赖服务出问题同样会传导过来。网站自身没崩，但调用的支付、短信、对象存储、第三方API超时，应用线程被拖住，最后自己也没法响应。缓存层故障更典型，Redis连不上，应用每次都回源数据库，数据库瞬间被压垮，503跟着来。消息队列堆积、定时任务卡死、锁没释放，也会让某些接口长时间不可用。

排查时别只盯着首页。先看503是全局还是某个接口，看看响应头有没有Retry-After，查负载均衡和后端实例的健康状态。再看服务器监控里的CPU、内存、磁盘、连接数，重点看故障前十分钟的变化。应用日志找OOM、连接池耗尽、超时、启动失败；反向代理日志看upstream timeout、connect refused、no live upstreams。最近有没有发布、改配置、扩缩容、证书到期，也要对一遍。数据库慢查询和锁等待、缓存命中率、第三方调用耗时，往往能解释“服务器看着正常但就是503”。

处理上，临时可以重启异常实例、扩容、摘掉坏节点、调大进程池和连接池，但别把参数一改了事。进程池调大要配合内存，连接池调大要配合数据库承载，否则只是把故障往后推。长期还是要把健康检查做准，给静态页和关键接口做降级，设置合理的限流和超时，监控磁盘和inode，发布时保留旧实例直到新实例真正就绪。Service Unavailable不是单一故障，它更像一个信号：前端还能连上，后端已经接不住了。顺着链路从负载均衡、反向代理、应用、数据库一层层看，通常比反复刷新页面有用得多。