Server Load Balancer:CLB error status codes

400 (Bad request)

The HTTP request is malformed.

Possible causes for an upstream_status of 400:

• CLB uses HTTP to access the backend server, but the backend server is configured for HTTPS. To resolve this issue, use one of the following methods:

  • Configure the backend server to use the HTTP protocol.

  • Use Application Load Balancer (ALB) and create a server group that uses HTTPS as the backend protocol. For more information, see Create and manage server groups.

• The request passed the CLB validation but failed a custom validation check on the backend server. Investigate the backend server to determine why the validation failed.

Possible causes for a status of 400:

• The backend server returned a 400 status code, and CLB passed the status code to the client. Investigate why the backend server returned the 400 status code.

• The HTTP header of the client request is malformed. For example, the Content-Length does not match the request body size, the request method is not in uppercase, or an HTTP request was sent to an HTTPS listener. Capture packets on the client to analyze the request format and compare it with a valid request.

• An HTTPS listener is configured for the CLB instance. If the client sends a non-HTTPS request and receives a 400 status code, check whether the client sent an HTTP request to an HTTPS port.

• The client closed the connection before the HTTP request was complete. Capture packets to investigate why the client disconnected.

• CLB requires that each HTTP header does not exceed 32 KB. If this limit is exceeded, CLB returns a 400 status code. Reduce the HTTP header size to stay within the limit.

405 (Method not allowed)

The request method is not supported.

Possible causes for the backend status code (upstream_status): The backend server does not support the method used in the client request. We recommend that you check whether the method used by the client is compatible with the backend server. For example, you can use the curl -X method ip:port command to directly test whether the backend server supports a specific method, where method is the method used in the client request, ip is the IP address of the backend server, and port is the port of the backend server.

Possible causes for a status of 405:

• CLB does not support the TRACE request method. Use a different method.

• The backend server returned a 405 status code, and CLB passed the status code to the client. Investigate why the backend server returned the 405 status code.

408 (Request timeout)

The request timed out, and CLB closed the connection.

Possible causes for a status of 408:

• The client sent only partial data, such as only the HTTP header without the body, within the client-to-CLB request timeout period (60s by default). Capture packets on the client to check for performance bottlenecks or other abnormal behaviors.

• A network issue exists on the connection between the client and CLB, such as a high TCP round-trip time (RTT) or packet loss. Check the request_time and tcpinfo_rtt fields in the access log, or capture packets to diagnose network issues on the client side.

• Traffic to the CLB instance is too high, which triggers bandwidth throttling and connection drops. Check the outbound bandwidth and dropped connection metrics for the instance in CloudMonitor. For more information, see View CLB monitoring information.

414 (URI too long)

CLB rejected the request because the request URI is too long for the backend server to process.

Possible causes for an upstream_status of 414: If the backend server returns a 414 status code, use one of the following methods to resolve this issue:

• Shorten the URI, or use the POST method to transmit data.

• Increase the maximum URI length that the backend server accepts.

Possible causes for a status of 414:

• The backend server returned a 414 status code, and CLB passed the status code to the client. Investigate why the backend server returned the 414 status code.

• The URI of a request sent to CLB cannot exceed 32 KB. If the URI exceeds this limit, a 414 status code is returned. Shorten the URI. For large amounts of data, use the POST method.

499 (Client closed request)

The client closed the connection.

Possible causes for a status of 499:

• A network issue exists on the connection between the client and CLB, such as a high round-trip time (RTT) or packet loss. Check the request_time and tcpinfo_rtt fields in the access log, or capture packets to diagnose network issues on the client side.

• Traffic to the CLB instance is too high, which triggers bandwidth throttling and connection drops. Check the outbound bandwidth and dropped connection metrics for the instance in CloudMonitor. For more information, see View CLB monitoring information.

• The backend server took too long to process the request, which exceeded the client's request timeout period. The upstream_response_time field in the access log indicates the backend processing time. Check for performance bottlenecks on the backend server, such as high CPU, memory, or network usage.

• The request timeout period configured on the client is too short. As a result, the client closed the connection due to a timeout before the HTTP request was completely sent. Check the request_time field in the access log. This field indicates the total time of the client request. Use this value as a reference to set an appropriate request timeout on the client.

• The client encountered an unknown issue and closed the connection before the HTTP request was complete. Check whether the client prematurely closes connections.

