Loading

504 Gateway Time-out or 502 Bad Gateway HTTP Errors from CloudHub Dedicated Load Balancer

Дата публикации: Jun 21, 2025
Решение

SYMPTOM

When sending a HTTP Request to a CloudHub Application that utilizes a Dedicated Load Balancer, the client receives a 504 Gateway Time-out or 502 Bad Gateway. Please note that this article is only for CloudHub; if you see a 502 error on RTF, one possible cause is given in Runtime Fabric 502 error to HTTPS application after deploy.

For Example 

 
$ curl https://lb-daniel.lb.anypointdns.net/dlb-test-kb/hello
<html>
<head><title>504 Gateway Time-out</title></head>
<body bgcolor="white">
<center><h1>504 Gateway Time-out</h1></center>
<hr><center>nginx</center>
</body>
</html>

$ curl https://lb-daniel.lb.anypointdns.net/dlb-test-kb/hello
<html>
<head><title>502 Bad Gateway</title></head>
<body bgcolor="white">
<center><h1>502 Bad Gateway</h1></center>
<hr><center>nginx</center>
</body>

 

CAUSE

1. 504 Gateway Time-out

  • This is often caused by the CloudHub Application that the DLB is forwarding to is either not running or is in an unhealthy state.
  • It can also be caused by a resource (e.g., DB) upstream of the application not returning before the DLB timeout.
  • A 504 indicates that the DLB was able to reach the application, but the application did not return a result before the DLB timeout.

2. 502 Bad Gateway

    This always means that the backend application is unreachable by the DLB, a number of reasons can lead to it:

  • The CloudHub Application's HTTP Listener configured to the incorrect port number
  • Unsupported TLS version
  • Application deployed outside the VPC

As a generalization, a 5xx error for Dedicated Load balancer usually indicates some issue with the backend CloudHub application that the DLB is trying to forward to.

Both of these errors can also occur if the URL mapping rules are configured incorrectly, which results in the request being forwarded to the wrong/unintended application. To check if the URL mapping rules are configured correctly, refer to the following article: DLB URL Mapping Guidelines for Input Path

3. 502 Bad Gateway due to oversized response header from applications 502 Bad Gateway From DLB Due to Big Header from Upstream

SOLUTION

1. 504 Gateway Time-out

  • Check that application is successfully running. Look in the Runtime Manager console to check for a green icon indicating the application is up and running or look for the most recent restart in your logs, because it is likely, if running on a single worker, every request will fail for a limited time period.
  • Check the application is healthy, check the logs for error messages. There is a possibility that the application is running, but is in a hung state and not responding to HTTP. If you suspect the application is hung / not responding, take thread dumps using the diagnostic monitoring capability. You can analyze the thread dumps, or open a support case with MuleSoft Customer Support for assistance.
  • Use wire logging to inspect the transaction received from the DLB.
  • It's possible that you have run out of CPU credits available to a fractional vCore worker. As the balance is not visible from the CloudHub Console (refer to this Idea) it's hard to determine this. If you suspect this is the case, please still gather diagnostic information as mentioned above, and check the threads. If this is the case, the Symptom will be that there aren't many active worker threads, but the application will appear not to be processing until a restart, a prolonged period of zero activity or deployment to a full vCore worker.


2. 502 Bad Gateway

  • Dedicated Load Balancer will only forward to ports 8091 (HTTP) or 8092 (HTTPS). Check that the target application's HTTP listener is configured to receive requests on 8091 or 8092. This port misconfiguration can be caused by accidentally trying to override the properties http.port or https.port to 8091 or 8092. In CloudHub, this is not possible, these properties always resolve to 8081 and 8082 respectively and cannot be overridden. In order to avoid this, use a property like ${http.private.port} or ${https.private.port} and configure your properties file to include http.private.port=8091 or https.private.port=8092 and use this within the listener, as below.
<http:listener-config name="HTTP_Listener_Configuration" host="0.0.0.0" port="${http.private.port}" doc:name="HTTP Listener Configuration"/>
  • 502 Bad Gateway can also be caused when the app deployed to CloudHub doesn't support TLSv1.1 and only supports TLSv1.2. The DLB supported inbound connections on TLSv1.1 and 1.2, but when the DLB acts as a client and connects to the CloudHub app, it uses TLSv1.1. If you run into 502 Bad Gateway and your app doesn't support TLSv1.1, enable that, update your app and test again.
  • Make sure that the environment your application pertains to is associated with the same VPC your DLB belongs to. If this is not the case, then correct the association. If you have already corrected the association, keep in mind you will need a redeployment. Refer to Changed VPC Association with Environment But Still Don't See Apps Using New VPC CIDR or Traffic Going To New VPC's VPN
  • Make sure the configured protocol for the rule under the Mapping Rules section matches with what is configured for the application's listener as described above. Take into account the rule's priority, refer to this article for more information: Checklist of using DLB mapping rules


Reference: CloudHub Dedicated Load Balancer

Номер статьи базы знаний

001118075

 
Загрузка
Salesforce Help | Article