监控显示Varnish backend healthy，用户却偶尔看到Guru Meditation 503。健康探针只证明一个轻量URL在阈值内响应，不代表结账、搜索或未命中缓存的商品页能在backend timeout内完成。
先从503请求本身取证
varnishlog -g request -q 'RespStatus == 503' varnishstat -1 | grep -E 'backend_(fail|busy|unhealthy)|sess_dropped'
看VSL中的FetchError：first byte timeout、connection reset、no backend connection分别指向应用耗时、进程崩溃或连接池容量。不要因为探针healthy就直接提高所有timeout。
对照PHP-FPM容量
curl -s http://127.0.0.1/fpm-status?full grep -R "server reached pm.max_children" /var/log/php* /var/log/*fpm* -n
若active processes长期等于max children且listen queue增长，Varnish等待不到响应。先用慢日志找出占用进程的请求和SQL，再根据CPU、内存和平均进程大小调整pm.max_children；盲目翻倍可能把服务器拖进swap。
探针URL要代表应用但不能太重
探针只请求静态文件会漏掉PHP和数据库故障；请求完整首页又可能因外部服务波动误判。使用一个经过Magento bootstrap、检查关键依赖但响应轻量的健康端点，并限制只允许内网访问。
多后端Director
- 每个backend探针host和path是否正确；
- Host头是否命中正确虚拟主机；
- 一台节点的env.php、静态版本和Redis连接是否不同；
- Director是否仍包含已下线IP；
- 连接和首字节超时是否按慢请求证据设置。
修复后持续观察至少一个业务高峰，503计数、FPM队列和慢请求应同时下降。对checkout等不缓存路径单独压测，不能只看缓存HIT首页。
