Nginx Server Blöcke (Virtuelle Hosts) zur Verwaltung Mehrerer Websites

Nginx Server-Blöcke ermöglichen es Ihnen, mehrere Domains oder Websites mit separaten Konfigurationen auf einer einzigen Nginx-Installation zu hosten. Beispielsweise können Sie auf demselben VPS unterschiedliche Stammverzeichnisse, Protokolldateien, SSL-Zertifikate und PHP-Einstellungen für example.com, blog.example.com und zweite-seite.com definieren. Kurz gesagt, die Lösung besteht darin, für jede Site ein separates Verzeichnis zu erstellen, die DNS-Einträge der Domain auf die IP-Adresse des Servers weiterzuleiten, unter /etc/nginx/sites-available einen separaten Serverblock zu erstellen, diesen mit dem Verzeichnis sites-enabled zu verknüpfen, die Konfiguration zu testen und den Nginx-Dienst neu zu laden.

In diesem Leitfaden werden wir den Prozess der Verwaltung mehrerer Websites mit Nginx Server-Blöcken für Produktionsumgebungen behandeln. Das Ziel ist nicht nur, eine funktionierende Struktur zu schaffen, sondern ein verwaltbares, sicheres, schnelles, backupfähiges und skalierbares Setup zu erstellen. Besonders für Agenturen, Entwickler, E-Commerce-Besitzer, Unternehmen mit mehreren Marken und Systemadministratoren, die mehrere Projekte auf einem einzigen Server betreiben, werden wir praktische Schritte teilen. Wenn Sie noch keinen Server haben, können Sie die Seiten VPS-Server für die Auswahl der Ressourcen und Domainregistrierung für die Verwaltung von Domains durchsehen.

Was sind Nginx Server-Blöcke?

Nginx Server-Blöcke sind Konfigurationsteile innerhalb der Nginx-Konfiguration, die als server block definiert sind und bestimmen, auf welche Website eine eingehende HTTP- oder HTTPS-Anfrage weitergeleitet wird. Dies ähnelt dem Konzept von VirtualHost auf der Apache-Seite. Wenn ein Besucher einen Domainnamen in den Browser eingibt, löst das DNS diesen Domainnamen in die IP-Adresse des Servers auf. Anschließend prüft Nginx den Host-Header der Anfrage und führt den Serverblock mit dem übereinstimmenden server_name-Wert aus.

Auf diese Weise können Dutzende von verschiedenen Websites unter derselben IP-Adresse und demselben physischen oder virtuellen Server gehostet werden. Für jede Site können separate Stammverzeichnisse, Zugriffsprotokolle, Fehlerprotokolle, Weiterleitungsregeln, SSL-Zertifikate, Cache-Politiken und Sicherheitsrichtlinien definiert werden. Beispielsweise können Sie Ihre Unternehmenswebsite in /var/www/unternehmenswebsite/public, Ihren Blog in /var/www/blog/public und Ihre Testumgebung in /var/www/staging/public halten.

Nginx ist in diesem Setup sehr effizient, da es durch seine ereignisgesteuerte Architektur hohe gleichzeitige Verbindungen mit niedrigem Ressourcenverbrauch verwalten kann. Daher wird es häufig in Shared Hosting, VPS, Cloud-Servern und Hochlast-Anwendungs-Infrastrukturen bevorzugt. Damit das Hosting mehrerer Websites reibungslos funktioniert, müssen jedoch alle Details, von Dateiberechtigungen über DNS-Weiterleitungen bis hin zu SSL-Installationen und Protokolltrennung, sorgfältig geplant werden.

Wann sollten Nginx Server-Blöcke verwendet werden?

Nginx Server-Blöcke werden besonders verwendet, wenn Sie mehrere Web-Präsenzen auf einem einzigen Server verwalten müssen. Dies kann manchmal zwei kleine Unternehmensseiten oder auch Dutzende von Kundenprojekten, Subdomains oder Mikrodienste umfassen. Der kritische Punkt hier ist die logische Trennung jedes Projekts voneinander.

