:CLB status codes

400 (Bad Request)

The format of an HTTP request is invalid.

Possible causes if the value of the upstream_status field is 400

• CLB uses HTTP to access the backend server, but the backend server uses HTTPS. We recommend that you use one of the following methods to resolve this issue:

  • Change the protocol of the backend server to HTTP.

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

• The packet passes the verification of the CLB instance, but fails the verification of the backend server that uses different logic. We recommend that you check why the packet fails the verification of the backend server.

Possible causes if the value of the status field is 400

• The backend server returns the 400 status code, and CLB passes the backend status code to the client. We recommend that you check why the backend server returns the 400 status code.

• The HTTP header of the client request uses an invalid format. For example, the length of the content is different from the length of the request body, the request method is not capitalized, or the HTTPS service is accessed over HTTP. We recommend that you capture packets on the client and compare the HTTP requests with valid HTTP requests.

• An HTTPS listener is added to the CLB instance. If the client does not send an HTTPS request but the 400 status code is returned, we recommend that you check whether the client sent an HTTP request to an HTTPS port.

• Before the HTTP request is sent, the client closes the connection. We recommend that you capture packets and identify the cause of the disconnection.

• CLB requires that an HTTP header does not exceed 32 KB in size. Otherwise, CLB returns the 400 status code. We recommend that you adjust the length of the HTTP header.

405 (Method not allowed)

The request method is not supported.

Possible causes if the value of the upstream_status field is 405: The backend server does not support the request method that is used by the client. We recommend that you check whether the request method matches the method that is used by the backend server. For example, to check whether a specific method is supported by a backend server, run the curl -X method ip:port command. method specifies the request method that is used by the client, ip specifies the IP address of the backend server, and port specifies the port of the backend server.

Possible causes if the value of the status field is 405

• CLB does not support the TRACE request method. We recommend that you use other methods.

• The backend server returns 405, and CLB passes the backend status code to the client. We recommend that you check why the backend server returns 405.

408 (Request Timeout)

The request timed out and CLB closes the connection.

Possible causes if the value of the status field is 408

• During the request timeout period, only part of the request is sent, and CLB closes the connection. For example, only the HTTP header is sent and the body is not sent. We recommend that you capture packets to check whether the client has performance bottlenecks or other abnormal behaviors. You can also increase the request timeout period of the CLB listener to check whether the issue can be resolved. For more information, see CLB FAQ.

• Issues exist on the connection between the client and the CLB instance. The round-trip time (RTT) of TCP packets is large or packet loss occurs. We recommend that you check the request_time and tcpinfo_rtt fields of the access log or capture packets to check whether the client network is abnormal.

• Traffic to the CLB instance is excessively large, which causes bandwidth throttling and packet loss. We recommend that you check the outbound bandwidth and the number of dropped connections of the CLB instance by using CloudMonitor. For more information, see View monitoring information about a CLB instance.

414 (URI too long)

The URI length of the client request exceeds the length that is supported by the backend server, and CLB rejects the request.

Possible causes if the value of the upstream_status field is 414: If the backend server returns 414, we recommend that you use one of the following methods to resolve this issue:

• Shorten the URI and use the POST method to transmit data.

• Increase the URI length of client requests that is supported by the backend server.

Possible causes if the value of the status field is 414

• The backend server returns 414, and CLB passes the backend status code to the client. We recommend that you check why the backend server returns 414.

• The URI of requests to CLB cannot exceed 32 KB in size. If the URI of a request exceeds 32 KB, the 414 status code is returned. We recommend that you shorten the URI. If the amount of data to be transmitted is large, we recommend that you use the POST method to transmit data.

499 (Client Close Request)

The client closes the connection.

Possible causes if the value of the status field is 499

• Issues exist on the connection between the client and the CLB instance. The RTT is large or packet loss occurs. We recommend that you check the request_time and tcpinfo_rtt fields of the access log or capture packets to check whether the client network is abnormal.

• Traffic to the CLB instance is excessively large, which causes bandwidth throttling and packet loss. We recommend that you check the outbound bandwidth and the number of dropped connections of the CLB instance by using CloudMonitor. For more information, see View monitoring information about a CLB instance.

• The request processing time of the backend server is excessively long, and exceeds the request timeout period of the client. The upstream_response_time field in the access log indicates the time that is required for the backend server to process the request. We recommend that you check the CPU, memory, and network of the backend server for performance bottlenecks.

• The request timeout period that is configured on the client is too short. As a result, the client closed the connection before the HTTP request is sent. We recommend that you check the request_time field in the access log. This field indicates the time that is required for the client to send the request. Refer to the value of this field to set a proper request timeout period on the client.

