线上接口偶发白屏？一个 Nginx 参数救了我一命

这两天排查了一个非常“玄学”的线上问题：

接口在本地、测试环境都正常，但一到生产环境，前端偶发白屏，控制台报错：

net::ERR_INCOMPLETE_CHUNKED_ENCODING

刷新有时能好，有时直接挂，后端日志也没有明显异常，非常折磨人。

一开始我怀疑过很多方向：

是不是后端服务被 OOM？

是不是接口超时？

是不是前端代码有问题？

结果折腾了半天，真正的原因居然在 Nginx 的两个默认参数上。

问题现象回顾

接口是正常 200 返回

没有明显 5xx 错误

数据量偏大（JSON 响应）

浏览器直接报ERR_INCOMPLETE_CHUNKED_ENCODING

这个错误的本质是：

浏览器期望接收完整的 chunked 响应，但连接在中途被断开了

而“断开连接”的，不是前端，也不是后端，而是——Nginx。

真正的原因

在反向代理场景下，Nginx 默认会做两件事：

1️⃣proxy_buffering 开启

Nginx 会先把后端响应缓存下来，再一次性返回给客户端

2️⃣gzip 开启

对响应内容进行压缩

当接口响应较大、或者返回速度不稳定时，

缓冲 + 压缩 + chunked 传输组合在一起，很容易在中途触发连接中断。

于是浏览器就收到了一个“没传完的数据”。

最终解决方案（关键就在这里）

我只改了 Nginx 的两个参数：

proxy_buffering off;gzip off;

修改后效果非常明显：

接口稳定

白屏问题消失

再也没有出现ERR_INCOMPLETE_CHUNKED_ENCODING

为什么这两个参数这么关键？

proxy_buffering off

关闭响应缓冲，后端返回多少，Nginx 就转发多少，特别适合大 JSON、流式接口、下载接口

gzip off

避免 chunked + 压缩 在某些场景下引发的中断问题

总结一句话

当前端报ERR_INCOMPLETE_CHUNKED_ENCODING时，不要急着怀疑前端或后端，先看看 Nginx。

很多线上“疑难杂症”，最后往往只是一个默认参数的问题。

如果你也遇到过类似问题，希望这篇文章能帮你少走点弯路。