PHP-FPM已经恢复，直接打源站内容也是新的，用户仍看到故障前的旧页面。Varnish在后端被判定unhealthy时会使用grace；健康探针一直失败，旧对象就会持续被服务。

问题不在表面

先用一个真实失败样本复现，不要一上来全量重建。把请求、实体ID和时间记下来，后面的SQL与日志才能对得上。

几条命令足够定位

  • 先看backend health，不要只做ban。
  • 比较经过Varnish与绕过Varnish的响应头、Age和内容。
varnishadm backend.list
varnishlog -g request -q 'RespHeader:X-Varnish ~ "."'
curl -sI https://shop.example.com/ | grep -i "age|x-magento-cache|x-varnish"
curl -sI http://127.0.0.1:8080/health_check.php

这里的重点不是把报错暂时消掉，而是让同一操作再执行一次仍保持幂等；因此修复后一定要做第二次重复执行测试。

改动落在哪里

修复probe使用的Host、URL、端口及期望状态码，让后端重新Healthy。再针对受影响tag/URL执行ban或Magento cache:clean full_page。合理设置beresp.grace，并区分短期stale-if-error与长期缓存TTL；监控health持续时间。

实施时的顺序

  • 先在单个SKU、单个订单或单个Store验证。
  • 保留可回退的旧配置，不覆盖原始证据。
  • 需要批量处理时分批提交并输出成功/失败清单。

验收清单

  • backend.list为Healthy
  • 新请求Age从0开始且内容更新
  • 再次模拟短故障只在约定窗口用旧页
  • 恢复后自动退出grace

验收不只看后台提示“成功”。我还会从前台/API再走一次真实链路，并在下一轮cron、索引或缓存命中后重复检查，确认不是短暂正常。

不要这样处理

全局restart Varnish会丢全部缓存并造成回源洪峰，先修探针。