Target.ResponseCodeMismatch Error due to 301 HTTP Redirect to HTTPS in Elastic Load Balancer Health Checks
I've been experiencing error "Target.ResponseCodeMismatch" after redirecting HTTP to HTTPS in ALB. Checking the access.log shows "10.x.xx.345 - - [08/Nov/2023:03:11:20 +0000] "GET / HTTP/1.1" 301 162 "-" "ELB-HealthChecker/2.0" "-"". My application is running good, only the redirect that caused the error during health checks. I tried inserting the following block below in nginx.conf file to handle the redirect but it didn't solve the issue.
location / {
return 301 https://$host$request_uri;
}
Any help is appreciated. Thanks guys in advance!
- Neueste
- Die meisten Stimmen
- Die meisten Kommentare
Hello.
It's strange that health check access is being redirected in the first place.
First of all, I think it would be better to prevent health check access from being redirected.
Is there a setting in Nginx settings to redirect when accessing the ALB health check path?
Do not use http to https redirect on ngnix. If you want to redirect http to https, create a 2nd listener on the ALB on port 80 and perform the redirect here. There isnt a need to perform this on NGINX. I would remove that
Thank you Gary for looking into my issue. I just removed the redirect. I tried creating a page in website with slug "elb-health-check" then I added a block in nginx.conf this "location /elb-health-check { access_log off; return 200; }". Do you think this is an ideal approach to check the actual health of the environment?
Relevanter Inhalt
AWS OFFICIALAktualisiert vor 2 Jahren- AWS OFFICIALAktualisiert vor 3 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren
Thank you Riku for looking into my issue. This is my only redirection "location / { return 301 https://$host$request_uri; }" for http to https.
As Gary says, if you redirect to HTTPS with Nginx, a redirect loop will occur. Therefore, I think it is necessary to eliminate redirect settings in Nginx.
I've already removed the redirect
The ALB health check is a GET request, so if you can confirm that the application is running at least when you access that path, I don't think there will be any problems.