HTTP Error reported by nginx (phpcgi)

Address: http://raocl.spaces.live.com/blog/cns! 3f6cff93fd0e3b79! 181. Entry http://edu.codepub.com/2010/0504/22510.php

Nginx 502 Bad Gateway means that the requested PHP-CGI has been executed, but the PHP-CGI process is terminated for some reason (generally because the problem with reading resources) is not completed.
Nginx 504 gateway time-out means that the requested gateway does not have a request. Simply put, it does not have a request for PHP-CGI that can be executed.

To solve these two problems, we need to think about it comprehensively. In general, nginx 502 Bad Gateway is related to the setting of the php-fpm.conf, while nginx 504 gateway time-out is related to the setting of nginx. conf.

1. Check whether the FastCGI process has been started.
Nginx 502 error indicates that sock and port are not listened. First, check whether FastCGI is running.
2. Check the FastCGI process running status.
In addition to the first case, FastCGI processes are insufficient, PHP Execution takes a long time, or the PHP-CGI process is dead, which may also cause nginx 502 errors.
Run the following command to check whether the number of FastCGI processes is close to the value set in the configuration file. If the number of FastCGI processes is close to that set in the configuration file, the number of worker processes is too small.
Netstat-anpo | grep "PHP-cgi" | WC-l
3. FastCGI execution time is too long
Increase the following parameter values based on actual conditions:
Fastcgi_connect_timeout 300;
Fastcgi_send_timeout 300;
Fastcgi_read_timeout 300;
4. the header is too large, which may be caused by the small buffer of nginx default FastCGI process response. This will cause the FastCGI process to be suspended. If your FastCGI service does not handle this suspension well, in the end, 504 gateway time-out may occur.
Today's websites, especially some forums, have a lot of replies and a lot of content. One page even has hundreds of K
The default FastCGI Process Response Buffer is 8 K. We can set the value to a greater value: fastcgi_buffer_size 128 K;
Fastcgi_buffers 8 128 K;
If you are using nginx Server Load balancer proxying, adjust
Proxy_buffer_size 16 K; here the parameter is increased
Proxy_buffers 4 16 K;
5. HTTPS forwarding configuration error
Correct configuration method
SERVER_NAME www. xok. La;
Location/myproj/repos {
Set $ fixed_destination $ http_destination;
If ($ http_destination ~ * ^ HTTPS (. *) $)
{
Set $ fixed_destination HTTP $1;
}
Proxy_set_header host $ host;
Proxy_set_header X-real-IP $ remote_addr;
Proxy_set_header destination $ fixed_destination;
Proxy_pass http: // subversion_hosts;
}

Next we will carefully analyze several important parameters of the php-fpm.conf:
The php-fpm.conf has two crucial parameters: "max_children" and "request_terminate_timeout"
One of my two values is "40" and the other is "900", but this value is not general, but needs to be calculated by myself.
The calculation method is as follows:
If your server has good performance and sufficient bandwidth resources, you can directly set "request_terminate_timeout" to 0 s if the PHP script does not have loops or bugs. 0 s means to keep the PHP-CGI running without a time limit. And if you can't do that, that is, your PHP-CGI may have a bug, or if your bandwidth is insufficient or your PHP-CGI may be suspended for other reasons, we recommend that you assign a value to "request_terminate_timeout", which can be set based on the performance of your server. In general, the better the performance, the higher you can set, 20 minutes-30 minutes can be done. Since my server PHP script takes a long time to run, some may take more than 10 minutes, so I set 900 seconds, this will not cause the PHP-CGI to die and the 502 Bad Gateway error occurs.

How is the value of "max_children" calculated? In principle, the larger the value is, the better. If the PHP-CGI process is too large, it will process very quickly and there will be very few requests in the queue. "Max_children" also needs to be set based on the server performance. Generally, a server normally consumes about 20 mb of memory per PHP-CGI, so my "max_children" I set to 40, 20 m * 40 = 800m that is to say that at the peak of all PHP-CGI consumption exists within M, less than my Effective Memory 1 GB. If my "max_children" settings are small, such as 5-10, PHP-CGI will be "very tired", the processing speed will be slow, and the waiting time will be long. If a request is not processed for a long time, the error 504 gateway time-out occurs, if the PHP-CGI that is working very well encounters a problem, the 502 Bad Gateway error will occur.

