Server Load Balancer:ALB status codes

Backend directly returns 400: Check the access logs. If the value of upstream_status is 400, ALB likely passed through the upstream status code. Troubleshoot the backend service.

HTTP request sent to HTTPS listener: The HTTPS listener of ALB rejects non-HTTPS requests and returns 400. Check whether the client mistakenly sent an HTTP request to the HTTPS port.

Request header size exceeded: ALB requires that each HTTP request header does not exceed 32 KB. If this limit is exceeded, 400 is returned. Reduce the length of the HTTP request header.

Request not fully sent: The client closed the connection before the HTTP request was fully sent. Capture packets on the client to analyze the cause.

Request header format error: For example, Content-Length does not match the actual request body length. Capture packets on the client to analyze the HTTP request format and compare it with normal requests.

ALB limitation: ALB does not support the TRACE request method. Use another method instead.

Backend service limitation: Except for TRACE, whether other request methods can be processed depends on whether the backend server supports them. Run curl -X METHOD http://<backend_server_IP>:<service_port> to verify, where METHOD is the request method used by the client.

Slow client data transmission: Within the connection request timeout period configured for the listener (default 60 seconds), the client only transmitted partial data (for example, only HTTP Header was transmitted without HTTP Body. Capture packets to check whether the client has performance bottlenecks or other issues. If your business requires a longer request sending time, increase the connection request timeout appropriately.

Poor network quality between client and ALB: The TCP Round Trip Time (RTT) is large or there are network issues such as packet loss. Check the request_time and tcpinfo_rtt fields in the access logs, or perform network diagnostics on the client.

ALB instance bandwidth throttling: Traffic to the ALB instance is too high, triggering bandwidth throttling and packet loss. Check the outbound bandwidth and Dropped Connections metrics through CloudMonitor.

ALB limitation: ALB requires that the URI length of requests does not exceed 32 KB, otherwise 414 is returned. Shorten the URI length. If you need to transmit large amounts of data, you can use the POST method to put the data in the request body. ALB supports a maximum POST request body of 50 GB.

Backend service limitation: If the URI does not exceed the ALB limit but the backend service has a stricter length limit, ALB passes through the 414 status code returned by the backend. Troubleshoot the backend service.

Backend service misconfiguration: The backend service is misconfigured, causing requests to be sent back to ALB and forming a loop. Troubleshoot the ALB backend service configuration.

Network architecture design flaw: For example, multiple Server Load Balancer (SLB) instances exist in the forwarding path of a single request. Optimize the network architecture.

Poor network quality between client and ALB: The TCP RTT is large or there are network issues such as packet loss. Check the request_time and tcpinfo_rtt fields in the access logs, or perform network diagnostics on the client.

ALB instance bandwidth throttling: Traffic to the ALB instance is too high, triggering bandwidth throttling and packet loss. Check the outbound bandwidth and Dropped Connections metrics through Cloud Monitor.

Backend processing time too long: The backend request processing time exceeded the client's request timeout. Check the upstream_response_time field in the access logs, which represents the time taken by the backend to process the request. If this value is generally high, troubleshoot whether the backend service has performance bottlenecks.

Client request timeout set too short: The client closed the connection due to timeout before the request was fully sent. Check the request_time field in the access logs, which represents the total time of the client request. Set a more reasonable client request timeout based on this field value.

Client encountered unknown issues: The client closed the connection prematurely before the request was completed. Troubleshoot whether the client has behavior that closes connections prematurely.

Backend directly returns 500: Check the access logs. If upstream_status is 500, ALB likely passed through the upstream status code. Troubleshoot the backend service.

Backend server abnormally closed connection: The backend server abnormally closed the connection before sending the complete response. Capture packets on the backend server to troubleshoot the cause of the abnormal connection closure.

Backend directly returns 502: Check the access logs. If upstream_status is 502, ALB likely passed through the upstream status code. Troubleshoot the backend service.

Backend returns other error status codes: For example, 504 or 444, but ALB uniformly returns 502. Check the status and upstream_status fields in the access logs and troubleshoot based on the upstream status code.

TCP communication error between ALB and backend server: Check whether the backend service is running normally, whether the service port is listening properly, or capture packets to check whether the TCP handshake is normal.

Backend server backlog is full: This causes new connection requests to be rejected or dropped. Run netstat -s | grep -i listen on the backend server to check whether there is a drop count.

Client packet length exceeds backend server MTU: This is characterized by normal short packets such as health checks, but abnormal long packets. Capture packets on the backend server to analyze whether the packet length meets requirements.

Backend server response packet format is abnormal or contains illegal HTTP headers: Capture packets on the backend server to analyze whether the response packet format is standard.

Backend server did not process the request in time: Check the backend server logs and view CPU and memory utilization.

Backend directly returns 503: Check the access logs. If upstream_status is 503, ALB likely passed through the upstream status code. Troubleshoot the backend service.

Client request triggered ALB throttling:

• Check the Requests per second metric through CloudMonitor.

• CloudMonitor displays minute-level data and may not reflect second-level exceeded situations. Check the access logs. If the value of the upstream_status field is -, the request did not reach the backend server.

• Check the response packet header. If it contains the ALB-QPS-Limited:Limited field, the request triggered ALB throttling.

Client directly accesses ALB IP or DNS resolution is abnormal when accessing through domain name: This may cause traffic to concentrate on a few IPs and exceed the limit. We recommend that the client access through the ALB domain name (refer to Configure a CNAME record for an ALB instance and ensure that DNS resolution is normal.

Listener has no backend servers configured or the configured backend servers have weight 0

Backend directly returns 504: Check the access logs. If upstream_status is 504, ALB likely passed through the upstream status code. Troubleshoot the backend service.

Connection establishment between ALB and backend server timed out: The default timeout is 5 seconds and cannot be modified. Capture packets to troubleshoot why the backend server response timed out.

Backend server response timed out: The connection request timeout defaults to 60 seconds. You can check the UpstreamResponseTime metric in CloudMonitor and the upstream_response_time field in access logs to determine whether the backend server response timed out.