可能导致NGINX 499错误代码的原因之一是在用户和NGINX之间使用负载均衡服务（如AWS或haproxy）。在这种配置下，负载均衡服务将作为客户端连接到NGINX服务器，并作为服务器向Web浏览器代理数据。

对于haproxy来说，适用的某些超时的默认值是60秒，用于连接上游和从上游（NGINX）或下游（Web浏览器）读取数据。这意味着如果在60秒后代理未连接到上游进行写入，或者未从下游（Web浏览器）或上游（NGINX）接收到任何数据作为HTTP请求或响应的一部分，它将关闭相应的连接，这将被NGINX视为错误，至少在请求处理时（花费的时间过长）。

超时可能会发生在繁忙的网站或需要更多执行时间的脚本上。您可能需要找到适合您的超时值。例如，将超时值延长到更大的数字，如180秒。这可能会解决问题。

根据您的设置，您可能会在浏览器中看到504 Gateway Timeout HTTP错误，这可能表明php-fpm出现了问题。然而，在日志文件中出现499错误的情况不会如此。

非常感谢，您拯救了我的一天。我花了很多天来解决这个问题。我的问题与haproxy中的超时有关。我从未意识到这一点。

可能导致NGINX 499错误代码出现的原因以及解决方法：

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

作为一个特殊情况，我注意到有时当最终用户双击表单提交按钮时会发生这种情况。表单被发送两次，但客户端只期望收到一次响应。可以通过在JS中禁用按钮（至少几秒钟）来解决这个问题，第一次点击时禁用按钮。

需要注意的是，“客户端”实际上可能是一个代理。例如，如果您使用负载均衡器，由于超时，它可能会取消对NGINX服务器的请求。

如果用户关闭选项卡而我的API请求没有完成，这在我的Angular应用程序中会发生。

需要注意的重要一点是，这也可能是由于服务器导致的；如果服务器响应时间过长，客户端会放弃请求。

在我的情况下，由于云前缘起源在等待来自目标的响应之前关闭了连接，AWS负载均衡器不得不关闭连接。增加起源中的响应和连接超时值可以解决这个问题。

在我的情况下，一个VPN导致了499错误，随后重新提交了请求。

问题：NGINX 499错误代码出现的可能原因和解决方法

在我的情况下，我太急躁了，误解了日志的意思。实际上，真正的问题是nginx和uwsgi之间的通信问题，而不是浏览器和nginx之间的问题。如果我在浏览器中加载网站并等待足够长的时间，我会得到一个"504 - Bad Gateway"错误。但是等待的时间太长了，我继续尝试其他方法，然后在浏览器中刷新。所以我从来没有等到足够长的时间看到504错误。当在浏览器中刷新时，上一个请求就会关闭，Nginx会将其记录为499。

深入分析

在这里，我假设读者在开始尝试时和我一样对此一无所知。

我的设置是一个反向代理，nginx服务器，和一个应用服务器，uWSGI服务器在其后。所有来自客户端的请求都会经过nginx服务器，然后转发到uWSGI服务器，然后响应以相同的方式返回。我认为这是每个人都在使用nginx/uwsgi时，也应该使用的方式。

我的nginx工作正常，但是uwsgi服务器出了问题。uwsgi服务器无法响应nginx服务器有两种方式（也可能有其他方式）：

1）uWSGI说：“我正在处理，请等待，很快你就会得到回应。” nginx有一段时间愿意等待，例如20秒。之后，它会向客户端返回一个504错误。

2）uWSGI已经关闭，或者uWSGI在nginx等待时关闭。nginx立即发现这一点，在这种情况下，它会返回一个499错误。

我通过在客户端（浏览器）发出请求来测试我的设置。在浏览器中什么也没有发生，页面一直在加载。大约10秒后（小于超时时间），我得出结论有些不对劲（这是真的），然后从命令行关闭了uWSGI服务器。然后我会去uWSGI设置中尝试一些新的东西，然后重新启动uWSGI服务器。当我关闭uWSGI服务器时，nginx服务器就会返回一个499错误。所以我一直在调试499错误，这意味着我在搜索499错误。但是如果我等待足够长的时间，我就会得到504错误。如果我得到504错误，我就能更好地理解问题，然后进行调试。

所以结论是，问题出在uWGSI上，它一直卡住（“再等一会儿，再等一会儿，我就有答案了...”）。

我如何解决这个问题，我不记得了。我想这可能是由很多原因引起的。

你是如何解决这个问题的？我遇到了同样的问题，但还没有找到原因。

我添加了一个详细说明，不幸的是，我认为它无法解决你的问题。

谢谢！是的，你是对的:)不过这不是你的错，我很感激你的努力。我的设置在低层面上出现了一些奇怪的问题，开始觉得最好是按照行业标准重新配置，或者换用gunicorn...

只是想说谢谢！我遇到了完全相同的情况，这让我找对了方向。

如果你忘记了解决办法，请删除这篇文章。我读了你的整篇文章，感到很愚蠢。

我的详细说明并没有解释导致uWSGI出问题的原因，它只是解释了uWSGI是问题的原因（而不是nginx）。这个详细说明描述了症状以及我是如何误解这些症状的。我理解你的失望，但是你误解了我的答案的要点。诚挚地说。

非常有用的答案，永远不要删除！这些概念应该在文档中详细说明，你通过解释它们与文档所暗示的行为不同，为大家提供了很大的帮助！

这也适用于PHP（至少如果你使用php-fpm）。因为我也想验证php-fpm是否正常工作，我的服务器检查是一个php脚本。这意味着如果所有的fpm工作进程都在处理长时间的请求，服务器健康检查也会失败（这也是我想要的结果，因为服务器无法处理新的请求）。

非常感谢！我花了很长时间来调试nginx+uwsgi+flask的配置。然后我在一个运行时间约为100毫秒的python脚本中发现了一个问题，有时会与大约30个并发请求同时发生。而且，如果XHR在等待响应之前就中断了连接。