O que diz o log/production.log (no Docker em execução) quando você tenta fazer login com falha (portanto, com force_https=true)?
@RGJ – Adorei sua solução! Devo usar force-https com a última sugestão? RE proxy_pass https.
EDIT: Recebo um erro 502 se apenas usar proxy_pass https://192.168.86.108.
EDIT2: Desabilitei a porta 80 no Discourse via app.yml e ainda assim não funcionou. Acabei de reler sua postagem: o container do Discourse possui sua própria instância do Nginx? Então, na prática, estou passando um proxy para outro proxy? Desculpe, estou realmente confuso neste momento.
@itsbhanusharma eu devo comentar 80:80 #http e seguir o conselho de @RGJ de usar proxy_pass https?
Por que você não está seguindo o processo suportado para multisite aqui? Você está essencialmente reinventando uma roda muito frágil.
Foram fornecidos tantos links agora, @Stephen, que estou sem saber como entender tudo. Eu achava que estava seguindo os processos suportados. Os comentários acima não são suportados? 
Sim, porque você não estava usando force_https, daí a tag unsupported-install acima. Se você se desviar de uma trajetória suportável, não receberá muita assistência.
Comece aqui:
Há um guia separado para lidar com encapsulamento SSL em multisite.
Então, o container padrão executa apenas http? Como o que estou tentando fazer é multi-site? Não estou tentando hospedar múltiplos domínios; tenho um único domínio. Poderia, por favor, esclarecer como isso resolve meu problema?
O que você quis dizer com:
Configurei servidores Discourse em cerca de 5 instâncias e todas parecem apresentar comportamento estranho; não tenho certeza se é realmente um bug ou se alguém mais teve a mesma experiência.
Infraestruturas independentes, de forma alguma conectadas entre si.
Mas todas com configurações muito semelhantes, conforme descrito acima.
Então, por que o nginx está fazendo proxy do host de qualquer forma? O que mais está acontecendo nas máquinas?
Temos várias VMs que não são expostas externamente; o tráfego é roteado através do proxy (que está exposto externamente) até a VM do Discourse internamente. Situação semelhante em cada uma das instalações separadas. Isso esclarece?
Não exatamente, mas de uma forma ou de outra, essa é uma dor técnica com a qual você vai ter que conviver. É impossível comentar se há uma abordagem melhor quando o caso de uso e a topologia são tão ambíguos.
Acredito que a combinação correta de soluções foi a seguinte:
Conforme mencionado por @itsbhanusharma:
EDITAR /var/discourse/containers/app.yml e alterar as portas para algumas personalizadas. Eu usei:
- "8080:80" #http
- "4343:443" #https
Executei ./launcher rebuild app
Em seguida, modifiquei nosso proxy externamente acessível para encaminhar solicitações nas portas 80/443 para http://ip_interno:8080
Após executar sudo nginx -t e sudo systemctl restart nginx, fiz login no servidor https://discourse.mobiusnode.io (que ainda apresentava os problemas mencionados acima) e ativei force_https, momento em que parece que tudo está funcionando corretamente.
Agora vou reproduzir isso nos demais servidores/infraestruturas.
Apenas para esclarecer, isso não é o que eu sugeri.
Eu apenas pedi que você expusesse a porta 80 em um IP local e terminasse o SSL no seu proxy reverso.
Então, não usar SSL no meu proxy externo, mas sim encaminhar solicitações http simples para o servidor Discourse e permitir que o force_https trate essas solicitações? Como o certificado é então transmitido? Através da primeira instância do Nginx? É aqui que as coisas quebram para mim.
Bem, desde que funcione e você possa reconstruir/atualizar sem problemas. Parece que você já está fazendo o que @itsbhanusharma sugeriu em sua postagem mais recente.
Se você estiver compartilhando um único IP com múltiplas conexões SSL, precisará de um certificado SAN na frente do seu proxy. Se a rede for segura, tudo o que estiver atrás dela pode ficar sem criptografia.
O Discourse exige o force_https se o usuário se conectar via SSL, e você precisa garantir que o cabeçalho mencionado acima seja preservado e encaminhado.
Não, existe algo chamado SNI.
Estou bem ciente disso, mas como todos os certificados vêm do Let’s Encrypt, qual seria o valor em solicitar certificados separados? O LE suporta SAN, então por que não usá-lo?