• Wenn Sie mehrere Domains auf demselben VPS hosten möchten.
• Wenn Sie www- und non-www-Domains auf eine einzige kanonische Adresse umleiten möchten.
• Wenn Sie Subdomains mit verschiedenen Ordnern oder Anwendungen verknüpfen möchten.
• Wenn Sie für jede Site separate SSL-Zertifikate und Sicherheitsrichtlinien definieren möchten.
• Wenn Sie Kundenprojekte mit separaten Protokolldateien verfolgen möchten.
• Wenn Sie verschiedene Anwendungen wie Laravel, WordPress, statisches HTML und Node.js auf demselben Server betreiben möchten.

Beispielsweise ist es technisch möglich, dass eine digitale Agentur auf einem einzigen VPS mit 4 GB RAM 8 low-traffic Unternehmensseiten hostet. Allerdings müssen für jede Site Traffic, Speicherplatznutzung, Anzahl der PHP-Prozesse, Datenbankbelastung und Backup-Frequenz berechnet werden. Wenn die Projekte hohen Traffic haben oder die Ressourcenisolierung kritisch ist, sollten stärkere VPS, Cloud-Server oder verwaltete Hosting-Lösungen gewählt werden. An dieser Stelle können die Optionen Web Hosting und Geschäftliches Hosting verglichen werden.

Anforderungen vor dem Start

In diesem Leitfaden werden wir von einem Linux-Server ausgehen, der auf Ubuntu oder Debian basiert. Die Befehle können je nach Distribution geringfügig variieren; die Logik bleibt jedoch dieselbe. Stellen Sie sicher, dass Sie vor Änderungen in der Produktionsumgebung immer ein Backup erstellen. Eine falsche Nginx-Konfiguration kann dazu führen, dass alle Websites vorübergehend nicht erreichbar sind.

Technische Vorbereitungen

• Ein Linux-Benutzerkonto mit Root- oder Sudo-Rechten.
• Ein installiertes und laufendes Nginx-Service.
• Mindestens eine Domain, die auf die IP-Adresse des Servers zeigt.
• Ports 80 und 443 müssen in der Firewall geöffnet sein.
• Eine regelmäßige Verzeichnisstruktur für die Website-Dateien.
• Ein gültiges Zertifikat für SSL oder die Verwendung von Let’s Encrypt.
• Installation von PHP-FPM für PHP-basierte Anwendungen.

Auf der DNS-Seite leitet der A-Record die Hauptdomain auf die IPv4-Adresse weiter, während der AAAA-Record gegebenenfalls auf die IPv6-Adresse verweist. Für Subdomains wie www können CNAME oder A-Records verwendet werden. Die DNS-Propagation dauert in der Regel zwischen wenigen Minuten und 24 Stunden. Wenn Sie eine neue Installation durchführen, ist es ratsam, zuerst die DNS-Einträge vorzubereiten und dann zur Konfiguration der Nginx-Server-Blöcke überzugehen, um den Prozess zu beschleunigen.

Empfohlene Verzeichnisstruktur

Einer der häufigsten Fehler beim Hosting mehrerer Websites besteht darin, alle Dateien chaotisch in einem einzigen Verzeichnis zu speichern. Dieser Ansatz mag kurzfristig einfach erscheinen, führt jedoch zu erheblichen Zeitverlusten bei Wartungs-, Backup- und Debugging-Prozessen. Eine bessere Methode besteht darin, für jede Domain ein separates übergeordnetes Verzeichnis und darin Unterverzeichnisse wie public, logs, backups zu verwenden.

Eine Beispielstruktur könnte wie folgt geplant werden: /var/www/site1.com/public, /var/www/site1.com/logs, /var/www/site2.com/public und /var/www/site2.com/logs. Der Nginx-Root-Wert sollte direkt auf das öffentliche Verzeichnis zeigen. Dadurch sind Anwendungsdateien, sensible Dateien wie .env und Backups nicht direkt über das Web zugänglich.

Sie können für jedes Site-Verzeichnis eine einfache index.html-Datei als statische Testseite einfügen. Indem Sie den Site-Namen in den Inhalt schreiben, können Sie schnell überprüfen, welcher Serverblock aktiv ist. In Produktionsumgebungen wird der Besitz dieser Verzeichnisse normalerweise mit dem Benutzer www-data oder einem speziellen Benutzer, der das Deployment durchführt, verwaltet. In den Dateiberechtigungen sind 755 für Verzeichnisse und 644 für Dateien in den meisten statischen Szenarien ausreichend. Bereiche wie das uploads-Verzeichnis in Anwendungen wie WordPress, die Schreibzugriff benötigen, sollten gesondert behandelt werden.

