我得到了很多499 NGINX错误码。我知道这是客户端的问题。这不是NGINX或我的uWSGI堆栈的问题。当a得到499时，我注意到uWSGI日志中的相关性。
address space usage: 383692800 bytes/365MB} {rss usage: 167038976
bytes/159MB} [pid: 16614|app: 0|req: 74184/222373] 74.125.191.16 ()
{36 vars in 481 bytes} [Fri Oct 19 10:07:07 2012] POST /bidder/ =>
generated 0 bytes in 8 msecs (HTTP/1.1 200) 1 headers in 59 bytes (1
switches on core 1760)
SIGPIPE: writing to a closed pipe/socket/fd (probably the client
disconnected) on request /bidder/ (ip 74.125.xxx.xxx) !!!
Fri Oct 19 10:07:07 2012 - write(): Broken pipe [proto/uwsgi.c line
143] during POST /bidder/ (74.125.xxx.xxx)
IOError: write error
我正在寻找一个更深入的解释，希望我的NGINX配置uwsgi没有问题。我只看表面。好像是客户的问题。
事实证明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
这并没有回答OPs的问题，但由于我在激烈地寻找答案后来到这里，我想分享我们的发现。
在我们的例子中，这些499是意料之中的。例如，当用户在某些搜索框中使用提前输入功能时，我们会在日志中看到类似的内容。
GET /api/search?q=h [Status 499]
GET /api/search?q=he [Status 499]
GET /api/search?q=hel [Status 499]
GET /api/search?q=hell [Status 499]
GET /api/search?q=hello [Status 200]
因此，在我们的情况下，我认为使用proxy_ignore_client_abort是安全的，这是在前面的回答中建议的。谢谢你!
使用标准的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的调用。
