Nginx-Server – Unterordner-Hosting

Um Ihre Document360-Wissensdatenbank in einem Unterordner (wie example.com/docs) mit dem Nginx-Server zu hosten, sind spezifische Konfigurationen erforderlich. Dieser Artikel führt Sie dabei, die erforderlichen Module zu aktivieren, Proxy- und Rewrite-Regeln zu konfigurieren sowie Pfade für Artikel, APIs und Sitemaps zu verwalten. Es wird auch erklärt, wie man URL-Weiterleitungen richtig handhabt, um Probleme mit doppelten Inhalten in Suchmaschinen zu vermeiden.

Um mehr über Nginx zu erfahren, besuchen Sie die Nginx-Dokumentation.

Einrichten eines Unterordners/Unterverzeichnisses

Beispiel:

HINWEIS

Ersetzen Sie die Beispieldomain durch Ihre eigene, von document360 bereitgestellte Domain/benutzerdefinierte Domain.

• Beispieldomäne dargestellt mit example.document360.io

• Unterordner-/Unterverzeichnispfad (/docs) dargestellt als example.document360.io/docs

1. Füge die folgenden Standortblöcke in deine Nginx-Konfigurationsdatei hinzu (/etc/nginx/default).

location /docs {
    proxy_pass https://example.document360.io/docs;
    proxy_set_header Host example.document360.io;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header "requested-by" "proxy";
    proxy_ssl_server_name   on;
}

2. Neustart des Nginx-Webservers

3. Wenn du zum Beispiel Nginx unter Linux verwendest, dann verwende den Befehl
   $ sudo systemctl restart nginx

HINWEIS

Wenn Sie sich auf KB Site 2.0 befinden und Ihre Wissensdatenbank als Unterordner hosten möchten, müssen Sie beide definieren:

• Der Unterordnerpfad (z. B. /docs, ) /help

• Der Site-API-Pfad (z. B. /api, ) /docs-api

Nachdem Sie diese Werte gesetzt haben, müssen Sie auch die entsprechenden location Blöcke auf Ihrem Webserver konfigurieren, um sowohl UI- als auch API-Verkehr zu proxyen. Das Beispiel für die API-Konfiguration findest du im untenstehenden Abschnitt.

Verwendung eines benutzerdefinierten Unterordner-/Unterverzeichnispfads

• Du kannst deine Wissensdatenbank auch auf Unterverzeichnispfaden ausrichten /docs.
  Zum Beispiel /help, /support, , usw.

• Beim Einrichten anderer Pfade fügen Sie die jeweiligen Sprachen hinzu.

• Füge ein paar weitere Linien hinzu, um das zu erreichen. Neustarte den Server, sobald du fertig bist.

Beispiel:

HINWEIS

Ersetzen Sie die von Document360 bereitgestellte Domain und die Unterverzeichnis-Domain durch Ihre eigenen Domains. Ersetzen Sie außerdem den Arbeitsbereichsnamen, den Unterordnerpfad und die Sprache durch Ihre Anforderungen.

• Document360 stellte eine Domain dargestellt als example.document360.io

• Arbeitsbereichsname dargestellt als /v1/

• Unterordnerpfad dargestellt als /help/

• Sprache wird wie /he für Hebräisch dargestellt.

location /help {
    proxy_pass https://example.document360.io/docs;
    proxy_set_header Host example.document360.io;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header "requested-by" "proxy";
    proxy_ssl_server_name   on;

    sub_filter "v1/docs/" "v1/help/";
    sub_filter "docs/he/" "/help/he";
    sub_filter "/docs/" "/help/";
    sub_filter_once off;
}

Entfernung des Arbeitsflächen-Slugs aus internen Links

Falls erforderlich, können Sie Workspace-Slugs aus internen Verbindungen auf NGINX-Reverse-Proxy-Ebene mithilfe sub_filter von Regeln entfernen.

Beispiel:

sub_filter "/Version_slug/docs/" "/help/";

Verwenden Sie diesen Ansatz nur, wenn Ihre Website-Struktur workspace-agnostische URLs benötigt.

Warum proxy_set_header Accept-Encoding "" ist erforderlich