Schritt-für-Schritt-Anleitung zur Erstellung eines Nginx Server-Blocks

Die folgenden Schritte werden anhand des Domainnamens site1.com erläutert. Sie können dieselbe Methode für die zweite, dritte oder mehr Websites wiederholen. Der kritische Punkt ist, für jede Site einen einzigartigen server_name, root und log-Dateinamen zu verwenden.

1. Erstellen Sie das Site-Verzeichnis

Der erste Schritt besteht darin, das Verzeichnis zu erstellen, in dem die Webdateien gespeichert werden. Beispiel: sudo mkdir -p /var/www/site1.com/public. Anschließend können Sie eine index.html-Datei für Tests in /var/www/site1.com/public erstellen und darin einen unterscheidbaren Text wie „Dies ist die Testseite von site1.com“ schreiben.

Um den Datei Besitzt richtig einzustellen, kann der Befehl sudo chown -R www-data:www-data /var/www/site1.com verwendet werden. Wenn Sie das Deployment mit einem anderen Benutzer durchführen, passen Sie die Gruppenberechtigungen entsprechend an. Vermeiden Sie in Produktionsumgebungen die Verwendung von 777-Berechtigungen, bei denen jeder Schreibzugriff hat. Diese Berechtigungen können Angreifern ermöglichen, Upload-Verzeichnisse auszunutzen.

2. Erstellen Sie die Serverblock-Datei

Eine gängige Praxis in Nginx besteht darin, inaktive Konfigurationen unter /etc/nginx/sites-available aufzubewahren und sie in /etc/nginx/sites-enabled über symbolische Links zu aktivieren. Beispiel-Datei: /etc/nginx/sites-available/site1.com.

Ein einfacher HTTP-Serverblock wird wie folgt geschrieben: server { listen 80; server_name site1.com www.site1.com; root /var/www/site1.com/public; index index.html index.htm; access_log /var/log/nginx/site1.com.access.log; error_log /var/log/nginx/site1.com.error.log; location / { try_files $uri $uri/ =404; } }

In dieser Konfiguration hört listen 80 auf den HTTP-Verkehr, server_name gibt an, welche Domains zu diesem Block gehören, root zeigt das Verzeichnis an, in dem sich die Webdateien befinden, und index definiert die Standarddatei. try_files gibt an, dass, wenn die angeforderte Datei oder das Verzeichnis nicht gefunden wird, ein 404 zurückgegeben wird. Diese Struktur ist für statische Sites ausreichend.

3. Aktivieren Sie die Site

Um die Konfiguration zu aktivieren, wird ein symbolischer Link erstellt: sudo ln -s /etc/nginx/sites-available/site1.com /etc/nginx/sites-enabled/site1.com. Diese Methode ist gesünder als das Kopieren von Dateien, da Sie an einer einzigen Hauptkonfigurationsdatei arbeiten. Wenn Sie Änderungen vornehmen, bleibt die verlinkte Datei aktuell.

Wenn Sie nicht möchten, dass die Standard-Nginx-Seite Ihre Site überschreibt, können Sie die Standardkonfiguration deaktivieren. Dazu kann der Link /etc/nginx/sites-enabled/default entfernt werden. Stellen Sie jedoch sicher, dass Ihr eigener Serverblock korrekt funktioniert, bevor Sie dies tun.

4. Testen Sie die Konfiguration und laden Sie Nginx neu

Nach jeder Änderung sollte der Befehl sudo nginx -t zur Syntaxprüfung verwendet werden. Wenn der Test erfolgreich ist, wird der Dienst mit dem Befehl sudo systemctl reload nginx ohne Unterbrechung neu geladen. Der Reload-Befehl ist in der Regel sicherer als der Restart-Befehl, da er aktive Verbindungen sanfter verwaltet.

Wenn der Test fehlschlägt, zeigt die Fehlermeldung meist den Dateinamen und die Zeilennummer an. Fehlende Semikolons, falsche geschweifte Klammern, falsche Verzeichnispfade oder sich überschneidende server_name-Werte sind die häufigsten Probleme. Nginx sollte nicht neu geladen werden, bevor der Fehler behoben ist.

