proxy_pass Not Working on Port 80

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

proxy_pass Not Working on Port 80

zakirenish
I have two servers behind on IP address. Server1 is hosting several websites
all using TLS exclusively.
 Recently I set up Server2 and setup one website using reverse proxy from
Server1 and finally successfully deployed TLS on it as well.
During that setup I had to use port 80 to use Certbot with Let's Encrypt.
Now I'm trying to do it again the same way with another domain.
The proxy_pass directive works on port 8080, but when I switch it to port 80
I get a 404 error.

Here is setup in question: (again, Port 8080 works, but port 80 does not)

----------------------------------
#Proxy server (Server1)

# threedaystubble.com server
server {
        listen 80;
        server_name www.threedaystubble.com threedaystubble.com;
        location / {
                proxy_pass <a href="http://192.168.3.5:80;">http://192.168.3.5:80;
        }
}


#Proxied Server (Server2)

server {
        listen 80;

        server_name threedaystubble.com www.threedaystubble.com;

        root /var/www/threedaystubble.com;

        location / {
        }

}

--------------------------------------

Also, I checked if anything was happening on port 80 on both machines with
net stat -plant:

Server1
Proto Recv-Q Send-Q Local Address           Foreign Address         State  
   PID/Program name
tcp               0            0  0.0.0.0:80                 0.0.0.0:*      
              LISTEN      -

Server2
Proto Recv-Q Send-Q Local Address           Foreign Address         State  
   PID/Program name
tcp               0           0  0.0.0.0:8080             0.0.0.0:*        
            LISTEN      -                  
tcp               0           0  0.0.0.0:80                 0.0.0.0:*      
              LISTEN      -

Any help would be greatly appreciated.

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,289348,289348#msg-289348

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: proxy_pass Not Working on Port 80

Francis Daly
On Wed, Sep 09, 2020 at 01:58:42AM -0400, figshta wrote:

Hi there,

> I have two servers behind on IP address.

What does that mean, in terms of "traffic to the IP address gets sent
to server#1 or to server'2"?

> Server1 is hosting several websites
> all using TLS exclusively.

That suggests that all incoming traffic to your IP on port 443 gets sent
to server#1.

>  Recently I set up Server2 and setup one website using reverse proxy from
> Server1 and finally successfully deployed TLS on it as well.
> During that setup I had to use port 80 to use Certbot with Let's Encrypt.
> Now I'm trying to do it again the same way with another domain.
> The proxy_pass directive works on port 8080, but when I switch it to port 80
> I get a 404 error.

What request do you make that returns the 404 error?

What response do you want for that request? (Probably something like
"http 200 and the contents of *this* file".)

(And: what does the nginx log file say about the 404 error? Is it trying
to read a different file from what you expect?)