• The client encounters an unknown issue and closes the connection before the HTTP request is sent. We recommend that you check whether the client closes the connection before the HTTP request is sent.

500 (Internal Server Error)

An internal error occurred on the backend server. The request cannot be processed by the backend server.

Possible causes if the value of the upstream_status field is 500: The backend server returns the 500 status code. We recommend that you use tools such as the error log of the backend server to determine why the backend server returns the 500 status code.

Possible causes if the value of the status field is 500

• The backend server returns 500, and CLB passes the backend status code to the client. We recommend that you check why the backend server returns 500.

• The backend server closes the connection before sending the response. We recommend that you capture packets on the backend server to determine the cause and troubleshoot.

502 (Bad Gateway)

The HTTP or HTTPS listener of CLB fails to send the request to the backend server or no response is returned from the backend server. As a result, the 502 status code is returned to the client.

Possible causes if the value of the upstream_status field is 502

• The communication between CLB and the backend server over TCP is abnormal. Check whether the status of the backend server is normal, whether the service port is being listened as expected, or whether the TCP SYN packets are normal.

• The backend server fails to respond due to excessive workloads. For example, if the backend backlog is full, packets are dropped. We recommend that you use netstat to check whether the network statistics of the backend server show the number of dropped packets.

• The length of the packets sent by the client exceeds the maximum transmission unit (MTU) of the backend server. In this case, the health check is successful, or shorter packets are sent as expected. However, longer packets are not sent as expected. We recommend that you capture packets on the backend server to analyze whether the packet length meets the requirements.

• The packets returned by the backend server are in an invalid format or contain invalid HTTP headers. We recommend that you capture packets on the backend server to check whether the formats of the packets are invalid.

• The backend server of CLB has not completed the processing of the request. Check the log data of the backend server. In addition, check the CPU utilization and the memory usage.

Possible causes if the value of the status field is 502

• The backend server returns 502, and CLB passes the backend status code to the client. We recommend that you check why the backend server returns 502.

• The backend server returns another status code (such as 504 and 444), but CLB returns 502. We recommend that you check the upstream_status and status fields of the access log or capture packets to check whether the backend server has exceptions.

• All backend servers of the same server group are abnormal. The CLB instance associated with the server group cannot forward requests and returns 502. We recommend that you check whether the listeners pass health checks. For more information, see Health check FAQ.

503 (Service Temporarily Unavailable)

The service is unavailable because traffic exceeds the limit or the backend server is unavailable.

Possible causes if the value of the upstream_status field is 503: The backend server returns the 503 status code. We recommend that you use tools such as the error log of the backend server to determine why the backend server returns the 503 status code.

Possible causes if the value of the status field is 503

• The backend server returns 503, and CLB passes the backend status code to the client. We recommend that you check why the backend server returns 503.

• Traffic from clients triggers CLB throttling. For more information about CLB instance specifications, see Overview. We recommend that you use one of the following methods to resolve this issue:

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

  • Use Alibaba Cloud DNS to point a domain name to multiple CLB instances. This way, more requests can be processed.

  • If you require more concurrent connections at Layer 4, use Network Load Balancer (NLB). If you require a higher queries per second (QPS) value at Layer 7, use ALB. For more information, see What is ALB and What is NLB.

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

  • View the number of requests per second in the CloudMonitor console. For more information, see View monitoring information about a CLB instance.

  • CloudMonitor displays monitoring data at the minute level. You can view the number of requests per second by using the access log. View the upstream_status field of the access log. If the content is "-", the request is not sent to the backend server.

• No backend server is associated with the listener or the weight of the backend server is set to 0.

504 (Gateway Time-out)

The response of the backend server timed out.

Possible causes if the value of the upstream_status field is 504: The backend server returns the 504 status code. We recommend that you check whether the response timed out because the backend server accesses other internal services.

Possible causes if the value of the status field is 504

• The backend server returns 504, and CLB passes the backend status code to the client. We recommend that you check why the backend server returns 504.

• The connection from CLB to the backend server timed out. The response timeout period of the backend server is set to 5 seconds by default. You can check whether the upstream_connect_time field in the access log is set to 5 seconds or approximately 5 seconds. We recommend that you capture packets to determine the cause of the response timeout.

• The workload on the backend server is heavy and the time that is required to return a response is longer than the specified timeout period. For example, the configured request timeout period is 60 seconds. If the response time is 60.001 seconds, CLB returns 504. You can view the latency during the period in which issues occur in the CloudMonitor console or in the access log. To view the latency, check the upstream_rt field in CloudMonitor, or the upstream_response_time field in the access log.