404 的意思是“这里没有内容”，5xx 的意思是“我现在处理不了”。对访客来说，前者还能退回上一页换个入口，后者只能看到一个空白或错误提示；对搜索引擎蜘蛛来说，反复撞上 5xx 的地址，抓取节奏会被打乱，原本稳定的访问时间表也会变得不确定。所以 5xx 值得从站点运营的角度单独盯一条线。
先分清是全局故障还是局部故障
打开监控面板之前，先做一个简单判断：同一时间，首页、列表页、详情页、接口地址分别返回什么状态码。如果全部 5xx，多半是服务进程、数据库连接或网关层面的问题；如果只有某一类页面 5xx，通常和该页面的模板、查询语句或依赖的第三方接口有关。这个判断能省掉大量排查时间。
常见来源与对应自查点
数据库连接数与慢查询
连接池被占满是 5xx 的常见原因。自查时看三个数：连接池上限、峰值并发连接数、慢查询日志里持续超过阈值的语句。列表页或标签聚合页如果没有走缓存，一条没有索引的查询就足以拖住整条链路。
后端进程与超时配置
进程数少、单个请求又慢，请求就会排队，排在后面的直接超时。检查 PHP-FPM 或应用容器的进程上限、最大执行时间、网关的读取超时，是否存在“应用还在算，网关已经放弃”的错配。
缓存失效后的回源洪峰
缓存整层过期、重启后缓存为空、某次改版换了缓存键，都会让原本被挡住的请求在同一秒钟涌回源站。表现往往很整齐：整点或重启后几分钟内 5xx 陡增，之后自己恢复。这种情况要把缓存预热和过期时间打散写进流程，而不是等它自己好。
磁盘写满与日志暴涨
日志目录写满、临时文件堆积、会话文件没有清理，都会让写入失败进而返回 5xx。这类问题排查起来最快，也最容易被忽略，值得放进日常巡检。
可以直接照着做的自查清单
- 在监控里单独建立 5xx 曲线，按状态码分组，而不是只看“可用性”一个数字。
- 确认错误日志里有足够上下文：请求地址、上游耗时、异常堆栈，至少保留其中两项。
- 给关键页面准备降级方案：读缓存、静态兜底或简短提示，而不是直接抛出错误页。
- 区分 5xx 与 404、403 的统计口径，避免混在一起导致判断失真。
- 限制重试次数与退避时间，防止上游抖动被自己的重试放大成雪崩。
- 把第三方接口调用加上超时和熔断，避免外部拖垮内部。
监控与告警的几条经验
固定阈值告警容易在夜里被忽略，比例告警更实用，比如“过去五分钟 5xx 占全部请求的比例超过 1%”。告警内容里带上最近一次变更记录，往往能直接指向原因：刚发过版本、刚调整过缓存、刚做过后台批处理。没有变更记录的告警，排查时间通常要翻倍。
处理顺序建议
先止血再定位：先通过重启、扩容、切换备用节点把错误率压下去，再回头翻日志找根因。反过来做，往往一边排查一边继续报错。事后把这次的原因、影响范围、恢复动作写进记录，下次同类问题会快很多。
5xx 不需要被彻底消灭，但需要被看见、被分类、被记录。对站点运营来说，稳定返回 200 的页面，才是后续所有讨论的前提。