Hinzufügen der zweiten und dritten Site

Die Schönheit des Hostings mehrerer Sites liegt darin, dass der Prozess nach der ersten richtigen Einrichtung wiederholbar wird. Sie erstellen das Verzeichnis /var/www/site2.com/public für site2.com, schreiben die Datei /etc/nginx/sites-available/site2.com, ändern die root- und log-Werte auf site2.com, erstellen den symbolischen Link und führen den Nginx-Test durch.

Die einfache Struktur für die zweite Site wird wie folgt getrennt: server { listen 80; server_name site2.com www.site2.com; root /var/www/site2.com/public; index index.html; access_log /var/log/nginx/site2.com.access.log; error_log /var/log/nginx/site2.com.error.log; location / { try_files $uri $uri/ =404; } }

Das Führen separater Logs für jede Site ist in der Praxis sehr wertvoll. Beispielsweise kann eine Site ansteigende 404-Fehler aufweisen, während es bei einer anderen Site keine Probleme gibt. Durch die separate Log-Struktur können Sie die Fehlerquelle innerhalb von Sekunden finden. Ebenso können der Traffic-Analyse, Bot-Angriffe, gebrochene Links und Leistungsprobleme auf Site-Ebene überwacht werden.

SSL- und HTTPS-Konfiguration

In den SEO-Standards von 2026 ist HTTPS nicht mehr nur eine Sicherheitsfunktion, sondern auch ein Indikator für Benutzervertrauen und technische Qualität. Browser kennzeichnen HTTP-Sites als unsicher; für Projekte, die Zahlungen, Mitgliedschaften, Formulare oder Verwaltungs-Panels enthalten, ist SSL zwingend erforderlich. Beim Hosting mehrerer Sites muss für jede Domain das richtige Zertifikat definiert werden. Für Ihre SSL-Bedürfnisse können Sie die Seite SSL-Zertifikate bei Hostragons besuchen.

Wenn Sie Let’s Encrypt verwenden, können Sie mit Certbot für jede Domain ein Zertifikat erhalten. Im Beispielprozess kann der Befehl certbot --nginx -d site1.com -d www.site1.com die Nginx-Konfiguration erkennen und den HTTPS-Block automatisch hinzufügen. Es ist jedoch eine gute Gewohnheit, die Datei nach der automatischen Bearbeitung zu überprüfen. Falsche Weiterleitungen oder sich wiederholende Serverblockprobleme können auftreten.

In der HTTPS-Konfiguration wird der Verkehr auf Port 80 in der Regel dauerhaft auf Port 443 umgeleitet. Eine 301-Weiterleitung gibt ein dauerhaftes Vorzugsignal in Bezug auf SEO. Entscheiden Sie, ob Sie www verwenden möchten oder nicht, und bündeln Sie alle Varianten auf eine einzige kanonische Adresse. Wenn Sie beispielsweise https://www.site1.com anstelle von https://site1.com verwenden möchten, leiten Sie sowohl den HTTP- als auch den HTTPS-www-Verkehr auf die non-www-Adresse um. Dies reduziert das Risiko von doppeltem Inhalt.

Nginx Server-Blöcke für PHP- und WordPress-Sites

Bei statischen HTML-Sites ist die Konfiguration einfach; jedoch erfordert WordPress, Laravel oder spezielle PHP-Anwendungen eine Integration mit PHP-FPM. In diesem Fall wird die index.php-Datei definiert, und PHP-Anfragen werden an den entsprechenden Socket weitergeleitet. Zum Beispiel kann der Socket-Pfad für PHP 8.3 unter Ubuntu /run/php/php8.3-fpm.sock sein. Die Version variiert je nach Server.

Die Beispielstruktur für PHP lautet: server { listen 80; server_name wordpress-site.com www.wordpress-site.com; root /var/www/wordpress-site.com/public; index index.php index.html; location / { try_files $uri $uri/ /index.php?$args; } location ~ php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.3-fpm.sock; } }

Für die Funktionalität der Permalinks in WordPress ist die Struktur try_files $uri $uri/ /index.php?$args wichtig. Auch Sicherheitsmaßnahmen wie der Zugriff auf xmlrpc.php, die Ratenbegrenzung von wp-login.php und das Verhindern von PHP-Ausführungen im uploads-Verzeichnis sollten berücksichtigt werden. Wenn Sie viele WordPress-Sites auf demselben VPS hosten, verwenden Sie separate Datenbanken, separate Benutzer und eine regelmäßige Aktualisierungsrichtlinie für jede Site. Für diejenigen, die nach Alternativen zum WordPress-Hosting suchen, könnte WordPress Hosting eine verwaltbare Option sein.

