服务器响应在中途被切断答案

【问题标题】：Server response gets cut off half way through服务器响应在中途被切断
【发布时间】：2019-08-23 08:47:23
【问题描述】：

我有一个返回 json 响应的 REST API。有时（而且似乎是完全随机的），json 响应在中途被切断。所以返回的 json 字符串看起来像：

...route_short_name":"135","route_long_name":"Secte // end of response

我很确定这不是编码问题，因为截止点不断改变位置，具体取决于返回的 json 字符串。我也没有找到发生截断的特定响应大小（我看到 65kb 没有被截断，而 40kbs 会）。

在中断发生时查看响应标头：

{
    "Cache-Control" = "must-revalidate, private, max-age=0";
    Connection = "keep-alive";
    "Content-Type" = "application/json; charset=utf-8";
    Date = "Fri, 11 May 2012 19:58:36 GMT";
    Etag = "\"f36e55529c131f9c043b01e965e5f291\"";
    Server = "nginx/1.0.14";
    "Transfer-Encoding" = Identity;
    "X-Rack-Cache" = miss;
    "X-Runtime" = "0.739158";
    "X-UA-Compatible" = "IE=Edge,chrome=1";
}

也不响铃。有人吗？

【问题讨论】：

标签： json rest response

【解决方案1】：

我遇到了同样的问题：

Nginx 切断了 FastCGI 后端的一些响应。例如，我无法从 PhpMyAdmin 生成正确的 SQL 备份。我检查了日志，发现：

2012/10/15 02:28:14 [暴击] 16443#0: *14534527 open() “/usr/local/nginx/fastcgi_temp/4/81/0000004814”失败（13：权限拒绝）同时读取上游，客户端：*，服务器：，请求： “POST / HTTP/1.1”，上游：“fastcgi://127.0.0.1:9000”，主机： “”，引荐来源网址：“http://*/server_export.php?token=**”

我所要做的就是为/usr/local/nginx/fastcgi_temp 文件夹和client_body_temp 授予适当的权限。

已修复！

非常感谢samvermette，您的问答让我走上了正轨。

【讨论】：

