¿Qué dice el archivo log/production.log (en el contenedor Docker en ejecución) cuando intentas iniciar sesión y falla (por lo tanto, con force_https=true)?
@RGJ – ¡Me gusta tu solución! ¿Debo forzar HTTPS con la última sugerencia? En cuanto a proxy_pass https.
EDICIÓN: Recibo un error 502 si solo uso proxy_pass https://192.168.86.108.
EDICIÓN 2: Desactivé el puerto 80 en Discourse mediante app.yml y aún así no funcionaba; acabo de volver a leer tu publicación, ¿tiene el contenedor de Discourse su propia instancia de Nginx? Entonces, en efecto, estoy reenviando un proxy a otro proxy. Lo siento, en este punto estoy realmente confundido.
@itsbhanusharma ¿Debo comentar 80:80 #http y seguir el consejo de @RGJ de usar proxy_pass https?
¿Por qué no estás siguiendo el proceso soportado para multisitio aquí? Básicamente, estás reinventando una rueda muy frágil.
Se han proporcionado tantos enlaces ahora, @Stephen, que me encuentro perdido tratando de entenderlo todo. Pensé que estaba siguiendo los procesos admitidos. ¿No se admiten los comentarios anteriores? 
Sí, porque no estabas usando force_https, de ahí la etiqueta unsupported-install de arriba. Si te desvías de una ruta compatible, no recibirás mucha ayuda.
Comienza aquí:
Hay una guía separada para manejar el encapsulamiento SSL con multisitio.
Entonces, ¿el contenedor estándar solo ejecuta http? ¿En qué se basa lo que estoy intentando hacer para ser multi-sitio? No estoy tratando de alojar múltiples dominios; tengo un único dominio. ¿Podrías aclarar cómo eso resuelve mi problema?
¿Qué quisiste decir con:
He configurado servidores de Discourse en unas 5 instancias y todos parecen mostrar un comportamiento extraño; no estoy seguro de si es realmente un error o si alguien más ha experimentado lo mismo.
Infraestructuras independientes, que de ninguna manera están conectadas entre sí.
Pero todas con configuraciones muy similares, como se indica anteriormente.
¿Entonces por qué nginx está haciendo proxy del host en absoluto? ¿Qué más está ocurriendo en las máquinas?
Tenemos varias máquinas virtuales que no están expuestas externamente; el tráfico se enruta a través del proxy (sí expuesto externamente) hacia la máquina virtual de Discourse internamente. Situación similar en cada una de las instalaciones por separado. ¿Eso aclara?
No realmente, pero de una manera u otra, este es un dolor técnico con el que simplemente tendrás que vivir. Es imposible comentar si existe un enfoque mejor cuando el caso de uso y la topología son tan ambiguos.
Creo que la combinación correcta de soluciones fue la siguiente:
Según @itsbhanusharma:
EDITAR /var/discourse/containers/app.yml y modificar los puertos a unos personalizados; yo usé:
- "8080:80" #http
- "4343:443" #https
Ejecuté ./launcher rebuild app
Luego modifiqué nuestro proxy accesible externamente para reenviar las solicitudes en los puertos 80/443 a http://internal_ip:8080.
Después de ejecutar sudo nginx -t y sudo systemctl restart nginx, inicié sesión en el servidor https://discourse.mobiusnode.io (que aún mostraba los problemas mencionados) y habilité force_https, momento en el cual parece que todo funciona correctamente.
Ahora voy a reproducir este proceso en los servidores/infraestructuras restantes.
Solo para aclarar, esto no es lo que sugerí.
Solo te pedí que expusieras el puerto 80 en una IP local y terminaras SSL en tu proxy inverso.
Entonces, ¿no usar SSL en mi proxy expuesto externamente, sino reenviar solicitudes http en texto plano al servidor de Discourse y permitir que force_https gestione esas solicitudes? ¿Cómo se transmite entonces el certificado? ¿A través de la primera instancia de Nginx? Aquí es donde las cosas se rompen para mí.
Bueno, mientras funcione y puedas reconstruir o actualizar sin problemas. Parece que ya estás haciendo lo que @itsbhanusharma sugirió en su publicación más reciente.
Si estás compartiendo una única dirección IP con múltiples conexiones SSL, necesitas un certificado SAN en el extremo frontal de tu proxy. Si la red es segura, todo lo demás detrás de ella puede ir sin cifrar.
Discourse requiere force_https si el usuario se conecta mediante SSL, y debes asegurarte de que la cabecera señalada anteriormente se conserve y reenvíe.
No, existe algo llamado SNI (Indicación del Nombre del Servidor).
Lo tengo muy claro, pero si todos los certificados provienen de Let’s Encrypt, ¿qué valor tiene solicitar certificados separados? Let’s Encrypt admite SAN, así que ¿por qué no usarlo?