500 (Internal server error)

The backend server encountered an internal error and could not fulfill the request.

Possible cause for an upstream_status of 500: The backend server returned a 500 status code. Check the error logs and other tools on the backend server to identify the cause.

Possible causes for a status of 500:

• The backend server returned a 500 status code, and CLB passed the status code to the client. Investigate why the backend server returned the 500 status code.

• The backend server unexpectedly closed the connection before sending a full response. Capture packets on the backend server to investigate why the connection was unexpectedly closed.

502 (Bad gateway)

An HTTP or HTTPS listener returns a 502 Bad Gateway status code if CLB cannot forward a client request to a backend server or fails to receive a response from the backend server.

Possible causes for an upstream_status of 502:

• TCP communication between CLB and the backend server is abnormal. Verify that the backend server is in a normal state and its service port is listening correctly. You can also capture packets to check if the TCP handshake is successful.

• The backend server is overloaded and fails to respond. For example, if the backend server backlog is full, packets are dropped. Use netstat to check the backend server's network statistics for a packet drop count. For example,

• The length of the packet sent by the client exceeds the maximum transmission unit (MTU) of the backend server. This can cause long packets to fail while short packets and health checks succeed. Capture packets on the backend server to analyze whether the packet length is acceptable.

• The packet returned by the backend server is malformed or contains an invalid HTTP header. Capture packets on the backend server to confirm whether the HTTP format is valid.

• The backend server did not complete request processing in time. Check the logs and resource utilization, such as CPU and memory, of the backend server.

Possible causes for a status of 502:

• The backend server returned a 502 status code, and CLB passed the status code to the client. Investigate why the backend server returned the 502 status code.

• The backend server returned a different error status code, such as 504 or 444, but CLB returns a 502 status code to the client. Check the upstream_status and status fields in the access log, or capture packets to check for issues on the backend server.

• All backend servers in a server group fail their health checks. The associated CLB instance cannot forward requests and directly returns a 502 status code. Check whether the health check configured for the listener is working as expected. For more information, see Health check FAQ.

503 (Service temporarily unavailable)

The server is temporarily unable to handle the request, often because traffic has exceeded a limit or the backend server is unavailable.

Possible cause for an upstream_status of 503: The backend server returned a 503 status code. Check the logs and other tools on the backend server to identify the cause.

Possible causes for a status of 503:

• The backend server returned a 503 status code, and CLB passed the status code to the client. Investigate why the backend server returned the 503 status code.

• Client request traffic has triggered the rate limiting of the CLB instance. For more information about CLB instance specifications, see Overview of CLB instances. To resolve this issue, use one of the following methods:

  • Upgrade the instance specification. For more information, see Change the specifications of a pay-as-you-go instance.

  • Use Alibaba Cloud DNS to point a domain name to multiple CLB instances to scale out.

  • For Layer 4 workloads that require more concurrent connections, use Network Load Balancer (NLB). For Layer 7 workloads that require higher QPS, use Application Load Balancer (ALB). For more information, see What is Application Load Balancer (ALB)? and What is Network Load Balancer (NLB)?.

  You can use one of the following methods to view the performance metrics of a CLB instance:

  • View the requests per second metric for the instance in CloudMonitor. For more information, see View CLB monitoring information.

  • CloudMonitor displays data at one-minute granularity and may not show per-second throttling. You can view the number of requests per second in the access log. If the upstream_status field in the access log is "-", the request was not sent to a backend server.

• The CLB listener has no backend servers configured, or all configured backend servers have a weight of 0.

504 (Gateway timeout)

The backend server response timed out.

Possible cause for an upstream_status of 504: The backend server returned a 504 status code. Investigate if the backend server timed out while accessing other internal services.

Possible causes for a status of 504:

• The backend server returned a 504 status code, and CLB passed the status code to the client. Investigate why the backend server returned the 504 status code.

• The connection from CLB to the backend server timed out. The default connection timeout period for a backend server is 5 seconds. Check if the value of the upstream_connect_time field in the access log is 5 or close to 5. Capture packets to investigate the cause of the response timeout.

• A high workload on the backend server causes its response time to exceed the configured request timeout period. For example, if the request timeout period is 60 seconds and the response time is 60.001 seconds, CLB returns a 504 status code. You can check the latency during the problematic period by viewing the upstream_rt metric in CloudMonitor or the upstream_response_time field in the access log.