221

I'm getting a lot of 499 NGINX error codes. I see that this is a client side issue. It is not a problem with NGINX or my uWSGI stack. I note the correlation in uWSGI logs when a get a 499.

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

I'm looking for a more in depth explanation and hoping it is nothing wrong with my NGINX config for uwsgi. I'm taking it on face value. It seems like a client issue.

Alex Kulinkovich
  • 4,408
  • 15
  • 46
  • 50
Tampa
  • 75,446
  • 119
  • 278
  • 425

16 Answers16

278

HTTP 499 in Nginx means that the client closed the connection before the server answered the request. In my experience is usually caused by client side timeout. As I know it's an Nginx specific error code.

mrbo
  • 3,067
  • 1
  • 18
  • 7
  • 6
    As a special case, I noticed it sometimes happen when the end-user double-clicks a form submit button. The form is sent twice, but only one response is expected by the client. This can be worked around by disabling (at least for a few seconds) buttons in JS the first time they get clicked. – Antoine Pinsard Jan 11 '17 at 11:09
  • 57
    It's important to note that the "client" might actually be a proxy. For example, if you're using a load balancer, it might cancelling the request to the nginx server due to a timeout. – Brad Koch May 14 '19 at 15:30
  • 2
    Its happens on my Angular APP if the user closes the tab and my API requests does not get completed. – Vivek Saurabh Jun 26 '20 at 07:20
  • 4
    Important to note that this can also be caused by the **server**; if the server takes too long to respond, the client gives up. – ijoseph Jul 28 '20 at 17:58
  • In my case the aws loadbalancer had to close the connection as the cloudfront origin had closed the connection due to timeout before waiting for the response from target. Increasing the response and connection timeout value in origin fixed for me. – Yugendran Jul 14 '22 at 13:34
  • In my case, a VPN was causing the 499 and subsequently re-submitting the request. – Ryan DuVal May 11 '23 at 15:08
115

In my case, I was impatient and ended up misinterpreting the log.

In fact, the real problem was the communication between nginx and uwsgi, and not between the browser and nginx. If I had loaded the site in my browser and had waited long enough I would have gotten a "504 - Bad Gateway". But it took so long, that I kept trying stuff, and then refresh in the browser. So I never waited long enough to see the 504 error. When refreshing in the browser, that is when the previous request is closed, and Nginx writes that in the log as 499.

Elaboration

Here I will assume that the reader knows as little as I did when I started playing around.

My setup was a reverse proxy, the nginx server, and an application server, the uWSGI server behind it. All requests from the client would go to the nginx server, then forwarded to the uWSGI server, and then response was sent the same way back. I think this is how everyone uses nginx/uwsgi and are supposed to use it.

My nginx worked as it should, but something was wrong with the uwsgi server. There are two ways (maybe more) in which the uwsgi server can fail to respond to the nginx server.

1) uWSGI says, "I'm processing, just wait and you will soon get a response". nginx has a certain period of time, that it is willing to wait, fx 20 seconds. After that, it will respond to the client, with a 504 error.

2) uWSGI is dead, or uWSGi dies while nginx is waiting for it. nginx sees that right away and in that case, it returns a 499 error.

I was testing my setup by making requests in the client (browser). In the browser nothing happened, it just kept hanging. After maybe 10 seconds (less than the timeout) I concluded that something was not right (which was true), and closed the uWSGI server from the command line. Then I would go to the uWSGI settings, try something new, and then restart the uWSGI server. The moment I closed the uWSGI server, the nginx server would return a 499 error.

So I kept debugging with the 499 erroe, which means googling for the 499 error. But if I had waited long enough, I would have gotten the 504 error. If I had gotten the 504 error, I would have been able to understand the problem better, and then be able to debug.

So the conclusion is, that the problem was with uWGSI, which kept hanging ("Wait a little longer, just a little longer, then I will have an answer for you...").

How I fixed that problem, I don't remember. I guess it could be caused by a lot of things.

Tomasz
  • 4,847
  • 2
  • 32
  • 41
