这个坑值得记一笔。后台生成报表的页面响应要十秒以上，网关 5 秒就返回 504。日志里蜘蛛对同一地址一分钟内请求了四次，越重试越慢。
刚开始盯着「页面没有缓存，每次请求都重新计算，超时必然复现」，折腾了半个多小时，排掉了。
真正麻烦的地方在于，几个原因的现象几乎一样。504 在蜘蛛看来是临时故障，会触发短期内的重试；重试请求又打到同一台慢节点，形成正反馈；网关的超时和 PHP 的执行上限设置不一致。
动手时先统计同一 IP 对同一地址的重复请求
awk -F'"' '$3==504 {print $1, $2}' access.log | sort | uniq -c | sort -rn | head接着确认慢在哪一段耗时
curl -o /dev/null -s -w '%{time_connect} %{time_starttransfer} %{time_total}\n' https://www.example.com/report/给重页面加短时缓存
add_header Cache-Control "public, max-age=300";末了把重活改成异步任务
wp cron event run report_build --due-now怎么算真的好了，看的是同一批现象。日志里 504 计数归零，同一地址一分钟内的重复请求降到一次，抓取统计里的服务器错误不再出现。
504 比 500 更危险，因为它天然鼓励重试，慢页面要么加缓存要么改成后台任务，别指望蜘蛛少来几次。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。