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

nginx-504_gateway_time-out

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://127.0.0.1:9000", ...

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