Home > Applications & Tools > Nginx: How to Fix Timeout Issues and More

Nginx: How to Fix Timeout Issues and More

If you’ve followed my blog, you’ve read several articles on Nginx. This is the last article of the series, and also an interesting one. While troubleshooting a system I helped to build, I found a very challenging problem that I think is worthwhile to share. The system consists of a client and a server, between which is a Nginx server as reversed proxy. This is a typical setting for flexibility and control. Somehow, the client got disconnected pretty consistently but the back end work went through successfully. It’s really a false alarm but not good for a product.

Further debugging excludes the possibility of the back end server because direct connection works just fine. The issue remains on the Nginx server and is confirmed with 504 error (gateway error) on the client side. It turns out that Nginx has default timeout of 60 seconds for its connection to the server side. If the back end server does not respond in 60 seconds, Nginx tears down its connection to the server, and further the connection from the client.

Time to learn how to "Google" and manage your VMware and clouds in a fast and secure


To fix the problem, just increase the timeout to longer period, say 3 minutes (180s, and yours could be different), in the configuration file as follows:

    location /
         proxy_read_timeout 180s;

The proxy_read_timeout can in fact be defined on any of http, server, and location levels (see the official page). The lower level inherits the upper level values by default, but can overwrite upper levels if value is explicitly specified. If you’ve programmed in object oriented languages, it’s quite easy to understand.

There are a few other timeouts you can explicitly specify, for example, proxy_connect_timeout, which is useful when a back end server hangs but still handles new connections into pool for processing. It’s like new cars continue to get onto freeway but go nowhere.

Although the problem is fixed nicely, it’s not the best solution, and should be avoided if possible.

For one thing, the connection is still there taking system resources when you allow longer timeout. If it’s a high volume server, it can easily result in performance and scalability problems. As a general rule, a server should reply as soon as possible. For any long running task, just include a task ticket with which the client can query progress later. If you need a reference, you can check out the design of Task in VMware vSphere API.

Categories: Applications & Tools Tags: , ,
  1. December 15th, 2014 at 14:20 | #1

    Can you please try to comment on my forum.nginx.org/read.php?11,241909,241909,template=head%253F%253F question ?

    I have tried it using latest nginx too. Everything works great with httpd but its too heavy :(

  2. May 11th, 2015 at 05:13 | #2

    Hey guys! Today something wierdo happend to my site. i got error like this Bad Gateway or something http://www.asysteo.pl any idea what could happend?
    i recently updated php version so maybe thats a problem?

  3. May 11th, 2015 at 11:01 | #3

    You may want to check if your back-end PHP server works fine. The Bad Gateway normally indicates there is problem for Nginx server to connect to the back end server it proxies. Good luck!

  4. December 4th, 2015 at 04:33 | #4

    I just deployed a VPS for my new website, Nignx was installed successfully but I can’t access via Server’s public IP, my browser always shows me timeout. I don’t have any firewall settings on that VPS, do you think anything I did wrong? How to fix the issue?

  5. December 4th, 2015 at 12:24 | #5

    Could you ping the public IP? What OS/version? Do you have SeLinux on the machine?

  1. No trackbacks yet.