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

Question

双重上传

自从我们从一个简单的 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 配置

配置文件

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;
}

配置文件

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

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;

Answer 1

简短回答：为您的位置块试试这个：

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

更长的解释：

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

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

事实证明，这实际上是 nginx 作为反向代理的默认行为，因此将其升级到更高版本并不能解决此问题，尽管此处给出了可能的解决方案，但这解决了一个不同的问题。

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

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

另一种选择是在超时的情况下通过设置来阻止反向代理尝试使用下一个节点proxy_next_upstream error;。或者您可以设置这两个选项，如上所述。

Answer 2

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

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

在错误再次出现之前，我将其称为“修复”（或者至少：问题的解决方案）。

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