Great question! These three FastCGI timeout settings are key to keeping your LEMP stack stable, especially when dealing with slow PHP-FPM processes. Let’s break down what each does, how to pick the right values, and how to configure them properly.

First, let’s clarify what each timeout controls—this makes it easier to adjust them strategically:

• fastcgi_connect_timeout: The maximum time Nginx waits to establish a connection to your PHP-FPM pool. If this times out, you’ll usually see 502 errors, which often means PHP-FPM is overloaded or unresponsive (e.g., struggling to spawn child processes during traffic spikes).
• fastcgi_send_timeout: How long Nginx will wait to send the full request to PHP-FPM. This rarely needs adjustment unless you’re sending massive request bodies, but it’s good to keep in mind.
• fastcgi_read_timeout: The most commonly adjusted one—this is how long Nginx waits for PHP-FPM to send back a response. If you have slow-running scripts (like complex database queries, image processing, or API calls), this is the timeout you’ll tweak.

There’s no one-size-fits-all number, but here’s a practical approach to find what works for your stack:

1. Start with defaults
   Nginx’s out-of-the-box values are typically 60s for all three. Use this as a baseline before making changes.
2. Audit your slow scripts
   Enable PHP-FPM’s slow log to catch scripts that take longer than 60s to run. In your PHP-FPM pool config (e.g., /etc/php/8.2/fpm/pool.d/www.conf), set:

   slowlog = /var/log/php-fpm/slow.log
   request_slowlog_timeout = 60s
   

   After collecting data, set fastcgi_read_timeout to at least the longest execution time you find, plus a 20-30% buffer (e.g., if your slowest script takes 90s, set it to 120s).
3. Monitor error logs
   Check /var/log/nginx/error.log for messages like upstream timed out (110: Connection timed out) while connecting to upstream—this means you need to increase fastcgi_connect_timeout. For read timeouts, you’ll see upstream timed out (110: Connection timed out) while reading response header from upstream.
4. Balance resource usage
   Don’t set timeouts to extreme values (like 5 minutes) without caution. A single slow script tied to an Nginx worker for that long can lead to resource exhaustion if multiple such requests hit your server. Find a middle ground between accommodating slow tasks and keeping your stack responsive.
5. Test incrementally
   Adjust one parameter at a time, reload Nginx, and monitor for errors or performance issues. Small, targeted changes are better than big jumps.

You can apply these settings at three levels, depending on how granular you want to be:

1. Global Nginx Config (Affects All Sites) #

Edit /etc/nginx/nginx.conf and add the timeout lines inside the http block:

http {
    # ... existing global settings ...
    
    fastcgi_connect_timeout 60s;
    fastcgi_send_timeout 60s;
    fastcgi_read_timeout 120s;
    
    # ... rest of the config ...
}

2. Site-Specific Config (Affects One Domain) #

For per-site adjustments, edit your domain’s config file (e.g., /etc/nginx/sites-available/your-domain.conf) and add the settings inside the PHP-handling location block:

server {
    # ... server name, root, SSL settings ...
    
    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.2-fpm.sock; # adjust to your PHP version
        
        # Add timeout settings here
        fastcgi_connect_timeout 60s;
        fastcgi_send_timeout 60s;
        fastcgi_read_timeout 120s;
    }
}

3. FastCGI Params/Snippets File #

If your setup uses a shared FastCGI config snippet (like /etc/nginx/snippets/fastcgi-php.conf or /etc/nginx/fastcgi_params), you can add the timeout lines there to apply them to all PHP locations that include this file.

Final Steps After Configuring #

Always test your Nginx config for syntax errors before reloading:

sudo nginx -t

If you see test is successful, reload Nginx to apply the changes:

sudo systemctl reload nginx

内容的提问来源于stack exchange，提问作者Aaron