Magento 2 出现 503 Service Unavailable 如何排查？

2024/4/19 上午9:32

发布者: alwayly

Magento 2 返回 503 时，最容易做错的事情是反复清缓存。503 表示当前服务暂时不能处理请求，真正原因可能发生在 Magento 启动之前。先观察页面长什么样：如果是 Magento 自带的维护提示，和 Nginx、CDN 或负载均衡器生成的 503，处理方向完全不同。

先看是不是维护模式

bin/magento maintenance:status
ls -la var/.maintenance.flag

发布中断后，维护标记可能没有被关闭。确认部署已经完成、数据库升级和静态文件都正常后，再执行：

bin/magento maintenance:disable

不要只删除标记文件就立即开放流量。如果编译或数据库升级只完成了一半，前台恢复后会出现更难定位的错误。

查看响应头和服务器错误日志。Nginx 常见记录包括 upstream timed out、connection refused 和 no live upstreams。它们分别指向 PHP 执行超时、PHP-FPM 未监听、或上游节点全部不可用。

systemctl status php-fpm
ss -lntp | grep php
tail -n 100 /var/log/nginx/error.log

实际服务名称与日志路径取决于系统版本，不要照抄后直接重启未知服务。

如果故障只在活动高峰出现，要同时查看 CPU、内存、磁盘和 PHP-FPM 队列。磁盘空间或 inode 用尽时，Session、缓存和日志都可能无法写入。

uptime
free -m
df -h
df -i

PHP-FPM 的 pm.max_children 太小会让请求排队，设置过大又可能耗尽内存。调整前先根据单个 PHP 进程内存和机器容量估算，而不是盲目加倍。

源站正常但公开域名仍 503，检查健康检查路径、超时时间和节点状态。健康检查不应依赖结账、搜索等重接口，也不能被维护规则错误拦截。

恢复服务后，保留故障时段的 Nginx、PHP-FPM、Magento 和系统指标。503 已消失不代表问题解决；如果根因是进程数、慢接口或磁盘持续增长，它还会再次出现。