A 502 Bad Gateway error occurs when you are using Anti-DDoS Advanced, as shown below:
Possible causes
The following figure shows how the business traffic flows:
Cause 1: The forwarding IP is blocked by the real server or limited to a specific rate.
After you connect to Anti-DDoS Advanced, Anti-DDoS Advanced will process access requests as a proxy for the real server and send received requests to the real server using the forwarding IP instead of the client IP. Thus, the real server IP becomes invisible to the client. However, the number of forwarding IPs is insufficient to handle volumes of access requests.
If the real server is configured with protection policies, it is possible to trigger corresponding policies to limit the rate of the forwarding IP and even block it.
Cause 2: The real server works abnormally, causing a response timeout.
Possible reasons:
1. The real server IP is not connected to Anti-DDoS Advanced and crippled by malicious attacks.
2. A failure occurs to the data center of the real server.
3. High memory and CPU usage lead to weakening performance.
4. Web programs such as Apache and Nginx are abnormal.
5. The forwarding linkage between the public network and the real server is faulty.
Cause 3: There is network jitter or faulty linkage.
The poor public network quality affects the stability of business access and a 502 error is returned.
Test whether access to the real server IP and the Anti-DDoS Advanced forwarding IP is normal through the Cloud Automated Testing (CAT) platform. For the testing method, see here.
If only the real server IP works normally, the forwarding IP is blocked by the real server or is rate-limited. We recommend you add the forwarding IP to your allowlist.
Modify the local host resolution result to the real server to check whether the real server works normally. Firstly, edit the hosts file and ensure that the binding in the file has taken effect. Then use your domain name to check whether the real server can be accessed normally. If the access fails, perform the following steps:
1. Protect the real server IP, as instructed in Measure 1.
2. Ask for technical support to troubleshoot the data center, as instructed in Measure 2.
3. Check whether the web service is normal and restore it if it works abnormally, as instructed in Measure 3.
4. Check whether performance metrics such as the server process occupancy and memory usage are normal, and restore them to normal, as instructed in Measure 4.
5. Check the network layer. Alternatively, check the linkage status or change to another linkage. You can refer to Measure 5.
Add the forwarding IP range of Anti-DDoS Advanced to the firewall and host security software allowlists. Here, let's take the firewall of CentOS 6.5 as an example:
1. Run the following command to check the Linux firewall status.
service iptables status
If there are no rules for Chain INPUT, Chain FORWARD, and Chain OUTPUT displayed in the console, the firewall is not yet started.
2. Run the following command to check the firewall configuration file.
cat /etc/sysconfig/iptables
Make sure that you have completed the blocklist and allowlist configuration before you start the firewall.
3. Run the following command to start the firewall.
service iptables start
4. Run the following command to check the firewall status again.
service iptables status
If any rules for Chain INPUT, Chain FORWARD, and Chain OUTPUT are displayed in the console, the firewall is started successfully.
5. Run the following command to add the forwarding IP range to the firewall allowlist.
Iptables -A INPUT -s Forwarding IP -j ACCEPT
6. Run the following command to check whether the configured allowlist policy is added to the firewall settings.
iptables -nL --line-number
The allowlist policy is added successfully if there are firewall rules in the output.
7. Run the following command to save the firewall settings.
service iptables save
8. Run the following command to restart the firewall to have the configuration take effect.
service iptables restart
Instructions for cause 2
Modify the local host resolution result to the real server to check whether the real server is normal. Firstly, modify the local hosts file. The specific steps are as follows:
1. Edit the local hosts file to allow local requests to the protected business domain name to reach the real server. The following uses the Windows OS as an example to configure the local hosts file:
Open the hosts file in C:\\Windows\\System32\\drivers\\etc, and add the following content at the end of the file:
For example, if the real server IP is 10.1.1.1 and the domain name is www.qqq.com, add:
Save the hosts file. Run the ping command to ping the protected domain name on the local computer.
If the resolved IP address is the real server IP address bound in the hosts file, the file has taken effect. Otherwise, run ipconfig /flushdns in the Windows command prompt to refresh the local DNS cache.
2. After confirming the binding in the 'hosts' file has taken effect, check whether access to the real server is normal using the domain name. If the real server cannot be accessed normally, the following measures can be taken.
Measure 1: Protect the real server IP.
Check whether the real server has a significant increase in traffic and request volume, and the monitoring data from the Anti-DDoS Advanced console. The following describes how to check the real server traffic volume when the OS is CentOS.
1. Check the traffic usage of a Linux server using iftop:
Run the command`iftop [-i interface]`. The parameter `interface` indicates the API name, such as eth0 and eth1.
The output is as follows:
Output description:
The bandwidth usage is displayed at the top.
The external connection list is in the middle. The list records IPs that are connecting to the local network.
On the right of the list is the real-time traffic information, which is the average traffic of 2 seconds, 10 seconds, and 40 seconds when the real server is accessed.
=> means sending data and <= means receiving data.
The bottom three lines:
In the first column, TX stands for sending traffic, RX for receiving traffic, and TOTAL for total traffic.
In the second column, cumm stands for the total traffic in the first column.
In the third column, peak stands for the peak traffic in the first column.
In the fourth column, rates stands for the average traffic for each period of 2 seconds, 10 seconds, and 40 seconds.
2. For instructions on how to view business traffic in the Anti-DDoS Advanced console, see Protection Overview.
If the real server is attacked by a large amount of traffic without any exceptions displayed in the Anti-DDoS Advanced console, the attacks might have bypassed Anti-DDoS Advanced. You can refer to In Case of Real Server IP Exposed to deal with this situation.
Measure 2: Ask for technical support to troubleshoot the data center.
You can check whether the data center has physical hardware failures, such as failures with power, network interface card, drive, memory, and wiring.
Measure 3: Check the web service.
Check the monitoring data of the real server, such as CPU usage, memory usage, and bandwidth usage.
Note:
Normally, if the usage of CPU or memory exceeds 90% for a long time, the web service is in abnormal status.
You need to compare the bandwidth usage with business process occupancy during normal periods to see if there is a significant increase. For more details, see CVM Bandwidth Utilization Is Too High.
If there is an exception, please contact technical support for further troubleshooting.
Measure 4: Check server performance parameters such as server process occupancy and memory usage.
Check the web program status. Run the ps -C nginx -o pid command to check whether the server's nginx process is running normally.
If there is an exception, please contact technical support for further troubleshooting.
Measure 5: Check the network layer or the linkage status.
Run a check on the linkage quality, linkage connectivity, and forwarding status of the intermediate network equipment between the public network and the real server. You can also verify and avoid the issue by changing to another linkage.
Instructions for cause 3
Check and monitor the public network quality of the real server IP and the Anti-DDoS Advanced forwarding IP through the CAT platform. For the monitoring method, see here.
If the public network is not working well, contact the ISP for assistance.
Yes
No
Was this page helpful?