Beim Hosten einer Document360-Wissensdatenbank in einem benutzerdefinierten Unterordner (zum Beispiel /help), verwendet sub_filter NGINX häufig interne URLs /docs wie zu /help.

Standardmäßig kann der Upstream-Server (Document360) gzip-komprimiertes HTML zurückgeben. NGINX kann keine Regeln für komprimierte Antworten anwendensub_filter.

Dies führt zu folgenden Problemen:

• Interne Links werden nicht umgeschrieben

• Startseiten-Widgets zeigen weiterhin auf /docs

• Kategoriekarten und Navigationsrouten werden unterbrochen

Um sicherzustellen, dass die URL-Umschreibung korrekt funktioniert, müssen Sie die Kompression vom Upstream-Server deaktivieren, indem Sie folgende Anweisung hinzufügen:

proxy_set_header Accept-Encoding "";

Diese Einstellung:

Diese Einstellung ist immer dann erforderlich, wenn sub_filter sie verwendet wird.

Obligatorische API-Pfadkonfiguration für KB Site 2.0

Wenn Sie sich auf KB Site 2.0 befinden, müssen Sie einen benutzerdefinierten Site-API-Pfad definieren und einen entsprechenden location Block in Ihrer NGINX-Konfiguration hinzufügen.

Dies stellt sicher, dass API-Anfragen korrekt an Document360 weitergeleitet werden und verhindert Probleme wie Umleitungsschleifen oder defekte API-Aufrufe.

Hier ist ein Beispiel mit /api dem Site-API-Pfad:

location /api {
    proxy_pass https://example.document360.io/api;
    proxy_set_header Host example.document360.io;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header "requested-by" "proxy";
    proxy_ssl_server_name on;
    proxy_set_header Accept-Encoding "";

    sub_filter_types *;
    sub_filter "v1/docs/" "v1/help/";
    sub_filter "docs/he/" "/help/he";
    sub_filter "/docs/" "/help/";
    sub_filter_once off;
}

HINWEIS

Ersetzen /api und /docs-api mit den genauen Werten, die unter dem Site-API-Pfad im Document360-Portal konfiguriert sind.

Sobald du beide location Blöcke hinzugefügt hast, starte den Nginx-Webserver neu. Wenn du zum Beispiel Nginx unter Linux verwendest, dann benutze den Befehl $ sudo systemctl restart nginx.

Verwenden sub_filter_types *; Sie nur beim Umschreiben von HTML- oder API-Antworten, die möglicherweise nicht-HTML-Inhalte zurückgeben. Vermeiden Sie es, es sei denn, eine URL-Neuschreibung ist erforderlich.

Wann im API-Standortblock verwendet werden sollte sub_filter

Das Hinzufügen sub_filter von Regeln im API-Standortblock ist nicht immer erforderlich.

Verwendung sub_filter im API-Standortblock nur, wenn:

• Dein UI-Pfad wird umgeschrieben (zum Beispiel /docs → /help)

• API-Antworten enthalten eingebettete /docs Pfade, die umgeschrieben werden müssen

Wenn dein Projekt weiterhin als UI-Pfad verwendet /docs wird, füge dem API-Block keine Regeln hinzu. sub_filter

WICHTIG
Wenn Ihre Domain bereits für eine andere Anwendung verwendet /api wird, müssen Sie den Site-API-Pfad im Document360-Portal auf einen anderen Wert aktualisieren (zum Beispiel /docs-api) und denselben Pfad in Ihrer NGINX-Konfiguration verwenden.

Der im Portal konfigurierte API-Pfad und der NGINX-Standortblock müssen exakt übereinstimmen.

Um das Dropdown-Menü für Arbeitsbereiche zu aktivieren

Wenn Sie die Workflow-Dropdown-Navigation für Ihr Projekt aktivieren möchten, wenn Sie es in einem benutzerdefinierten Unterverzeichnis und Pfad hosten, fügen Sie für jeden der in Ihrem Projekt verfügbaren Arbeitsbereiche den folgenden Code hinzu.

Beispiel:

Nehmen wir an, dein Projekt hat zwei Arbeitsbereiche, v1 und v2. In diesem Fall musst du zwei Codeblöcke hinzufügen, einen für jeden Arbeitsbereich.

HINWEIS

