Shulou(Shulou.com)05/31 Report--

Today, the editor will share with you the relevant knowledge points about how to solve nginx 502 Bad Gateway errors. The content is detailed and the logic is clear. I believe most people still know too much about this knowledge, so share this article for your reference. I hope you can get something after reading this article. Let's take a look.

Trigger conditions of nginx 502

The most common occurrence of a 502 error is a backend host crash. There is such a configuration in the upstream configuration: proxy_next_upstream, which specifies what kind of error nginx will transfer to the next backend host when fetching data from one backend host. It is written that all situations in which 502will occur. The default is error timeout. Error is a crash, disconnection and so on, and timeout is a read blocking timeout, which is easier to understand. I usually write it all down:

Proxy_next_upstream error timeout invalid_header http_500 http_503; but now I may want to remove the http_500 item. Http_500 specifies that when the backend returns a 500error, it will be transferred to a host. If the backend jsp goes wrong, it will print a bunch of stacktrace error messages, but now it has been replaced by 502s. But the programmers in the company don't think so. they think there is something wrong with nginx. I really don't have time to explain the principle of 502to them.

503 error can be retained, because the backend is usually apache resin, if apache crashes is error, but resin crashes, only 503, so it is necessary to keep.

Solution.

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

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

The copy 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 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, so you can increase the timeout time of fastcgi in nginx.conf configuration file appropriately, for example:

The copy code is as follows:

Http {

Fastcgi_connect_timeout 300

Fastcgi_send_timeout 300

Fastcgi_read_timeout 300

.

}

.

If the memory_limit is set low in php.ini, it will make an error. Modify the memory_limit of php.ini to 64m, restart nginx, and find that php is out of memory.

If this modification does not solve the problem, you can refer to the following solutions:

1. Max-children and max-requests

Nginx php (fpm) xcache is running on a server with an average daily traffic of about 300w pv.

Recently, it often happens that php pages open very slowly, cpu usage suddenly drops to a very low level, system load suddenly rises to a very high level, and if you look at the traffic of the network card, you will find that it suddenly drops to a very low level. The situation only lasted a few seconds before it recovered.

Check php-fpm 's log files and find some clues.

The copy code is as follows:

Sep 300 0832 line 23.289973 [notice] fpm_unix_init_main (), line 271: getrlimit (nofile): max:51200, cur:51200 sep 3008 line 3223. 290212 [notice] fpm_sockets_init_main (), line 371: using inherited socket fd=10, "127.0.0.19000 using inherited socket fd=10" sep 30 0832 using inherited socket fd=10 sep 30 0832 using inherited socket fd=10 [notice] fpm_event_init_main (), line 109: libevent: using epoll sep 308 using epoll sep 308 32 using inherited socket fd=10 [notice] fpm_init () Line 47: fpm is running, pid 30587

In front of these sentences are more than 1000 lines of log of closing children and opening children.

It turns out that php-fpm has a parameter max_requests, which indicates how many requests each children can handle before it is turned off. The default setting is 500. Because php polls requests to each children, it takes about the same time for each childre to arrive at max_requests under high traffic, which causes all children to be shut down at about the same time.

During this period, nginx cannot transfer php files to php-fpm for processing, so cpu will drop to a very low level (no processing of php, let alone sql), while the load will rise to a very high level (turn off and enable children, nginx wait for php-fpm), and Nic traffic will also be very low (nginx cannot generate data for transfer to the client).

To solve the problem, increase the number of children and set the max_requests to not 0 or a larger value:

Open / usr/local/php/etc/php-fpm.conf to increase the following two parameters (according to the actual situation of the server, it is not allowed to be too large)

The copy code is as follows:

5120

six hundred

Then restart php-fpm.

Second, 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 consulting the data, it is to the effect that there is a bug in the nginx buffer, and the page consumption of our website may take up too much of the buffer. With reference to the correction method written by foreigners, 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,fastcgi buffer size.

