Windows upstream 60 proxy_pass timeout

[Cruz Fernandez]

Normal usage of proxy_pass produces a delay of 60 seconds (on a second request) on Windows 7 and Windows 2008 on 64 bits.

The configuration is like this:

<snip>
location /api {

proxy_pass ​http://localhost:3000;
proxy_set_header X-Real-IP $remote_addr;

}
</snip>

First request goes fine, second request is being loaded after 60 seconds. An error appears on the error log of upstream error:

2014/01/30 10:32:32 [error] 6760#3604: *1 upstream timed out (10060: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond) while connecting to upstream, client: 127.0.0.1, server: localhost, request: "GET /api/xxxxx HTTP/1.1", upstream: "​http://[::1]:3000/api/xxxxx", host: "localhost"

Reported on the forum:
​http://forum.nginx.org/read.php?15,239760,239760
and
​http://forum.nginx.org/read.php?5,245516,247010

Working version is Nginx 1.2.9.

workaround:
Can be added the following parameter to avoid waiting for 60 seconds (this is a good solution if the backend is node.js, as it connects pretty fast):

proxy_connect_timeout 2s;

[Maxim Dounin]

Apparently, your backend doesn't respond on IPv6 localhost address (::1), while "localhost" name you use resolves to both IPv4 and IPv6 addresses.

The 1.2.9 version works for you as names written in the configuration file are resolved to IPv6 addresses as well as IPv4 ones only starting with this change in nginx 1.3.10:

Changes with nginx 1.3.10                                        25 Dec 2012

    *) Change: domain names specified in configuration file are now resolved
       to IPv6 addresses as well as IPv4 ones.

...

Using IPv4 address you want nginx to connect to should be a proper solution, that is

     proxy_pass http://127.0.0.1:3000;

should do the trick. Alternatively, configure your OS to map "localhost" name to only IPv4 address.

[Cruz Fernandez]

Thanks a lot Maxim!!

I have tested opening the backend on ipv6 and ipv4 addresses avoiding the error and alternatively using this:

proxy_pass ​http://127.0.0.1:3000;

works awesome.

Hopefully no one else will encounter this common mis-configuration on Windows with ipv6 (as reported on the two threads on the forum).