EDIT: @pfaffman reescreveu isso como um tópico independente com base no que @tophee havia escrito anteriormente. Ainda não foi testado por mim, e eu reorganizei as palavras do Chris, então quaisquer erros provavelmente são de @pfaffman.
Existem motivos para não usar o NGINX Proxy Manager em vez de fazer isso manualmente, conforme descrito em Run other websites on the same machine as Discourse?
Eu já o estou usando. Tenho ele no meu servidor doméstico há algum tempo e, quando migrei minha instância do Discourse para um novo servidor em nuvem, percebi que havia esquecido a maior parte da configuração do proxy reverso NGINX que fiz há 4 anos no servidor antigo. Então pensei: por que não fazer isso com o NGINX Proxy Manager? Para minha surpresa, descobri que ele foi mencionado bastante raramente aqui no meta, então comecei a me perguntar se havia algumas desvantagens que eu poderia ter perdido…
De fato, isso exigiu um pouco de tentativa e erro, mas consegui fazê-lo funcionar da seguinte forma (sem garantia de que esta seja a melhor maneira de fazer isso — na verdade, sei que deve haver uma maneira melhor — então correções e melhorias são muito bem-vindas):
Para começar, existem duas maneiras de acessar sua instância do Discourse: 1. expondo uma porta, 2. via websocket. Acredito ter aprendido em algum lugar neste fórum que o websocket é mais rápido/mais eficiente, então é isso que estou usando, mas expor uma porta deve ser muito mais fácil, então se você não conseguir fazer o socket funcionar, tente expor uma porta. Portanto, para evitar confusão: para acessar o Discourse via porta, siga os passos 0, 1, 2, 3, 4 e 8 abaixo. Se você quiser usar um websocket, siga os passos 0, 1, 5, 6, 7, 8 e 9.
0. Ponto de partida
Vamos supor que você tenha concluído a instalação padrão de 30 minutos e vamos supor que você não tenha deixado o Discourse adquirir um certificado lets encrypt ainda — porque você não precisa dele ao usar um proxy reverso. O NGINX Proxy Manager cuidará disso. Não importa, no entanto, se você já tiver um certificado. O NGINX Proxy Manager simplesmente obterá um novo.
1. Instalar o NGINX Proxy Manager
O próximo passo é instalar o NGINX Proxy Manager para que você tenha mais dois contêineres Docker em execução (o NGINX Proxy Manager e seu contêiner de banco de dados).
Agora vem a parte complicada sobre a qual você está perguntando.
O primeiro obstáculo é que o Discourse roda na rede bridge padrão do Docker, enquanto o NGINX Proxy Manager, por padrão, roda em uma “rede criada pelo usuário” padrão (chamada npm_default no meu caso), o que significa que o NGINX Proxy Manager não consegue ver o Discourse. 
2. Trazer todos os contêineres para a rede bridge padrão
Então, enquanto não sei se e como o Discourse pode ser movido para uma rede personalizada, temos que mover o NGINX Proxy Manager para a rede bridge padrão. Podemos fazer isso adicionando network_mode: bridge a ambos os contêineres do NGINX Proxy Manager em nosso arquivo docker compose.
3. Usar endereço IP em vez de nome de serviço
O próximo problema é que o arquivo docker compose padrão não funcionará mais se você apenas movê-lo para a rede bridge. O NGINX Proxy Manager não conseguirá mais encontrar seu contêiner de banco de dados. Isso ocorre porque a resolução interna de DNS para nomes de serviço (da qual o arquivo docker-compose depende) está disponível apenas em redes criadas pelo usuário, não nas redes padrão do Docker. Portanto, temos que recorrer a endereços IP codificados (o que torna isso definitivamente não a solução ideal, pois quebrará se os IPs dos seus contêineres mudarem). Então, você precisa iniciar o contêiner mesmo sabendo que não funcionará, anote o IP do contêiner de banco de dados do NGINX Proxy Manager e substitua DB_MYSQL_HOST: "db" no seu arquivo docker compose por DB_MYSQL_HOST: "<ip_do_contêiner_db>".
Agora todos os contêineres devem estar na rede bridge padrão para que o NGINX Proxy Manager possa ver tanto o Discourse quanto seu banco de dados.
4. Tornar o Discourse acessível
Mas “ver” o Discourse e ser capaz de acessá-lo não é a mesma coisa. Então, você precisa garantir que o Discourse aceitará qualquer tráfego que o NGINX Proxy Manager encaminhar para ele. Se você não se importa em usar o websocket, imagino que possa apenas apontar o NGINX Proxy Manager para a porta 80 (não 443) do IP do seu contêiner do Discourse, assim:
Não testei isso, no entanto. Como mencionei, estou usando a configuração do websocket, que requer alguns passos adicionais. Note que o nome de host/IP e a porta acima serão ignorados quando você usar o websocket.
5. Configurar app.yml para usar websocket
Isso está explicado no OP, então não vou entrar nisso.
6. Montar o websocket no contêiner do NGINX Proxy Manager
Precisamos dar ao NGINX Proxy Manager acesso ao websocket montando-o como um volume: - /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock. Esta é a última alteração no arquivo docker compose padrão do NGINX Proxy Manager, então aqui está a versão final que funciona para mim:
version: '3'
services:
app:
image: 'jc21/nginx-proxy-manager:latest'
restart: unless-stopped
network_mode: bridge
ports:
- '80:80'
- '81:81'
- '443:443'
environment:
DB_MYSQL_HOST: "172.17.0.6"
DB_MYSQL_PORT: 3306
DB_MYSQL_USER: "npm"
DB_MYSQL_PASSWORD: "my-super-safe-pwd"
DB_MYSQL_NAME: "npm"
volumes:
- ./data:/data
- ./letsencrypt:/etc/letsencrypt
- /var/discourse/shared/standalone/nginx.http.sock:/var/discourse/shared/standalone/nginx.http.sock
db:
image: 'jc21/mariadb-aria:latest'
restart: unless-stopped
network_mode: bridge
environment:
MYSQL_ROOT_PASSWORD: 'my-super-safe-pwd'
MYSQL_DATABASE: 'npm'
MYSQL_USER: 'npm'
MYSQL_PASSWORD: 'my-super-safe-pwd'
volumes:
- ./data/mysql:/var/lib/mysql
7. Configurar o NGINX Proxy Manager para usar o websocket
Último passo: dizer ao NGINX Proxy Manager para usar o websocket. Até onde me lembro, não foi suficiente apenas ativar o “Suporte a Websockets”, então copiei o local NGINX do OP para a aba “Avançado”, assim:
Não consegui fazer isso funcionar na aba “Locais personalizados”.
8. Não esqueça de ativar o SSL
Não mencionei a configuração SSL no NGINX Proxy Manager porque parece bastante óbvia e não acho que importa em que ponto do processo você a ativa. Então, se você ainda não fez isso, é assim que a minha se parece:
9. Atenção
tl;dr Sempre que você reiniciar o contêiner do Discourse, também precisará reiniciar o contêiner principal do NGINX Proxy Manager (não é necessário reiniciar o banco de dados).
Se você estiver acessando o Discourse através do websocket, precisa estar ciente de que, ao reconstruir seu contêiner do Discourse (como é necessário a cada poucos meses para atualizar a imagem base), o websocket anterior será excluído e um novo será criado. Como consequência, o NGINX Proxy Manager perderá o contato com sua instância do Discourse e retornará um erro 502. Talvez uma atualização futura do NGINX Proxy Manager seja capaz de encontrar o novo websocket automaticamente, mas atualmente (janeiro de 2022) o NGINX Proxy Manager não encontrará seu contêiner do Discourse reconstruído a menos que você reinicie o NGINX Proxy Manager.
Explicação
Se você está se perguntando por que as instruções acima combinam o websocket com portas, a razão simples é que, enquanto escrevia este post, de repente me ocorreu que o NGINX Proxy Manager e o Discourse provavelmente nem precisam estar na mesma rede Docker quando usamos o websocket. E quando isso foi confirmado, ninguém sentiu vontade de reescrever completamente as instruções.
Este é o aspecto mais fascinante dos fóruns de suporte: fazer um bom trabalho descrevendo seu problema muitas vezes leva você à solução sem nem mesmo postar sua pergunta. E neste caso, eu estava respondendo à pergunta de outra pessoa, mas também pude ter encontrado a resposta para a minha própria. 
Mas, após examinar o NGINX Proxy Manager por 12 segundos ou mais, acredito que ele funcionará bem. Há outra ferramenta “automágica” de proxy NGINX que já vi ser discutida anteriormente também, mas com meu extenso conhecimento do NGINX Proxy Manager, acho que ele pode ser melhor. Posso dar uma olhada nela, pois estou ficando desiludido com o Traefik.
está morto.
), enfim, tudo funcionou como deveria. Em seguida, fiz as modificações para que o Discourse funcionasse com WebSocket: tudo certo também dessa vez. Felizmente, a configuração anterior do Discourse fez backups automáticos, então com apenas alguns cliques restaurei tudo (quanto mais uso o Discourse, mais o amo!).