Vergleich von Nginx Server-Blöcken und Apache VirtualHost

Nginx und Apache erreichen dasselbe Ziel mit unterschiedlichen Architekturen. Beide können mehrere Sites auf einem einzigen Server hosten. Die Wahl hängt von den Anwendungsbedürfnissen, Verwaltungsvorlieben und Leistungserwartungen ab.

Wenn Ihre Anwendung stark von .htaccess-Regeln abhängig ist, kann Apache einfacher erscheinen. Für hohen Verkehr, Reverse Proxy, Caching und moderne Bereitstellungsflüsse ist Nginx jedoch in den meisten Projekten die stärkere Wahl. In einigen Infrastrukturen kann Nginx als Reverse Proxy und Apache als Backend-Anwendungsserver zusammen verwendet werden.

Best Practices für die Sicherheit

Das Hosten mehrerer Sites auf demselben Server bietet Kostenvorteile, erhöht jedoch die Sicherheitsverantwortung. Um zu verhindern, dass eine Schwachstelle auf einer Site andere beeinflusst, sollten Isolation und das Prinzip der minimalen Berechtigung angewendet werden.

• Erstellen Sie separate Datenbanken und separate Datenbankbenutzer für jede Site.
• Beschränken Sie das Web-Stammverzeichnis auf nur das öffentliche Verzeichnis.
• Halten Sie Backups, .env, .git, Konfigurations- und SQL-Dateien außerhalb des Webzugriffs.
• Erneuern Sie SSL-Zertifikate regelmäßig und erzwingen Sie HTTPS-Weiterleitungen.
• Verwenden Sie UFW oder eine ähnliche Firewall auf dem Server; öffnen Sie nur die erforderlichen Ports.
• Wenden Sie regelmäßige Updates für Nginx und das Betriebssystem an.
• Führen Sie separate access_log- und error_log-Dateien für jede Site.
• Fügen Sie IP-Einschränkungen oder zusätzliche Authentifizierung zu Verwaltungs-Panels hinzu.
• Vermeiden Sie breite Berechtigungen wie 777 in den Datei-Berechtigungen.

Es ist auch vorteilhaft, grundlegende Sicherheitsheader hinzuzufügen. Header wie X-Frame-Options, X-Content-Type-Options, Referrer-Policy und Content-Security-Policy können in geeigneten Projekten berücksichtigt werden. Insbesondere die Content-Security-Policy sollte jedoch zuerst in einer Testumgebung getestet werden, da sie andernfalls Skripte und Stylesheets blockieren kann. Weitere Inhalte über Sicherheit können in den Artikeln zu Website Sicherheit verlinkt werden.

Beachten Sie, was die Leistung und SEO betrifft

Nginx Server-Blöcke beeinflussen nicht nur das Hosting, sondern auch die Leistungs- und SEO-Qualität. Fehlgeleitete Weiterleitungsketten, falsche kanonische Präferenzen, fehlende gzip- oder brotli-Komprimierung, große Protokolldateien und unzureichende Caching-Einstellungen können die Geschwindigkeit der Website verringern. Die von Google gesendeten Signals zur Seitenbenutzererfahrung sind benutzerzentriert; schnell antwortende, sichere und stabile Sites neigen dazu, besser abzuschneiden.

Bestimmen Sie zunächst eine einzige kanonische Version für jede Domain. Leiten Sie den Verkehr von HTTP nach HTTPS, von www nach non-www oder umgekehrt in einem einzigen Schritt um. Die Kette sollte nicht so aussehen: http://site.com zuerst http://www.site.com, dann https://www.site.com, dann https://site.com. Stattdessen ist es besser, mit einer einzigen 301-Umleitung zum Ziel zu gelangen.

