Discourse mit Reverse Proxy Manager

Hallo, ich versuche, Discourse mit Reverse Proxy Manager auf Nginx auf einer Maschine einzurichten. Alles ist über meine DNS mit Standardports auf der Box erreichbar, aber wenn ich es mit einem Reverse Proxy einrichte, um den Traffic über meine Subdomain mit erzwungenem SSL zu leiten, funktioniert es einfach nicht. Ich bekomme einen 502. Ich betreibe mehrere Container. Proxy Manager ist isoliert und alles andere Discourse in einem anderen. Ich habe mir so ziemlich jeden Leitfaden angesehen, den ich finden kann, und nichts funktioniert. Es muss einen Weg geben, dies 2025 erfolgreich zu tun! Ich habe eine Website mit Proxy Manager laufen und das stimmt alles. Muss ich das FPM-Netzwerk an die Discourse-Container übergeben, da dies das Standardnetzwerk ist, das Proxy Manager verwendet, um Discourse-Container für Proxy Manager zugänglich zu machen? Wenn ja, wo muss ich das einstellen, da ich keine Informationen finden kann. Leute sagen, sie sollen es in ihre Setups einfügen, aber ich weiß nicht genau, wo. ? Ich möchte die Setups nicht ändern. Ich habe einige Anleitungen gesehen, die besagen, dass Ports nicht freigegeben werden sollen und Proxy Manager den Rest erledigen soll, das habe ich getan. Ich habe Anleitungen gesehen, die versuchen, Web.socketed templates.yml im Discourse/templates-Verzeichnis zu verwenden, aber das funktioniert auch nicht. Ich habe Leute gesehen, die dies mit und ohne das Freigeben von Ports auf Discourse zum Laufen gebracht haben. Nichts scheint hier konsistent zu sein. Was funktioniert und was funktioniert heutzutage gut. Denken Sie daran, ich betreibe nur eine Box.

1 „Gefällt mir“

Meine Vermutung ist, dass der Proxy-Manager perfekt funktioniert und der 502-Fehler von Discourse stammt, weil er nicht richtig konfiguriert ist.

Haben Sie die Let’s Encrypt- und SSL-Vorlagen in Ihrer YAML-Datei auskommentiert?

2 „Gefällt mir“

Gute Nachrichten – es sieht noch nichts „kaputt“ aus. Diese 502er-Fehlermeldung war mit ziemlicher Sicherheit ein Race Condition beim ersten Start: Nginx hat versucht, auf Ihren /srv/status zuzugreifen, bevor Unicorn bereit war. Ihre Protokolle zeigen:\n\n* unicorn: run :white_check_mark:\n* Rails gestartet :white_check_mark:\n* Nginx-Fehler um 17:34:11 „connection refused“ (wahrscheinlich bevor Unicorn fertig war)\n\nLassen Sie uns das schnell beheben.\n\n### 1) Versuchen Sie den Status erneut (Host → app2)\n\n\ncurl -sSI http://127.0.0.1:8002/srv/status\n\n\n2) Wenn immer noch 502 angezeigt wird, starten Sie Nginx in app2 einfach neu und testen Sie innerhalb des Containers:\n\n\ndocker exec -it app2 bash -lc 'sv restart nginx \u0026\u0026 sleep 2 \u0026\u0026 curl -sSI http://127.0.0.1/srv/status'\n\n\n\ncurl -sSI http://127.0.0.1:8002/srv/status\n\nSie sollten HTTP/1.1 200 OK sehen.\n\n- - -

Ich habe es zum Laufen gebracht. Da ich in 2 Docker-Containern laufe, musste ich den Zugriff erlauben, damit sie sich über ein Netzwerk sehen können. Es werden keine Ports über Discourse freigegeben, da es über interne Docker-Ports läuft. Außerdem ist es sicherer.

Jonnyboy! iPhones rocken!

1 „Gefällt mir“

Das hat Ihnen also eine KI erzählt. Hat es funktioniert?

1 „Gefällt mir“

Ja, es hat funktioniert, und dann habe ich das Ergebnis im folgenden Thema bekannt gegeben: