id	summary	reporter	owner	description	type	status	priority	milestone	component	version	resolution	keywords	cc	uname	nginx_version
890	with caching enabled, nginx returns 502 bad gateway error long after upstream server comes back up	fortran77@…		"Using nginx as a front-end proxy for an upstream apache server, I enabled caching of stale content during upstream failures:

{{{
  proxy_cache_use_stale         error timeout invalid_header updating http_500 http_502 http_503 http_504;
  proxy_cache_valid             200 20m;
  proxy_cache_valid             302 20m;
  proxy_cache_valid             404 20m;
  proxy_cache_valid             any 20m;
}}}

Now consider the following sequence of events:

1. The upstream aka back-end server (apache in this case) is down.
2. The front-end server `nginx` is down.
3. We `rm -rf` the contents of the `nginx` cache directory.
4. We start `nginx`.

At this point, since the upstream server is down and the cache is empty, anybody accessing our website gets a `502 Bad Gateway nginx/1.8.1` error from `nginx`  as expected.

Now the upstream server comes back up. There is no longer any need to report a bad gateway error.

But even though the upstream server is up, and our website is active on the upstream server, visitors reaching our nginx front-end continue to see the ""`502 Bad Gateway nginx/1.8.1`"" error for at least the amount of time for which caching has been enabled — 20 minutes in the above example.

So not only is `nginx` caching content that it gets from the upstream server, but it's apparently also caching its own `502 Bad Gateway nginx/1.8.1` message. And for the next 20 minutes in this case, visitors will see the 502 error. And according to the nginx error log file, it makes no attempt to contact the upstream for those 20 minutes even if there are ongoing incoming hits.

If my experiments have not misled me, any time  `nginx` tries to access a page not in its cache while the upstream server is down, it will cache its 502 response. So even if the upstream server was down only for briefly, website visitors may see the `502 gateway error` for much longer. In the specific case above, they will see the `502 gateway error` for 20 minutes.

I have confirmed the above behavior with with `wget` and `curl` and with the Chrome browser.

Also, incidentally I have enabled transmitting of the X-Cache-Status: header, and nginx does send it in the normal case. But in the above situation, when it is sending a cached `502 gateway error`, it does not send the X-Cache-Status: header. So the end-user cannot examine the headers and be able to tell that he is seeing a stale cached message.

I am using a stable `nginx `package installed from the `nginx` repo at `http://nginx.org/packages/centos/7/x86_64/`.)

Please let me know if more information is needed."	defect	closed	major		nginx-core	1.8.x	invalid			Linux hostedited.example.com 3.10.0-327.4.5.el7.x86_64 #1 SMP Mon Jan 25 22:07:14 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux	"nginx version: nginx/1.8.1
built by gcc 4.8.3 20140911 (Red Hat 4.8.3-9) (GCC)
built with OpenSSL 1.0.1e-fips 11 Feb 2013
TLS SNI support enabled
configure arguments: --prefix=/etc/nginx --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --pid-path=/var/run/nginx.pid --lock-path=/var/run/nginx.lock --http-client-body-temp-path=/var/cache/nginx/client_temp --http-proxy-temp-path=/var/cache/nginx/proxy_temp --http-fastcgi-temp-path=/var/cache/nginx/fastcgi_temp --http-uwsgi-temp-path=/var/cache/nginx/uwsgi_temp --http-scgi-temp-path=/var/cache/nginx/scgi_temp --user=nginx --group=nginx --with-http_ssl_module --with-http_realip_module --with-http_addition_module --with-http_sub_module --with-http_dav_module --with-http_flv_module --with-http_mp4_module --with-http_gunzip_module --with-http_gzip_static_module --with-http_random_index_module --with-http_secure_link_module --with-http_stub_status_module --with-http_auth_request_module --with-mail --with-mail_ssl_module --with-file-aio --with-ipv6 --with-http_spdy_module --with-cc-opt='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic'"