Proxy returns 504 then blocks next connections

Server NGINX
1

I’m having an issue where I proxy a long running script and receive a
504
error when it exceeds my proxy_read_timeout setting. All of that’s
behaving
normally – what isn’t behaving normally is that the next several
requests I
make to the domain via the same proxy code also return 504s after timing
out, despite the fact that the request should complete properly.

The first script that runs takes approximately 10 minutes to run and,
once
it completes on the origin, the server again takes connections. The
oddest
part is that all of this is specific to the web browser calling the
pages on
the server. If I access the long running script in Chrome, I can no
longer
access another page through the proxy until the script finishes on the
origin. Meanwhile, I can access pages without issue on Firefox or IE. If
I
run the script through Firefox, it becomes locked out but Chrome and IE
work
fine.

Here are the relevant proxy lines:

proxy_cache CACHEFOLDER;
proxy_cache_use_stale updating error timeout invalid_header http_500
http_502 http_503 http_504;
proxy_cache_valid 60m;
proxy_redirect off;
proxy_connect_timeout 120;
proxy_send_timeout 120;
proxy_read_timeout 120;
proxy_buffers 8 16k;
proxy_buffer_size 16k;
proxy_busy_buffers_size 64k;
proxy_cache_key $host$request_uri;
proxy_set_header X-Forwarded-For $IP;
proxy_set_header Host $VAR_HOST;
proxy_pass $REQUEST_PROTO://$PROXY_TO;

Has anyone experienced anything like this before? Or is there any
setting
within NGINX that could be the culprit? The server being proxied is
running
IIS, but when I run the long running script directly against the proxied
server, I’m not getting the same behavior. The long running script runs
and
I’m able to open a new browser tab and continue browsing as well.

Posted at Nginx Forum:

2

Does your script use sessions? You didn’t specify with language it uses,
but
several popular languages such as PHP will lock a session file until the
request is complete, preventing multiple requests while the first
request
continues to run. Mechanisms similar to session_write_close() in PHP can
work around this, but it sounds like this script should run as a
background
process rather than as a web request.

Posted at Nginx Forum:

3

The script is an ASPX script and, to my knowledge, it doesn’t use
sessions.
I don’t control the script, but I can’t duplicate the behavior when
running
against the proxied server. It only occurs when going through the proxy.
I
don’t believe sessions are the issue.

Posted at Nginx Forum:

4

Hello!

On Mon, Jul 15, 2013 at 12:46:41AM -0400, abstein2 wrote:

The script is an ASPX script and, to my knowledge, it doesn’t use sessions.
I don’t control the script, but I can’t duplicate the behavior when running
against the proxied server. It only occurs when going through the proxy. I
don’t believe sessions are the issue.

For me it looks like the problem is a concurent connections limit
in a browser. Not sure why it’s triggered though, but probably
there are other connections to the same host open.

If you are using Chrome, try looking into
chrome://net-internals/ page, it might be helpful.

–
Maxim D.
http://nginx.org/en/donation.html