Making sense of the basics of NGINX reverse proxying and https

[Andersama]

I have what should be a relatively uncomplicated (not quite) homelab setup, one server hosting docker (with portainer).

Recently after having power outages take down the server, several docker projects stopped functioning. This was in part because of a mix of containers I had started with and without port randomization, and a misunderstanding of how to get nginx proxy manager to route using the container names. After solving that, I have a bit of drive to solve/make sense of https. What wasn't clear to me at the time was that containers create their own distinct individual networks, and that the docker networking feature using container names requires that the containers that want to talk to each other that way belong to a shared network. I've wrapped my head around that now, makes complete sense.

Here's the issue I'm having, there are clearly a wide spread of projects where the servers running inside docker containers follows what one might expect: That you have ports 80 and 443 bound (or some other two for compatibility reasons) for your standard web traffic. These projects I generally don't have a problem with. However for projects whose servers only bind one port, I have run into problems.

I would like to be able to ensure that at the very least (from the user's perspective) that they're using https. (Part of this is just for ease of use, because virtually every browser will swap http:// for https:// unless you really make it clear you're trying to use http://). Some projects which only bind one port, expect https for security reasons and wouldn't have it any other way. These I've done a poor job making sense of certs and where they belong in the scheme of things, but I've managed to get these working?

Projects which only bind a port and only deal with http are a distinct problem. Every attempt I've made has resulted in 502 gateway errors. My understanding of NGINX is that this should be possible, EG: that the NGINX server (provided the certs) can take https traffic targeting a particular domain...downgrade it to http for communication with the server playing it fast and loose, and return the traffic back with https.

Now there is one distinct complication which is...I'm already running another NGINX reverse proxy in order to reach docker. I believe I've set that up correctly since I have successfully navigated to projects which use https and http fine*. However I have no clue how to tell which of the NGINX servers is upset with what I'm doing when attempting for force https.

So my question is, for anyone with this type of NGINX experience. What config gets this to work?

[tigran-sargsyan-w]

Your understanding is correct: the backend application does not need to support HTTPS for the user to access it over HTTPS.

A very normal setup is:

Browser
   |
   | HTTPS :443
   v
Nginx Proxy Manager
   |
   | HTTP
   v
application:internal-port

NPM performs TLS termination. The browser-to-NPM connection is encrypted, while the NPM-to-application connection can be plain HTTP on the private Docker network.

For example, if your application listens on port 8080:

Proxy Host

Scheme: http
Forward Hostname / IP: my-container
Forward Port: 8080

SSL

Request/select SSL certificate
Force SSL: enabled

The important Docker part is exactly what you already discovered: NPM and my-container need to share a Docker network if you want to resolve the backend using its container/service name.

A 502 Bad Gateway usually means Nginx cannot successfully talk to the configured upstream. Common causes are:

wrong scheme (https configured while the backend only speaks HTTP)
wrong internal port
containers not sharing a Docker network
wrong hostname
application only listening on 127.0.0.1 inside its container

A very useful test is to run the request from inside the NPM container:
curl -v http://my-container:8080
If that doesn't work, NPM won't be able to proxy it either.

If you currently have two Nginx reverse proxies in series, I would simplify the path while debugging. You generally only need the public-facing proxy to terminate TLS.

If both proxies really are required, think of each hop independently:
client --HTTPS--> proxy A --HTTP/HTTPS--> proxy B --HTTP--> app
The configured scheme at every hop has to match what the next server is actually listening for.

So for a normal HTTP-only Docker app, there is nothing insecure or unusual about using:
HTTPS externally -> NPM -> HTTP internally
That's one of the main purposes of a reverse proxy.