One instance:

http://www.levil.cn/post/29/

I have basically used the same configuration file to configure the lnmp combination in centos, and I have never encountered any problems. However, after installing the same environment on a VPs recently, when the website is online for more than 10 people, the opening speed is very slow. Several times, the maximum timeout time of the script set in nginx is 300 seconds, as a result, nginx sent a 504 gateway time-out error to the client browser Code . After analysis, several configuration files were modified, finally, this situation is avoided.
the error code is basically unrelated to nginx, mainly because the requests submitted to PHP-FPM fail to provide correct feedback. Generally, when a dynamic request is submitted, nginx will directly forward the request to PHP-FPM, while PHP-FPM will distribute the PHP-CGI process to process the related requests, and then return them in sequence, finally, nginx sends the result to the client browser. However, my VPs currently runs a pure PHP application. In fact, all users' requests are PHP requests, and some of them take a long time, the PHP-CGI process is always full, and the configuration file of PHP-FPM itself only opens 10 PHP-CGI processes, in this way, if there are a few online users, the requests will not be processed properly and errors will occur.
after analyzing the cause, it is easier to do the following. First, modify the configuration of PHP-FPM:
change max_children from the previous 10 to the current 30, so that sufficient PHP-CGI processes can be used;
change request_terminate_timeout from 0 s to 60 s. In this way, the timeout time for the PHP-CGI process to process scripts is 60 seconds, which can prevent all processes from being suspended and improve utilization efficiency.
then, modify several nginx configuration items to reduce the number of FastCGI requests and keep buffers unchanged as much as possible:
change fastcgi_buffers from 4 64 K to 2 256 K;
change fastcgi_buffer_size from 64 K to 128 K;
change fastcgi_busy_buffers_size from 128 K to 256 K;
change fastcgi_temp_file_write_size from 128 K to 256 K.
now, reload the configuration of PHP-FPM and nginx, and test again. No 504 gateway time-out has been found in two weeks.

Another example:

IE is normal. FF is normal for others, but an error 502 is reported when FF is used.
View the error log in the background.
Upstream sent too big header while reading response header from upstream
The header information returned is too large.
Generally, it must contain cookies.
It is suspected that a plug-in FF has returned too much header information.
One by one. Finally, it was discovered that it was caused by firebug.
Since the header returned by FastCGI is too large, you can configure
After searching the information, we found that it was related to fastcgi_buffer _ *.
Increase related configurations to solve problems
Here we use
Fastcgi_buffer_size 32 K;
Fastcgi_buffers 8 32 K;
It is much larger than the default 4 K/8 K

http400 error:
the nginx http400 error does not occur every time. Check that the nginx 400 error is caused by a large request header, it is usually caused by a long string written in the cookie. The solution is not to record too much data in the cookie. If necessary, you can consider adjusting it to nginx. client_header_buffer_size (1 K by default) in conf
If the cookie is too large, you may need to adjust large_client_header_buffers (4 K by default). The parameter description is as follows:
If the request line exceeds the buffer, an HTTP 414 error (URI Too long)
the maximum size of the HTTP header accepted by nginx must be larger than one of the buffer; otherwise, a 400 HTTP Error (Bad request) will be reported ).
http413 error:
nginx returned error 413 when uploading. Check the log file. The error message displayed is: "413 Request Entity too large ", so I found the "nginx 413 error" on the Internet and found the following settings:
In nginx. added the client_max_body_size setting in Conf. The default value is 1 MB, which can be increased to 8 MB to increase the file size limit.
If PHP is running, check PHP. INI, The client_max_body_size and PHP. in INI, the maximum values of the following values are the same or slightly larger, so that no error occurs due to inconsistent data size.
post_max_size = 8 m
upload_max_filesize = 2 m