Causes and solutions for front-end exception 502 bad gateway

502 Bad Gateway When the server acts as a gateway or proxy, it accesses the next server to complete the request, but the server returns an illegal response. The solution is: refresh the webpage or clean up the computer's cache files and then open the webpage you want to open. Generally speaking, this method works, but it does not rule out the possibility that the webpage you are visiting is blocked. If the webpage you are visiting is blocked, no matter how you refresh it, it will be useless.

502 bad gateway error formation

1. What is the 502 bad gateway error?

Simply put, 502 is an error code of bad gateway.

2. Causes of 502 Errors

Connection timeout. We sent a request to the server. Because the server currently has too many connections, the server cannot give a normal response, resulting in this type of error, as follows:

Reason 1: DNS caching

DNS caching. The common reason for this is that you are visiting a site like Facebook without a VPN.

At this time, it is naturally not accessible, but a buffer is left on the local machine.

This situation is usually accessible within a few minutes. You can also try running ipconfig /flushdns in a DOS window. This command will flush the DNS cache.

The second reason: browser proxy

Your browser has a proxy turned on. Make sure to turn off the proxy.

The third reason: DNS is hijacked

The dns has been hijacked. Even if you use a foreign dns, it will be hijacked. Some machines can be accessed with VPN, but some machines cannot. And the causes of proxy, firewall and local network have been ruled out. At this time, ping remote websites, such as Facebook. The inaccessible machine usually gets a weird IP address that cannot be pinged from anywhere. The IP address of the accessible machine can be directly accessed from the inaccessible machine and can also be pinged. In this case we can remove the DNS of the VPN server.

Switch to another dns. In Windows system, you can remove the default DNS in the properties of the local network connection and choose a foreign DNS, such as Google's. or opendns.

3.502 HTTP cycle error

Any client (like a web browser or our CheckUpDown robot) communicates with your web server by going through the following loop:

Get your website's IP address from the IP name (the leading 'http://' in your website's URL). This lookup (converting IP names to IP addresses) is provided by Domain Name Servers (DNSs).

Open an IP socket connection to that IP address. Writes a stream of HTTP data through this socket.

Receive an HTTP data stream from your web server with the response. This data stream contains the status code values ​​​​generated by the HTTP protocol. Parse this data stream for status codes and other useful information.

This error occurs in the last step when the client above receives an HTTP status code that it confirms is "502".

4. Fix 502 Errors

Generally this problem is due to poor IP communication between the backend computers, including the website on the web server that you may be trying to access. Before analyzing this problem, you should completely clear your browser cache.

If you see this problem on every website you try to visit while surfing the Internet, there are two possibilities:

• 1) Your ISP has a major equipment failure/overload
• 2) There is a problem with the internal Internet connection such as your firewall not functioning properly.

In the first case, only your ISP can help you. In the second case, it is up to you to resolve any issues that are preventing you from accessing the Internet.

If this problem only occurs on some of the websites you try to visit, then there is most likely a problem with one of those websites having a malfunctioning or overloaded equipment. Contact the site's administrator.

5. How to solve the problem of 502 bad gateway

The simplest method: CTRL+F5 force refresh

The best solution is of course to do it on the server, which is not possible for everyone, so what solution do we have? To put it simply, it is very simple, that is - refresh (not just a normal refresh)

The principle of refresh: Many people may not know that there are two types of refresh. The so-called refresh actually means downloading data from the server to the local hard disk browser, and then reading data from the local hard disk to the browser to display it to us.

• ① Basic refresh: click refresh or use the F5 shortcut key. Basic refresh only retrieves data from the local hard disk to the browser, and does not re-issue a request to the server. Most users refresh in this way most of the time, and if they encounter a 502 error, it will have no effect.
• ② Refresh from the server: If you directly click on the web link you want to browse again, you will find that the page that just showed 502 bad getway can now be browsed normally! Do you understand the logic? When you click on the link of the web page you want to browse, the data will be downloaded again from the server. The solution is to refresh from the server: shortcut key ctrl+F5, which will resend the request to the server. If the server can respond to you normally, you can see the page.

Attached: Causes and solutions for Nginx 502 Bad Gateway error

Causes and solutions for Nginx 502 Bad Gateway error

I have encountered the Nginx 502 Bad Gateway error several times. I’ll make a note of it here as a reminder.

There are many situations in which 502 errors may occur. Let's talk about each situation separately.

1. The fastcgi buffer is set too small

When an error occurs, first look for the nginx log file in the directory /var/log/nginx. The following error is found in the log.

2013/01/17 13:33:47 [error] 15421#0: *16 upstream sent too big header while reading response header from upstream

After checking the information, I found that there is a bug in the nginx buffer, and the pages on our website may consume too much buffer.

I searched for a solution online and saw a method to increase the buffer on a foreign website, which completely solved the Nginx 502 Bad Gateway problem. Here’s how:

http {
    ...
    fastcgi_buffers 8 16k;
    fastcgi_buffer_size 32k;
    ...
}

