我遇到了这篇文章，它完全显示了我的问题
http://nginx.org/en/docs/faq/chunked_encoding_from_backend.html
但是这些天浏览器都在使用 http 1.1，所以我真的不明白。我们的后端是 playframework，我不介意修复它，但我真的不明白什么不起作用，特别是因为 firefox、safari、chrome 都可以毫无问题地下载响应。只有当我们将 NGINX 放在中间时，事情才会中断，我们最终会在 json 响应中得到额外的数据。
知道如何解决这个问题吗？因为上面的文档似乎是错误的，因为我们现在使用的是更高版本的 http PLUS，浏览器似乎工作得很好。
谢谢，院长
当您的设置看起来像browser -> nginx -> backend时，当我们谈论nginx和backend之间的连接时，它或多或少与浏览器能够处理的内容无关。
默认情况下，nginx 用于与后端通信的协议是 HTTP/1.0，RFC 2616 明确禁止使用分块编码：
如果您的后端返回对 HTTP/1.0 请求的分块响应 - 它会做错事并需要修复，无论您是否在浏览器中看到问题。常见的结果是块大小的字符串（如FAQ
47中的十六进制数字）被各种 HTTP/1.0 客户端解释为响应主体的一部分。在（旧版本的）nginx 的情况下，过去发生的事情是，在将数据传递给浏览器时（它使用 HTTP/1.1，因此是 undersand chunked）nginx 在不正确的主体之上添加了它自己的分块编码，并嵌入了块大小的字符串。因此，浏览器过去常常以 nginx 的方式查看响应主体。
从上面应该很清楚，只有一种正确的方法可以解决问题——修复后端。另一方面，对于较新的 nginx 版本 (1.1.4+)，您应该不会看到常见问题解答中概述的问题。如果您看到 - 这意味着您对使用的 nginx 版本的假设是错误的，或者您没有使用 proxy_pass（但使用其他后端模块？），或者您有不止一个问题。使用 nginx调试日志可能有助于找出这里发生了什么。或者您可以从修复后端开始（无论如何这是正确的做法）。
升级 nginx 解决了这个问题。有一个为分块而硬编码的 url，所以我必须有一个可以进行分块的 LB。没有办法解决这个问题。我们有时会使用分块技术将数 GB 的研究数据流式传输下来。我们必须让 http 1.1 分块工作。
无论如何，如果您遇到此问题并修复了它，请升级 nginx ...此时没有理由接触后端，因为所有浏览器现在都在工作并且一切看起来都很好。