III. Request_terminate_timeout

If this occurs mainly during some post or database operations, rather than in static page operations, take a look at one of the php-fpm.conf settings:

Request_terminate_timeout

This value is max_execution_time, which is the time when the script was executed by fast-cgi.

0s

0s is closed, it is executed indefinitely. (when you change a number without looking at it carefully) the problem is solved, and it won't go wrong for a long time. In optimizing fastcgi, you can also change this value to 5s to see the effect.

502errors can occur when the number of php-cgi processes is insufficient, the php execution time is long, or the php-cgi process dies.

Solution to nginx 502 bad gateway error 2

Today, my vps frequently prompts nginx 502bad gateway error, which appears again after restarting the vps solution, which is very annoying. A little puzzled, the website reached 1290 visitors two days ago, there is nothing wrong with it, why did it appear 502 bad gateway this time? Depressed! After searching for a long time, I finally found a lot of relevant answers. I hope this error will not occur again after the revision. Alas, since I have been looking for answers on the Internet for so long, of course I have to write down what is useful, so that I will not go to Google next time.

As I am using the lnmp one-click installation package, if there is a problem, we must first go to the official forum to search, really good, the official has such a top post, we first take a look.

Lnmp installs the package with one click:

The first reason: at present, the problem with more lnmp one-click installation packages is 502bad gateway. In most cases, 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 manually according to the script in the lnmp one-click installation package to see what error caused it.

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:

There are 502 problems in the process of installation and use, generally because the default php-cgi process is 5, which may be caused by insufficient phpcgi processes, so you need to modify / usr/local/php/etc/php-fpm.conf to increase the max_ child value appropriately.

The fourth reason:

Php execution timed out, modify / usr/local/php/etc/php.ini to change max_execution_time to 300

The fifth reason:

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

The sixth reason:

Check whether the php-cgi process is running

Some netizens have also given another solution:

Nginx 502 bad gateway means that the requested php-cgi has been executed, but the php-cgi process is terminated due to some reason (usually the problem of reading resources). Generally speaking, the nginx 502 bad gateway is related to the setting 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, but needs to be calculated by yourself.

There are 502 problems in the process of installation and use, generally because the default php-cgi process is 5, which may be caused by insufficient phpcgi processes, so you need to modify / usr/local/php/etc/php-fpm.conf to increase the max_ child value appropriately.

The method of calculation is as follows:

If your server performance is good enough and the broadband resources are sufficient, you can set the request_terminate_timeout to 0s directly if the php script does not have loops or bug. 0s means to keep the php-cgi running without a time limit. If you can't do this, that is to say, there may be some bug in your php-cgi, or your broadband is insufficient or your php-cgi is suspended for other reasons, then it is recommended that you assign a value to request_terminate_timeout, which can be set according to the performance of the server. Generally speaking, the better the performance, the higher you can set it, even 20-30 minutes.

And how is the value of max_children calculated? In principle, the larger the better, the more php-cgi processes will be processed quickly, and the number of queued requests will be very small. Setting max_children also needs to be set according to the performance of the server. Generally speaking, a server normally consumes about 20m memory per php-cgi.

According to the official answer, checked the relevant possibilities, and combined with the answers of netizens, came to the following solution.

1. Check the number of processes in php fastcgi (max_ child value)

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

5 (if displayed)

2. View the current process

Code: top

Observe the number of fastcgi processes. If the number of processes used is equal to or more than 5, it means that it needs to be increased (depending on the actual condition of your machine)

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

ten

60s

Max_children up to 10 processes, according to each process 20mb memory, up to 200mb.

The execution time of the request_terminate_timeout is 60 seconds, or 1 minute.

These are all the contents of this article entitled "how to solve nginx 502 Bad Gateway errors". Thank you for reading! I believe you will gain a lot after reading this article. The editor will update different knowledge for you every day. If you want to learn more knowledge, please pay attention to the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.