Home  >  Article  >  Operation and Maintenance  >  How to solve nginx 502 Bad Gateway error

How to solve nginx 502 Bad Gateway error

WBOY
WBOYforward
2023-05-20 15:16:064722browse

nginx 502 triggering conditions

The most common occurrence of 502 errors is that the backend host crashes. There is such a configuration in the upstream configuration: proxy_next_upstream. This configuration specifies what kind of errors nginx encounters when fetching data from a back-end host. It will go to the next back-end host. What is written in it is all the 502s that will appear. Depending on the situation, the default is error timeout. Error refers to crashes, disconnections, etc. Timeout refers to read blocking timeout, which is easier to understand. I usually write it all:

proxy_next_upstream error timeout invalid_header http_500 http_503; But now I may have to remove the http_500 item. http_500 specifies that when the backend returns a 500 error, it will transfer to a host. The backend jsp error If so, a bunch of stacktrace error messages would have been printed, but now they have been replaced by 502. But the company's programmers don't think so. They believe that there is an error in nginx. I really don't have time to explain to them the principle of 502...

503 errors can be retained, because the backend is usually apache resin. If apache crashes, it will be an error, but if resin crashes, it will only be 503, so it is still necessary to retain it.

Solution

If you encounter a 502 problem, you can give priority to following the following two steps to solve it.

1. Check whether the current number of php fastcgi processes is sufficient:

Copy the code The code is as follows:

netstat -anpo | grep "php-cgi" | wc -l

If the actual "number of fastcgi processes" used is close to the preset "number of fastcgi processes", then it means that the "number of fastcgi processes" is not enough and needs to be increased.

2. The execution time of some PHP programs exceeds the waiting time of nginx. You can appropriately increase the timeout time of fastcgi in the nginx.conf configuration file, for example:

Copy code The code is as follows:

http {
fastcgi_connect_timeout 300;
fastcgi_send_timeout 300;
fastcgi_read_timeout 300;
......
}
......

If the memory_limit in php.ini is set low, an error will occur. I modified the memory_limit in php.ini to 64m, restarted nginx, and found that it was ok. It turned out that php had insufficient memory.

 If this modification still cannot solve the problem, you can refer to the following solutions:

1. max-children and max-requests

One set nginx php (fpm) xcache is running on the server, and the average number of visits per day is about 300w pv.

Recently, this situation often occurs: the PHP page opens very slowly, the CPU usage suddenly drops to a very low level, the system load suddenly rises to a very high level, and if you check the traffic of the network card, you will also find that it suddenly dropped to a very low level. . This condition lasts only a few seconds before reverting.

Checking the log files of php-fpm found some clues.

Copy code The code is as follows:

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″ 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 

Before these sentences, there are more than 1,000 lines of logs for closing children and opening children.

It turns out that php-fpm has a parameter max_requests, which specifies the maximum number of requests each child can handle before being closed. The default setting is 500. Because PHP polls requests to each child, under heavy traffic, each child takes about the same amount of time to reach max_requests, which causes all children to be closed basically at the same time.

During this period, nginx cannot transfer the php file to php-fpm for processing, so the cpu will drop to a very low level (no need to process php, let alone execute sql), and the load will rise to a very high level (close and Turn on children, nginx waits for php-fpm), and the network card traffic is also reduced to very low (nginx cannot generate data to transmit to the client)

The solution to the problem is very simple, increase the number of children, and set max_requests to less than 0 or A relatively large value:

Open /usr/local/php/etc/php-fpm.conf and increase the following two parameters (according to the actual situation of the server, too large will not work)

Copy the code The code is as follows:

5120
600 

Then restart php-fpm.

2. Increase the buffer capacity

Open the nginx error log and find an error message like "pstream sent too big header while reading response header from upstream". After checking the information, the general idea is that there is a bug in the nginx buffer. The buffer occupied by the page consumption of our website may be too large. Referring to the modification method written by a foreigner, the buffer capacity setting is increased, and the 502 problem is completely solved. Later, the system administrator adjusted the parameters and retained only two setting parameters: client head buffer and fastcgi buffer size.

3. request_terminate_timeout

If 502 occurs mainly during some post or database operations, rather than common in static page operations, then you can check one of the php-fpm.conf settings:

request_terminate_timeout

This value is max_execution_time, which is the execution script time of fast-cgi.

