Nginx (all versions since September 2014, but at least 1.7.9, 1.7.10)
sometimes returns HTTP status code 500, when serving pages from
fastcgi_cache.
Each time this happens, following conditions hold true:
*) $upstream_cache_status = HIT (so we don’t even hit php-fpm)
*) $body_bytes_sent = 0 (which is strange, because I’ve got an error
page
defined for http code 500, that is obviously not sent)
I’ve configured an error page for status code 500 which is correctly
shown
on errors from PHP - this was tested for status code 503.
Nginx seems to have a bug here, I guess? Why would it otherwise return a
zero bytes size body?
This happens for about 30-40 requests a day. All other requests (several
thousand) are correctly returning status code 200. Server load/CPU load
is
very low…
On Mon, Mar 02, 2015 at 07:50:46AM -0500, mastercan wrote:
Maxim D. Wrote:
Hello!
Try looking into the error log. When nginx returns 500, it used to
complain to the error log explaining the reason.
Unfortunately the error log for that vhost does not reveal anything at the
specific times in question…
This makes me think that it is just a cached 500 response from
your backend then. If in doubt, you can obtain details using
debug log, see Debugging | NGINX.
I’ve had 2 cases with status code 500 now since setting error log to
debug
level:
The error msg: “epoll_wait() reported that client prematurely closed
connection while sending request to upstream”
It’s interesting to note that:
If a “normal” file (no caching involved) is requested and the client
closes
the connection prematurely, the status code is 200 and the response body
is
0 bytes.
If first a php script is called, which responds with a X-Accel-Redirect
to
the cached file, and the client closes the connection prematurely, the
status code is 500 and the response body is 0 bytes.
On Mon, Mar 02, 2015 at 09:11:11AM -0500, mastercan wrote:
I’ve had 2 cases with status code 500 now since setting error log to debug
level:
The error msg: “epoll_wait() reported that client prematurely closed
connection while sending request to upstream”
It’s expected to be 499, not 500. If it’s 500, it problably means
that there is some invalid error_page handling configured.
It’s interesting to note that:
If a “normal” file (no caching involved) is requested and the client closes
the connection prematurely, the status code is 200 and the response body is
0 bytes.
If first a php script is called, which responds with a X-Accel-Redirect to
the cached file, and the client closes the connection prematurely, the
status code is 500 and the response body is 0 bytes.
When talking to upstream servers, nginx tries to detect if a
client closed connection. If it does so, nginx terminates request
processing with the 499 status code. The
fastcgi_ignore_client_abort directive can be used to control the
behaviour in case of the fastcgi module, see Module ngx_http_fastcgi_module for details.
This makes me think that it is just a cached 500 response from
your backend then. If in doubt, you can obtain details using
debug log, see Debugging | NGINX.
I also considered that, but then I’d need to have at least hundreds of
500
status codes since other users are hitting the same page some seconds
before
or later. They get status code 200 though with a valid response. I even
looked at the content of the cache file and it seemed ok.
Thanks for the link - I’ll turn on debugging for the error log and see
if I
can find something.
Posted at Nginx Forum:
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.