Nginx and php-fpm: upstream timed out / failed (110: Connection timed out or reset by peer) while reading

Want to help support this blog? Try out Oh Dear, the best all-in-one monitoring tool for your entire website, co-founded by me (the guy that wrote this blogpost). Start with a 10-day trial, no strings attached.

We offer uptime monitoring, SSL checks, broken links checking, performance & cronjob monitoring, branded status pages & so much more. Try us out today!

Profile image of Mattias Geniar

Mattias Geniar, March 30, 2012

Follow me on Twitter as @mattiasgeniar

You may receive a response such as this when running Nginx and php-fpm after a fixed amount of time (default = 60s).

Connection timed out

[error] upstream timed out (110: Connection timed out) while reading upstream, client: x.x.x.x, server: host.tld, request: "POST /script.php HTTP/1.1", upstream: "fastcgi://", ...

The “Connection timed out” usually happens when running large scripts, that need a lot of time for processing – such as import jobs parsing large XML or CSV files. The problem is that Nginx waits by default for 60s on the fastCGI response. If it takes too long, the request is stopped. The “Connection timed out” error means that Nginx hit a timeout before it received a response from the FastCGI backend.

You can change the time Nginx waits for the FastCGI backend, by changing the fastcgi_read_timeout parameter in the general nginx.conf.

http {
    fastcgi_read_timeout 600s;

With the fastcgi_read_timeout change above, you essentially let Nginx wait for 600s on its backend.

Connection reset by peer

Alternatively, you can also get the “Connection reset by peer” error in your Nginx logs:

[error] readv() failed (104: Connection reset by peer) while reading upstream, client: x.x.x.x, server: host.tld, request: "POST /script.php, ...

With these errors, it may be any of the following PHP parameters in the php.ini that is causing the PHP process to end abruptly, thus causing Nginx to get a “reset” from its peer (in this case, the php-fpm backend).

max_input_time = ...
max_execution_time = ...
default_socket_timeout = ...

And in php-fpm.conf (usually /etc/php-fpm.conf) there’s a configuration parameter called “request_terminate_timeout” that ends processes if they have been running for that specific time.

request_terminate_timeout = 600

Hope this helps!

Want to subscribe to the cron.weekly newsletter?

I write a weekly-ish newsletter on Linux, open source & webdevelopment called cron.weekly.

It features the latest news, guides & tutorials and new open source projects. You can sign up via email below.

No spam. Just some good, practical Linux & open source content.