加速日志里近两成请求是 499，源站日志里几乎看不到对应记录。第一次遇到会往复杂处想，其实漏掉的多是个小前提。
# 源站日志统计
grep ' 499 ' access.log | wc -l
# 首字节
curl -o /dev/null -s -w '%{time_starttransfer}\n' https://www.example.com/
客户端在服务端返回前主动断开连接，常见于首字节时间过长或页面提前跳转。这一点先确认清楚，后面就不用反复试。
碰到「499 状态码」这类问题，我习惯先把当前配置原样备份一份，改坏了立刻换回来，不用现场推。把这次用到的命令存进笔记，比记住结论有用，换个环境还能照着走。
改完隔一天再看一次，当场正常不代表能稳住。测试环境和线上的差别，往往就在版本号和那几行被忽略的配置上。
线上出问题先对时间点，跟发布、备份、任务执行的时刻排一排，能省掉一半功夫。日志级别临时调高可以，记得改回去，长期开着既占磁盘又掩盖真问题。
具体做法是，确认是节点侧还是源站侧记录；对比首字节耗时；优化慢接口并调整超时。
改完照着核一遍，499 占比明显下降，首字节时间回到正常范围。