Functionality in reverse proxy setup


I am very new in using reverse proxy. Therefor I need some background knowledge.

I have running 2 servers behind my router. Both are using different ports and for cert renewal I change the ports to 80 and/or 443 depending on requirements.

Now I want to add a reverse proxy. So can I keep the cert renewal process and SSL config on each server and just add the reverse proxy or MUST do the reverse proxy take care of the cert handling?

Looking forward to your reply.

Kind regards

1 Like

It depends on which ports will be handled by the reverse proxy.
If only port 80, then that can be proxied quite easily.
If port 443 will be proxied, then the proxy may have to terminate the TLS connections before it can proxy them correctly to their respective servers. As such, the proxy would need to have a valid cert for those names.
That said, those certs could be shared with the downstream servers and they too can use them.


I need to proxy 443 and want to redirect requests on port 80 to https. Does it mean it is better or easier to let the proxy handle the issuing of certs and remove the SSL config from the configuratin of the servers behind the proxy?

Easier? Yes [definitely much simpler].
Better? That's subjective.
It depends mainly on your view of where TLS encryption/security is required.


Yes, if your reverse proxy is answering https requests for your services it will normally handle the ssl stuff (terminate ssl) TLS termination proxy - Wikipedia

Your back-end services can optionally also use TLS (ssl) but the client browser is directly interacting with the proxy only. [This is also a particularly useful setup if your backend services are running in docker on a a variety of ports]


OK, hope I got it. :wink:

A question left and I know it might be not a LE issue. I have installed a proxy for test purpose. I ran Certbot and it managed my nginx configuration as expected. Here it is:

server {
        location / {
                proxy_set_header Host $host;
                proxy_set_header X-Real-IP $remote_addr;
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        client_max_body_size 0;

        # SSL config managed by Certbot
        listen 443 ssl; # managed by Certbot
        ssl_certificate /etc/letsencrypt/live/; # managed by Certbot
        ssl_certificate_key /etc/letsencrypt/live/; # managed by Certbot
        include /etc/letsencrypt/options-ssl-nginx.conf; # managed by Certbot
        ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem; # managed by Certbot

        # Nextcloud service redirect as described in here:
        location /.well-known/carddav {
                return 301 $scheme://$host/remote.php/dav;

        location /.well-known/caldav {
                return 301 $scheme://$host/remote.php/dav;

server {
        if ($host = {
        return 301 https://$host$request_uri;
        } # managed by Certbot

        listen 80;
        return 404; # managed by Certbot


Now I thought all http calls will be redirected to https: But it is still possible to call the page via http and it will be delivered via http. :frowning: Any idea what it is caused by?

It looks to me like it's redirecting properly—do you maybe have a browser with a cached connection with no redirect? Maybe you would see something different after restarting the browser?


Well, I tried with Edge and Chrome and both of them has been cleaned previously and restarted afterwards. You can try by your own:

Yep, it loaded securely for me in Firefox, Chromium, and Brave.


Strange, with Chrome on my mobile device it will be secured as well, but not on my laptop.

Tested Brave as well on laptop, unsecure as well:

Any idea why the redirect is not working? I am working from Egypt this week. Might this be a reason? Some testers in Germany confirmed, that the redirect is working properly fine at their end.

What about some orphaned nginx running process(es)?


Are you using a VPN that somehow is connecting you, in some other way, to the proxied address?:


Could your network be doing an SSLstrip attack?

1 Like

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.