事实证明499确实意味着“客户端连接中断”。

我有一个客户端“读超时”设置为60s (nginx也有一个默认的proxy_read_timeout为60s)。因此，在我的情况下发生的是nginx将error.log上游超时(110:连接超时)，而读取上游，然后nginx重试“下一个代理服务器在后端服务器组中配置”。如果你有不止一个。

然后它尝试下一个，下一个，直到(默认情况下)耗尽所有。当每个服务器超时时，它也会从“活动”后端服务器列表中删除它们。在耗尽所有资源后，它返回一个504网关超时。

所以在我的情况下，nginx标记服务器为“不可用”，在下一个服务器上重新尝试，然后我的客户端60s超时(立即)发生，所以我看到一个上游超时(110:连接超时)，同时读取上游日志，紧随其后的是499日志。但这只是时间上的巧合。

相关:

如果组中的所有服务器都标记为当前不可用，则返回502 Bad Gateway。10秒也一样。参见这里的max_fails和fail_timeout。在日志中，当连接到上游时，它会说没有实时上游。

如果您的服务器组中只有一个代理后端，它只尝试使用一个服务器，并返回一个504网关超时，如果超过proxy_read_timeout，它不会从“活动”服务器列表中删除单个服务器。参见这里“如果组中只有一台服务器，max_fails, fail_timeout和slow_start参数将被忽略，这样的服务器将永远不会被认为不可用。”

The really tricky part is that if you specify proxy_pass to "localhost" and your box happens to also have ipv6 and ipv4 "versions of localhost" on it at the same time (most boxes do by default), it will count as if you had a "list" of multiple servers in your server group, which means you can get into the situation above of having it return "502 for 10s" even though you list only one server. See here "If a domain name resolves to several addresses, all of them will be used in a round-robin fashion." One workaround is to declare it as proxy_pass http://127.0.0.1:5001; (its ipv4 address) to avoid it being both ipv6 and ipv4. Then it counts as "only a single server" behavior.

有一些不同的设置，你可以调整，使这个“少”的问题。比如增加超时时间，或者在服务器超时时不将其标记为“禁用”……或者修复列表，使它只有大小1，见上面:)

参见:https://serverfault.com/a/783624/27813

在我的例子中，我有这样的设置

AWS ELB >> ECS(nginx) >> ECS(php-fpm).

我为ECS(php-fpm)服务配置了错误的AWS安全组，因此Nginx无法接触到php-fpm任务容器。 这就是为什么我在nginx任务日志中得到错误

499 0 - elb-healthchecker/2.0

健康检查配置为检查php-fpm服务并确认其正常运行并返回响应。

Nginx中的HTTP 499意味着客户端在服务器响应请求之前关闭了连接。以我的经验，通常是由客户端超时引起的。据我所知，这是Nginx特定的错误代码。

使用标准的nginx配置和php-fpm，这个错误很容易重现。

在页面上按下F5按钮将向服务器创建数十个刷新请求。浏览器在刷新时取消之前的每个请求。以我为例，我在客户的网上商店日志文件中发现了数十个499。从nginx的角度来看:如果在下一次刷新请求之前没有将响应传递给客户端，nginx将记录499错误。

mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:32 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:33 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:34 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)
mydomain.com.log:84.240.77.112 - - [19/Jun/2018:09:07:35 +0200] "GET /(path) HTTP/2.0" 499 0 "-" (user-agent-string)

当然，如果php-fpm处理需要更长的时间(比如一个沉重的WP页面)，它可能会导致问题。例如，我听说过php-fpm崩溃，但我相信可以通过正确配置服务来防止崩溃，比如处理对xmlrpc.php的调用。

当你指向499时，nginx记录了一个连接中止。但这通常是在您的后端服务器太慢，另一个代理超时或用户软件终止连接时产生的。因此，检查uWSGI是否响应快，或者uWSGI /数据库服务器上是否有负载。

在很多情况下，在用户和nginx之间有一些其他的代理。有些可能在你的基础设施中，比如CDN，负载均衡器，清漆缓存等。其他可以在用户端，如缓存代理等。

如果你这边有代理，比如LoadBalancer / CDN……您应该将超时设置为先超时您的后端，然后逐步将其他代理超时给用户。

如果你有:

user >>> CDN >>> Load Balancer >>> Nginx >>> uWSGI

我建议你设置:

n秒到uWSGI超时 N +1秒到nginx超时 n+2秒超时到负载均衡器 n+3秒超时到CDN。

如果你不能设置一些超时(如CDN)，找到它的超时是什么，并根据它调整其他的(n, n-1…)

这提供了一个正确的超时链。你会发现是谁给出了超时并将正确的响应代码返回给用户。

在我的例子中，当客户端的API在得到任何响应之前关闭连接时，我得到了499。字面上发送了一个帖子，并立即关闭连接。 这是通过选项解决的:

proxy_ignore_client_abort上

Nginx doc