502 Bad Gateway error solution
There are many causes of Nginx 502 errors because of problems with backend servers in proxy mode. These errors are not nginx problems, so you must find the cause from the backend! However, nginx has put all these errors on its own, which makes it highly questionable for nginx promoters. After all, we can understand the word "bad gateway? Isn't it bad nginx? People who do not know it will directly put the responsibility on nginx. I hope the next version of nginx will make the error prompt slightly more friendly, at least it's not a simple 502 Bad Gateway statement, and I don't forget to attach my name to it.
Nginx 502 trigger conditions
The most common occurrence of 502 errors is that the backend host is used as the machine. In the upstream configuration, there is a configuration: proxy_next_upstream, which specifies what errors nginx will encounter when retrieving data from a backend host to the next backend host, the default value is error timeout. An error occurs when a machine or disconnection occurs, and a timeout is a read congestion timeout, which is easy to understand. I generally write all of them:
Proxy_next_upstream error timeout invalid_header http_500 http_503; but now I may want to remove http_500. If http_500 specifies that the backend will return a 500 error, it will convert it to a host. If the backend jsp fails, A bunch of stacktrace error messages will be printed, which is now replaced by 502. But programmers in the company do not think so. They think that nginx has encountered an error. I really don't have time to explain the 502 principle to them ......
503 error can be retained, because the backend is usually apache resin. If apache crashes, it is error, but resin crashes, it is only 503, so it is necessary to keep it.
Solution
If you encounter a 502 problem, you can take the following two steps as a priority.
1. Check whether the current PHP FastCGI Process count is sufficient:
Netstat-anpo | grep "php-cgi" | wc-l if the number of FastCGI processes actually used is close to the preset number of FastCGI processes, it indicates that the number of FastCGI processes is insufficient and needs to be increased.
2. If the execution time of some PHP programs exceeds the Nginx waiting time, you can add the FastCGI timeout time in the nginx. conf configuration file, for example:
......
Http
{
......
Fastcgi_connect_timeout 300;
Fastcgi_send_timeout 300;
Fastcgi_read_timeout 300;
......
}
...... Php. in ini, if memory_limit is set low, an error occurs. php is modified. the memory_limit of ini is 64 MB. Restart nginx and check that the memory of PHP is insufficient.
If the problem persists, you can refer to the following solutions:
1. max-children and max-requests
Nginx php (fpm) xcache is running on one server, with an average traffic volume of around 300 PVS per day
Recently, this situation often occurs: the php page is very slow to open, the cpu usage suddenly drops to a very low level, the system load suddenly rises to a very high level, view the network card traffic, you will also find that suddenly fell to a very low level. In this case, it takes only a few seconds to recover.
Check the log file of php-fpm and find some clues.
Sep 30 08:32:23. 289973 [NOTICE] fpm_unix_init_main (), line 271: getrlimit (nofile): max: 51200, cur: 51200
Sep 30 08:32:23. 290212 [NOTICE] fpm_sockets_init_main (), line 371: using inherited socket fd = 10, "127.0.0.1: 9000 & Prime;
Sep 30 08:32:23. 290342 [NOTICE] fpm_event_init_main (), line 109: libevent: using epoll
Sep 30 08:32:23. 296426 [NOTICE] fpm_init (), line 47: fpm is running, pid 30587 is at the beginning of the sentence, is more than 1000 lines of logs for disabling children and enabling children
Originally, php-fpm has a max_requests parameter, which specifies the maximum number of requests processed by each children will be disabled. The default value is 500. Because php round-robin requests to every children, in the case of high traffic volumes, each Childe takes almost the same time to reach max_requests, which causes all children to be shut down at the same time.
During this period, nginx cannot forward the php file to php-fpm for processing, so the cpu will be reduced to a very low level (no php processing or SQL execution is required ), however, the load will rise to a very high level (disable and enable children and nginx to wait for php-fpm), and the NIC traffic will also decrease to a very low level (nginx cannot generate data for the client)
It is easy to solve the problem. Increase the number of children and set max_requests to a value not 0 or greater:
Open/usr/local/php/etc/php-fpm.conf
Increase the following two parameters (too large based on the actual situation of the server)
<Value name = "max_children"> 5120 </value>
<Value name = "max_requests"> 600 </value> and restart php-fpm.
II. Increase the buffer capacity
Open the error log of nginx and find an error message such as "pstream sent too big header while reading response header from upstream. After checking the information, the problem was caused by a bug in the nginx buffer zone. The page consumption on our website may be too large. According to the modification method written by foreigners, the buffer size setting is added, and the 502 problem is completely solved. Later, the system administrator adjusted the parameters and kept only two set parameters: client head buffer and fastcgi buffer size.
III. request_terminate_timeout
If it is common in some post or database operations, rather than static page operations, you can look at one of the php-fpm.conf settings:
Request_terminate_timeout
The value is max_execution_time, which is the script execution time of fast-cgi.
0 s
If 0 s is disabled, it is executed infinitely. (When I did not look carefully at fashion, I changed a number)
If the problem is solved, the execution will not go wrong for a long time.
In fastcgi optimization, you can change the value to 5 s to see the effect.
If the php-cgi process is insufficient, the php execution time is long, or the php-cgi process is dead, a 502 error will occur.
Basic knowledge
A server (not necessarily a Web server) serves as a gateway or proxy to meet customer requirements (such as a Web browser or our CheckUpDown robot) to access the requested URL. This server receives an invalid response from the upstream server to fulfill its requirements.
Description
This usually does not mean that the upstream server has been closed (no response gateway/proxy), but the upstream server and the Gateway/proxy do not agree to the protocol for data exchange. Given that Internet protocols are quite clear, they often mean that one or two machines are not properly or completely programmed.
HTTP cycle with 502 errors
Any client (such as a Web browser or our CheckUpDown robot) communicates with your Web server after the following cycles:
Obtain the IP address name of your website (your website URL leads to 'http ://'). This is the domain name server (DNSs) provided by (converted intellectual property name, IP address ).
Open an IP socket to connect to this IP address.
Write an HTTP data stream through this socket.
Receives an HTTP data stream response from your Web server. The value of the status code contained in this data stream is determined by the HTTP protocol. Parse the status code and other useful information of this data stream.
When this error occurs in the last step, the client above receives an HTTP status code, which is recognized as 502 '.
Fixed 502 errors
Generally, this problem is caused by poor communication between IP addresses on backend computers, which may include websites on Web servers that you try to access. When analyzing this problem, you should clear the browser cache completely.
If you are surfing the Internet, check all the websites with this problem you are trying to access, and then select
1) your ISP has a major device fault/overload or
2) If your firewall fails to work properly, the problematic internal internet connection may fail.
In the first case, only your ISP can help you. In the second case, what do you need to solve is to prevent you from accessing the Internet.
If you receive this problem only for some websites you try to access, it is very likely that one of these websites, its devices are not/overloaded. Contacts are located in these locations.
Fixed error 502-CheckUpDown
Add proxy and cache on the network. Our CheckUpDown robot will always try to 'drill through 'The Real computer host, in fact your website, but we do not have full control, our HTTP request is actually over. If there is only one link for the computer to process our HTTP request to be broken, then an error such as 502 can easily occur.