问题出现得很突然，日志倒是留得挺全。监控每 5 分钟对 /health 发一次 HEAD，返回 200，运维一直以为站点健康。可 GSC 的抓取统计里 5xx 占比涨到 12%，用 curl -X GET 打同一个地址能稳定复现 500，带上 Cookie 才出现。
刚开始盯着「上游负载均衡只探 HEAD，把有问题的节点一直留在池子里」，折腾了半个多小时，排掉了。
把日志和配置对完，能解释这个现象的基本就这几处。Nginx 把 HEAD 请求内部重写到静态空文件，请求压根没进 PHP。还有一种是应用只在 GET 时查主库，连接池打满后直接抛异常。
另外，探活脚本不校验响应体，200 的空响应也被算成健康。
两种方法各打一次，把状态码放在一起对比
curl -sI https://www.example.com/health | head -1带上完整请求头复现 GET 的 500
curl -s -o /dev/null -w '%{http_code} %{time_total}\n' -H 'Cookie: sid=test' https://www.example.com/health然后在 Nginx 里找按请求方法分流的规则
grep -rn 'request_method' /etc/nginx/conf.d/剩下的就是把
探改完先别撤，确认这几项。改完探活后同一个节点的 HEAD 与 GET 返回码一致，抓取错误里的 5xx 条目一周内从一百多条降到个位数。
容易忽略的是，只探 HEAD 的监控等于给坏节点发健康证，蜘蛛拿到的 500 要等收录掉了才会被发现。拖得越久，排查成本越高，因为现场状态会被后续操作覆盖。