Fresh install returning 502 Bad Gateway

Hi All,

I have setup discourse twice once in a container and the current one in a VM on both installs discourse is not reachable. Im not too sure what could be wrong.

Discourse VM:

  • Cores 4
  • Ram 6GB
  • Storage 50GB
  • OS: Ubuntu 22.04.3

Clean Post OS Install commands:

apt update -y && apt upgrade -y && apt wget curl zip git -y && reboot

Then I followed the following guide: discourse/docs/ at main · discourse/discourse · GitHub

Once completed, i can see that the container is running but its return 502 Bad Gateway.

How i set it up: Nginx Reverse Proxy (includes SSL) → VM. This does not work.
it does not even load when i add it directly into my hosts file.

From the last lines of the install i can see docker created a new network:

DOCKER_HOST_IP= --name app -t -p 80:80 -p 443:443

How to i get it to use the HOST machine’s IP ?
I do not need another network in a network. I am happy for docker to use the HOST IP as this is the only service on this VM.

Any assistance would be greatly appreciated!

Is there an official method to install without docker ?


Is the container on a machine with a public IP? Does that public IP have a domain name assigned?

Did you run discourse-setup? Did you get past the part where it checks if your DNS is valid and the host is available?

Did you run a bunch of rebuilds so that you got rate limited by let’s encrypt and can’t be assigned a certificate?

No, this machine is assigned a local IP and traffic gets routed to the localIP via my firewall. This is not the issue.
The Public IP has an A record for the server and it gets routed correctly. points → to the correct server.

Yes, I have passed the install. Completed it 100% (3 times) to the point where the container is running.
It gets passed all the domain/dns checks. It states valid.

No, this cannot get rate limited as the SSL certificate is issued via my reverse proxy. I have the certificate.

This install is completed 100%. The issue is that Docker is creating a new network which is not needed as i would like to use the HOST local IP 192.xx.xx.xx

The container is running but on a different network. I am unable to get it to the HOST IP

The docker host should be the IP of the host server ( and not a new network. It is probably working but on that network.
How do i tell the install to use my local ip and not

@pfaffman Something like this. From a comment you made

How do i set the ./discourse-setup to use host ip 192.168.1.X and network on install ?

You can’t use discourse-setup with a reverse proxy. You’ll have to edit the yml file yourself. There are some topics about running discourse with other sites on the same machine.

You’ll need to remove the ssl and let’s encrypt templates if you’re using a reverse proxy that does the ssl stuff.

That’s the thing, I am not running any other services on this machine. Its a standalone VM.

I think theres a misunderstanding.

The ./docker-setup installs successfully. It creates a network of its own for the app

How to i get the install or the docker container to use the host ip 192.168.1.X as in use a bridge network not create its own network.

But you said this:

If you’re using a reverse proxy you can’t use discourse-setup.

Yes, the reverse proxy is on another server but i get what you are saying.

I have an idea. Im just going to route all traffic from my network to the docker containers network.

Is there an installation guide for running discourse behind a nginx reverse proxy?

Or a way i can build discourse myself ?

That is quite trivial. You allow http port on app.yml where Ngix is sending traffic. And SSL is disabled. Those two things are the only ones you have yo fix. Of course you have to tell real IP, but that must do everytime is backend Discourse, Moodle, WordPress on what ever. UFW tries to limit access just between frontend and backend because there is no need to allow direct access to backend.

If I recall right here is doc how to setup Apache2. Nginx does same thing, but it’s own way of course.

Or what am I missing now?

1 Like

Let me start from the top so you can its something simple i am missing.

I have Nginx Reverse Proxy. Running and managing the Public IP and doing the routing to services.

EG: client requests → Nginx Reverse Proxy (handles ssl) → Points to

Now i have setup a VM for discourse and used the following:
Ubuntu 23.04. Post OS Install commands:

apt update -y \
apt upgrade -y \
apt install wget curl zip git -y

Then I followed this guide from Discourse discourse/docs/ at main · discourse/discourse · GitHub

The install completes successfully and then the issues starts.

I cannot access the docker container from the host because of the docker0 network. I can ping and it is up and running but from the host machine does not pass traffic to the container.

All i want is for the docker container to use the host network as the container has 80 & 443 ports exposed.

The first nginx reverse proxy handles the traffic from the outside and passes it to the VM correctly. If it did not then the ./discourse-setup would not have picked up the domain name correct and it would not be able to retrieve ssl certificates for the container.

At the end. I know that the container is working 100% i just cannot access it due to the docker network.

if you need any information please let me know.

Another way to approach this is use the discourse base image

And build your own orchestration with eg docker compose (remembering you need some other services like redis and postgres)

I can do that with Nginx or Nginx+Varnish to Discourse on same VPS or VPS on different IP. You don’t tell what you actually do with your Nginx acting as reverse proxy. Your examples are bit difficult because there is no way to know if those are examples or if you are actual trying to use private network.


Of course not, because that takes care incoming traffic. You must use something else port for backend.

Something like this (that is actually used with Varnish, but the princible is totally same, and very much 101-level stuff):

proxy_set_header X-Real-IP  $remote_addr;
proxy_set_header X-Forwarded-For
proxy_set_header X-Forwarded-Proto https;
proxy_set_header X-Forwarded-Port 443;
proxy_set_header Host $host;
proxy_pass_header Server;

Understandable, Thank you for being specific :).