Für statische Dateien können Cache-Control-Header verwendet werden. Bilder, CSS- und JS-Dateien können für eine bestimmte Zeit im Browser gespeichert werden. Bei häufig wechselnden Dateien sollten jedoch Strategien wie Dateinamenversionierung oder Query-String verwendet werden. Gzip-Komprimierung reduziert die Bandbreite für textbasierte Dateien wie HTML, CSS, JS und JSON. Bei stark frequentierten Sites können Nginx-Microcache, FastCGI-Cache oder CDN in Betracht gezogen werden. Für CDN und globale Zugriffsbedürfnisse kann auf Inhalte wie Was ist ein CDN? verwiesen werden.

Protokollmanagement und Überwachung

Das Protokollmanagement beim Hosting mehrerer Sites ist der Schlüssel zur Problemlösung. Separate Protokolldateien zeigen klar an, auf welcher Site welcher Fehler aufgetreten ist. access_log zeichnet die Besucheranfragen auf, während error_log Konfigurationsfehler, Berechtigungsprobleme, fehlende Dateien und Upstream-Fehler festhält. Ein 502 Bad Gateway-Fehler ist oft mit dem PHP-FPM-Service oder der Verbindung zum Backend-Service verbunden. Ein 403 Forbidden-Fehler kann auf ein Problem mit dem Root-Verzeichnis, den Dateiberechtigungen oder der Indexdatei hinweisen. Ein 404 Not Found könnte auf einen falschen Dateipfad, ein Rewrite-Problem oder ein falsches Root-Problem nach DNS hinweisen.

Um das unbegrenzte Wachstum von Protokolldateien zu verhindern, sollte die logrotate-Konfiguration überprüft werden. In kleinen Projekten kann eine tägliche oder wöchentliche Rotation ausreichend sein. Bei stark frequentierten Sites sollten zentrale Protokollsammlungen, Metriküberwachung und Alarmsysteme verwendet werden. Ein voller Speicher kann dazu führen, dass Nginx keine Protokolle mehr schreiben kann, die Datenbank stoppt und die Sites nicht mehr zugänglich sind. Daher ist es praktisch, Schwellenwerte für die Datenträgerspeicherung festzulegen.

Häufige Fehler und schnelle Lösungen

Beim Arbeiten mit Nginx Server-Blöcken können einige Fehler in fast jedem Projekt auftreten. Diese zu kennen, kann die Einrichtung erheblich verkürzen.

• Die Domain öffnet die falsche Site: Überprüfen Sie die server_name-Konflikte und den Standard-Serverblock.
• 403 Forbidden-Fehler: Überprüfen Sie das Root-Verzeichnis, die Datei-Berechtigungen und das Vorhandensein der Indexdatei.
• 404 Not Found-Fehler: Überprüfen Sie den Root-Pfad und die try_files-Regel.
• 502 Bad Gateway-Fehler: Bestätigen Sie, dass der PHP-FPM-Service läuft und der Socket-Pfad korrekt ist.
• Das SSL-Zertifikat scheint zur falschen Site zu gehören: Überprüfen Sie die server_name- und Zertifikatsdateien auf Port 443.
• Es entsteht eine Umleitungs-Schleife: Vereinfachen Sie die HTTP-HTTPS- und www-Weiterleitungsregeln.
• Nginx wird nicht neu geladen: Korrigieren Sie den Syntaxfehler gemäß der Zeilennummer in der sudo nginx -t-Ausgabe.

Erfahrene Administratoren verwenden eine einfache Checkliste: Ist DNS korrekt? Ist die Nginx-Konfiguration aktiv? Gibt es das Root-Verzeichnis? Sind die Berechtigungen korrekt? Hat der Dienst den Test bestanden? Was sagt das Log? Diese Reihenfolge ermöglicht es Ihnen, schnell Lösungen zu finden, ohne in Panik zu geraten.

Praktische Checkliste für die Produktionsumgebung

Überprüfen Sie jede Site mit der folgenden Checkliste, bevor Sie sie live schalten. Insbesondere in Kundenprojekten ist es wichtig, diese Punkte vor der Übergabe zu dokumentieren, um einen professionellen Arbeitsstandard zu schaffen.