Mads Skjern
  • 5,648
  • 6
  • 36
  • 40
  • 1
    How did you end up solving this? I am having the same issue and haven't been able to pin down the cause. – Colin Nichols Jan 08 '16 at 16:56
  • 1
    I added an elaboration, unfortunately, I don't think it will solve your problem. – Mads Skjern Jan 09 '16 at 14:10
  • Thank you! And yes you are right :) not your fault though and I appreciate the effort. There is something strange going on at a low level with my setup, starting to think it'd be better solved by blowing up the legacy configs and starting fresh with industry standards... or perhaps moving to gunicorn... – Colin Nichols Jan 09 '16 at 21:33
  • 1
    Just wanted to say thank you! I had the exact same situation and this put me in the right track. – Aaron Feb 10 '16 at 17:45
  • If you forget your solution , then please remove then post . I read your whole post and become a fool . – Kernelv5 Jul 15 '16 at 02:56
  • 3
    @Shafiul: My elaboration does not explain what caused the problem with uWSGI, it simply explains that uWSGI was the cause (and not nginx). The elaboration describes the symptoms and how I misinterpreted these. I understand your disappointment, but you have misunderstood the essence of my answer. Sincerely. – Mads Skjern Jul 15 '16 at 10:51
  • 6
    Extremely useful answer, never delete! These concepts should be fleshed out in the documentation somewhere, you do a great service by elaborating how it behaves differently than the docs would imply! – jerclarke Oct 18 '16 at 16:36
  • This applies to PHP as well (at least if you're using php-fpm). As I also want to verify that php-fpm is healthy, my server check is a php script. This means if all fpm workers are busy serving long requests, the server health check will fail as well (which is also my desired outcome, as the server can't serve new requests). – Jervelund Jun 21 '19 at 07:12
  • Thank you very much! Played with nginx+uwsgi+flask configuration for a long time. Then I find a problem in a python script with concurrent.futures.ProcessPoolExecutor which ran in ~100ms but sometimes stuck with ~30 concurrent requests. And XHR, without waiting for a response, broke the connection. – andronick83 Apr 26 '23 at 09:48
47

The "client" in "client closed the connection" isn't necessarily the Web browser!

You may find 499 errors in an Nginx log file if you have a load balancing service between your users and your Nginx -- using AWS or haproxy. In this configuration the load balancer service will act as a client to the Nginx server and as a server to the Web browser, proxying data back and forth.

For haproxy the default values for certain applicable timeouts are some 60 seconds for connecting to upstream and for reading from upstream (Nginx) or downstream (Web browser).

Meaning that if after some 60 seconds the proxy hasn't connected to the upstream for writing, or if it hasn't received any data from the downstream (Web browser) or upstream (Nginx) as part of a HTTP request or response, respectively, it will close the corresponding connection, which will be treated as an error by the Nginx, at least, if the latter has been processing the request at the time (taking too long).

Timeouts might happen for busy websites or scripts that need more time for execution. You may need to find a timeout value that will work for you. For example extending it to a larger number, like 180 seconds. That may fix it for you.

Depending on your setup you might see a 504 Gateway Timeout HTTP error in your browser which may indicate that something is wrong with php-fpm. That won't be the case, however, with 499 errors in your log files.

Armen Michaeli
  • 8,625
  • 8
  • 58
  • 95
Upment
  • 1,581
  • 3
  • 15
  • 28
  • 2
    Thank you very much, you saved my day :'(. I spent many days to solve this problem. my problem's related to the timeout in `haproxy`. I never realize that – Spring Dec 22 '20 at 08:31
27

As you point 499 a connection abortion logged by the nginx. But usually this is produced when your backend server is being too slow, and another proxy timeouts first or the user software aborts the connection. So check if uWSGI is answering fast or not of if there is any load on uWSGI / Database server.

In many cases there are some other proxies between the user and nginx. Some can be in your infrastructure like maybe a CDN, Load Balacer, a Varnish cache etc. Others can be in user side like a caching proxy etc.

If there are proxies on your side like a LoadBalancer / CDN ... you should set the timeouts to timeout first your backend and progressively the other proxies to the user.

If you have:

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

I'll recommend you to set:

  • n seconds to uWSGI timeout
  • n+1 seconds to nginx timeout
  • n+2 senconds to timeout to Load Balancer
  • n+3 seconds of timeout to the CDN.

If you can't set some of the timeouts (like CDN) find whats is its timeout and adjust the others according to it (n, n-1...).

This provides a correct chain of timeouts. and you'll find really whose giving the timeout and return the right response code to the user.

Jens
  • 8,423
  • 9
  • 58
  • 78
bartomeu
  • 486
  • 4
  • 5
24

Turns out 499's really does mean "client interrupted connection."

I had a client "read timeout" setting of 60s (and nginx also has a default proxy_read_timeout of 60s). So what was happening in my case is that nginx would error.log an upstream timed out (110: Connection timed out) while reading upstream and then nginx retries "the next proxy server in the backend server group you configured." That's if you have more than one.

Then it tries the next and next till (by default) it has exhausted all of them. As each one times out, it removes them from the list of "live" backend servers, as well. After all are exhausted, it returns a 504 gateway timeout.