> Here is setup in question: (again, Port 8080 works, but port 80 does not)
>
> ----------------------------------
> #Proxy server (Server1)
>
> # threedaystubble.com server
> server {
>         listen 80;
>         server_name www.threedaystubble.com threedaystubble.com;
>         location / {
>                 proxy_pass <a href="http://192.168.3.5:80;">http://192.168.3.5:80;

With that config, your server#2 will not see a Host: header that includes
threedaystubble.com.

If your server#2 needs that Host header, things will probably break.

> #Proxied Server (Server2)
>
> server {
>         listen 80;
>
>         server_name threedaystubble.com www.threedaystubble.com;
>
>         root /var/www/threedaystubble.com;
>
>         location / {
>         }
>
> }

If that is the entire config on server#2, it should probably work. But
if you have more server{} blocks, such that the "default" port-80 server
is something else, then that extra config might be causing this not to
act in the way that you want.

> Any help would be greatly appreciated.

Depending on what else is wanted, I'd suggest one of the methods to
make sure that the Host: header that you want, is sent to server#2 in
the proxy_pass request from server#1.

That can be proxy_set_header; or proxy_pass with the hostname and either
an upstream of the hostname, or the system resolver to refer to the
server#2 address.

(Or: just use port 8080 on server#2 for this site; and port 8081 on
server#2 for the next site.)

Good luck with it,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

RE: proxy_pass Not Working on Port 80

Reinis Rozitis
In reply to this post by zakirenish
> ----------------------------------
> #Proxy server (Server1)
>
> # threedaystubble.com server
> server {
>         listen 80;
>         server_name www.threedaystubble.com threedaystubble.com;
>         location / {
>                 proxy_pass <a href="http://192.168.3.5:80;">http://192.168.3.5:80;
>         }
> }


In this configuration nginx doesn't pass the Host header to backend.
In case there are multiple name based virtualhosts on the 192.168.3.5, you'll always get the default or first one (the order in the backend config).

Try to change to this and see if helps:

location / {
        proxy_pass <a href="http://192.168.3.5:80;">http://192.168.3.5:80;
        proxy_set_header Host $host;
}

rr

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: RE: proxy_pass Not Working on Port 80

zakirenish
Thank you Francis and Rennis.
I really appreciate your help, unfortunately it isn't working yet...

Are there any another ways to trouble shoot this port problem?

Rennis:
Your suggestion looked so promising.
 
> In this configuration nginx doesn't pass the Host header to backend.
> In case there are multiple name based virtualhosts on the 192.168.3.5,
> you'll always get the default or first one (the order in the backend
> config).

It really makes sense because I do have another configuration pointing to
this backend server; it is, however, on port 443.

Here is the complete proxy configuration for both sites on Server1: (I added
the proxy_set_header directive as suggestedl)

#Proxy server (Pi3) (Server1)
# houseofavi.com server
server {
        listen 443;
        server_name houseofavi.com;
        location / {
                proxy_pass              <a href="https://192.168.3.5:443;">https://192.168.3.5:443;
                proxy_set_header        Host $host;
        }

    ssl_certificate /etc/letsencrypt/live/houseofavi.com/fullchain.pem; #
managed by Certbot
    ssl_certificate_key /etc/letsencrypt/live/houseofavi.com/privkey.pem; #
managed by Certbot
}

# threedaystubble.com server
server {
        listen 80;
        server_name www.threedaystubble.com threedaystubble.com;
        location / {
                proxy_pass              <a href="http://192.168.3.5:80;">http://192.168.3.5:80;
                proxy_set_header        Host $host;
        }
}

Are there another ideas to allow port 80?

Francis:

I don't want to use port 8080 or 8081 because Certbot requires port 80 and
it should work.
I plan to have everything on port 443 once it's all set up.
I am however, now concerned about running into trouble with multiple sites
using 443.
It it difficult?
I hope I can pass various requests to different "virtual" server blocks on
the same port.

Here both server configurations on Server2 in case it helps.

#Proxied Server (Server2)
#houseofavi.com
server {
        if ($host = houseofavi.com) {
                        return 301 https://$host$request_uri;
        } # managed by Certbot
        server_name houseofavi.com;
        return 404; # managed by Certbot
        root /var/www/houseofavi.com;
}

server {
        listen 443 ssl; # managed by Certbot
        root /var/www/houseofavi.com;
        location / {
        }
        ssl_certificate /etc/letsencrypt/live/houseofavi.com/fullchain.pem;
# managed by Certbot
        ssl_certificate_key
/etc/letsencrypt/live/houseofavi.com/privkey.pem; # managed by Certbot
        include /etc/letsencrypt/options-ssl-nginx.conf; # managed by
Certbot
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot
}

#Proxied Server (Server2)
#threedaystubble.com
server {
        listen 80;
        server_name threedaystubble.com www.threedaystubble.com;
        root /var/www/threedaystubble.com;
        location / {
        }
}

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,289348,289362#msg-289362

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: RE: proxy_pass Not Working on Port 80

Francis Daly
On Wed, Sep 09, 2020 at 10:40:35AM -0400, figshta wrote:

Hi there,

> I really appreciate your help, unfortunately it isn't working yet...
>
> Are there any another ways to trouble shoot this port problem?

What request do you make of nginx-frontend?

What request do you want nginx to make of the backend/upstream?

What request does nginx actually make of the backend?

The logs, or tcpdump, should show you exactly what is happening.


> I don't want to use port 8080 or 8081 because Certbot requires port 80 and
> it should work.

Certbot requires port 80 on the frontend.

You get to decide for yourself what happens on the backend - certbot
should not know or care.

> I plan to have everything on port 443 once it's all set up.

Certbot will still require port 80, unless you have an alternative plan.

> I am however, now concerned about running into trouble with multiple sites
> using 443.
> It it difficult?

http://nginx.org/en/docs/http/configuring_https_servers.html has some
useful notes.

> Here both server configurations on Server2 in case it helps.
>
> #Proxied Server (Server2)
> #houseofavi.com
> server {
>         if ($host = houseofavi.com) {
>                         return 301 https://$host$request_uri;
>         } # managed by Certbot
>         server_name houseofavi.com;
>         return 404; # managed by Certbot

That is the 404 return that you get, because your frontend nginx did
not send the Host: header that you want. (Instead, it sent the Host:
header that you configured it to send.)

There is, in this case, an implicit "listen 80 default;" in this
server{}. So...

> server {
>         listen 80;
>         server_name threedaystubble.com www.threedaystubble.com;

...this server{} will only be used if you include a Host: header of one
of those two strings.

Add some logging; or (temporarily)

    return 200 "this is the backend you want: $request_uri\n";

to see that it is (or is not) being used.

Good luck with it,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: RE: proxy_pass Not Working on Port 80

zakirenish
Thank you Francis!

I realize that some of these are probably rhetorical questions, but in the
interest of learning, I will try to answer them anyway.

<What request do you make of nginx-frontend?

I am mostly working with http/https 'get' requests for now.

<What request do you want nginx to make of the backend/upstream?

I want all requests for specific domains to pass to the backend (Server2)
(The idea is that Server2 will eventually replace Server1 as domains are
eventually moved over to it.)

<What request does nginx actually make of the backend?
The backend (server2) is also an nginx server.
I have seen the access logs and error logs for the backend (Server2), but
since I'm new to this, I'm slow to understand it all.

<The logs, or tcpdump, should show you exactly what is happening.
I will keep looking at the logs and study tcpdump, thank you.

<Certbot requires port 80 on the frontend.
<You get to decide for yourself what happens on the backend - certbot should
not know or care.

Right, and perhaps my scheme is erroneous.
I am trying to keep certificates on both servers.
Originally, I was trying to keep the certificates for domains on the backend
(Server2) on that machine, but I couldn't proxy_pass encrypted traffic
easily.

Here is that story:
https://community.letsencrypt.org/t/nginx-proxied-server-running-certbot-wrong-certificate/132635/2

In short, I ran Cerbot twice, once for each server (backend first), and in
order to run it on the backend I needed port 80.
It worked.
I'm trying to do that again the same way because I think it will be easier
to promote Server2 to the frontend later.
Maybe that is a misconception though, not sure.

<That is the 404 return that you get, because your frontend nginx did not
send the Host: header that you want.
<(Instead, it sent the Host:header that you configured it to send.)

I commented out 'return 404; # managed by Certbot' and that did the trick.
Now I can use port 80. Thank you!
That said, I don't really understand where I configured the Host: header or
how to do it correctly.

>There is, in this case, an implicit "listen 80 default;" in this server{}.
So...

>> server {
>> listen 80;
>> server_name threedaystubble.com www.threedaystubble.com;

>....this server{} will only be used if you include a Host: header of one of
those two strings.
>Add some logging; or (temporarily)
>return 200 "this is the backend you want: $request_uri\n";
>to see that it is (or is not) being used.

It is clear that you have given me the guidance I need to try figure it
out.
I will play with it and try to learn it.
Thank you!

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,289348,289371#msg-289371

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: RE: proxy_pass Not Working on Port 80

Francis Daly
On Thu, Sep 10, 2020 at 01:31:48AM -0400, figshta wrote:

Hi there,

> I realize that some of these are probably rhetorical questions, but in the
> interest of learning, I will try to answer them anyway.

No, not rhetorical.

Also, not general.

I mean: when you reply with "does not work", what was the one specific
test case that you ran?

Something like: I run the command

  curl -v http://www.example.com/one/two.html

and I expect the response "http 301" and a redirect to /one/three.html;
or I expect the response "http 200" and the content of the file
/usr/local/nginx/html/one/two.html from the machine server2; or whatever
exact specific response that you want for this one specific request

> <What request do you make of nginx-frontend?
>
> I am mostly working with http/https 'get' requests for now.

So, let's say "http://www.example.com/one/two.html".

> <What request do you want nginx to make of the backend/upstream?
>
> I want all requests for specific domains to pass to the backend (Server2)
> (The idea is that Server2 will eventually replace Server1 as domains are
> eventually moved over to it.)

And let's say "/one/two.html", talking to backend "www.example.com".

> <What request does nginx actually make of the backend?
> The backend (server2) is also an nginx server.
> I have seen the access logs and error logs for the backend (Server2), but
> since I'm new to this, I'm slow to understand it all.

If you have more than one backend server{} block, and you write all
the logs for all server{} blocks into one file, then you possibly will
not easily know which one server{} block nginx used to process this
one request.

If you make it possible to see what is happening, it will be easier to
see what is happening.

> <The logs, or tcpdump, should show you exactly what is happening.
> I will keep looking at the logs and study tcpdump, thank you.

tcpdump will be useful for http content; it can be slightly useful
for https content, to show that you are or are not using SNI (which is
relevant when you have more than one "virtual host" on the same IP:port).

> <Certbot requires port 80 on the frontend.
> <You get to decide for yourself what happens on the backend - certbot should
> not know or care.
>
> Right, and perhaps my scheme is erroneous.
> I am trying to keep certificates on both servers.
> Originally, I was trying to keep the certificates for domains on the backend
> (Server2) on that machine, but I couldn't proxy_pass encrypted traffic
> easily.

The certbot side seems... complicated. If that wants discussing here,
it probably should be in a dedicated thread. It is not directly related
to the subject of this thread.

(In very short: you need to decide how exactly you want inbound traffic
to your public IP address to be handled. After you have a clear design
for how you want each request to be handled, you will be able to see
how and whether it is possible.)

> <That is the 404 return that you get, because your frontend nginx did not
> send the Host: header that you want.
> <(Instead, it sent the Host:header that you configured it to send.)
>
> I commented out 'return 404; # managed by Certbot' and that did the trick.
> Now I can use port 80. Thank you!
> That said, I don't really understand where I configured the Host: header or
> how to do it correctly.

There is (potentially) lots in the configuration that you want. So it
is worth taking one step at a time.

There is also lots of documentation available on the nginx.org web
site. For example, every directive (e.g "location") is documented at
(e.g.) http://nginx.org/r/location.

For nginx http -- a request comes in, and is handled in exactly one
server{} block (based on the configuration, and the incoming IP:port and
hostname within the request). Then (after rewrite-module directives)
the request is handled in exactly one location{} block (based on the
configuration and the request). Then either a subrequest is created,
and a new rewrite-module/location-selection happens; or the request is
just processed.

On your frontend, this means that your /one/two.html
request to threedaystubble.com is proxy_pass'ed to
http://192.168.3.5:80/one/two.html.

On your backend, the http://192.168.3.5:80/one/two.html is handled
in the "houseofavi.com" server{} block, where it will return
404; or, now that you have removed that, return the content of
/var/www/houseofavi.com/one/two.html


If you want the request to be handled in the server2 "threedaystubble.com"
server block, you'll probably want the proxy_set_header that was mentioned
previously.


If you use "curl" for testing, rather than a more full-featured web
browser, you will have a better chance of seeing what exactly is
happening, and you will avoid things like browser caching that can
interfere with useful testing.

Good luck with it,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: RE: proxy_pass Not Working on Port 80

zakirenish
Francis,

Thank you very much for the detailed reply and being patient with me.
I have learned a lot from you and Reinis and I am truly grateful.

My sites are now working with TLS/SSL...

I couldn't have done it with out you guys!!

>curl -v http://www.example.com/one/two.html

I see the value in this tool. I will use it in the future.

I have much to learn.

Thanks again.

Posted at Nginx Forum: https://forum.nginx.org/read.php?2,289348,289387#msg-289387

_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx
Reply | Threaded
Open this post in threaded view
|

Re: RE: proxy_pass Not Working on Port 80

Francis Daly
On Thu, Sep 10, 2020 at 11:11:48AM -0400, figshta wrote:

Hi there,

> My sites are now working with TLS/SSL...

Good to hear that you have it working; and best of luck with nginx!

Cheers,

        f
--
Francis Daly        [hidden email]
_______________________________________________
nginx mailing list
[hidden email]
http://mailman.nginx.org/mailman/listinfo/nginx