Reverse proxy redirection issue

Daniel Armando Rodriguez drodriguez at unau.edu.ar
Sat Sep 18 12:16:28 UTC 2021


El 2021-09-18 05:03, Francis Daly escribió:
> On Fri, Sep 17, 2021 at 10:24:44PM -0300, Daniel Armando Rodriguez 
> wrote:
> 
> Hi there,
> 
>> I am using nginx as a reverse proxy, I managed to configure SSL 
>> certificates
>> using LetsEncrypt but nginx does the redirection to the wrong vhost.
>> 
>> This is the configuration of one of the vhost, they are 3 identical 
>> ones
>> pointing to the same virtual machine. I have a fourth one pointing to
>> another virtual machine that works without problems.
>> 
>> I have the domains 1.DOMAIN.edu.ar, 2.DOMAIN.edu.ar and 
>> 3.DOMAIN.edu.ar
>> pointing to the same internal IP. But any domain I enter in the 
>> browser the
>> redirection is made to 1.DOMAIN.edu.ar.
> 
> I think you are reporting that if you do
> 
>     curl -i http://1.DOMAIN.edu.ar
> 
> you get a http 301 redirect from nginx to https://1.DOMAIN.edu.ar 
> (which
> is what you want); and if you do
> 
>     curl -i http://2.DOMAIN.edu.ar
> 
> you get a http 301 redirect from nginx to https://1.DOMAIN.edu.ar 
> (which
> is not what you want).
> 
> Is that correct?

Yep, that was exactly the issu. And saying 'was' 'cause this morning 
everything is working like a charm. Without made any further 
modification I mean. Really don't know what have happened here, but glad 
to see it working as expected.

> 
> If so...
> 
>> Also set a 4th as default_server, but behaviuor still remains.
>> 
>> This is the vhost configuration
>> ---
>> # cat /etc/nginx/sites-enabled/2.DOMAIN.edu.ar.conf
>> server {
>>     listen 80;
>>     server_name 2.DOMAIN.edu.ar;
>>     server_tokens off;
>>     # Don't show the nginx version number
>> 
>>     include /etc/nginx/snippets/location-letsencrypt.conf;
>> 
>> #    return 301 https://2.DOMAIN.edu.ar$request_uri;
>>     rewrite ^ https://2.DOMAIN.edu.ar$request_uri? permanent;
>> }
> 
> ...can you show the "server" blocks that have "listen 80", to make sure
> that they each have the expected "server_name" values and 
> return/rewrite
> value?

At the time the mail was sent I've double check those values.

> The output of "nginx -T" should list the configuration that nginx 
> actually
> reads; that might be simpler to copy from than the files.
> 
> 
> (There are other possible things to check too -- perhaps the problem is
> not that "curl -i http://2.DOMAIN.edu.ar" gives the unwanted response,
> but that "curl -i https://2.DOMAIN.edu.ar" gives the unwanted response. 
> Or
> perhaps the problem is that the requests are not getting to this nginx
> at all. But, one step at a time, to identify where the problem is.)

The issue raised on https redirection, indeed. But, as said, no changes 
made at all and now it's all working.

> Good luck with it,

Thank's for taking the time to read, and sorry for the noise.


ATB


  	f


_______________________________________________
Daniel A. Rodriguez
Informática, Conectividad y Sistemas
Universidad Nacional del Alto Uruguay
San Vicente - Misiones - Argentina
www.unau.edu.ar


More information about the nginx mailing list