Health check failure with HTTP/2 in an ALB target group but succeeding with HTTP1.1

0

I created a new ALB with HTTP/2 support and configured the target group to use HTTP/2 as well. The goal was to make them compatible. However, I am currently facing health check failures when using HTTP/2 with the target group in the ALB. Interestingly, when I used the same container with a different target group, it was able to successfully pass data using the HTTP/1.1 protocol. Could you please help me understand why the health checks are failing in the HTTP/2 configuration?

2 Answers
1

Sounds like your webservice on nodes within the Target group doesnt support HTTP2.0? The ALB will handle traffic to and from clients and then from the ALB to the Target.

profile picture
EXPERT
answered 5 days ago
  • Currently my ALB supports http2 and I have made target group protocol version also as HTTP2 to support my ALB. Am I missing something else. Basically this was failing when it starts running tasks on ECS.

  • If your nodes do not support http2 then disable it on the target group. You can still leave the ALB as http2

1

The issue you're experiencing with health check failures when using HTTP/2 in your Application Load Balancer (ALB) target group, while succeeding with HTTP/1.1, could be due to a few factors:

  1. Protocol Mismatch: ALBs handle protocol negotiation automatically between clients and targets. When you configure an HTTPS listener on your ALB, it automatically supports both HTTP/2 and HTTP/1.1 on the front-end (client-facing side). However, on the backend, the ALB communicates with your targets using HTTP/1.1 by default, regardless of the protocol used between the client and the ALB.

  2. Health Check Configuration: The health check might be configured to use HTTP/1.1, which could cause issues if your target is strictly expecting HTTP/2 traffic. Ensure that your health check settings are compatible with the protocol your target is expecting.

  3. Application Configuration: Your application might not be properly configured to handle HTTP/2 requests, especially if it's expecting certain headers or behaviors specific to HTTP/1.1.

  4. Host Header Mismatch: The HTTP host header in the health check request contains the IP address of the load balancer node and the listener port, not the IP address of the target and the health check port. If your application is mapping incoming requests by host header, this could cause health checks to fail.

To resolve this issue, you could try the following:

  1. Verify that your target application can handle both HTTP/2 and HTTP/1.1 requests.
  2. Check the health check configuration in your target group and ensure it's compatible with your application's expectations.
  3. Consider using TCP health checks instead of HTTP/2 if the protocol specifics are causing issues.
  4. Ensure your application is not strictly relying on HTTP/2-specific features for the health check endpoint.

Remember, even if you configure HTTP/2 support, the ALB might still use HTTP/1.1 to communicate with your targets. If you need end-to-end HTTP/2 support, you may need to enable it specifically for backend communication.
Sources
Is it possible for alb listener to support both http2 and http1.1 ? | AWS re:Post
Troubleshoot your Network Load Balancer - Elastic Load Balancing

profile picture
answered 5 days ago
profile picture
EXPERT
reviewed 5 days ago

You are not logged in. Log in to post an answer.

A good answer clearly answers the question and provides constructive feedback and encourages professional growth in the question asker.

Guidelines for Answering Questions