Please increase the above two configuration items according to the situation of the server and website.

2. The proxy buffer is set too small

If you are using nginx reverse proxy, if the header is too large, exceeding the default 1k, it will trigger the upstream sent too big header mentioned above (to put it simply, nginx sends the external request to the backend for processing, and the header returned by the backend is too large, which nginx cannot process, resulting in 502.

server {
        listen 80;
        server_name *.lxy.me;
 
        location / {
 
################Add these 3 lines proxy_buffer_size 64k;
            proxy_buffers 32 32k;
            proxy_busy_buffers_size 128k;
###############Add these 3 lines proxy_set_header Host $host;
            proxy_set_header X-Real-IP $remote_addr;
            proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
............
}

3. The default number of php-cgi processes is too small

If a 502 error occurs during installation and use, it is usually because the default number of php-cgi processes is 5. 502 may be caused by insufficient phpcgi processes. You need to modify /usr/local/php/etc/php-fpm.conf and increase the max_children value appropriately. It is also possible that the max_requests value is not enough. It should be noted that these two configuration items take up a lot of memory, please set them according to the server configuration. Otherwise it may have the opposite effect.

4. PHP execution timeout

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

5. nginx waiting time timeout

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.

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

How to troubleshoot nginx 502 bad gateway

Some websites running on Nginx sometimes get the "502 Bad Gateway" error, sometimes even frequently. The following are some Nginx 502 error troubleshooting methods collected and sorted by the editor for reference:

There are many reasons for Nginx 502 errors, which are caused by problems with the backend server in proxy mode. These errors are generally not problems with nginx itself, and the reasons must be found from the backend! But nginx took all the blame for these mistakes, which really made nginx promoters questionable. After all, from the word point of view, it means bad gateway? Isn’t it just bad nginx? If people who don't understand the problem see this, they will directly put the blame on nginx. I hope that the next version of nginx will make the error message a little more friendly, at least not the simple 502 Bad Gateway that it has now, and not forget to attach its own name.

Nginx 502 trigger conditions

The most common occurrence of a 502 error is when the backend host crashes. There is a configuration in the upstream configuration: proxy_next_upstream. This configuration specifies what kind of error nginx encounters when retrieving data from a backend host and will forward it to the next backend host. It contains all the situations in which 502 will appear. The default is error timeout. Error means crash, disconnection, etc., and timeout means read congestion timeout, which is easier to understand. I usually write the whole thing:

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 redirect to another host. If there is an error in the backend jsp, a bunch of stacktrace error information will be printed, but now it is replaced by 502. But the programmers in the company didn’t think so. They believed that there was an error in nginx. I really didn’t have time to explain the principle of 502 to them...

The 503 error can be retained because the backend is usually Apache Resin. If Apache crashes, it is an error, but if Resin crashes, it is only 503, so it is still necessary to retain it.

Solution

If you encounter a 502 problem, you can prioritize solving it by following the following two steps.

1. Check whether the current number of PHP FastCGI processes 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 means that the number of FastCGI processes is insufficient 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:

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

If the memory_limit in php.ini is set too low, an error will occur. I changed the memory_limit in php.ini to 64M, restarted nginx, and found that it was fixed. It turned out that PHP had insufficient memory.

If this modification still 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 3 million pv.

Recently, the following situation often occurs: PHP pages open very slowly, the CPU usage rate suddenly drops to a very low level, the system load suddenly rises to a very high level, and when checking the traffic of the network card, it is found that it has suddenly dropped to a very low level. This situation only lasted for a few seconds before recovering.

Checking the php-fpm log files revealed 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″ 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 about closing and opening children.

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

During this period, nginx cannot transfer php files to php-fpm for processing, so the CPU will drop to a very low level (no need to process php, let alone execute sql), while the load will rise to a very high level (closing and opening children, nginx waiting for php-fpm), and the network card traffic will also drop to a very low level (nginx cannot generate data to transmit to the client)

The solution is simple, increase the number of children and set max_requests to 0 or a larger value:

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

<value name="max_children">5120</value> <value name="max_requests">600</value>

Then restart php-fpm.

2. Increase the buffer size

I opened the nginx error log and found an error message like "pstream sent too big header while reading response header from upstream". After checking the information, I found that there is a bug in the nginx buffer, and the pages on our website may consume too much buffer. Referring to the modification method written by a foreigner, the buffer capacity size setting was added, and the 502 problem was completely solved. Later, the system administrator adjusted the parameters and only retained two settings: client head buffer and fastcgi buffer size.

3. request_terminate_timeout

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

request_terminate_timeout

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

0s

0s means shutdown, which means it will execute indefinitely. (I changed a number without paying attention when installing it) The problem is solved and there will be no errors when executing for a long time. When optimizing fastcgi, you can also change this value to 5s to see the effect.

A 502 error may occur if the number of php-cgi processes is insufficient, the php execution time is long, or the php-cgi process dies.

The above is the full content of this article. I hope it will be helpful for everyone’s study. I also hope that everyone will support 123WORDPRESS.COM.