So in my case nginx marked the server as "unavailable", re-tried it on the next server, then my client's 60s timeout (immediately) occurred, so I'd see a upstream timed out (110: Connection timed out) while reading upstream log, immediately followed by a 499 log. But it was just timing coincidence.

Related:

If all servers in the group are marked as currently unavailable, then it returns a 502 Bad Gateway. for 10s as well. See here max_fails and fail_timeout. Inn the logs it will say no live upstreams while connecting to upstream.

If you only have one proxy backend in your server group, it just try's the one server, and returns a 504 Gateway Time-out and doesn't remove the single server from the list of "live" servers, if proxy_read_timeout is surpassed. See here "If there is only a single server in a group, max_fails, fail_timeout and slow_start parameters are ignored, and such a server will never be considered unavailable."

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.

There's a few different settings you can tweak to make this "less" of a problem. Like increasing timeouts or making it so it doesn't mark servers as "disabled" when they timeout...or fixing the list so it's only size 1, see above :)

See also: https://serverfault.com/a/783624/27813

rogerdpack
  • 62,887
  • 36
  • 269
  • 388
  • 1
    Got caught by the "502 for 10s" when adding localhost as a proxy_pass. Your answer was very helpful in understanding the underlying problem thanks! – Antoine May 10 '22 at 14:27
12

In my case I got 499 when the client's API closed the connection before it gets any response. Literally sent a POST and immediately close the connection. This is resolved by option:

proxy_ignore_client_abort on

Nginx doc

Community
  • 1
  • 1
DerSkythe
  • 429
  • 6
  • 11
  • 4
    I dont understand how does this help – Vladimir Starkov Jul 02 '19 at 07:45
  • 1
    Maybe it's not your case? The client sends the data and is not interested in what will happen to them and what will be the answer. But my application should process the data. Without this option, the data simply does not have time to reach my application. – DerSkythe Jul 02 '19 at 11:34
  • Thank you. Exact symptoms and perfect fix. – TTimo Jul 23 '19 at 16:29
  • Whoa! That's _almost_ exactly what I need. The only thing I'd add — would be to send 200 response to the webhook source a little bit _before_ it closes connection itself. Otherwise, they tend to disable webhooks and dont' send them again… Can I do so for selected URLs? – pilat Oct 31 '19 at 06:54
  • @pilat, yes you can add it for these contexts: http (all nginx), server (ip or something like that), location (url or whole site) – DerSkythe Nov 01 '19 at 07:46
  • @DerSkythe is there anything I can do in order to prevent client closing the connection on timeout? Say, generate OK response after 1.5 seconds (because 2 seconds is the max time the client would wait, and after a few 499's it will disable webhooks to my endpoint…) even if my app is still busy processing the request? Or, even better: send OK to client immediately and let my app process this request "in background". I don't really have use cases when I need to communicate my apps failures back to the webhooks source (if any). My first consideration is not to allow timeouts. – pilat Nov 12 '19 at 06:11
  • @pilat If you have the ability to answer “ok” and perform in background, then this will be the best option in your case. – DerSkythe Nov 14 '19 at 07:15
  • @DerSkythe I mean, I'd want nginx to say "OK" ands then pass the request further to my PHP application "in background". I already use Laravel queues, so, my controller is only registering a Job and sends "OK"… but still, sometimes I get this issue. Most probably, it's connected to available "warmed-up" php-fpm processes, which I cannot increase indefinitely. So, it would be great that the web server responds immediately and only then calls my PHP app. – pilat Nov 20 '19 at 16:57
  • @pilat, I meant that your script should put a new message somewhere in the queue and finish. It will force the Nginx to return a successful status. Next, the queue handler in the background will process the new message. I don’t know well the modern PHP, in other platforms you can run background processes that perform their tasks. In the old days on PHP, I made a call to a special script for background processes through the crontab in the system. – DerSkythe Nov 25 '19 at 07:45
  • This solved my problem. I’m using nginx ingress controller in GKE. – john Dec 04 '19 at 10:23
  • 9
    This doesn't solve the problem of your client not getting a response. It only eliminates 499 errors in your logs and replaces them with status code 200. Bad idea to do this. The real solution is to tell your client to increase their timeout setting... – marcinx Feb 12 '20 at 16:23
6

This error is pretty easy to reproduce using standard nginx configuration with php-fpm.

Keeping the F5 button down on a page will create dozens of refresh requests to the server. Each previous request is canceled by the browser at new refresh. In my case I found dozens of 499's in my client's online shop log file. From an nginx point of view: If the response has not been delivered to the client before the next refresh request nginx logs the 499 error.

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)

