Reverse proxy redirection issue

[Daniel Armando Rodriguez]

El 2021-09-20 13:49, Francis Daly escribió:
> On Sun, Sep 19, 2021 at 10:08:08PM -0300, Daniel Armando Rodriguez 
> wrote:
>> El 2021-09-19 04:00, Francis Daly escribió:
> 
> Hi there,
> 
>> Today I added a new domain, and the issue showed up again.
>> 
>> curl -i http://4.DOMAIN.edu.ar
>> 
>> Returns a redirect to https://4.DOMAIN.edu.ar
> 
> Ok, so that much is doing what is wanted.
> 
>> But
>> 
>> curl -i https://4.DOMAIN.edu.ar
>> 
>> Returns a redirect to https://4.DOMAIN.edu.ar
> 
> And that is a redirect loop, which is not what you want.
> 
> When you request https://4.DOMAIN.edu.ar, that should get to nginx,
> which should make a http request to INTERNAL_IP and return the 
> response.
> 
>> server {
>>     listen 443 ssl http2;
>> 
>>     server_name 4.DOMAIN.edu.ar;
> 
>>     location / {
>>        proxy_http_version  1.1;
>>        #For Websockets and keepalive connections
>>        proxy_set_header Upgrade           $http_upgrade;
>>        proxy_set_header Connection        "upgrade";
>>        #required when using Websockets
>>        proxy_set_header Host              $host;
> ...
>>        proxy_pass http://INTERNAL-IP/;
>>     }
> 
> What response do you get if you start on the nginx server and run the 
> command
> 
>     curl -v -H Host:4.DOMAIN.edu.ar http://INTERNAL-IP/
> 
> ? I'm not sure if the Connection header will make a difference here;
> it is possible that some of the X- headers are specially handled by the
> internal server; and maybe adding --http1.1 to the curl command line
> will make a difference too.
> 
> The aim is to see how the internal server responds, to see if there is
> an nginx-side config that can be made to make the end-user experience
> more useful.
> 
> 
> 
> It is possible that the internal server logs, or the nginx debug log,
> could give more detail; but the "curl" command is probably relatively
> quick to run and interpret.
> 
> Cheers,
> 
> 	f

This is the output

# curl -v -H Host:4.DOMAIN.edu.ar http://INTERNAL-IP/
* Expire in 0 ms for 6 (transfer 0x56179d823c10)
*   Trying INTERNAL-IP...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x56179d823c10)
* Connected to INTERNAL-IP (INTERNAL-IP) port 80 (#0)
> GET / HTTP/1.1
> Host:4.DOMAIN.edu.ar
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Date: Mon, 20 Sep 2021 20:07:38 GMT
< Server: Apache/2.4.38
< X-Pingback: http://1.DOMAIN.edu.ar/xmlrpc.php
< X-Redirect-By: WordPress
< Location: https://1.DOMAIN.edu.ar/
< Content-Length: 0
< Content-Type: text/html; charset=UTF-8
<
* Connection #0 to host INTERNAL-IP left intact

However, the same target machine hosts other services (each one with its 
own subdomain: 1, 2 & 3) that also go through the proxy. And they work 
as expected. Just to compare, this is the output.

# curl -v -H Host:2.DOMAIN.edu.ar http://INTERNAL-IP/
* Expire in 0 ms for 6 (transfer 0x55c30497ac10)
*   Trying INTERNAL-IP...
* TCP_NODELAY set
* Expire in 200 ms for 4 (transfer 0x55c30497ac10)
* Connected to INTERNAL-IP (INTERNAL-IP) port 80 (#0)
> GET / HTTP/1.1
> Host:2.DOMAIN.edu.ar
> User-Agent: curl/7.64.0
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Mon, 20 Sep 2021 20:12:01 GMT
< Server: Apache/2.4.38
< Set-Cookie: PHPSESSID=qujrksv6dbcf4t2pvf53judvnk; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< Vary: Accept-Encoding
< Content-Length: 4364
< Content-Type: text/html; charset=UTF-8