WARNUNG: Port 443 des Computers scheint nicht zugänglich zu sein, aber die Webseite ist in Ordnung

Hallo,

ich bekomme diesen Fehler bei der Einrichtung von Discourse:
WARNUNG: Port 443 des Computers scheint über den Hostnamen nicht erreichbar zu sein.
auf einem selbst gehosteten Debian-Server.
Ich benutze eine dedizierte Domain für Discourse, ich habe eine einfache HTML-Indexseite eingefügt, sie funktioniert.
Aber es gibt andere Domains, die auf diesen Server zeigen, aber nur einfache HTML-Webseiten.
Ich habe in ähnlichen Themen gelesen, dass Discourse nicht auf demselben Server wie WordPress laufen kann.
Aber gibt es andere Einschränkungen?
Vielen Dank.

Discourse kann und wird sehr gut mit Wordpress funktionieren. Aber ob das auf Ihrem eigenen Computer geht, ist eine ganz andere Geschichte. Ich bringe das nur zur Sprache, weil jemand dieses Thema über die Suche finden und ein Bild davon bekommen könnte, dass die Verwendung von Wordpress (oder fast jedem anderen CMS/App) auf demselben Server wie Discourse, im Sinne von Server == VPS, unmöglich ist. Und das ist es nicht. Das ist eigentlich ganz einfach.

1 „Gefällt mir“

oki danke für die Präzision:)

Sie müssen die Dinge von Hand konfigurieren. Siehe So richten Sie Discourse auf einem Server mit vorhandenen Apache-Websites ein. Sie können discourse-setup nicht verwenden.

1 „Gefällt mir“

oki danke für den Link, er handelt von Apache, aber ich bin bei Nginx, wird wohl das Gleiche funktionieren?

1 „Gefällt mir“

Sie können nach einem ähnlichen Thema für nginx suchen.

Ich gehe davon aus: Sie haben einen Server, der von mehreren Domains oder Subdomains genutzt wird, die alle auf denselben Server zeigen.

Sie müssen also hauptsächlich einen Haupt-Proxy-Server betreiben, der auf Port 80 und 443 lauscht, wenn Sie TLS/SSL verwenden.

Der Haupt-Proxy-Server leitet den Datenverkehr dann basierend auf dem Host/der Domain weiter, d.h. discourse.example.com => zu Discourse, blog.example.com => zu WordPress.

Ich denke, Sie haben mehrere Optionen, wie Sie eine solche Bereitstellung handhaben können, da WordPress normalerweise mit seinem eigenen Proxy-Server geliefert wird, ebenso wie Discourse. Ihre Optionen könnten also sein:

  • Verwenden Sie den Nginx-Proxy-Server von Discourse als Hauptserver, und dieser leitet an WordPress weiter.
  • Verwenden Sie WordPress als Haupt-Proxy-Server, und dieser leitet an Discourse weiter.
  • Verwenden Sie Ihren eigenen Haupt-Proxy-Server, der an beide weiterleitet.

In jedem Fall, was auch immer Sie wählen, ich denke, TLS/SSL wird normalerweise vom Haupt-Proxy-Server gehandhabt.

Ich habe Discourse in den beiden oben genannten Szenarien verwendet. Als ich einen anderen Proxy-Server für den eingehenden Datenverkehr verwendete (erste Option), musste ich Ports ändern und TLS deaktivieren, anstatt den anderen Proxy-Server damit zu beauftragen. Und für das zweite Szenario änderte ich die Nginx-Konfigurationsdatei im Discourse-Container und fügte eine Deklaration für einen anderen Server hinzu und generierte dann mit Certbot ein Zertifikat dafür.

Äh… nein. Typischerweise gibt es keine Proxys. Nur ein normaler Webserver, wie Apache2 oder Nginx, wenn er virtuelle Hosts bedient und SSL beendet, ist kein Proxy-Server. Sicher, er kann als einer fungieren, aber das ist keine typische Lösung und hat nichts mit WordPress zu tun.

WordPress wird mit keiner Art von Server geliefert.

Installiertes WordPress kann zusammen mit einem Webserver, PHP, SQL usw. verkauft werden, aber das ist etwas völlig anderes, als dass es “mitgeliefert” wird.

Discourse wird jedoch mitgeliefert.

Und ja, die Verwendung eines Proxys oder was auch immer vor Discourse und die Bereitstellung von WordPress auf demselben Server ist ziemlich trivial.

Ich bezog mich hauptsächlich auf den Fall, in dem der WordPress-Stack entweder Nginx oder Apache enthalten würde. Er wird zwar nicht mitgeliefert, aber in dieser containerisierten Ära, wenn man sich das offizielle Docker-Image von WordPress ansieht (das über 1 Milliarde Downloads hat), wird es mit Apache ausgeliefert.

Es tut mir leid, dass ich den Begriff Proxy vielleicht nicht richtig verwendet habe, aber der Punkt, auf den ich mich beziehen wollte, ist, dass man am Ende meistens zwei Webserver (oder Proxy-Server) hat, wenn man WordPress mit Discourse betreiben möchte.

Entschuldigung für die späte Antwort, ich war eine Weile offline und nicht in den Foren, fühlt sich gut an, aber ich habe versucht, E-Mail-Probleme zu beheben, bevor ich gegangen bin, aber ich erhalte immer noch den Fehler 502, wenn ich auf das Forum zugreife.

Entschuldigung, ich habe mich falsch ausgedrückt, ich brauche WordPress nicht auf demselben Server, es war nur ein Beispiel dafür, was Sie nicht tun konnten.
Tatsächlich habe ich nur 4 Domains, die auf eine einfache Website auf diesem Server verweisen.
Der Discourse-Doktor scheint keine Fehler zu haben
aber ich erhalte immer noch den Fehler 502 auf der Forendomain
Muss ich haProxy installieren, wie sie hier sagen? Danke

Nein. Sie können Apache auch als Reverse-Proxy verwenden.

Es ist die gleiche Idee, egal ob Sie WordPress oder ein anderes Framework verwenden.

Wenn mehrere Websites auf denselben Server verweisen, lauschen alle Website-/HTTP(S)-Datenverkehr an Port 80/433. Daher hätten Sie normalerweise einen Server, der an diesen Ports lauscht und den Datenverkehr basierend auf dem Hostnamen/der Website weiterleitet.

Was bedeutet das im Kontext von Discourse?
Sie können entweder den Discourse-Nginx-Server den Datenverkehrsumleitungen handhaben lassen (in diesem Fall würde Discourse auf 80/443 lauschen, siehe dieses Thema Run other websites on the same machine as Discourse) oder Sie lassen Discourse auf einem anderen Port, z. B. 8080, lauschen und bitten dann Ihren Server, ihn weiterzuleiten, wenn die Anfrage von der Forum-Website kommt. Hinweis: In diesem Fall ist es besser, TLS/SSL von Discourse zu deaktivieren und Ihren Hauptserver dies handhaben zu lassen.

2 „Gefällt mir“