Was sagt die Datei log/production.log (im laufenden Docker-Container), wenn Sie sich mit einem Fehler anmelden versuchen (also mit force_https=true)?
@RGJ – Deine Lösung gefällt mir! Soll ich bei dem letzten Vorschlag force-https verwenden? Bezüglich proxy_pass https.
EDIT: Ich erhalte einen 502-Fehler, wenn ich nur proxy_pass https://192.168.86.108 verwende.
EDIT2: Ich habe Port 80 in Discourse über app.yml ausgeblendet, aber es funktionierte immer noch nicht. Ich habe deinen Beitrag gerade noch einmal gelesen: Verfügt der Discourse-Container über eine eigene Instanz von Nginx? Stelle ich also im Grunde einen Proxy vor einen Proxy? Entschuldigung, ich bin an diesem Punkt wirklich verwirrt.
@itsbhanusharma Kommentiere ich 80:80 #http aus und befolge @RGJs Rat, proxy_pass https zu verwenden?
Warum befolgst du hier nicht den unterstützten Prozess für Multisite? Du erfindest damit effektiv ein sehr fragiles Rad neu.
Es wurden so viele Links bereitgestellt, @Stephen – ich weiß gar nicht mehr, was ich daraus machen soll. Ich dachte, ich würde die unterstützten Prozesse befolgen. Sind die oben genannten Kommentare nicht unterstützt? 
Ja, weil du force_https nicht verwendet hast, weshalb oben der Tag unsupported-install steht. Wenn du von einem unterstützten Pfad abweichst, erhältst du nur wenig Unterstützung.
Beginne hier:
Es gibt einen separaten Leitfaden zur Handhabung von SSL-Verschlüsselung bei Multisite.
Also, läuft der Standard-Container nur http? Wie ist das, was ich versuche, multi-site? Ich versuche nicht, mehrere Domains zu hosten? Ich habe eine einzige Domain. Können Sie bitte klären, wie das mein Problem löst?
Was hast du mit folgendem gemeint:
Ich habe Discourse-Server in etwa 5 Instanzen eingerichtet, und alle zeigen seltsames Verhalten. Ich bin mir nicht sicher, ob es sich tatsächlich um einen Fehler handelt oder ob jemand anderes ähnliche Erfahrungen gemacht hat.
Unabhängige Infrastrukturen, die in keiner Weise miteinander verbunden sind.
Alle jedoch mit sehr ähnlichen Einstellungen wie oben beschrieben.
Warum proxyt nginx den Host überhaupt? Was läuft noch auf den Maschinen?
Wir haben mehrere VMs, die nicht extern exponiert sind; der Verkehr wird über den Proxy (ist extern exponiert) zur internen Discourse-VM geleitet. Eine ähnliche Situation besteht bei jeder der einzelnen Installationen. Ist das jetzt klarer?
Nicht wirklich, aber auf die eine oder andere Weise ist dies ein technisches Problem, mit dem du einfach leben musst. Es ist unmöglich zu kommentieren, ob es einen besseren Ansatz gibt, wenn der Anwendungsfall und die Topologie so unklar sind.
Ich bin der Meinung, dass die richtige Kombination von Lösungen wie folgt aussah:
Wie von @itsbhanusharma angegeben:
BEARBEITET /var/discourse/containers/app.yml und ändern Sie die Ports auf benutzerdefinierte Werte. Ich habe Folgendes verwendet:
- "8080:80" #http
- "4343:443" #https
Dann habe ich ./launcher rebuild app ausgeführt.
Anschließend habe ich unseren extern zugänglichen Proxy so angepasst, dass er Anfragen auf 80/443 an http://internal_ip:8080 weiterleitet.
Nach einem sudo nginx -t und sudo systemctl restart nginx habe ich mich auf dem Server https://discourse.mobiusnode.io angemeldet (auf dem weiterhin die oben genannten Probleme auftraten) und force_https aktiviert. Seither scheint alles zu funktionieren.
Nun werde ich dies auf den verbleibenden Servern/Infrastrukturen nachvollziehen.
Nur zur Klarstellung: Das ist nicht das, was ich vorgeschlagen habe.
Ich habe nur darum gebeten, Port 80 auf einer lokalen IP-Adresse freizugeben und SSL auf Ihrem Reverse-Proxy zu terminieren.
Also, nicht SSL auf meinem nach außen gerichteten Proxy zu verwenden, sondern stattdessen normale http-Anfragen an den Discourse-Server weiterzuleiten und force_https die Bearbeitung dieser Anfragen zu überlassen? Wie wird das Zertifikat dann übergeben? Über die erste Nginx-Instanz? Hier scheitert es bei mir.
Nun, solange es funktioniert und Sie sauber neu aufbauen/upgraden können. Es sieht so aus, als würden Sie bereits das tun, was @itsbhanusharma in ihrem neuesten Beitrag vorgeschlagen hat.
Wenn Sie eine einzelne IP-Adresse mit mehreren SSL-Verbindungen teilen, benötigen Sie ein SAN-Zertifikat an der Vorderseite Ihres Proxys. Ist das Netzwerk sicher, kann alles dahinter unverschlüsselt bleiben.
Discourse benötigt force_https, wenn der Benutzer über SSL verbindet, und Sie müssen sicherstellen, dass der oben genannte Header erhalten bleibt und weitergeleitet wird.
Nein, es gibt etwas, das SNI genannt wird.
Mir ist das sehr wohl bewusst, aber da alle Zertifikate von Let’s Encrypt stammen, welchen Mehrwert hat es, separate Zertifikate anzufordern? LE unterstützt SAN, also warum nicht damit arbeiten?