这个坑值得记一笔。access.log 里 499 状态码每天两千多条，占比接近 8%，对应 UA 里一半是 Googlebot，另一半是站内列表页的翻页请求，CPU 看着不高但页面打开偏慢。
排查方向其实有限，先把可能性排一排。499 是客户端在服务端响应前关闭连接，Nginx 侧记录，跟业务无关；PHP 执行时间超过蜘蛛等待阈值，慢查询把响应拖到 10 秒以上；上游限流组件返回前就断开，Nginx 只看到客户端先走。
第一件事是统计 499 对应的 URI 与耗时
awk '$9==499 {print $7}' access.log | sort | uniq -c | sort -nr | head随后看这些请求的上游耗时分布
grep " 499 " access.log | awk '{print $NF}' | sort -nr | head -10定位慢查询并给接口加索引
mysqldumpslow -s t -t 10 /var/log/mysql/slow.log白天有业务在跑，能验证的部分都压到了晚上做。
改完先别撤，确认这几项。慢查询优化后这些 URI 的上游耗时从 9 秒降到 400 毫秒，499 数量回落到每天一百条以内，蜘蛛抓取成功的比例上升。
这里还有个坑。把 499 当错误码平均处理会误判，它更多是上游太慢的信号，先看耗时再看状态码。报错文案容易误导，真正的原因往往在相邻那一层的日志里。