Nginx upstream timed out (why and how to fix)

Nginx upstream timed out

Nginx upstream timed out (110: Connection timed out) while reading response header from upstream is pretty common error. Lets find out why it happens and how to avoid it.

When you get this error, it usually means your upstream is slow and while there are couple easy fixes which I’ll show below, the proper solution is to figure out why it’s slow and improve the speed of upstream service.

There are two main directives responsible for Nginx upstream timed out (110: Connection timed out) error:

  • proxy_read_timeout – Defines a timeout for reading a response from the proxied server. Default is 60 seconds.

    ..... location ~ ^/slow-proxy { proxy_read_timeout 180; # <--- proxy_pass ...; } .....

    * you can use proxy_read_timeout inside http, server and location blocks.

  • fastcgi_read_timeout – Defines a timeout for reading a response from the FastCGI server. Default is 60 seconds.

    ..... location ~ \.php$ { fastcgi_read_timeout 180; # <--- fastcgi_pass ...; } .....

    * you can use fastcgi_read_timeout inside http, server and location blocks.

    This is commonly overlooked directive used for running fastcgi services (PHP-FPM for example). I see people first trying to adjust proxy_read_timeout directive. When that doesn’t help they start tweaking all possible timeout related options they can find in the docs (send_timeout, client_body_timeout etc) and then get mad at Nginx. I know, I’ve been there myself.. 🙂

    The trick here is to look in the Nginx error_log and see what exactly error message says. Specifically upstream: part which could tell us if it’s regular proxy upstream: "http://my-awesome-proxy" or fastcgi upstream: "fastcgi://127.0.0.1:9000". Once you know which upstream type you are dealing with, you can accordingly adjust either proxy_read_timeout or fastcgi_read_timeout.


Let me repeat the initial point one more time. While you can easily increase timeouts and “hide” the Nginx upstream timed out (110: Connection timed out) while reading response header from upstream from your logs, the clients and your users will be experiencing big delay. In most case when you see this error (response not generated within default 60 seconds window), it means you need to look what happens in your upstreams (apps) and fix underlying problems.


Also published on Medium.

11 Comments

  1. Good article! My logs show this:
    `upstream: “fastcgi://unix:/var/run/php/php7.0-fpm.sock”`

    I understand this is PHP7-FPM, but then how do I go about diagnosing the issue with PHP7?

    Reply
  2. What is that uses of fascgi , can i disable it ?

    Reply
  3. Your popup is annoying….

    Reply
    1. @jeremy I discovered that there is an “x” in the right side of the popup.

      Reply
  4. Good one bro

    Reply
  5. Yeah that popup is obnoxious as hell, I’m out..

    Reply
    1. Good luck! ?

      Reply
  6. Where is the file location?

    Reply
  7. Thank you! Saved the day!

    Reply
  8. Getting the below error while connecting to database from the client instance. The NGINX server looks like failed.

    [error] 7161#0: *13 upstream timed out (110: Connection timed out) while connecting to upstream, client:

    Reply
  9. I am also getting similar error. Can anyone please help?
    2022/12/02 10:04:38 [error] 16#16: *74044 connect() failed (110: Connection timed out) while connecting to upstream, client: 60.0.2.40, server: apigateway-test.allthingsott.com, request: “GET / HTTP/1.1”, upstream: “fastcgi://127.0.0.1:9000”, host: “apigateway-test.allthingsott.com”

    Reply

Leave a Reply