If the php-fpm processing takes longer (like a heavyish WP page) it may cause problems, of course. I have heard of php-fpm crashes, for instance, but I believe they can be prevented configuring services properly like handling calls to xmlrpc.php.

karvonen
  • 658
  • 9
  • 10
6

I know this is an old thread, but it exactly matches what recently happened to me and I thought I'd document it here. The setup (in Docker) is as follows:

  • nginx_proxy
  • nginx
  • php_fpm running the actual app.

The symptom was a "502 Gateway Timeout" on the application login prompt. Examination of logs found:

  • the button works via an HTTP POST to /login ... and so ...
  • nginx-proxy got the /login request, and eventually reported a timeout.
  • nginx returned a 499 response, which of course means "the host died."
  • the /login request did not appear at all(!) in the FPM server's logs!
  • there were no tracebacks or error-messages in FPM ... nada, zero, zippo, none.

It turned out that the problem was a failure to connect to the database to verify the login. But how to figure that out turned out to be pure guesswork.

The complete absence of application traceback logs ... or even a record that the request had been received by FPM ... was a complete (and, devastating ...) surprise to me. Yes, the application is supposed to log failures, but in this case it looks like the FPM worker process died with a runtime error, leading to the 499 response from nginx. Now, this obviously is a problem in our application ... somewhere. But I wanted to record the particulars of what happened for the benefit of the next folks who face something like this.

Mike Robinson
  • 8,490
  • 5
  • 28
  • 41
  • 2
    “nginx returned a 499 response, which of course means "the host died." seems not correct. Should be “nginx **logs** a 499 response, which means "the client is not waiting for nginx anymore ." – Michael Freidgeim Mar 11 '22 at 01:11
5

This doesn't answer the OPs question, but since I ended up here after searching furiously for an answer, I wanted to share what we discovered.

In our case, it turns out these 499s are expected. When users use the type-ahead feature in some search boxes, for example, we see something like this in the logs. 

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]

So in our case I think its safe to use proxy_ignore_client_abort on which was suggested in a previous answer. Thanks for that!

Ron DeFulio
  • 125
  • 1
  • 7
4

...came here from a google search

I found the answer elsewhere here --> https://stackoverflow.com/a/15621223/1093174

which was to raise the connection idle timeout of my AWS elastic load balancer!

(I had setup a Django site with nginx/apache reverse proxy, and a really really really log backend job/view was timing out)

Community
  • 1
  • 1
David Lam
  • 4,689
  • 3
  • 23
  • 34
3

Once I got 499 "Request has been forbidden by antivirus" as an AJAX http response (false positive by Kaspersky Internet Security with light heuristic analysis, deep heuristic analysis knew correctly there was nothing wrong).

TeeJay
  • 1,593
  • 3
  • 21
  • 33
1

In my case, I have setup like 

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

I had configured the wrong AWS security group for ECS(php-fpm) service, so Nginx wasn't able to reach out to php-fpm task container. That's why i was getting errors in nginx task log

499 0 - elb-healthchecker/2.0

Health check was configured as to check php-fpm service and confirm it's up and give back a response.

Piyush Sonigra
  • 1,423
  • 11
  • 10
0

One of the reasons for this behaviour could be you are using http for uwsgi instead of socket. Use the below command if you are using uwsgi directly. 

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

Same command in .ini file is

chdir = /path/to/app/folder
socket = :8080
module = app-name.wsgi
Penkey Suresh
  • 5,816
  • 3
  • 36
  • 55
0

I encountered this issue and the cause was due to Kaspersky Protection plugin on the browser. If you are encountering this, try to disable your plugins and see if that fixes your issue.

EGN
  • 2,480
  • 4
  • 26
  • 39
0

We were also getting 499 response code in Production.Our stack is

  1. NGINX,
  2. Gunicorn
  3. Django
  4. Celery (Asynchronous)
  5. Redis celery broker.
  6. Postgresql

Problem : Our API was not return response to Gunicorn -> NGINX. Because Redis was down (Loading the data), celery passing the request to .delay() method for offloading the workload from API and it did not return any response.

How to reproduce it in Django and other stack ?

Don't return any response from API.NGINX will send 499 response code to the client.

How we solved it ?

We checked each component of stack and finally reached on causing component, which was Redis. We commented the .delay() (This method used Redis) method call and tested the API, it was working fine.

This is one possible reason NGINX returns 499. Make sure your Web Framework returning the response or not. If it returns 200 then check your NGINX configurations or client side.

Muhammad Faizan Fareed
  • 3,298
  • 34
  • 30
-1

For my part I had enabled ufw but I forgot to expose my upstreams ports ._.

Alexandre Daubricourt
  • 3,323
  • 1
  • 34
  • 33