我有以下的负载平衡configuration：
upstream upstream { ip_hash; keepalive 1000; server 10.10.10.1; server 10.10.10.2; server 10.10.10.3; } server { listen 443; server_name example.com; ssl_certificate /etc/nginx/certs/cert.crt; ssl_certificate_key /etc/nginx/certs/cert.key; ssl on; ssl_session_cache builtin:1000 shared:SSL:10m; ssl_protocols TLSv1 TLSv1.1 TLSv1.2; ssl_ciphers HIGH:!aNULL:!eNULL:!EXPORT:!CAMELLIA:!DES:!MD5:!PSK:!RC4; ssl_prefer_server_ciphers on; location / { client_max_body_size 80m; proxy_http_version 1.1; proxy_set_header Connection ""; proxy_set_header Host $host; proxy_set_header X-Real-IP $remote_addr; proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for; proxy_set_header X-Forwarded-Proto $scheme; proxy_read_timeout 90; proxy_pass http://upstream; } } 虽然我的后端节点是稳定的，一切正常。 但是，当我closures其中一个节点（例如10.10.10.2）时，即使请求保持超时（因为服务器closures），NGINX也会继续向它发送stream量。 我已经尝试设置max_fails和fail_timeout参数，但行为仍然是相同的。
NGINX能够自动检测服务器是否closures，而不是在那里发送stream量？ 我错过了什么configuration？
Keepalive背后的想法是解决在高延迟networking上build立TCP连接的延迟。 build立一个TCP连接需要3次握手，所以当客户端和服务器之间存在可感知的延迟时，keepalive会通过重用现有的连接大大加快速度。
Nginx在处理数以千计的连接时效率非常高，而许多后端不会加快速度，所以人们常常把nginx放在真正的Web服务器前面，以加速云端和用户之间的连接cachingKeepalive以供后续重用。
请注意，根据http://nginx.org/r/keepalive，nginx甚至不支持upstream keepalive直到1.1.4，因为按照上面的说法，更有可能使用更多的上游资源来加速处理，只要你在你所有的主机之间（例如nginx和上游服务器之间）有亚毫秒的延迟。
通过在局域网上使用过多的keepalive连接，每个上游服务器只需要几百个keepalive连接，即使您没有遇到如您所描述的问题，您也可能只会使速度变慢，速度不会变快。
通常情况下，当一个给定的端口在主机上不可用时，主机会立即返回一个TCP重置数据包，即RST ，它立即告诉客户端（例如nginx）什么情况，让它立即采取适当的行动。 （ RST以外的分组也可以用于相同的效果，例如，当到达主机的路由不可用时）。
如果我们在后端停止服务，nginx会正确处理它。 该问题仅在停止整个虚拟机时才会重现。 – Ramiro Berrelleza 10月27日22:48
你的上面的评论可能表明，这是缺乏及时的连接被拒绝的数据包，肯定混淆了nginx – 看来你的设置可能只是丢弃nginx发送的数据包。 如果没有对这些请求作出任何回应，那么人们怎么能够知道你的后端服务是否不可用，而不是简单地展示企业级的行为呢？
首先，如前所述，即使您没有遇到您所描述的问题，您也可能只是通过在局域网上使用upstream keepalivefunction来降低速度，尤其是在这么高的数量下。
否则，您可能需要configuration您的设置（防火墙，路由器，虚拟化环境等）为不可用的主机返回适当的数据包，这肯定会使nginx按预期工作，因为您已经testing了TCP RST数据包时发生的情况，其实是由主机返回的。
另一个select是调整nginx中的各种超时，以解决上游消失的可能性，并补偿您的networking无法生成适当的控制数据包。
这可能包括connect(2)超时，build立新的TCP连接，通过http://nginx.org/r/proxy_connect_timeout在毫秒范围内（例如，如果你所有的服务器都在本地networking，而你不是运行具有企业级多秒延迟的企业级软件），以及通过http://nginx.org/r/proxy_read_timeout和http：:// nginx进行正在进行的read(2)和send(2)操作的超时.org / r / proxy_send_timeout ，这将取决于您的后端应用程序应该多快回复请求。 您可能还想要按照http://nginx.org/en/docs/http/ngx_http_upstream_module.html#server在upstream上下文中增加server指令的fail_timeout参数。
尝试设置keepalive 16并再次testing。 每个工作人员1kcaching的连接可能对您的情况太多了。