Request time of 60s when denying SSL requests?

JB Hobbs hobbsjb at
Thu Jan 10 19:59:06 UTC 2013

I purposely use the following rule to deny both http and https requests made to the root or our nginx server:
location = / { access_log  /logs/nginx/forbidden.log main; deny all; }
If you enter into a browser then nginx immediately returns the 403 page to the browser, as expected.  This shows up in the log as this:
"[10/Jan/2013:12:57:30 -0500]" "-" "400" "0" "80" "-" "-" "0.000" "-" "-" "-"
where 0.000 is the $request_time.
However, if you make the request using https, like this then nginx immediately displays a 408 page in the browser (why this instead of 403?). And the most troubling part is that nothing shows up in the logs until about 60 seconds later, and then shows like this:
"[10/Jan/2013:12:59:20 -0500]" "-" "408" "0" "443" "-" "-" "59.999" "-" "-" "-"
Sometimes the request_time is 59.999, sometimes it is 60.000. But it is always 60 seconds.
This is troubling because it seems nginx is in a wait state of some sort for 60 seconds before finishing up with the request. I am concerned this is tying up resources of some kind. I am using nginx to front-end Tomcat, but my understanding is that with the "deny all" the processing should end there? And even if it was passing this on to Jetty, it would get a valid response back within a few ms.
I am certain the above "location" rule is being triggered, because if I change "deny all" to "return 507;" (just to pick an arbitrary number) then the browser shows "507" as the error code.
This seems odd to me. I don't know why nginx is following the rule I set up to deny the request, yet still seems to be "in process" in some way to account for the 60 seconds.  And this only happens for HTTPS. So it looks like nginx handles it from the client perspective immediately, but then expects something else to happen during that 60 seconds. I don't think nginx is really doing any work on this during the 60 seconds. It doesn't show in top and the cpu is at 0% (doing this on a testing box). I tried forcing keep alive off in these situations but the results is still the 60 second "request time". Nginx is being used to front end a web service and in no case should someone make a request to the root like this. Therefore my goal is to immediately terminate any such request and minimize the amount of cpu resources being used to service such requests.
Any ideas? Thank you so much in advance for any help you can provide!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the nginx mailing list