☰

使用 nginx 负载均衡服务器重复 POST 请求（状态 499）

tag-icon • tag-icon apache-2.2 nginx http-status-code
使用 nginx 负载均衡服务器重复 POST 请求（状态 499）

重复上传

自从我们从一个简单的 Apache 实例转到一个负载平衡的环境后，POST 请求有时会重复出现问题。我们正在运行 nginx 作为反向代理。静态内容由 nginx 本身提供，动态内容由两个 Apache 后端提供。

我已检查过这不是界面/用户错误。举个小例子：一个简单的图片上传将导致图片上传两次。请求/POST 不会因双击或用户故障而发送两次。我没有发现任何证据表明浏览器发送了两次请求，所以我怀疑是在服务器端。（请注意，这只是怀疑。）大多数这些请求都是内部的，这意味着它们来自员工，所以我可以验证它们是如何产生的。

我发现的唯一“错误”是 nginx499在这些情况下会记录错误。但我不确定这是问题的起因还是问题的（副作用）。（我知道 499 不是默认的 http 状态，它是 nginx 状态，表示“客户端已关闭连接”）

要求

重复的 POST 请求几乎都是需要一段时间的请求。我在这里展示的示例是一个简单的图像上传，但脚本在后台执行了一些操作（必须将图像转换为不同的格式/大小，并应分发到两个服务器等）。

日志

一个例子是上传图像。nginx 将记录一个“499”和一个 200 请求，但 Apache 正在接收（并处理！）两个请求。

阿帕奇

[17:17:37 +0200] "POST ***URL** HTTP/1. 0" 200 9045   
[17:17:47 +0200] "POST ***URL** HTTP/1. 0" 200 20687

nginx

[17:17:47 +0200] "POST ***URL** HTTP/1.1" 499 0 
[17:17:52 +0200] "POST ***URL** HTTP/1.1" 200 5641

怀疑

在我看来，更大/更慢的上传会受到更多影响，所以我怀疑是超时。我尝试阅读 499 错误：结论似乎是“客户端关闭连接”。这可能是后台的情况，但我不确定这是否意味着应该发出第二个请求，而且肯定没有发生类似“用户关闭浏览器”的情况。

目前，它似乎有助于分解较慢的 POST 请求（如果要执行多项操作，只需让用户选择 1，然后对另一项进行第二次 POST），但这可能只是降低了发生这种情况的可能性。不确定。

这显然只是暂时的解决办法。是超时，我需要找出位置并增加相应的数字，但我不确定为什么超时会导致这种行为：我怀疑是“嗯，出错了”的消息，而不是重复。

问题

我想找出哪些过程/情况会导致 POST 重复。当然，任何“不确定原因，但可以通过增加此超时来解决”都很好。

nginx 配置

NGINX配置文件

user  nginx;
worker_processes  2;
worker_rlimit_nofile 10240;

error_log  /var/log/nginx/error.log error;
pid        /var/run/nginx.pid;


events {
    multi_accept on;
    worker_connections  4096;
    use epoll;
}

http {
    include       /etc/nginx/mime.types;
    default_type  application/octet-stream;

    log_format  main  '$remote_addr - $remote_user [$time_local] "$request" '
                      '$status $body_bytes_sent "$http_referer" '
                      '"$http_user_agent" "$http_x_forwarded_for"';

    access_log  /var/log/nginx/access.log  main;

    sendfile        on;
    tcp_nodelay     off;    
    client_max_body_size    30m;
    keepalive_timeout  65;
    include /etc/nginx/conf.d/*.conf;
}

配置文件

为了保持简单，我删除了geo部分中一些特定于 IP 的行以及SSL变体。如果需要，我可以替换它们，但归根结底还是需要geo为 ssl 后端以及相应的上游和配置文件添加一个额外的部分。

geo $backend {
    default apache-backend;
}

upstream apache-backend {
    ip_hash;
    server SERVER1 max_fails=3 fail_timeout=30s weight=2;
    server SERVER2 max_fails=3 fail_timeout=30s weight=3;
}

conf.d/somestring.conf

limit_conn_zone $binary_remote_addr zone=somestring:10m;
server {
    listen ip1:80;
    listen ip2:80;
    server_name name.tld www.name.tld;

    root PATH

    access_log PATH/name.log main;

    location / {
            proxy_pass              http://$backend;
    }

            //*some more locations**//

    gzip on;
    gzip_http_version 1.0;
    gzip_comp_level 2;
    gzip_proxied any;
    gzip_min_length 1100;
    gzip_buffers 16 8k;
    gzip_types text/plain text/css application/x-javascript text/xml application/xml application/xml+rss text/javascript;
}

conf.d/proxy.conf

proxy_set_header        Accept-Encoding "";
proxy_set_header        X-Real-IP $remote_addr;
proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header        Host $http_host;

proxy_buffering         on;
proxy_read_timeout      90;
proxy_buffer_size       32k;
proxy_buffers           8 32k;
proxy_busy_buffers_size    32k;
proxy_temp_file_write_size 32k;

答案1

简短回答：针对您的位置块尝试以下操作：

location / {
  proxy_read_timeout 120;
  proxy_next_upstream error;
  proxy_pass http://$backend;
}

更长的解释：

我想我刚刚遇到了你所描述的问题：

  • 我使用 nginx 反向代理作为负载均衡器
  • 对于长时间运行的请求，后端多次接收相同的请求
  • 上游节点的 nginx 访问日志显示了499这些请求的状态，并且相同的请求出现在不同的上游节点中

事实证明，这实际上是 nginx 作为反向代理的默认行为，因此将其升级到更高版本将无法解决此问题，尽管它被作为一种可能的解决方案这里，但这解决的是不同的问题。

这是因为 nginx 作为负载均衡器选择一个上游节点循环赛方式。当所选节点发生故障时，请求将发送到下一个节点。这里要注意的重要一点是，节点故障默认归类为error or timeout。由于您没有设置proxy_read_timeout，默认值为 60 秒。因此，经过 60 秒的等待后，nginx 会选择下一个节点并发送相同的请求。

因此，一个解决方案是增加此超时时间，以便您的长时间运行的操作可以完成，例如通过设置proxy_read_timeout 120;（或任何适合您需要的限制）。

另一个选项是通过设置来阻止反向代理在超时的情况下尝试使用下一个节点proxy_next_upstream error;。或者您可以按照上面的建议同时设置这两个选项。

答案2

从此论坛主题我们了解到罪魁祸首可能是 SPDY。对于该用户来说，禁用它似乎是一个解决方案，而且自从禁用它以来，我们也没有再出现过重复帖子。

目前，除了“SPDY 造成了问题”之外，确切的问题尚不清楚，所提出的解决方案（禁用 SPDY）的副作用显然是“不再有 SPDY”，但我们可以接受这一点。

直到错误再次出现，我才称之为“修复”（或至少：问题的解决方案）。

编辑：我们（2014 年 2 月 25 日）没有再看到这个问题出现，所以这确实似乎是一个持久的解决方案。

答案3

我还遇到了一个问题，nginx 重复请求，后端处理这些请求需要超过 1 分钟的时间。对我而言有帮助的是将以下行添加到 nginx 配置的块中server：

fastcgi_next_upstream off;

您也可以尝试

uwsgi_next_upstream off

此答案中的更多信息https://stackoverflow.com/a/43562407/1743367在 nginx 文档中：https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html#fastcgi_next_upstream，https://nginx.org/en/docs/http/ngx_http_uwsgi_module.html#uwsgi_next_upstream。

相关内容