A very common error encountered within an Nginx and PHP-FPM setup is “upstream prematurely closed FastCGI stdout while reading response header from upstream”. You may face this error while executing large script files. So when you run a large PHP file it shows the 502 Bad Gateway error.
In this article, we will learn more about this error and how to fix it.
How to debug this error?
To debug this error, you need to check the error logs.
Use this command to check the nginx error log –
$ tail -f /var/log/nginx/error.log
Output
2021/01/20 12:27:15 [error] 5408#0: *1257 upstream prematurely closed FastCGI stdout while reading response header from upstream, client: 106.215.70.130, server: mydomain.com, request: "GET /script.php HTTP/2.0", upstream: "fastcgi://unix:/opt/bitnami/php/var/run/www.sock:", host: "www.mydomain.com", referrer: "https://www.mydomain.com/script.php"
How to solve this error?
The error usually occurs when there is too much content on a web page and the server cannot handle it. So, the first step in solving this error is by doing the following –
- Reduce the amount of content on the pages
- Remove any errors, warning and notices
- Make sure your code is clean
If the error still exists, continue with the steps given below.
Increase client_body_timeout & client_header_timeout variable in nginx.conf file
You can solve this error is by increasing the value of the client_body_timeout & client_header_timeout variable. Use this command –
Command
$sudo vi /etc/nginx/nginx.conf
client_body_timeout 2024;
client_header_timeout 1024;
You need to increase the values of these variables slowly and check whether the error still pops up. But keep in mind that the values do not exceed the physical memory of server.
Then, restart the PHP-FPM and nginx service.
Command
sudo service php-fpm restart
sudo service nginx restart
Enable zend_extension xdebug
Xdebug is an extension in PHP used for debugging and developing programs. It has the following features –
- A single step debugger that you can use with IDEs
- Offers a code coverage functionality that can be used with PHPUnit
- It upgrades the var_dump() function in PHP
- The extension can add stack traces for notices, warnings, exceptions and errors.
- Consists of an in-built profiler
- This offers functionality for recording function calls and variable assignment to the disk
To fix this error, you need to enable xdebug extension in the php.ini file. Use the command given below –
Command
sudo vi vi /etc/php.ini
Add these lines to enable the extension –
;[XDebug]
zend_extension = xdebug
xdebug.remote_enable = true
xdebug.remote_host = 127.0.0.1
xdebug.remote_port = 9000
xdebug.remote_handler = dbgp
xdebug.profiler_enable = 1
xdebug.profiler_output_dir = /tmp
Then, restart the PHP-FPM and Nginx server using these lines of code.
Command
sudo service php-fpm restart
sudo service nginx restart
After you enable the xdebug extension in php.ini file, then the php-fpm will display all the errors, warnings and notices to the nginx server.
Note: Although this is a way to fix this error, it is not very effective. It’s because enabling the xdebug extension requires a lot of processing power and memory space. This happens as the extension gives information about different kinds of errors.
Disable Error Reporting in php.ini file
If you disable error reporting in php.ini file, the upstream error will be solved.
When you stop the error reporting process, while the amount of memory consumption required for the procedure is reduced. This helps in fixing the issue.
To do this, first, open the php.ini file in your favourite code editor using the command given below.
Command
sudo vi vi /etc/php.ini
Then, search for error_reporting and modify it to
error_reporting = ~E_ALL
After that, restart the php-fpm and nginx services with the code below –
sudo service php-fpm restart
sudo service nginx restart
Upgrade Your System’s RAM
This is perhaps the best practice when it comes to removing the upstream error. If the error persists even after you have performed the steps discussed above, you have to increase your server’s RAM. Before doing this, ensure that you have cleaned your code and removed errors.
Conclusion
The strategies mentioned above will surely help you to fix the “upstream prematurely closed FastCGI stdout while reading response header from upstream” issue. In some cases, a simple restart of the PHP-FPM service might resolve the issue.