Spring-boot redirects differently when hitting localhost vs host ip

Question

I have an AWS Application Load Balancer in front of a Java 8 Spring Boot (1.5.13) web server. The TLS termination is done by the ALB.

For a number of reasons, the web server reroutes users (for eg. to a login page). I've set the server as per the documentation. Use-forward-headers to true in application.properties will ensure that the X-Forwarded-Proto and Host headers are used to properly redirect to the external (https) url.

A (almost) identical setup does not function on Host 2, while this setup does on Host 1. I've distilled it down to the following for Host 2. Curling localhost makes everything function, but curling 172.32.1.1 (host 2's ip) does not.

On Host 2, the two commands below were executed. Any suggestions as to what the difference in response might be? http versus https

[ec2-user@ip-172-32-1-1 ~]$ curl -v localhost:8080 -H "X-Forwarded-Proto: https" -H "X-Forwarded-Port: 443" -H "Host: example.com"
*   Trying 127.0.0.1:8080...
* Connected to localhost (127.0.0.1) port 8080 (#0)
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/7.79.1
> Accept: */*
> X-Forwarded-Proto: https
> X-Forwarded-Port: 443
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 
< Set-Cookie: SESSION=6a9d14f0-07f6-4f73-ae31-8232f2d9de5d; Path=/; Secure; HttpOnly
< Location: https://example.com/login
< Content-Length: 0
< Date: Wed, 21 Dec 2022 21:43:28 GMT
< 
* Connection #0 to host localhost left intact

[ec2-user@ip-172-32-1-1 ~]$ curl -v 172.32.1.1:8080 -H "X-Forwarded-Proto: https" -H "X-Forwarded-Port: 443" -H "Host: example.com"
*   Trying 172.32.1.1:8080...
* Connected to 172.32.1.1 (172.32.1.1) port 8080 (#0)
> GET / HTTP/1.1
> Host: example.com
> User-Agent: curl/7.79.1
> Accept: */*
> X-Forwarded-Proto: https
> X-Forwarded-Port: 443
> 
* Mark bundle as not supporting multiuse
< HTTP/1.1 302 
< Set-Cookie: SESSION=cbf4800a-15a8-460a-a3db-d6e3c21c046e; Path=/; HttpOnly
< Location: http://example.com/login
< Content-Length: 0
< Date: Wed, 21 Dec 2022 21:42:50 GMT
< 
* Connection #0 to host 172.32.1.1 left intact

Host 1 and Host 2 are using the same VM Image, and WAR file. On Host 1, the 2 commands above both respond with https as expected.