< HTTP/1.1 464 Incompatible Request Protocol

TL;DR: AWS ALB 464 means the incoming request protocol does not match the selected target group’s protocol version. Inspect ProtocolVersion and the listener rule that selected the group; changing only the backend URL from HTTP to HTTPS does not resolve that mismatch.

What it means

464 is a non-standard AWS Application Load Balancer code. “Incompatible Request Protocol” is a descriptive label, not an AWS-defined reason phrase. AWS’s troubleshooting entry identifies an incompatible request and target group protocol version.

Use the target group compatibility table to check the actual combination. HTTP/1.1 requests cannot go to an HTTP/2 or gRPC group. gRPC requests cannot go to an HTTP/1.1 group. An ordinary HTTP/2 request to a gRPC group must be POST. HTTP/2 requests to an HTTP/1.1 group are supported, so do not assume both directions fail.

Confirm the selected target group

Search access logs for elb_status_code = 464. Inspect the request, target_group_arn and matched_rule_priority. target_status_code describes the target’s response, or - if none was recorded; it is distinct from the ALB-generated status.

Set ALB_ARN to your load balancer ARN and inspect its target groups:

aws elbv2 describe-target-groups \
  --load-balancer-arn "$ALB_ARN" \
  --query 'TargetGroups[].{Name:TargetGroupName,ARN:TargetGroupArn,Protocol:Protocol,Version:ProtocolVersion}'

Protocol and ProtocolVersion are separate fields. Check the group ARN from the failing request rather than inspecting a similarly named group in another environment.

Fix it

Route ordinary HTTP endpoints to a compatible group, and route gRPC calls to a group whose targets support gRPC. If a path-based rule sends a web page to the gRPC group, correct that rule rather than turning the page request into POST.

For an endpoint intended to use HTTP/2, confirm what protocol the caller actually negotiated. A client that reaches the ALB using HTTP/1.1 still conflicts with an HTTP/2 target group. Compare a working caller with the failing caller through the same listener and path.

After the routing or client change, repeat the original request and verify that its log entry selects the expected group. Record both the incoming protocol and target group version in the incident notes; the word “HTTPS” alone does not describe either combination fully.

Related

• 400 Bad Request
• 505 HTTP Version Not Supported