• Der A- oder AAAA-Eintrag der Domain zeigt auf die richtige IP-Adresse.
• Eine der www- und non-www-Versionen wurde kanonisch ausgewählt.
• HTTP-Verkehr wird mit 301 auf HTTPS umgeleitet.
• Das SSL-Zertifikat ist gültig und die automatische Erneuerung ist aktiv.
• Für jede Site wurden separate Root- und Protokolldateien definiert.
• Die Nginx-Konfiguration wurde mit sudo nginx -t überprüft.
• Ein Backup-Plan wurde erstellt und ein Wiederherstellungstest durchgeführt.
• Dateiberechtigungen entsprechen dem Prinzip der minimalen Berechtigungen.
• In der Firewall sind nur die erforderlichen Ports geöffnet.
• Fehlerprotokolle wurden mindestens 15 Minuten nach dem Live-Schalten überwacht.

Diese Liste mag klein erscheinen, reduziert jedoch das Risiko von Ausfallzeiten in realen Projekten erheblich. Insbesondere die Schritte zur SSL-Erneuerung, DNS-Überprüfung und Protokollüberwachung erfassen viele unsichtbare Fehler frühzeitig.

Fazit

Nginx Server-Blöcke sind eine der grundlegenden Methoden, um mehrere Sites auf einem einzigen Server ordentlich, sicher und leistungsfähig zu hosten. Richtig strukturierte Verzeichnisse, separate Konfigurationsdateien, klare Weiterleitungsregeln, die Verwendung von HTTPS, Protokolltrennung und regelmäßige Tests machen das Management mehrerer Sites äußerst effizient. Die gleichen Prinzipien können von kleinen Portfolios bis zu umfangreichen Kundenprojekten angewendet werden.

Wenn Sie ein neues Projekt veröffentlichen möchten, klären Sie zuerst Ihre Domain-, Serverressourcen- und SSL-Bedürfnisse; dann richten Sie Ihre Nginx-Konfiguration Schritt für Schritt mit der obigen Checkliste ein. Wenn Sie nach einer verwaltbaren Infrastruktur suchen, können Sie die Hosting-Pakete, VPS-Server und SSL-Zertifikate von Hostragons durchsehen, um den richtigen Ausgangspunkt für Ihr Projekt zu wählen.

Häufig gestellte Fragen

Wie viele Sites können mit Nginx Server-Blöcken gehostet werden?

Technisch gesehen können Sie mit Nginx viele Sites auf demselben Server hosten; die Grenzen hängen in der Regel von CPU, RAM, Speicher, Traffic, Datenbanklast und PHP-FPM-Kapazität ab. Bei statischen Sites mit niedrigem Traffic sind Dutzende von Sites möglich, während es bei stark frequentierten WordPress- oder E-Commerce-Projekten gesünder ist, weniger Sites zu hosten.

Benötigt jede Site ein separates SSL-Zertifikat?

Ja, jede Domain oder Subdomain, die über HTTPS veröffentlicht wird, muss im Zertifikat enthalten sein. Es können sowohl einzelne Zertifikate als auch SAN- oder Wildcard-Zertifikate verwendet werden. Wichtig ist, dass die richtigen Zertifikatsdateien im Nginx 443 Serverblock mit der richtigen Domain verbunden sind.

Kann eine Subdomain mit einem Nginx Server-Block veröffentlicht werden?

Ja. Sie können separate server_name-Einträge für Subdomains wie blog.site.com oder panel.site.com definieren und sie an ein anderes Stammverzeichnis oder eine andere Backend-Anwendung weiterleiten. Auf der DNS-Seite müssen Sie einen A- oder CNAME-Eintrag für die entsprechende Subdomain erstellen.

Was ist der Unterschied zwischen sites-available und sites-enabled?

sites-available ist der Ort, an dem die verfügbaren Konfigurationsdateien aufbewahrt werden; sites-enabled enthält die aktiven Konfigurationen. In der Regel wird in sites-enabled ein symbolischer Link zur Datei in sites-available erstellt. Diese Methode macht das Aktivieren und Deaktivieren von Sites übersichtlicher.

Woher kommt das Problem, wenn die falsche Site geöffnet wird?

Die häufigsten Ursachen sind, dass das DNS auf die falsche IP-Adresse zeigt, der server_name-Wert falsch ist, der Standard-Nginx-Block die Anfrage abfängt oder ein falscher SSL-Block auf Port 443 aktiv ist. Überprüfen Sie zuerst die DNS-Einträge, dann die Ausgabe von nginx -t, die aktiven sites-enabled-Verbindungen und die entsprechenden access_log-Dateien.