1、Nginx 线上 502、504，到底该查哪一层？

2、Nginx 接口没报错，用户却投诉打不开？这个码叫 499

3、503：Nginx 举白旗，后端全挂还是自己被压垮？

02 ｜ 接口没报错，用户却投诉打不开？这个码叫 499

排障实战系列 · 第 02 篇。上一篇拆了 502/504,这篇聊一个更阴的码——它连"错误"都算不上,却能让你背一整口黑锅。

客服转来一堆投诉:用户反馈页面"转圈圈""打不开""点了没反应"。

你紧张地登上去,查后端日志——一个异常都没有;查 Nginx error.log——也干干净净。监控大盘绿油油的,P99 延时正常,错误率 0%。

你甚至怀疑用户是不是在讹你。直到有人提醒:去 access.log 里看看 499。

一看,好家伙,某个接口的 499 占比飙到了 30%。

这就是 499 的阴间之处——它不算"错误",不进错误率统计,后端和 Nginx 都觉得自己没问题,但用户实实在在被坑了。

一、先说结论:499 不是 HTTP 标准码

很多人不知道,499 根本不在 HTTP 标准里。它是 Nginx 自己定义的私有状态码,含义很直白:

Client Closed Request —— Nginx 已经把请求转发给后端了,但客户端(用户)等不及,自己先把连接断了。

翻译成人话:用户发完请求,转圈等了十秒,不耐烦了,刷新了页面,或者干脆关了浏览器。Nginx 一看"哎人呢?",于是在日志里记一个 499。

所以记住这条铁律:只要看到 499,一定是用户那一端先"放手"了。 问题只在于——是用户主动走的(正常),还是被你的慢接口逼走的(故障)。

下面这张图把 499 的触发时序画清楚了,顺便和 504 做个对比,这俩太容易混:

一句话区分:504 是 Nginx 等不及后端(后端的锅),499 是用户等不及后端(可能后端慢,也可能就是用户自己走了)。 方向相反,排查思路也相反,别搞反。

二、关键判断:这批 499,到底要不要管?

不是所有 499 都是问题。页面正常跳转、用户关掉 tab、健康检查主动断连,这些都会产生 499,属于正常现象,不用管。

真正要管的是:499 集中在某个慢接口上,且占比异常。

判断就两步,先看占比,再看分布:

# 第一步:统计各状态码占比(排查万能命令,上一篇也提过)
tail -10000 /var/log/nginx/access.log | awk '{print $9}' | sort | uniq -c | sort -rn

输出大概长这样:

   7000 200
   2500 499     ← 占了 25%,明显偏高
    200 504
    100 500

499 偶尔几个无所谓,超过 5% 就值得盯一眼,某个接口飙到 10% 以上基本就是病态了。

然后定位是哪个接口在"逼走"用户:

# 第二步:499 都堆在哪些接口上?
grep " 499 " /var/log/nginx/access.log | awk '{print $7}' | sort | uniq -c | sort -rn | head

   2200 /api/export       ← 导出报表接口,占了绝大多数
    200 /api/search
     80 /api/upload

破案了。/api/export 一个接口贡献了 88% 的 499——这是个导出大报表的接口,跑一次要二三十秒,用户等不及疯狂刷新。这种 499 就得治。

经验:499 一旦高度集中在某几个接口,基本可以判定是这些接口太慢,把用户熬走了。要是 499 均匀散落在各处、且占比低,大概率是正常的用户行为,别瞎折腾。

三、灵魂问题:到底谁先超时的?

这一节是全文的硬菜。499 的根因,90% 出在"超时链路没对齐"上。

一个请求从用户到后端,要经过三层超时。把它们的时间排开看:

核心规则只有一句话:谁的超时最短,谁就先断开。 所以正确的链路是——越靠近用户越宽松,越靠近后端越紧:

后端实际处理时间  ≤  Nginx 超时  ≤  前端超时

后端的处理时间是"既成事实",改不了;Nginx 和前端的超时得能盖住它。对照三种情况:

