NGINX Reverse proxy for Docker app

#1

Im running HestiaCP 1.2.1 on ubuntu 20.04. Im using my current server as a webserver and installed couple of docker apps ie. plex,sonar,radar). Im using cloudflare as my DNS (mainly because of the auto ssl feature)

My objective is to reverse proxy + ssl for all my docker apps. My settings are as below for eg.plex

docker app: Plex
port: 32400
domain: plex.mydomain.com

I’ll add nginx config for the domain to

/etc/nginx/conf.d/domains/plex.mydomain.com.conf

with the following setting:

server {
    listen      192.168.1.100:80;
    server_name plex.mydomain.com;

location / {
    proxy_pass      http://192.168.1.100:32400;
    }
}

then i restarted the nginx server and the domain works for non-HTTPS plex
however when i set ssl config with HTTPS it will redirect me to the “success” webpage instead of my plex docker app. previously in vestaCP the setup above is sufficient to proxy pass into HTTPS address.

Does anyone have any idea how to do this with hestiacp? Thanks

#2

I would suggest to create a custom template for docker, then ssl will also work properly: https://docs.hestiacp.com/admin_docs/server_management.html#how-do-web-templates-work

#3

Well ive tried creating a custom nginx template as below and still having problem accessing docker app through https as it redirects to the “success” webpage instead of the port forwarded domain/docker app .

I don’t really understand what im doing though to be honest. Hoping anyone could lend a hand.

server {                                                                        
    listen      %ip%:%proxy_port%;                                              
    server_name %domain_idn% %alias_idn%;                                       
                                                                                
    location / {                                                                
        proxy_pass      http://%ip%:32400;                                       
    }                                                                           
}
#4

Did you also adjusted the stpl file?

#5

This will probably also work for you

Only need to modify the port…

1 Like
#6

Hi - thank you for this topic. I’ve been trying to migrate from ISPConfig, and how HestiaCP handles reverse proxies has been a challenge for me. I have tried the files @eris added (thank you!), and I now get an internal server error (500). So perhaps I can try to be more explicit.

The two files I’m editing are:

  • /usr/local/hestia/data/templates/web/nginx/cp.tpl, and
  • /usr/local/hestia/data/templates/web/nginx/cp.stpl

Correct? (and yes, the files can be named anything as long as the two are named the same with suffixes .tpl and .stpl, I’m just using the same filenames as what eris used)

Then, once I edit those two files, I change the HestiaCP interface here:

714×802 26.8 KB

Is that right? The only change I made to eris’s file is to change the port from 8083 (which is HestiaCP’s port) to 8183. Unfortunately, when I make that change, the server changes from “coming soon” to “internal server error.”

For what it’s worth, I’m testing the reverse proxy by using Bitwarden’s Docker image. The port to which I’m pointing the reverse proxy, 8183, is http. Bitwarden warns that I’m sending data to an insecure port, but that isn’t a big deal since 1- both HestiaCP and Bitwarden are on the same machine, and 2- ideally the HTTPS would be served through Hestia.

What else might I be missing?

#7

Are you sure the docker image is on that ip?

Also nginx -t will give errors :slight_smile:

#8

Fair question! Here’s the response from a curl:

/opt/bitwarden# curl 192.168.1.155:8183

<!DOCTYPE html>
<html>

<head>
    <meta charset="utf-8">
    <meta name="viewport" content="width=1010">
    <meta name="theme-color" content="#175DDC">

    <title page-title>Bitwarden Web Vault</title>
  ....

but, to your point, I don’t know exactly what %ip% is translated into, so I made one more modification to your file, removing %ip% and hardcoding 192.168.1.155 to see if that changed anything. I still get the internal server error.

Edit: Apologies, I missed your suggestion about nginx -t. Here’s the response:

/opt/bitwarden# nginx -t
nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful
/opt/bitwarden#
#9

I could confirm this template combo gives error 500 for reverse proxy. I change the port to my targetted app manually post lets encrypt ssl request.

#10

I believe I found the error. In this file: https://gist.github.com/jaapmarcus/25b513629139af4ff45915fa154675b9#file-cp-stpl

    location / {
        proxy_pass      https://%ip%:8083;
    }

That https should be http. I switched it to http and it works.

1 Like
#11

If your Docker app only supports http and no ssl yes…

#12

Also good point, thank you. It’s important http connects to http, and https connects to https. It’s unfortunate that the error isn’t more descriptive, but hey, at least the logs we able to shed a bit more light on the issue.

Thank you for your hard work on an open source project! In case it helps, my goal is to provide additional transparency for our government here in the United States. (We desperately need to re-establish a bit of credibility!) My web server will be dedicated to providing access to our government for the people, and I think it’s fitting that we choose open source technology throughout the process. People power that powers transparency for the people.

#13

Reserve proxy can be used to make from a non https website act as https website. Nginx will handle all SSL traffic and terminates it there.

In the “Hestia” case the as Hestia CP only supports ssl you can’t use it…

#14

Wait, the control panel can handle proxies if they have an SSL option? All of the Docker containers I intend to use also have HTTPS.

#15

Thanks for pointing this out. changing the https to http works

1 Like
#16

Hello,

Are there any ways to use upstream like the block below ?

### quiz
    upstream quiz {
      least_conn;
      server 172.30.0.20:5433;
      server 172.20.0.22:6433 down;
    }

Thanks !