< HTTP/1.1 460 Client Closed Connection

TL;DR: A 460 in your AWS Application Load Balancer logs means the client hung up before your backend answered, usually because the client’s own timeout is shorter than your slow endpoint. Speed up the target or raise the client’s timeout. Raising the ALB idle timeout won’t help, since the client gave up first.

What it means

460 is an AWS ALB code, not a standard HTTP status. “Client Closed Connection” is a descriptive label here; AWS documents the numeric code without a reason phrase. You’ll only ever see it in logs: the client has already disconnected, so no response with this code reaches it.

First figure out who is directly in front of the ALB. If it’s another proxy, its timeout matters as much as the end user’s. Sketch the real request path before you touch any timeouts.

Confirm it in access logs

Filter ALB access logs on elb_status_code = 460. That field is the load balancer’s status. target_status_code holds the target’s response code, or - when no target response was recorded. Even with a - there, the application may have started the work, or even finished it. See AWS’s field definitions.

Match the timestamp, URL, and client against the caller’s logs. Note when the caller started, when it cancelled, and when the target finished. Then check the ALB’s configured idle timeout with this read-only AWS CLI call, after setting ALB_ARN to your load balancer’s ARN:

aws elbv2 describe-load-balancer-attributes \
  --load-balancer-arn "$ALB_ARN" \
  --query "Attributes[?Key=='idle_timeout.timeout_seconds']"

The default is 60 seconds, but compare against whatever your deployment actually uses.

Fix it

If the cancellations line up with the client’s configured timeout, you have two options: make the target finish sooner, or raise that client timeout if the caller can afford to wait. AWS specifically recommends checking the client timeout against the ALB idle timeout. After the change, retest the slow endpoint with the same caller.

If the caller cancelled on purpose, such as a user navigating away or a script aborting, find out why before you change any configuration. For requests that modify state, check whether the operation went through before retrying. The client disconnecting doesn’t roll anything back on the server.

Do not confuse it with an ALB idle timeout

When the target doesn’t respond before the ALB idle timeout, AWS logs a 504 instead. That’s a different investigation from a 460. The question is who stopped waiting first: the client (460) or the ALB (504). The access log tells you which.

Related

• 499 Client Closed Request
• 408 Request Timeout
• 504 Gateway Timeout