Help Center/ Web Application Firewall/ Troubleshooting/ Troubleshooting Website Connection Exceptions/ What Should I Do If Error 502 or 400 Is Reported After My Website Is Connected to WAF in Dedicated Mode?
Updated on 2026-09-23 GMT+08:00

What Should I Do If Error 502 or 400 Is Reported After My Website Is Connected to WAF in Dedicated Mode?

Symptom

After a website is connected to WAF in dedicated mode, a 502 Bad Gateway or 400 Bad Request error occurs when the website is accessed. This usually indicates that the communication between the dedicated WAF engine and the origin server is faulty. Take the following steps to locate the fault.

Troubleshooting

Table 1 Table 1 Troubleshooting

No.

Probable Cause

Solution

1

Cause 1: The Dedicated WAF Instance Is Abnormal

Check the status and health check result of the dedicated engine instance.

2

Cause 2: The Back-to-Origin IP Addresses Are Blocked by the Security Policy of the Origin Server

Check whether the security group and firewall of the origin server allow access from the back-to-origin IP addresses of the dedicated engine.

3

Cause 3: The ELB Listener Is Incorrectly Configured

Check the mapping between the ELB listener protocol, port, and the WAF protection port.

4

Cause 4: The Security Group Rule Does Not Allow the Origin IP Address

Add an inbound rule to the origin server security group to allow access from the back-to-origin IP addresses of the dedicated engine.

5

Cause 5: The Origin Server Service Status Is Abnormal

Check whether the origin server is running properly and whether its performance is sufficient.

Cause 1: The Dedicated WAF Instance Is Abnormal

  1. Log in to the WAF console.
  2. In the navigation pane on the left, choose Assets > Dedicated WAF Engines.
  3. Check the Running Status column of the target dedicated engine instance.

Cause 2: The Back-to-Origin IP Address Is Blocked by the Security Policy of the Origin Server

After a website is connected to WAF in dedicated mode, all requests are returned to the origin server through the dedicated engine instance. All source IP addresses displayed on the origin server are the back-to-origin IP addresses of the dedicated engine instance (that is, the subnet IP address corresponding to the dedicated engine instance). The security software (such as security groups, firewalls, and CFW) on the origin server may mistakenly identify the back-to-origin IP address as a malicious IP address and block it. If the back-to-origin IP address of WAF is blocked, the origin server will deny all WAF requests. As a result, your website may become unavailable or respond very slowly.

You can take the following steps to check whether the back-to-origin IP address is blocked by the origin server security policies:

  1. Log in to the WAF console.
  2. In the navigation pane on the left, choose Assets > Dedicated WAF Engines.
  3. On the Dedicated WAF Engines page, click the IP address in the IP Address column of the dedicated engine and copy the address.
  4. Check whether the following security policies of the origin server allow the back-to-origin IP address:

    • ECS security group: Ensure that all ports mapping to the dedicated engine back-to-origin IP address are allowed in the inbound rules. For details, see Whitelist the Back-to-Origin IP Addresses of Your Dedicated WAF Instances.
    • Cloud Firewall (CFW): If CFW is used for the origin server, allow WAF back-to-origin IP addresses on CFW.
    • Host security software: Ensure that the back-to-origin IP addresses are not blacklisted by host security software or services, such as HSS.

  1. Use Telnet to test connectivity: telnet Origin_server_IP_address Service_port.

    If the port cannot be directly connected but the website can still be accessed, the security group rules are correctly configured. (Direct access is blocked, and only WAF back-to-origin is allowed.)

Cause 3: The ELB Listener Is Incorrectly Configured

  1. Go to the load balancer list page.
  2. Click the name of the target load balancer used for the dedicated WAF instance to go to the details page.
  3. On the Listeners tab, click the name of the target listener. On the displayed details page, check the following configurations:

    • Frontend Protocol/Port: Ensure that the protocol and port are the same as those used by your real-world service.
    • Default Backend Server Group: Ensure that the dedicated WAF instance has been added to the backend server group and the Health Check result is Healthy.
    • Backend Protocol/Port: If the backend protocol for the backend server group is HTTP or HTTPS, ensure that the backend protocol and port of the backend server group are the same as the access protocol and port of the WAF-protected domain name.
    • Load Balancing Algorithm: If you select Weighted round robin, ensure that Sticky Session is disabled. If Sticky Session is enabled, requests may be always forwarded to a specific engine instance. If the instance is faulty, an error occurs.

  4. If the ELB health check is abnormal, temporarily disable the health check and perform a test to check whether the health check configuration is correct.

Cause 4: The Security Group Rule Does Not Allow the Origin IP Address

  1. Log in to the ECS console.
  2. On the ECS instance details page, click the Security Groups tab.
  3. Check whether the inbound rule that allows the dedicated engine back-to-origin IP address has been added:

    • Action: Allow.
    • Protocol & Port: TCP Custom_port. The port number is left empty or falls into 1–65535 (to allow all ports).
    • Source: Each subnet IP address of all dedicated WAF instances has been added.

  4. If the inbound rule is not configured, configure it by referring to Whitelist Back-to-Origin IP Addresses of Your Dedicated WAF Instance.

Cause 5: The Origin Server Service Is Abnormal

  1. Check whether the origin server service is running properly.

    • Log in to the origin server and check whether the web service (such as Nginx, Apache, or Tomcat) is started and running properly.
    • Check whether the listening port of the origin server is the same as the origin server port configured in WAF.

  2. Check the origin server performance.

    • Check whether the CPU, memory, or disk usage is too high.
    • Check whether the network bandwidth is sufficient. If the origin server bandwidth is insufficient, a 504 response may be returned due to response timeout.

  3. Test the origin server connectivity.

    • Create an ECS that is in the same VPC as the dedicated WAF instance and send a request to the origin server.

      curl -kv -H "Host: Protected_object_added_to_WAF" http://Origin_server_IP_address:Origin_server_port

    • If the returned code is 200, the origin server is working properly. The fault may be caused by incorrect WAF or ELB configurations.
    • If the returned code is not 200, the origin server is faulty. Check the web service configuration of the origin server.

  4. Check whether WAF break protection is triggered.

    • When a large number of 502/504 errors occur or requests are stacked on the origin server, WAF triggers break protection and returns a response similar to {"status": "System is busy, please try again later."}.
    • In dedicated mode, you can adjust the settings of Break Protection and Connection Protection in Breakdown Protection on the WAF console.

  5. Check whether the HTTP/HTTPS protocol configurations match.

    • If the client protocol is different from the origin server protocol, WAF will perform protocol conversion. For example, if the client protocol is HTTPS and the origin server protocol is HTTP, WAF decrypts HTTPS requests and forwards them to the origin server using HTTP.
    • If HTTP-to-HTTPS redirection is configured on the origin server but only HTTPS-to-HTTP forwarding is configured in WAF, an infinite redirection loop will occur. Configure two forwarding rules: HTTP to HTTP and HTTPS to HTTPS.

Submitting a Service Ticket

If the problem persists, Submitting a Service Ticket.