Post Date: May 4, 2017
Last Updated: September 21, 2026
Introduction
When running PHP applications through Apache with FastCGI or PHP-FPM, you may occasionally encounter 500 Internal Server Errors along with FastCGI errors in the Apache logs.
A common error looks like this:
FastCGI: incomplete headers (0 bytes) received from server
followed by:
FastCGI: comm with server "/usr/lib/cgi-bin/php7-fcgi" aborted: idle timeout (30 sec)
This can happen when the PHP application takes longer than the configured FastCGI idle timeout to process a request.
This guide explains how to identify the issue and increase the FastCGI idle timeout in an Apache and PHP-FPM environment.
Note: This article was originally written for PHP 7.0 and Apache FastCGI configuration. PHP 7.0 is no longer supported. Current Apache/PHP-FPM deployments may use different PHP versions, configuration files, and integration methods. The configuration shown below is retained to document the original solution.
Prerequisites
Before making the changes, make sure you have:
- Apache installed and running.
- PHP-FPM or FastCGI configured.
- Root or sudo access.
- Access to Apache and PHP-FPM configuration files.
- A PHP application experiencing FastCGI timeout errors.
The original environment used:
Apache PHP 7.0 PHP-FPM FastCGI Ubuntu
Identifying the Error
Check the Apache error log when the 500 error occurs.
You may see messages similar to:
[fastcgi:error] [pid 1422] [client xx.xx.xx.xx:59020] FastCGI: incomplete headers (0 bytes) received from server "/usr/lib/cgi-bin/php7-fcgi"
and:
[fastcgi:error] [pid 1690] [client xx.xx.xx.xx:59021] FastCGI: comm with server "/usr/lib/cgi-bin/php7-fcgi" aborted: idle timeout (30 sec)
The important part is:
idle timeout (30 sec)
This indicates that the FastCGI connection was terminated after waiting for the configured timeout period.
Why Does the FastCGI Idle Timeout Occur?
A PHP request may require more time to complete depending on the application and workload.
For example, a request may:
- Process a large amount of data.
- Perform a complex database operation.
- Generate a large report.
- Process a long-running application task.
- Communicate with an external service.
If the configured FastCGI timeout is too low for the application’s workload, Apache may terminate the connection before PHP finishes processing the request.
This can result in a 500 Internal Server Error.
Resolution
The original solution is to increase the FastCGI idle timeout.
Step 1: Locate the FastCGI Configuration
In the original PHP 7.0 environment, the configuration file was:
/etc/apache2/conf-enabled/php7.0-fpm.conf
Open the file:
vi /etc/apache2/conf-enabled/php7.0-fpm.conf
Note: On newer systems, the PHP-FPM configuration location and Apache integration method may be different. Check the active Apache VirtualHost and PHP-FPM configuration before modifying files.
Step 2: Increase the FastCGI Idle Timeout
Locate the FastCgiExternalServer directive.
The original configuration was similar to:
FastCgiExternalServer /usr/lib/cgi-bin/php7-fcgi \
-socket /var/run/php/php7.0-fpm.sock \
-idle-timeout 300 \
-pass-header Authorization
The important setting is:
-idle-timeout 300
This increases the timeout from the original 30 seconds to 300 seconds.
If your server has separate FastCGI configurations for individual domains, update the configuration for the affected domain instead.
Step 3: Restart Apache
After modifying the configuration, restart Apache:
systemctl restart apache2
Step 4: Restart PHP-FPM
Restart the PHP-FPM service as well:
systemctl restart php7.0-fpm
For a newer PHP version, replace php7.0-fpm with the appropriate PHP-FPM service name.
For example:
systemctl restart php8.2-fpm
Step 5: Verify the Configuration
Before restarting Apache in a production environment, it is recommended to validate the Apache configuration:
apachectl -t
A valid configuration should return:
Syntax OK
After restarting the services, test the affected application again.
Monitor the Apache Error Log
If the issue continues, monitor the Apache error log:
tail -f /var/log/apache2/error.log
Check whether the following error continues to appear:
FastCGI: comm with server aborted: idle timeout
If the timeout has disappeared, the FastCGI timeout was likely too low for the request being processed.
Important Considerations
Increasing the timeout can resolve requests that genuinely require more processing time, but it should not be used as the only solution for every timeout problem.
If requests consistently take a long time to complete, investigate the application as well.
Check for:
- Slow database queries.
- Inefficient PHP code.
- Large file processing.
- External API delays.
- Long-running background operations.
- PHP-FPM worker limitations.
- Server CPU or memory constraints.
For applications that perform lengthy operations, background processing or asynchronous jobs may be more appropriate than keeping an HTTP request open for several minutes.
Conclusion
The Apache FastCGI error:
FastCGI: comm with server ... aborted: idle timeout
can occur when a PHP request takes longer than the configured FastCGI timeout.
In the original PHP 7.0 environment, the timeout was increased from 30 seconds to 300 seconds using:
-idle-timeout 300
After changing the configuration, restart Apache and PHP-FPM and verify the application again.
For modern deployments, also investigate the underlying application performance rather than continuously increasing timeout values.
Frequently Asked Questions
1. What causes the FastCGI idle timeout error?
The error occurs when the FastCGI connection remains idle longer than the configured timeout period. A long-running PHP request can therefore cause the connection to be terminated.
2. How can I increase the FastCGI timeout?
In the original configuration, the timeout was increased using:
-idle-timeout 300
This sets the timeout to 300 seconds.
3. Does increasing the timeout fix all PHP 500 errors?
No. A FastCGI timeout is only one possible cause of a 500 error. PHP errors, application failures, database problems, resource exhaustion, and other server configuration issues can also cause HTTP 500 responses.
4. Should I keep increasing the timeout if the problem continues?
Not necessarily. If requests consistently require a long time, investigate the application’s database queries, PHP code, external services, and server resources. Long-running work may be better handled through background processing.
5. Is php7.0-fpm still recommended?
No. PHP 7.0 is an end-of-life version. Modern production systems should use a currently supported PHP version and the corresponding PHP-FPM service and configuration.
Related Articles
- How to Configure Apache with PHP-FPM handler in ubuntu 20.04
- How to install and configure PHP with Nginx on centos7
Talk to our experts
Have a technology challenge or looking for the right solution for your business? Our team can help you with cloud, DevOps, development, infrastructure, design, and more. Feel free to reach out to our experts here.