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