发布结束后执行了：

php bin/magento maintenance:disable
php bin/magento maintenance:status

命令明确显示 maintenance mode is not active，浏览器却仍是一张维护页。这里最重要的不是再删一次 flag，而是先问：这张页面到底是谁返回的？

用响应特征确定层级

curl -I https://shop.example.com/
curl -sS -D /tmp/headers.txt -o /tmp/body.html https://shop.example.com/
head -40 /tmp/headers.txt

看状态码、Age、Via、CDN 命中标记、Server 以及响应里的自定义 request ID。再从允许的内网路径直连 origin 测一次。如果 origin 已正常而公网仍维护，问题在 CDN、WAF 或负载均衡，不在 Magento。

反过来，如果某些请求正常、某些仍维护，优先怀疑多节点。发布脚本可能只在一台共享代码目录外的节点执行了 disable；另一个节点的 var/.maintenance.flag 还在，负载均衡便会交替返回两种页面。

别把三个“维护开关”当成一个

  1. Magento 自己的维护模式：由 CLI 管理，可用 maintenance:status 检查；
  2. Web 服务器或部署脚本的静态维护页：Nginx/Apache 可能根据另一个文件或环境变量直接返回；
  3. 边缘层维护：CDN、Fastly、负载均衡或托管平台可能有独立开关和缓存。

很多事故就是发布脚本同时打开了第 1 和第 2 个开关，收尾只关闭一个。

如果确实是 Magento 仍在返回 503

确认命令是在正确项目根目录、由正确发布版本执行，并检查 PHP/Web 进程看到的代码路径是否相同。蓝绿发布时，SSH 当前目录可能已经指向新 release，但 Web 流量仍在旧 release。

还要看维护模式是否配置了允许 IP。测试人员的 IP 被放行时，自己看到正常页面，并不能证明公众已经恢复。用外部探测点测试比在办公室浏览器刷新可靠。

缓存能不能让维护页一直存在

正常配置下 503 不应被长期缓存，但自定义 VCL、反向代理规则或错误页缓存可能做错。此时先检查响应头与缓存键，再定向 purge。不要一看到旧页面就把 Magento、Redis、CDN 全部清空；既破坏命中率，也无法知道真正是哪层。

我的恢复标准是：公网与 origin 都返回预期状态，匿名和登录请求正常，至少连续命中所有应用节点，并且负载均衡健康检查恢复。只在一个浏览器里看到首页打开，还不能宣布发布结束。