非常感谢！！！我一直在努力解决这个问题，谁知道它会这么简单））
对于 CentOS，我的 /var/cache/nginx 是 root:root 所有权！所以我的“www-data”用户没有访问权限:-(你也可能想删除你的 fastcgi_temp 子目录，因为 NginX 应该会以正确的权限重新生成它们。
这个答案救了我！但对于 1.8，它是 /var/cache/nginx/fastcgi_temp 文件夹。所以我做了命令chmod 777 /var/cache/nginx/ -R
非常感谢，为我节省了很多时间！对于我的设置，我尝试授予对不同文件夹的完全访问权限，但不知何故 ti 不起作用，所以我通过实际覆盖 proxy_buggering 保存文件的路径来解决它 proxy_temp_path new/location/
“适当的权限”是什么意思？您是否更改了文件夹的所有者？还是你chmod 777？是否保存到chmod 777？

【解决方案2】：

查找了我的 nginx error.log 文件，发现如下：

13870 open() "/var/lib/nginx/tmp/proxy/9/00/0000000009" failed (13: Permission denied) while reading upstream...

看起来 nginx 的代理正在尝试将响应内容（由 Thin 传入）保存到文件中。只有当响应大小超过proxy_buffers（在 64 位平台上默认为 64kb）时才会这样做。所以最后这个错误与我的请求响应大小有关。

我通过在我的 nginx 配置文件中将 proxy_buffering 设置为 off 来解决我的问题，而不是升级 proxy_buffers 或修复文件权限问题。

仍然不确定 nginx 缓冲区的用途。如果有人能补充一下，我将不胜感激。完全禁用缓冲是个坏主意吗？

【讨论】：

我也使用了“proxy_buffering off;”这解决了我的问题。不知道有什么其他方法可以做得更好。
同样的问题。谢谢你救了我。我在这里束手无策。
非常感谢，我试过了，它对我有用。不过，我阅读了有关该主题的更多信息，但这似乎不是推荐的方式。

【解决方案3】：

我在切断服务器响应时遇到了类似的问题。

只有当我在返回响应 header('Content-type: application/json'); 之前添加 json 标头时才会发生这种情况

在我的情况下，gzip 导致了这个问题。

我通过在nginx.conf 中指定gzip_types 并在打开gzip 之前将application/json 添加到列表中解决了这个问题：

gzip_types text/plain text/html text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript application/json;
gzip on;

【讨论】：

我们遇到了同样的问题，尽管服务器配置与答案完全相同。在客户端添加请求标头“接受编码：gzip”解决了它。
这为我修复了这个问题，也为我在 Apache 和 Ubuntu 14 和 16 上安装 Zend Expressive 进行了修复

【解决方案4】：

可能你的 inode 用完了，这会阻止 NginX 正确使用 fastcgi_temp 目录。

试试df -i，如果你有 0% 的 inode 空闲，那就有问题了。

尝试find /tmp -mtime 10（超过 10 天）查看可能会填满磁盘的内容。

或者它可能是另一个包含太多文件的目录。例如，转到 /home/www-data/example.com 并计算文件数：

find . -print | wc -l

【讨论】：

【解决方案5】：

感谢您提出的问题和出色的答案，它为我节省了很多时间。最后，clement 和 sam 的回答帮助我解决了我的问题，所以功劳归于他们。

只是想指出，在阅读了有关该主题的一些内容后，似乎不建议禁用proxy_buffering，因为如果客户端（您系统的用户）的互联网连接不佳，它可能会使您的服务器停止运行例子。

我发现this discussion 对了解更多信息非常有用。 Francis Daly 的例子让我很清楚：

也许将整个过程视为一个过程链更容易。

网络浏览器通过 1 MB/s 链接与 nginx 对话。 nginx 通过 100 MB/s 的链接与上游服务器对话。上游服务器向 nginx 返回 100 MB 的内容。 nginx 将 100 MB 的内容返回到 Web 浏览器。

开启 proxy_buffering，nginx 可以容纳整个 100 MB，所以 nginx-upstream连接1s后可以关闭，然后nginx就可以了花费 100 秒将内容发送到网络浏览器。

关闭 proxy_buffering，nginx 只能从上游获取内容与 nginx 可以将其发送到 Web 浏览器的速率相同。

网络浏览器并不关心差异——它仍然需要 100 s 来获取全部内容。

nginx 不太在意区别——它仍然需要 100 秒将内容提供给浏览器，但它必须保持连接向上游开放额外的 99 秒。

上游确实在乎差异 - 可以采取什么措施 1 s 实际上需要 100 s；对于额外的 99 秒，上游服务器是不服务任何其他请求。

通常：nginx-upstream 链接比 browser-nginx 链接快；而upstream比nginx更“重量级”；所以谨慎的做法是让上游尽快完成处理。

【讨论】：

【解决方案6】：

我们遇到了类似的问题。这是由我们的 REST 服务器（DropWizard）启用了 SO_LINGER 引起的。在负载下，DropWizard 在有机会刷新其缓冲区之前就断开了 NGINX。 JSON 大于 8kb，前端会收到截断的数据。

【讨论】：

【解决方案7】：

我也遇到过这个问题——JSON 解析客户端出错，响应被切断或更糟，响应过时并且从一些随机内存缓冲区中读取。

在尝试配置 nginx 以提供简单的 JSON 文件时，通过一些指南 – Serving Static Content Via POST From Nginx 和 Nginx: Fix to “405 Not Allowed” when using POST serving static。

就我而言，我不得不使用：

max_ranges 0;

这样当nginx在响应头中添加Accept-Ranges: bytes时浏览器不会得到任何有趣的想法）以及

sendfile off;

在我的server 块中，用于为静态文件提供服务的代理。将其添加到最终将服务于找到的JSON 文件的location 块并没有帮助。

另一个提供静态JSONs 的提示也不会忘记响应类型：

charset_types application/json;
default_type application/json;
charset utf-8;

其他搜索产生了文件夹权限问题 - nginx is cutting the end of dynamic pages and cache it 或代理缓冲问题 - Getting a chunked request through nginx，但我的情况并非如此。

【讨论】：