awk '$9==499{print $7}' access.log | sort | uniq -c
awk '$9==499 && $NF>10' access.log | wc -l
监控里 499 占比突然到 15%，access.log 里 request_time 集中在 30 秒，upstream_response_time 却只有 0.002 秒。这类现象通常不是突然出现的，往前翻半天日志能看到苗头。
追下去是这么回事：客户端等不及先断开，Nginx 记成 499，上游时间很短说明后端早就返回了，慢在传输或者响应体太大，不是应用处理不过来。
这次卡住的地方就在「Nginx 499 定位」这一环，单独把它拎出来验证，别和其他改动混在同一次发布里。权限不要一口气开到最大，先加到够用再往上试，范围小才好收。
把复现步骤压到三条以内，交给同事也能跑出来，才算真的定位清楚。改动写完就同步给同事，下一个人踩同一个坑，成本还是你的。
验证用真实数据走一遍，测试数据太干净，边界情况根本碰不到。
处理上按这个顺序：按 request_uri 聚合找出 499 集中的接口；把 request_time 和 upstream_time 摆一起判断卡在哪段；拿同一条请求在服务端再复现一次 看实际耗时。
确认没问题再收工，定位到具体接口后把响应体压小，499 比例回落到 1% 以内。