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