0s

0s is closed, which means it will be executed indefinitely. (I changed a number without looking carefully during the installation) The problem is solved and the execution will be error-free for a long time. In optimizing fastcgi, you can also change this value for 5 seconds to see the effect.

If the number of php-cgi processes is not enough, the php execution time is long, or the php-cgi process dies, a 502 error will occur.

nginx 502 bad gateway error solution 2

Today, my vps frequently prompted nginx 502 bad gateway error. After restarting the vps, it reappeared. Very bother. I'm a bit confused. The website had 1290 visits in the past two days without any problems. Why did a 502 bad gateway appear this time? Depressing! ! ! After searching for a long time, I finally found a lot of relevant answers. I hope this error will not occur again after modification. Alas, since I have been looking for answers on the Internet for so long, of course I have to record the useful things so that I don’t have to go to Google again next time~

Because I used the lnmp one-click installation package, something went wrong. You must first go to the official forum and search for it. It’s great. There is an official pinned post like this. Let’s take a look.

lnmp one-click installation package official:

The first reason: Currently, the most common problem with lnmp one-click installation package is 502 bad gateway. In most cases, the reason is before installing php , some lib packages in the script may not be installed, resulting in PHP not being compiled and installed successfully.
Solution: You can try to install it manually according to the script in the lnmp one-click installation package to see what error is caused.

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 Reasons:

A 502 problem occurs during installation and use. Generally, it is because the default php-cgi process is 5. It may be due to insufficient phpcgi processes that the 502 problem occurs. /usr/local/php/ needs to be modified. Increase the max_children value appropriately in etc/php-fpm.conf.

Fourth reason:

php execution timeout, modify /usr/local/php/etc/php.ini to change max_execution_time to 300

Fifth reason:

Insufficient disk space, such as mysql log taking up a lot of space

The sixth reason:

Check whether the php-cgi process is running

Some netizens also gave There is another solution:

nginx 502 bad gateway means that the requested php-cgi has been executed, but due to some reason (usually a problem of reading resources) it has not been executed, resulting in php-cgi The process terminates. Generally speaking, nginx 502 bad gateway is related to the settings of php-fpm.conf.

php-fpm.conf has two crucial parameters, one is max_children and the other is request_terminate_timeout, but this value is not universal and needs to be calculated by yourself.
When a 502 problem occurs during installation and use, it is usually because the default php-cgi process is 5. It may be that there are not enough phpcgi processes to cause 502. /usr/local/php/etc/php-fpm needs to be modified. conf will increase the max_children value appropriately.

The calculation method is as follows:

If your server performance is good enough, broadband resources are sufficient, and there are no loops or bugs in the PHP script, you can directly set request_terminate_timeout to 0s. The meaning of 0s is to let php-cgi continue to execute without time limit. And if you can't do this, that is to say, your php-cgi may have a bug, or your bandwidth is not sufficient, or other reasons cause your php-cgi to freeze, then it is recommended that you assign a value to request_terminate_timeout. This value can be set according to the performance of the server. Generally speaking, the better the performance, the higher you can set it, ranging from 20 minutes to 30 minutes.
How is the value of max_children calculated? In principle, the larger the value, the better. If there are more php-cgi processes, it will be processed quickly and there will be fewer queued requests. Setting max_children also needs to be set according to the performance of the server. Generally speaking, the memory consumed by each php-cgi on a server is about 20m under normal circumstances.

According to the official answer, we checked the related possibilities and combined with the answers from netizens, we came up with the following solution.

1. Check the number of processes of php fastcgi (max_children value)

Code: netstat -anpo | grep "php-cgi" | wc -l

5 (if displayed 5)

2. View the current process

Code: top
Observe the number of fastcgi processes. If the number of processes used is equal to or higher than 5, it means that it needs to be increased (according to the actual situation of your machine) (Depends on the situation)

3. Adjust the relevant settings of /usr/local/php/etc/php-fpm.conf

1060s
max_children can have up to 10 processes, with 20mb memory per process, up to 200mb.
The execution time of request_terminate_timeout is 60 seconds, which is 1 minute.

The above is the detailed content of How to solve nginx 502 Bad Gateway error. For more information, please follow other related articles on the PHP Chinese website!

Statement:
This article is reproduced at:yisu.com. If there is any infringement, please contact admin@php.cn delete