Im not sure what because this docker network is confusing.

Absolutely thats why im getting frustrated with docker lol

Bellow is exactly how the WAN network passes and routes traffic from my nginx reverse proxy to the correct host.

map $scheme $hsts_header {
    https   "max-age=63072000;includeSubDomains; preload";

server {
  set $forward_scheme https;
  set $server         "";
  set $port           443;

  listen 80;
listen [::]:80;

listen 443 ssl http2;
listen [::]:443 ssl http2;


  # Let's Encrypt SSL
  include conf.d/include/letsencrypt-acme-challenge.conf;
  include conf.d/include/ssl-ciphers.conf;
  ssl_certificate /srv/ssl/domainname.pem;
  ssl_certificate_key /srv/ssl/domainname-ke.pem;

# Asset Caching
include conf.d/include/assets.conf;

# Block Exploits
include conf.d/include/block-exploits.conf;

# HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
add_header Strict-Transport-Security $hsts_header always;

# Force SSL
include conf.d/include/force-ssl.conf;

proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection $http_connection;
proxy_http_version 1.1;

access_log /var/logs/domainname-access.log proxy;
error_log /var/logs/domainame_error.log warn;

proxy_set_header  X-Real-IP $remote_addr;
proxy_set_header  X-Forwarded-For $http_x_forwarded_for;
proxy_set_header  X-Forwarded-Proto $scheme;

location / {

  # HSTS (ngx_http_headers_module is required) (63072000 seconds = 2 years)
  add_header Strict-Transport-Security $hsts_header always;

    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection $http_connection;
    proxy_http_version 1.1;
    # Proxy!
    include conf.d/include/proxy.conf;

What is weird, i have setup a docker container once for a client that wanted nginx reverse proxy manger and it was extremely simple.

docker-compose up -d
That was it . The private ip could reach the containers exposed 80/443 and the outgoing traffic was routed correctly to

It is confusing because it is packeting system that plays in its own sandbox. Basically that it is.

But understanding docker is different thing than using it (and now bunch of devs started crying :rofl: ) Your reverse proxy is sending traffic to IP thru firewall and you have to tell that IP and listening port. And you have Discourse, aka. docker, on that IP, and the port you tell on app.yml. Inner Nginx that works with Discourse itself takes care of rest.

Discourse should not listen 443 because you already terminated SSL.

And you basically can’t use caching on reverse proxy. Backend, Discourse, is not a web page. It is a web app sending jacascript and json.

I kind of somewhat figured that out.

That is something i can agree with. I would not say crying its just useless to sysadmins and devs who actually know there way around linux. Creating a LxC or VM which is isolated to then let docker create another isolated environment is redundant and pointless.

This is the part that is confusing. app.yml is exposing 80:80 and 443:443 on which is on the docker network with the VM’s IP on

How do i get discourse/docker to allow all traffic coming to to be passed to and all outgoing traffic must be passed to Thats all that is needed to solve this issue. Literally.

My Reverse proxy will handle the routing from the WAN to

Caching has been removed.

1 Like

Only if you don’t change those. As you should and use only one port.

80:80 and 443:443 are defaults and used per se only when there is no reverse proxy, or anything else, acting as a frontend.

1 Like

You gave me an idea.

I was busy checking all the base files and i think i have figured it out.

So simple lol. Im busy with rebuilding this might work 100% with using the standard officially supported installation methods.

Success The forum has now been installed and is working.

Using the standard and supported method of installation :smiley:


@pfaffman You can move this to installation as it is now a supported install.

It is there. It is just tagged as unsupported :smirk:

What was your issue in the first place why you didn’t start installing without reverse proxy? I’m just curious.