Ersetzen Sie die von Document360 bereitgestellte Domain und die Unterverzeichnis-Domain durch Ihre eigenen Domains. Ersetzen Sie außerdem den Arbeitsbereichsnamen, den Unterordnerpfad und die Sprache durch Ihre Anforderungen.

• Document360 stellte eine Domain dargestellt als example.document360.io

• Arbeitsbereichsname dargestellt als /v1/,/v2/

• Unterordnerpfad dargestellt als /help/

• Sprache wird wie /he für Hebräisch dargestellt.

location /v2/help {
    proxy_pass https://example.document360.io/v2/docs;
    proxy_set_header Host example.document360.io;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header "requested-by" "proxy";
    proxy_ssl_server_name   on;

    sub_filter "v2/docs/" "v2/help/";
    sub_filter "docs/he/" "/help/he";
    sub_filter "/docs/" "/help/";
    sub_filter_once off;
}
-----------------------------------------------------
location /v1/help {
    proxy_pass https://example.document360.io/v1/docs;
    proxy_set_header Host example.document360.io;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header "requested-by" "proxy";
    proxy_ssl_server_name   on;

    sub_filter "v1/docs/" "v1/help/";
    sub_filter "docs/he/" "/help/he";
    sub_filter "/docs/" "/help/";
    sub_filter_once off;
}
-----------------------------------------------------
location = /v2/docs {
    return 301 /v2/help;
}
-----------------------------------------------------
location = /v1/docs {
    return 301 /v1/help;
}

HINWEIS

Wenn Sie möchten, dass Ihre Leser über das Dropdown-Menü (per Mausklick) zwischen den verschiedenen öffentlichen Arbeitsbereichen Ihres Projekts navigieren, fügen Sie den Standortblock für alle verfügbaren Arbeitsbereiche hinzu.

1. Neustart des Nginx-Webservers

2. Wenn du zum Beispiel Nginx unter Linux verwendest, dann verwende den Befehl
   $ sudo systemctl restart nginx

Hilfreiche Links

Hier sind einige externe Links, die Ihnen helfen können, die Nginx-Serverstandortblöcke im Detail zu verstehen:

• NGINX Docs: NGINX und NGINX Plus als Webserver konfigurieren

• DigitalOcean: Verständnis von Nginx-Server- und Standortblockauswahlalgorithmen

Sitemap-Erstellung

Beispiel:

HINWEIS

Ersetzen Sie die Beispieldomain durch Ihre eigene, von document360 bereitgestellte Domain/benutzerdefinierte Domain.

• Beispieldomäne dargestellt mit example.document360.io

• Das Sitemap-Präfix bleibt gleich, außer dem Sprachcode (en, fr, de usw.).  example.document360.io/sitemap.xml.en

location /sitemap.xml.en {
    proxy_pass https://example.document360.io/sitemap.xml.en;
    proxy_set_header Host example.document360.io;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header "requested-by" "proxy";
    proxy_ssl_server_name   on;
    proxy_set_header Accept-Encoding "";

    sub_filter_types text/xml;
    sub_filter "https://www.example.document360.io/docs/" "https://www.example.document360.io/help/";
    sub_filter_once off;
 }

Startseite wird in einem Unterordner gehostet

Um die Startseite Ihres Projekts auf einem benutzerdefinierten Unterverzeichnis-/Unterordnerpfad zu hosten, fügen Sie für jeden der in Ihrem Projekt verfügbaren Homepage-Arbeitsbereiche folgenden Code hinzu.

Beispiel:

Nehmen wir an, dein Projekt hat zwei Arbeitsbereiche, V1 und V2. In diesem Fall musst du zwei Codeblöcke hinzufügen, einen für jeden Arbeitsbereich.

HINWEIS

Ersetzen Sie die von Document360 bereitgestellte Domain und die Unterverzeichnis-Domain durch Ihre eigenen Domains. Ersetzen Sie außerdem den Arbeitsbereichsnamen, den Unterordnerpfad und die Sprache durch Ihre Anforderungen.

• Document360 stellte eine Domain dargestellt als example.document360.io

• Arbeitsbereichsname dargestellt als /v1/,/v2/

location =/v1 {
    proxy_pass https://example.document360.io/;
    proxy_set_header Host example.document360.io;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header "requested-by" "proxy";
    proxy_ssl_server_name   on;
}