• 如果 前端超时最短:用户那边(浏览器/APP)先断 → Nginx 记 499。后端还在吭哧吭哧跑,跑完发现没人要,白干一场,还白白占用资源。(最常见的翻车)
• 如果 Nginx 超时最短:Nginx 先扛不住 → 返回 504。用户其实还在老老实实等着。
• 如果 前端最长、Nginx 盖得住后端:三层都不先断 → 正常 200。

最坑的翻车现场长这样:前端 axios 设了 10 秒超时,Nginx 的 proxy_read_timeout 是 60 秒,后端报表接口要跑 30 秒。

结果呢?后端没报错(它在正常干活),Nginx 没报错(它还在 60 秒的耐心窗口里),但前端 10 秒就把请求掐了 → 一水儿的 499。你盯后端盯 Nginx 都查不出毛病,因为这俩本来就没错——错在前端超时设短了。

这种 case,看后端日志和 Nginx error.log 永远查不出来。只有 access.log 里的 499 会出卖真相。

四、三个场景,三种治法

定位清楚后,按场景下药。

场景一:慢接口把用户逼走(最常见)

499 集中在 /api/export、/api/report 这类重接口。治本是优化接口本身——加索引、改异步、上缓存、分页导出。

但这需要开发周期。应急的止痛药是给这些慢接口单独放宽 Nginx 超时,同时前端配合把对应请求的超时也调大:

location /api/export {
    proxy_pass http://backend;
    proxy_read_timeout 120s;   # 报表允许 2 分钟
}

注意:只放宽 Nginx 没用,前端超时不跟着调,该 499 还是 499。这就是上一节"链路对齐"的意义。

场景二:前端超时设太短

后端其实不慢(比如 1 秒就返回了),但前端把所有请求超时都设成了 3 秒,网络一抖就 499。

这种根本不是后端/运维的问题,是前端的锅。把前端超时调到和 Nginx 对齐即可。原则:前端超时 ≥ Nginx proxy_read_timeout,让 Nginx 而不是浏览器来决定什么时候"放弃"。

场景三:proxy_ignore_client_abort —— 慎用的那把刀

Nginx 有个开关 proxy_ignore_client_abort on,作用是:用户断了之后,Nginx 依然把后端跑完。 这样 access.log 里就不会记 499(因为 Nginx 装作没看见用户跑了)。

location /api/health {
    proxy_pass http://backend;
    proxy_ignore_client_abort on;
}

听着挺美?别滥用。 它的副作用很实在:用户已经走了,后端还在傻跑,CPU、数据库连接全被这种"没人要的请求"白白占用,高峰期能把后端拖垮。

只在一种场景下该用它:必须跑完的异步任务(比如生成报表后写库、发通知)。普通接口开了它,等于把 499 这个"报警信号"给屏蔽了,真出问题你反而看不见。

我的建议:默认不开,只在确认需要的 location 上单独开。 宁可看着 499 头疼,也别把它埋起来。

五、复盘:别让 499 再"隐身"

499 最危险的地方是它不进常规错误统计。很多团队的告警只盯 5xx,499 安安静静地不报警,直到客服电话打爆才发现。

事后至少补上这两件事:

特别提一句健康检查接口。很多系统每 5 秒探一次 /health,稍有卡顿就主动断开,日志里全是 499,污染统计。给它单独配 proxy_ignore_client_abort on,或者干脆从日志里过滤掉,免得干扰你对"真正 499"的判断。

写在最后

499 这篇,记住三句话:

1. 499 不是错误码,是用户先跑了——但可能是被你的慢接口逼跑的。
2. 看分布不看绝对值:499 集中在某接口上才是病,均匀散落是正常。
3. 超时链路要递增对齐:前端 ≤ Nginx ≤ 后端,谁最短谁先炸,499 往往是前端最短。

还有一条心法:access.log 才是 499 的唯一现场。 后端日志和 Nginx error.log 都会骗你,唯独 access.log 不会。下次遇到"用户投诉但系统看起来一切正常",第一反应去 access.log 数 499。

下一篇 03,收尾这个码系列的最后一个——503。当 Nginx 自己说"我顶不住了",到底是后端全挂了,还是 Nginx 被连接数压垮了?下篇见。

本系列基于个人运维排障笔记整理,场景和命令都经过实战。你遇过哪些"系统没报错但用户体验崩了"的诡异 case?评论区聊聊。

阅读原文：点击这里​