Server Load Balancer:ALB status codes

The backend service directly returns a 400 status code: Check the access log. If the value of the upstream_status field is 400, ALB likely forwarded the status code from the backend service. You should troubleshoot the backend service.

An HTTP request is sent to an HTTPS listener: An ALB HTTPS listener rejects non-HTTPS requests and returns a 400 status code. Check if the client sent an HTTP request to an HTTPS port.

The request header size exceeds the limit: The maximum size of an HTTP request header in ALB is 32 KB. If a request header exceeds this limit, ALB returns a 400 error. We recommend that you adjust the size of the HTTP request header.

The request is incomplete: The client closed the connection before the HTTP request was fully sent. You can capture packets on the client to analyze the cause.

The request header format is invalid: For example, the Content-Length value does not match the actual request body length. We recommend that you capture packets on the client to analyze the format of the HTTP request and compare it with a normal request.

ALB-specific limitation: ALB does not support the TRACE request method. We recommend that you use a different method.

Backend service restriction: The ability to process request methods other than TRACE depends on whether the backend server supports them. You can run the curl -X METHOD http://<backend_server_IP>:<service_port> command to verify, where METHOD is the request method that the client uses.

Slow data transfer from the client: The client sends only partial data, such as the HTTP Header without the HTTP Body, within the listener's connection request timeout period (default is 60 seconds). We recommend that you capture packets to troubleshoot performance bottlenecks or other issues on the client. If your service requires a longer request transmission time, you can increase the connection request timeout.

Poor network quality between the client and ALB: The TCP Round Trip Time (RTT) is high, or network issues such as packet loss occur. You can check the request_time and tcpinfo_rtt fields in the access log or perform network diagnostics on the client.

ALB instance bandwidth throttling: Excessive traffic to the ALB instance triggers bandwidth throttling and packet loss. You can use Cloud Monitor to check the outbound bandwidth and Dropped Connections metrics.

ALB-specific limits: ALB requires that the request URI length does not exceed 32 KB. If this limit is exceeded, ALB returns a 414 status code. We recommend that you shorten the URI. To transfer a large amount of data, you can use the POST method and transfer the data in the request body. ALB supports a POST request body of up to 50 GB.

Backend service limit: If the URI does not exceed the ALB limit but the backend service has a stricter length limit, ALB forwards the 414 status code returned by the backend. You should troubleshoot the backend service.

Incorrect backend service configuration: The backend service is incorrectly configured, which causes requests to be sent back to ALB and form a loop. Check the backend service configuration of ALB.

A flaw in the network architecture design: For example, the forwarding path of a single request contains multiple Server Load Balancer (SLB) instances. You should optimize the network architecture.

Poor network quality from the client to ALB: The TCP Round Trip Time (RTT) is high, or network issues such as packet loss exist. You can check the request_time and tcpinfo_rtt fields in the access log or perform network diagnostics on the client.

ALB instance bandwidth throttling: Excessive traffic to the ALB instance triggers bandwidth throttling and packet loss. You can use Cloud Monitor to check the outbound bandwidth and Dropped Connections metrics.

Long backend request processing time: The backend request processing time exceeds the client's request timeout. Check the upstream_response_time field in the access log. The value of this field is the backend request processing time. If this value is consistently high, check the backend service for performance bottlenecks.

The client-side request timeout is too short: The client closes the connection because of a timeout before the entire request is sent. You can check the request_time field in the access log. This field represents the total client request time. You can use the value of this field to set a more appropriate client request timeout.

Unknown client issue: The client closes the connection before the request is complete. Check if the client has a behavior of prematurely closing connections.

The backend service directly returns a 500 error: Check the access log. If the value of the upstream_status field is 500, ALB likely forwarded the status code from the backend service. You should troubleshoot the backend service.

The backend server closes the connection unexpectedly: The backend server closes the connection unexpectedly before it sends the full response. You can capture packets on the backend server to investigate the cause of the unexpected connection closure.

The backend service directly returns a 502 error: Check the access log. If the value of the upstream_status field is 502, ALB likely forwarded the status code from the backend service. You should troubleshoot the backend service.

The backend server returns other error status codes: For example, the backend server may return a 504 or 444 error, but ALB returns a 502 error. We recommend that you check the status and upstream_status fields in the access log and troubleshoot the fault based on the backend status code.

Abnormal TCP communication between ALB and the backend server: Check if the backend service is in a normal state and if the service port is listening correctly. You can also capture packets to check if the TCP handshake is normal.

The backend server backlog is full: This causes new connection requests to be rejected or dropped. You can run the netstat -s | grep -i listen command on the backend server to check for a drop count.

The length of the message sent by the client exceeds the MTU of the backend server: Health checks or packets with shorter messages are processed normally, but packets with longer messages are not. You can capture packets on the backend server to analyze if the message length meets the requirements.

The format is invalid or the HTTP headers are illegal in the backend server's response: You can capture packets on the backend server to analyze if the format of the response message is standard.

The backend server did not process the request in time: Check the logs of the backend server and view its CPU and memory usage.

The backend service directly returns a 503 error: Check the access log. If the value of the upstream_status field is 503, ALB likely forwarded the status code from the backend service. You should troubleshoot the backend service.

Client request triggers ALB throttling:

• View the Requests per second metric in Cloud Monitor.

• Cloud Monitor displays minute-level data, which may not reflect when the per-second limit is exceeded. You can check the access logs. If the value of the upstream_status field is -, the request was not delivered to the backend server.

• If the response packet header contains the ALB-QPS-Limited:Limited field, the request triggered the ALB rate limit.

Direct IP access to an ALB instance or abnormal DNS resolution: This can cause traffic to be concentrated on a few IP addresses and exceed the limit. We recommend that you access the ALB instance using its domain name and ensure that DNS resolution is normal. For more information, see Configure a CNAME record for an ALB.

The listener has no backend servers configured, or the configured backend server weight is 0.

The backend service directly returns a 504 error: Check the access log. If the value of the upstream_status field is 504, ALB likely forwarded the status code from the backend service. You should troubleshoot the backend service.

The connection to the backend server times out: The timeout period is 5 seconds by default and cannot be modified. We recommend that you capture packets to determine the cause of the response timeout.

The backend server response times out: The response timeout period is 60 seconds by default. You can check the UpstreamResponseTime metric in Cloud Monitor and the upstream_response_time field in the access logs to determine whether the backend server has timed out.