.．.从谷歌搜索过来的

我在这里找到了答案——> https://stackoverflow.com/a/15621223/1093174

这是为了提高我的AWS弹性负载均衡器的连接空闲超时!

(我用nginx/apache反向代理设置了一个Django站点，一个非常非常非常日志后端作业/视图超时)

“客户端关闭连接”中的“客户端”不一定是Web浏览器!

如果你在你的用户和你的Nginx之间有负载平衡服务——使用AWS或haproxy，你可能会在Nginx日志文件中发现499个错误。在这个配置中，负载均衡器服务将充当Nginx服务器的客户端和Web浏览器的服务器，来回代理数据。

对于haproxy，连接到上游和从上游(Nginx)或下游(Web浏览器)读取的某些适用超时的默认值约为60秒。

这意味着如果代理在大约60秒后还没有连接到上游进行写入，或者如果它还没有分别从下游(Web浏览器)或上游(Nginx)接收到任何数据作为HTTP请求或响应的一部分，它将关闭相应的连接，这将被Nginx视为错误，至少，如果后者当时正在处理请求(花了太长时间)。

对于繁忙的网站或需要更多时间执行的脚本，可能会发生超时。您可能需要找到一个适合您的超时值。例如，将它扩展到更大的数字，比如180秒。那也许能帮你解决问题。

根据您的设置，您可能会在浏览器中看到一个504网关超时HTTP错误，这可能表明php-fpm有问题。但是，如果日志文件中有499个错误，情况就不是这样了。

事实证明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

出现这种行为的原因之一可能是你在uwsgi上使用了http而不是socket。如果您直接使用uwsgi，请使用以下命令。

uwsgi --socket :8080 --module app-name.wsgi

ini文件中的相同命令是

chdir = /path/to/app/folder
socket = :8080
module = app-name.wsgi

.．.从谷歌搜索过来的

我在这里找到了答案——> https://stackoverflow.com/a/15621223/1093174

这是为了提高我的AWS弹性负载均衡器的连接空闲超时!

(我用nginx/apache反向代理设置了一个Django站点，一个非常非常非常日志后端作业/视图超时)

使用标准的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的调用。