Nginx 502 error trigger conditions and Solutions
Some websites running on Nginx sometimes encounter "502 Bad Gateway" errors, sometimes even frequently. Some Webmasters have encountered this problem just after being transferred to Nginx, so they often suspect that this is not a problem with Nginx, but in fact this is a misunderstanding.
The following are some troubleshooting methods for Nginx 502 errors collected by Zhang Yan and Ayou blogs for your reference:
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;
However, now I may want to remove the http_500 option. When 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, it 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. the execution time of some PHP programs exceeds the Nginx Waiting Time
You can add the timeout time of FastCGI in the nginx. conf configuration file, for example:
- ......
- Http
- {
- ......
- Fastcgi_connect_timeout 300;
- Fastcgi_send_timeout 300;
- Fastcgi_read_timeout 300;
- ......
- }
- ......
An error occurs when memory_limit is set to low in php. ini. After modifying memory_limit of php. ini to 64 MB, restart nginx and check that PHP memory is insufficient.
If the problem persists, you can refer to the following solutions:
3. 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:
- Sep3008: 32: 23.289973 [NOTICE] fpm_unix_init_main (), line 271: getrlimit (nofile): max: 51200, cur: 51200
- Sep3008: 32: 23.290212 [NOTICE] fpm_sockets_init_main (), line 371: using inherited socket fd = 10, "127.0.0.1: 9000 ″
- Sep3008: 32: 23.290342 [NOTICE] fpm_event_init_main (), line 109: libevent: using epoll
- Sep3008: 32: 23.296426 [NOTICE] fpm_init (), line 47: fpm is running, pid 30587
Before the preceding statements, there are 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)
- <Valuename = "max_children"> 5120 </value>
- <Valuename = "max_requests"> 600 </value>
Restart php-fpm.
5. 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.
6. request_terminate_timeout
If it is common in some post or database operations, rather than static page operations, you can check 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.
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.
-------------------------------------- Split line --------------------------------------
Deployment of Nginx + MySQL + PHP in CentOS 6.2
Build a WEB server using Nginx
Build a Web server based on Linux6.3 + Nginx1.2 + PHP5 + MySQL5.5
Performance Tuning for Nginx in CentOS 6.3
Configure Nginx to load the ngx_pagespeed module in CentOS 6.3
Install and configure Nginx + Pcre + php-fpm in CentOS 6.4
Nginx installation and configuration instructions
Nginx log filtering using ngx_log_if does not record specific logs
-------------------------------------- Split line --------------------------------------
Nginx details: click here
Nginx: click here
This article permanently updates the link address: