Some websites that run on Nginx sometimes appear "502 Bad Gateway" errors, even when they occur frequently. The following is a small compilation of some of the Nginx 502 error troubleshooting methods, for reference:
The reason for Nginx 502 error is more because of a problem with the backend server in proxy mode. These errors are generally not the problem of nginx itself, be sure to find the reason from the back end! But Nginx put these mistakes are in their own body, really let Nginx promoter is questioned, after all, from the word understanding, bad gateway? Isn't that bad nginx? Let not understand the people see, will directly put the blame on the Nginx body, I hope nginx next version will be the wrong hint to write a little more friendly, at least not now a simple sentence 502 bad Gateway, also do not forget to attach their own name.
Trigger conditions for Nginx 502
The most common occurrence of a 502 error is the backend host machine. In the upstream configuration, there is a configuration: Proxy_next_upstream, this configuration specifies the Nginx in the data from a backend host to get the error when it will go to the next back-end host, which is written in the 502 will appear all the situation pull, default is error Timeout Error is when the machine, disconnection, and so on, timeout is to read the blocking timeout, more easily understood. I usually write it all up:
Proxy_next_upstream Error timeout invalid_header http_500 http_503; But now maybe I want to get rid of the http_500, http_500 specifies that the backend returns a 500 error when it turns a host, the back end of the JSP error, it would have printed a bunch of stacktrace error messages, is now replaced by 502. But the company's programmers do not think so, they believe that the nginx error, I really do not have time to explain to them the principle of 502 ...
503 error can be preserved, because the backend is usually Apache resin, if the Apache panic is error, but resin panic, just 503, so it is necessary to keep.
Solutions
If you encounter 502 problems, you can prioritize the following two steps to resolve them.
1. See if the current number of PHP fastcgi processes is sufficient:
Copy the code code as follows:
Netstat-anpo | grep "php-cgi" | Wc-l
If the number of "fastcgi processes" actually used is close to the preset number of fastcgi processes, then the number of "fastcgi processes" is not sufficient and needs to be increased.
2, some PHP program execution time exceeds the Nginx wait time, can appropriately increase the timeout time in the nginx.conf configuration file fastcgi, for example:
Copy the code code as follows:
HTTP {fastcgi_connect_timeout 300; Fastcgi_send_timeout 300; Fastcgi_read_timeout 300; ...... } ......
PHP.ini in Memory_limit set low will error, modified php.ini memory_limit for 64M, restart Nginx, found good, the original is the memory of PHP is insufficient.
If this modification does not solve the problem, you can refer to the following scenarios:
First, Max-children and max-requests
An nginx php (FPM) XCache is running on a single server with a daily average of 300W of PV traffic.
Recently, this is often the case: PHP page Open very slow, the CPU usage suddenly dropped to very low, the system load suddenly up to very high, look at the network card traffic, will also find suddenly dropped to very low. This only lasts a few seconds and then resumes.
Check the log files for php-fpm to find some clues.
Copy the code code as follows:
Sep 08:32:23.289973 [NOTICE] Fpm_unix_init_main (), line 271:getrlimit (nofile): max:51200, cur:51200 Sep 30 08:32:23.2 90212 [NOTICE] Fpm_sockets_init_main (), Line 371:using inherited socket fd=10, "127.0.0.1:9000″sep 30 08:32:23.290342 [ NOTICE] Fpm_event_init_main (), line 109:libevent:using epoll Sep-08:32:23.296426 [NOTICE] Fpm_init (), line 47:fpm I s running, PID 30587
In front of these sentences, there are more than 1000 lines of closed children and open children logs.
Originally, PHP-FPM has a parameter max_requests, which indicates how many requests per children will be closed and the default setting is 500. Because PHP is polling the request to each children, it takes about the same amount of time for each childre to reach max_requests at large traffic, which causes all children to be shut down essentially at the same moment.
During this time, Nginx can not transfer php files to PHP-FPM processing, so the CPU will be reduced to very low (not to process PHP, not to execute SQL), and the load will rise to very high (close and open children, nginx wait for php-fpm), network card traffic also dropped to very low ( Nginx cannot generate data transfer to client)
Solving the problem is simple, increase the number of children, and set the max_requests to 0 or a larger value:
Open/usr/local/php/etc/php-fpm.conf The following two parameters (according to the actual situation of the server, too large also not)
Copy the code code as follows:
<value>5120</value><value>600</value>
Then restart PHP-FPM.
Second, increase the buffer capacity size
Open the Nginx error log and discover "Pstream sent too big header while reading response headers from upstream" error message. Look up the information, to the effect that the nginx buffer has a bug caused, our site page consumption may be too large buffer. Refer to the foreigner write modification method increases the buffer capacity size setting, 502 problem solved completely. Later, the system administrator also adjusted the parameters to retain only 2 settings parameters: Client head buffer,fastcgi buffer size.
Third, Request_terminate_timeout
If this is the case when there are several post or database operations, but not common in static page operations, you can look at one of the php-fpm.conf settings:
Request_terminate_timeout
This value is Max_execution_time, which is the fast-cgi execution script time.
0s
0s is closed, is infinite execution goes on. (When the outfit was not carefully looked at the change of a number) problem solved, the implementation of a long time will not be wrong. Optimization fastcgi, you can also change the value of 5s to see the effect.
A 502 error occurs when the number of php-cgi processes is insufficient, the PHP execution time is long, or the php-cgi process dies. Nginx 502 Bad Gateway solution 2
Today, my VPS frequently prompt Nginx 502 Bad Gateway error, restart the VPS after the solution appeared again, very annoying. A little think, the previous two days the site reached 1290 of the number of visits did not have any problem, how this time there is 502 bad Gateway? Depressed Ah!!! In the search for a long time, finally found a lot of relevant answers, I hope the changes will not appear this error. Alas, since the online search for such a long answer, it is certainly useful to record the things, lest I go to Google next time ~
Because I used the LNMP one-click installation package, out of the problem must first go to the official forum to search under, really good, the official has a such a sticky post, we first look at.
LNMP One-click installation package official:
The first reason: the current LNMP one-click installation package more problem is 502 bad Gateway, in most cases the reason is that before the installation of PHP, some LIB packets in the script may not be installed, resulting in PHP did not compile and install successfully. Workaround: You can try to install it manually according to the script in the LNMP one-click installation package to see what the error is causing.
The second reason:
In PHP.ini, the Eaccelerator configuration item must be placed before the Zend optimizer configuration, otherwise it may also cause 502 bad Gateway
The third reason:
502 problems occur during the installation, generally because the default php-cgi process is 5, possibly because the phpcgi process is not enough to cause 502, need to modify/usr/local/php/etc/php-fpm.conf Max_ The children value is increased appropriately.
Fourth reason:
PHP execution timed out, modify/usr/local/php/etc/php.ini to change Max_execution_time to 300
Fifth reason:
Insufficient disk space, such as MySQL log takes up a lot of space
Sixth reason:
To see if the php-cgi process is running
Also has the netizen to give the alternative solution:
Nginx 502 Bad Gateway means that the requested php-cgi has been executed, but for some reason (generally the problem of reading resources) did not complete the php-cgi process terminated, in general, Nginx 502 Bad The gateway and php-fpm.conf settings are relevant.
Php-fpm.conf has two key parameters, one is Max_children, the other is request_terminate_timeout, but the value is not universal, but it needs to be calculated by itself. 502 problems occur during the installation, generally because the default php-cgi process is 5, possibly because the phpcgi process is not enough to cause 502, need to modify/usr/local/php/etc/php-fpm.conf Max_ The children value is increased appropriately.
The method is calculated as follows:
If your server performance is good enough and your broadband resources are sufficient, PHP scripts do not have loops or bugs, so you can set the request_terminate_timeout to 0s directly. The meaning of 0s is to let php-cgi go on without time limit. And if you can't do this, that is, your php-cgi may be a bug, or your broadband is not enough or other reasons cause your php-cgi suspended animation then suggest you give request_terminate_timeout a value, This value can be set based on the performance of the server. Generally, the better the performance, the higher you can set, 20 minutes-30 minutes. And how is the value of Max_children calculated? This value is in principle the bigger the better, the php-cgi process is much faster, the queue requests will be very small. Setting Max_children also needs to be set according to the performance of the server, in general, a server normally consumes about 20M of memory per php-cgi.
According to the official answer, to troubleshoot the relevant possible, and combined with the answer of the Netizen, the following solution is obtained.
1. View the number of processes in PHP fastcgi (max_children value)
Code: Netstat-anpo | grep "php-cgi" | Wc-l
5 (if show 5)
2. View current Process
Code: Top Observe the number of fastcgi processes, if the number of processes used is equal to or higher than 5, indicating the need to increase (depending on your machine's actual condition)
3, adjust the relevant settings/usr/local/php/etc/php-fpm.conf
<value name= "Max_children" >10</value><value name= "Request_terminate_timeout" >60s</value> Max_children up to 10 processes, per process 20MB memory, up to 200MB. The request_terminate_timeout executes for 60 seconds, or 1 minutes.
Nginx 502 Bad Gateway error workaround