I think fastcgi_read_timeout is what I need here, but would like to get expert confirmation on my use-case! Thanks.


I have nginx doing fastcgi relay to a php-fpm instance.

The fpm instance, from time to time needs to be restarted. This can take upwards of 1 to 2 seconds. If a request comes in during this time, nginx will give the user a 502 error.

Ideally we will have a cluster of fpm processes for rolling restarts, but that's out of scope at this time.

My goal is to have NGINX wait, up to X s/ms before returning a 502 to the user if the cgi-relay is not available.

Here is a general idea of what I'm working with:

  location ~ ^/path/to(/|$) {
    include includes/php.conf;
    fastcgi_param SCRIPT_FILENAME $document_root/index.php;
    fastcgi_param SCRIPT_NAME /index.php;
    fastcgi_param SERVER_NAME $host;
    fastcgi_param REQUEST_SCHEME $http_x_forwarded_proto;

    # Assume some timeout param can be added here??

    fastcgi_pass php-fpm:9000;

If I'm not mistaken, I believe a 502 Gateway timeout is returned when your php gateway is anything but up. For this reason, the time out is ideally controlled in php.

In your php.ini file look for the following line:

; Default timeout for socket based streams (seconds)
; http://php.net/default-socket-timeout
default_socket_timeout = 60

Change from 60 seconds to whatever you need then restart both and test the time out again.

  • So, you're correct fastcgi_read_timeout is not what I need, that's how long it waits for a response from cgi. Changing the value didn't affect my use-case at all. The reason I can't use your solution is because the php-fpm process is literally being stopped and restarted, so I can't handle it in php (since php isnt listening). I need to somehow allow nginx to just be more graceful in how long it will wait for the cgi back end to be available. Appreciate your insight regardless. – emmdee May 14 '20 at 19:44
  • The stopping and restarting is actually the recycling behavior of the FPM Process manager. Once a php-7.3fpm process processes a certain amount of php scripts, the process manager kills it and restarts it fresh. This helps php7.3-fpm stay healthy. The no downtime part of it is when you edit the pool of processes that php7.3-fpm can use. These settings can be finely tuned in /etc/php/7.3/fpm/pool.d/www.conf. This is the config file for php7.3-fpm – suchislife May 15 '20 at 16:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.