location =/v2 {
    proxy_pass https://example.document360.io/;
    proxy_set_header Host example.document360.io;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;
    proxy_set_header "requested-by" "proxy";
    proxy_ssl_server_name   on;
}

location /v1/en {
  return 301 /v1;
}

location /v2/en {
  return 301 /v2;
}

PRO-TIPP

Das Gleichheitszeichen kann verwendet werden, wenn der Standort exakt mit der Anfrage-URI übereinstimmen muss. Wenn dieser Modifikator abgestimmt ist, endet die Suche genau hier. Für weitere Informationen klicken Sie hier.

Beispiel: location =/help {

2. Neustart des Nginx-Webservers

3. Wenn du zum Beispiel Nginx unter Linux verwendest, dann verwende den Befehl
   $ sudo systemctl restart nginx

Startseite der Wissensdatenbank

Was passiert als Nächstes?

Sobald du den Webserver erfolgreich konfiguriert hast, ist deine Wissensdatenbank auf deinem eigenen Unterordner/Unterverzeichnis verfügbar. Die bestehende URL Ihres Projekts liefert jedoch die Anfragen.

Zum Beispiel example.document360.io und example.com/docs (wenn /docs dein Ordnerpfad ist) wird es auf die Knowledge Base-Seite verweisen.

Dies kann zu doppelten Inhalten in Suchmaschinen (Google, Bing usw.) führen. Um dies zu verhindern, wird eine Weiterleitung von der Document360-Projekt-Subdomain auf Ihre benutzerdefinierte Domain erforderlich.

HINWEIS

Um die Weiterleitung von example.document360.io zu example.com/docsermöglichen, kontaktieren Sie uns bitte unter support@document360.com.

Kanonische URL für Unterordner-Hosting

Wenn Sie Ihre Wissensdatenbank in einem Unterordner hosten, müssen Sie eine kanonische URL konfigurieren, um sicherzustellen, dass Suchmaschinen Ihre benutzerdefinierte Domain und den Unterordnerpfad indexieren, nicht die Standarddomäne *.document360.io .

Dies verhindert doppelte Indexierung und verbessert die SEO-Leistung.

Wie man die kanonische URL einlegt

1. Gehe zu Einstellungen > Knowledge Base-Seite > Benutzerdefinierte Domain > Unterordner-Hosting.

2. Geben Sie die URL des vollständigen Unterordners ein (zum Beispiel ). https://example.com/help

3. Klicken Sie auf Speichern.

Nach der Konfiguration behandeln Suchmaschinen die Unterordner-URL als primäre Quelle für die Indexierung.

Fehlerbehebung

Dieser Abschnitt bietet Schritt-für-Schritt-Anleitungen, um häufige Herausforderungen zu beheben, denen Sie während des NGINX-Einrichtungsprozesses begegnen können. Von Unterordner-Hosting-Problemen bis hin zu fehlgeschlagenen Konfigurationstests ist jede Lösung darauf ausgelegt, Ihnen zu helfen, potenzielle Hindernisse schnell zu erkennen und zu beheben, um eine reibungslose und effiziente Serverkonfiguration zu gewährleisten.

Auflösung ungültiger Standortanweisung in NGINX

Fehler: nginx: [emerg] "Standort"-Direktive ist hier nicht erlaubt

Dieser Fehler tritt auf, wenn eine Standortdirektive außerhalb ihres gültigen Kontexts platziert wird, zum Beispiel außerhalb des Serverblocks. In NGINX müssen Standortblöcke innerhalb eines Serverblocks definiert werden.

Schritte zur Lösung:

1. Stellen Sie sicher, dass der Standortblock korrekt innerhalb des Serverblocks platziert ist. Siehe den untenstehenden Beispielblock:

   server {
       listen 80;
       server_name example.com;
       location /docs {
           proxy_pass https://example.document360.io/docs;
           proxy_set_header Host example.document360.io;
       }
   }

2. Um dieses Problem zu vermeiden, sollten Standortanweisungen weder im globalen http Kontext noch außerhalb des server Kontexts platziert werden.

3. Wenn das Problem nach dem Ausführen dieser Schritte weiterhin besteht, wenden Sie sich an das Document360-Support-Team, um weitere Unterstützung zu erhalten: Wenden Sie sich an den Document360-Support

Problem der Verfügbarkeit von Certbot-Paketen

Fehler: Kein verfügbares Certbot für das Paket

Dieses Problem tritt häufig auf, wenn das EPEL-Repository (erforderlich für die Certbot-Installation auf RHEL-basierten Distributionen) nicht aktiviert ist oder der Paketmanager Certbot auf RHEL-basierten Distributionen nicht finden kann.

Schritte zur Lösung:

1. Aktivieren Sie das EPEL-Repository mit dem untenstehenden Code:

   sudo yum install epel-release

2. Aktualisieren Sie den Repository-Cache und versuchen Sie, Certbot erneut zu installieren, indem Sie den untenstehenden Code verwenden:

   sudo yum install certbot

3. Stelle sicher, dass deine Instanz Internetzugang hat, um die Repository-Dateien abzurufen. Wenn das Problem weiterhin besteht, überprüfen Sie die Repository-Konfigurationsdateien in /etc/yum.repos.d/.

4. Wenn das Problem nach dem Ausführen dieser Schritte weiterhin besteht, wenden Sie sich an das Document360-Support-Team, um weitere Unterstützung zu erhalten: Wenden Sie sich an den Document360-Support

NGINX-Konfigurationstestproblem

Fehler: NGINX-Konfigurationstest ist gescheitert

Dieses Problem tritt auf, wenn ein Syntaxfehler in der NGINX-Konfigurationsdatei auftritt.

Schritte zur Lösung e:

1. Führen Sie den Konfigurationstestbefehl aus:

   sudo nginx -t

2. Überprüfen Sie die Fehlermeldung und die Zeilennummer, wie im unten gezeigten Beispiel:

   nginx: [emerg] invalid parameter "proxy_pas" in /etc/nginx/sites-enabled/example:22
   nginx: configuration file /etc/nginx/nginx.conf test failed

3. Öffnen Sie die angegebene Datei /etc/nginx/sites-enabled/example und beheben Sie das Konfigurationsproblem. Zum Beispiel:

   # Incorrect
   proxy_pas https://example.com;
   
   # Correct
   proxy_pass https://example.com;

4. Sobald das Konfigurationsproblem behoben ist, starte NGINX neu:

   sudo systemctl restart nginx

5. Wenn das Problem nach dem Ausführen dieser Schritte weiterhin besteht, wenden Sie sich an das Document360-Support-Team, um weitere Unterstützung zu erhalten: Wenden Sie sich an den Document360-Support

SSL-Zertifikatsausgabe

Fehler: SSL-Zertifikat funktioniert nicht

Dieses Problem kann durch eine falsche NGINX-SSL-Konfiguration auftreten oder wenn ein Problem mit dem installierten Zertifikat vorliegt. Die Zertifikatsdetails, wie Domain und Ablaufdatum, stimmen möglicherweise nicht mit den Konfigurationsdetails überein.

Schritte zur Lösung:

1. Verifizieren Sie die Zertifikatsdateien mit dem untenstehenden Code:

   openssl x509 -in /etc/letsencrypt/live/yourdomain.com/fullchain.pem -text -noout

2. Stellen Sie sicher, dass Ihre Konfiguration mit den Zertifikatsdetails übereinstimmt, wie Domain und Ablaufdatum.

3. Stellen Sie sicher, dass die NGINX-SSL-Konfiguration korrekt ist. Siehe den untenstehenden Code als Beispiel:

   server {
       listen 443 ssl;
       server_name yourdomain.com;
       
       ssl_certificate /etc/letsencrypt/live/yourdomain.com/fullchain.pem;
       ssl_certificate_key /etc/letsencrypt/live/yourdomain.com/privkey.pem;
   }

4. Wenn Sie fertig sind, starten Sie NGINX mit dem untenstehenden Code neu:

   sudo systemctl restart nginx

5. Wenn das Problem nach dem Ausführen dieser Schritte weiterhin besteht, wenden Sie sich an das Document360-Support-Team, um weitere Unterstützung zu erhalten: Wenden Sie sich an den Document360-Support

proxy_set_header Accept-Encoding "";