Nginx Server Blocks: Mehrere Domains auf einem VPS betreiben

Ein einziger VPS kann dutzende Websites bedienen. Nginx verwendet Server Blocks, um anhand des Domainnamens in der Anfrage zu entscheiden, welche Website ausgeliefert wird. Diese Anleitung führt durch die vollständige Einrichtung: zwei Domains von Grund auf konfiguriert, sichere Standardwerte, domainspezifisches Logging und Verifikation bei jedem Schritt.

Dieses Tutorial richtet sich an Debian 12 und Ubuntu 24.04. Beide verwenden dasselbe sites-available/sites-enabled-Muster. Die Befehle funktionieren auf beiden Systemen identisch.

Was ist ein Nginx Server Block?

Ein Server Block ist ein Konfigurationsblock innerhalb von Nginx, der definiert, wie Anfragen für eine bestimmte Domain verarbeitet werden. Er entspricht dem Virtual Host von Apache. Jeder Server Block verwendet die listen-Direktive, um sich an einen Port zu binden, und die server_name-Direktive, um den Domainnamen aus dem Host-Header der Anfrage abzugleichen. Sie können beliebig viele Server Blocks haben, die sich alle Port 80 oder 443 teilen.

Voraussetzungen

Vor dem Start benötigen Sie:

• Nginx installiert und aktiv
• Zwei Domainnamen mit DNS-A-Records, die auf die IP Ihres Servers zeigen
• Eine Firewall, die die Ports 80 und 443 erlaubt
• SSH-Zugang als Nicht-Root-Benutzer mit sudo

Prüfen Sie, ob Nginx läuft:

sudo systemctl status nginx

In der Ausgabe sollte active (running) erscheinen. Falls nicht, starten und aktivieren Sie den Dienst:

sudo systemctl enable --now nginx

Das Flag enable sorgt dafür, dass Nginx nach einem Neustart automatisch startet. Das Flag --now startet ihn sofort.

Prüfen Sie, ob Ihre DNS-Records auf Ihren Server auflösen. Ersetzen Sie die Domains in dieser Anleitung durch Ihre eigenen:

dig +short site-one.com
dig +short site-two.com

Beide sollten die öffentliche IP-Adresse Ihres Servers zurückgeben.

Wie erstellen Sie einen Server Block für eine neue Domain?

Der Vorgang besteht aus drei Teilen: Dokumentenverzeichnis anlegen, Berechtigungen setzen und die Server-Block-Konfigurationsdatei schreiben. Wir richten zwei Domains ein: site-one.com und site-two.com.

Welche Verzeichnisstruktur sollten Sie verwenden?

Legen Sie für jede Website ein eigenes Dokumentenverzeichnis unter /var/www/ an:

sudo mkdir -p /var/www/site-one.com/html
sudo mkdir -p /var/www/site-two.com/html

Erstellen Sie für jede Website eine Testseite, um zu prüfen, welche Domain welchen Inhalt ausliefert:

echo '<h1>Site One</h1>' | sudo tee /var/www/site-one.com/html/index.html
echo '<h1>Site Two</h1>' | sudo tee /var/www/site-two.com/html/index.html

Welche Berechtigungen benötigt das Web-Root-Verzeichnis?

Nginx führt seine Worker-Prozesse als www-data-Benutzer aus. Die Web-Root-Verzeichnisse müssen von diesem Benutzer lesbar sein.

sudo chown -R www-data:www-data /var/www/site-one.com
sudo chown -R www-data:www-data /var/www/site-two.com

Setzen Sie die Berechtigungen auf 755 (Eigentümer kann lesen/schreiben/ausführen, Gruppe und andere können lesen und durchsuchen):

sudo chmod -R 755 /var/www/site-one.com
sudo chmod -R 755 /var/www/site-two.com

Prüfen Sie Eigentümer und Berechtigungen:

ls -la /var/www/

Erwartete Ausgabe:

drwxr-xr-x  2 www-data www-data 4096 Mar 19 10:00 site-one.com
drwxr-xr-x  2 www-data www-data 4096 Mar 19 10:00 site-two.com

Warum www-data und nicht Ihr eigener Benutzer? In der Produktion sollte der Webserver-Benutzer statische Dateien besitzen. Wenn Ihre Anwendung Dateien schreibt (Uploads, Caches), benötigt der Webserver-Benutzer Schreibzugriff. Die Verwendung Ihres persönlichen Benutzers öffnet einen Pfad von einer Web-Schwachstelle zu Ihrem SSH-Konto.

Konfigurationsdateien für die Server Blocks erstellen

Nginx auf Debian und Ubuntu verwendet ein Zwei-Verzeichnis-Muster: Konfigurationsdateien liegen in /etc/nginx/sites-available/ und werden durch das Verlinken (Symlink) in /etc/nginx/sites-enabled/ aktiviert. So können Sie eine Website deaktivieren, ohne ihre Konfiguration zu löschen.

Erstellen Sie den Server Block für die erste Domain:

sudo nano /etc/nginx/sites-available/site-one.com

server {
    listen 80;
    listen [::]:80;

    server_name site-one.com www.site-one.com;

    root /var/www/site-one.com/html;
    index index.html;

    access_log /var/log/nginx/site-one.com.access.log;
    error_log /var/log/nginx/site-one.com.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

Was jede Direktive bewirkt:

• listen 80 und listen [::]:80 binden an Port 80 auf IPv4 und IPv6.
• server_name listet die Domainnamen auf, die dieser Block verarbeitet. Geben Sie sowohl die Basisdomain als auch die www-Variante an.
• root zeigt auf das Dokumentenverzeichnis dieser Website.
• access_log und error_log schreiben domainspezifische Logdateien. Ohne diese teilen sich alle Websites /var/log/nginx/access.log, was das Debugging erschwert.
• try_files liefert die angeforderte Datei aus, versucht sie dann als Verzeichnis und gibt andernfalls 404 zurück.

Erstellen Sie den zweiten Server Block:

sudo nano /etc/nginx/sites-available/site-two.com

server {
    listen 80;
    listen [::]:80;

    server_name site-two.com www.site-two.com;

    root /var/www/site-two.com/html;
    index index.html;

    access_log /var/log/nginx/site-two.com.access.log;
    error_log /var/log/nginx/site-two.com.error.log;

    location / {
        try_files $uri $uri/ =404;
    }
}

Wie aktivieren und deaktivieren Sie Server Blocks?

Server Blocks in sites-available/ sind inaktiv, bis sie per Symlink in sites-enabled/ verlinkt werden.

Eine Website aktivieren

Erstellen Sie Symlinks für beide Domains:

sudo ln -s /etc/nginx/sites-available/site-one.com /etc/nginx/sites-enabled/
sudo ln -s /etc/nginx/sites-available/site-two.com /etc/nginx/sites-enabled/

Entfernen Sie den Standard-Server-Block, der mit Nginx ausgeliefert wird. Er kollidiert mit Ihren neuen Blöcken und liefert die "Welcome to Nginx"-Seite aus:

sudo rm /etc/nginx/sites-enabled/default

Damit wird nur der Symlink entfernt. Die Originaldatei bleibt in sites-available/, falls Sie sie später benötigen.

Konfiguration vor dem Anwenden testen

Testen Sie die Nginx-Konfiguration stets vor dem Neuladen. Ein Syntaxfehler in einer Datei legt alle Websites lahm:

sudo nginx -t

Erwartete Ausgabe:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Wenn Sie die vollständig zusammengeführte Konfiguration sehen möchten (alle Includes aufgelöst in einer Ausgabe), verwenden Sie:

sudo nginx -T

Dies ist das beste Werkzeug zur Fehlersuche bei Server-Block-Problemen. Es zeigt genau an, was Nginx laden wird, einschließlich der Reihenfolge der Server Blocks.

Reload statt Restart

Wenden Sie die neue Konfiguration an:

sudo systemctl reload nginx

Warum reload statt restart? Ein Reload sendet ein Signal an Nginx, seine Konfigurationsdateien neu einzulesen. Bestehende Verbindungen werden normal abgeschlossen. Ein Restart beendet den Prozess und startet einen neuen, wodurch alle aktiven Verbindungen unterbrochen werden. In der Produktion immer reload verwenden.

Prüfen Sie, ob der Reload funktioniert hat:

sudo systemctl status nginx

Achten Sie auf active (running) und prüfen Sie den Zeitstempel der Zeile "Main PID". Er sollte sich nicht geändert haben (was einen Reload bestätigt, keinen Restart).

Eine Website deaktivieren

Um eine Website offline zu nehmen, ohne ihre Konfiguration zu löschen:

sudo rm /etc/nginx/sites-enabled/site-two.com
sudo nginx -t && sudo systemctl reload nginx

Die Konfigurationsdatei bleibt in sites-available/. Jederzeit reaktivierbar durch erneutes Erstellen des Symlinks.

Wie prüfen Sie, ob Ihre Server Blocks funktionieren?

Öffnen Sie keinen Browser. Verwenden Sie auf einem headless VPS curl mit dem Host-Header, um Anfragen von jeder Domain zu simulieren:

curl -H "Host: site-one.com" http://localhost

Erwartete Ausgabe:

<h1>Site One</h1>

curl -H "Host: site-two.com" http://localhost

Erwartete Ausgabe:

<h1>Site Two</h1>

Dies funktioniert auch vor der DNS-Propagation, da Sie Nginx direkt über den Host-Header mitteilen, welche Domain Sie anfordern.

Sobald das DNS propagiert ist, testen Sie von Ihrem lokalen Rechner aus (nicht vom Server):

curl http://site-one.com
curl http://site-two.com

Jede Anfrage sollte die korrekte Testseite zurückgeben.

Wie entscheidet Nginx, welcher Server Block eine Anfrage bearbeitet?

Nginx ordnet eingehende Anfragen Server Blocks in einer festgelegten Reihenfolge zu. Wenn eine Anfrage eintrifft, filtert Nginx zuerst Server Blocks nach der listen-Direktive (IP und Port) und gleicht dann den Host-Header mit den server_name-Werten ab.

In welcher Reihenfolge wird server_name abgeglichen?

Die Abgleichreihenfolge ist fest und kann nicht durch die Reihenfolge der Konfigurationsdateien geändert werden:

Priorität	Mustertyp	Beispiel	Verwendung
1 (höchste)	Exakter Name	site-one.com	Wird immer zuerst geprüft. Schnellste Methode (Hash-Lookup).
2	Längster Wildcard-Präfix	*.site-one.com	Trifft auf www.site-one.com, api.site-one.com zu
3	Längster Wildcard-Suffix	mail.*	Trifft auf mail.site-one.com, mail.site-two.com zu
4	Erster treffender Regex	~^www\d+\.example\.com$	Wird in Konfigurationsdatei-Reihenfolge geprüft. Erster Treffer gewinnt.
5 (niedrigste)	default_server	N/A	Fallback, wenn nichts anderes passt.

Wichtige Hinweise:

• Exakte Namen werden immer zuerst geprüft, unabhängig davon, wo der Server Block in der Konfiguration erscheint.
• Wildcard-Namen dürfen das * nur am Anfang oder Ende haben, an einer Punkt-Grenze. w*.example.com ist ungültig.
• Regex-Muster beginnen mit ~ und werden in der Reihenfolge getestet, in der sie in Konfigurationsdateien erscheinen. Erster Treffer gewinnt. Sparsam einsetzen, da sie der langsamste Abgleichtyp sind.
• Wenn nichts passt und kein default_server gesetzt ist, verwendet Nginx den ersten Server Block in Konfigurationsdatei-Reihenfolge als Standard. Das ist eine häufige Fehlerquelle.

Was bewirkt die default_server-Direktive?

Der Parameter default_server bei der listen-Direktive teilt Nginx mit, welcher Server Block Anfragen bearbeitet, wenn kein server_name passt. Ohne ihn wählt Nginx stillschweigend den ersten geladenen Server Block für diesen Port. Das bedeutet: eine falsch konfigurierte Domain oder ein Bot, der Ihre IP-Adresse scannt, erhält eine Ihrer echten Websites.

Erstellen Sie einen Catch-all-Server-Block, der nicht zuordenbare Anfragen verwirft:

sudo nano /etc/nginx/sites-available/00-catch-all

server {
    listen 80 default_server;
    listen [::]:80 default_server;

    server_name _;

    return 444;
}

Was dieser Block bewirkt:

• default_server markiert diesen Block als Fallback für Port 80.
• server_name _ ist eine Konvention für "kein gültiger Name". Der Unterstrich ist für Nginx nicht speziell; er passt einfach nie auf einen echten Hostnamen.
• return 444 ist ein nicht standardisierter Nginx-Code, der die Verbindung schließt, ohne eine Antwort zu senden. Bots, die Ihre IP scannen, erhalten nichts. Keine Header, kein Body, keine Information über die verwendete Software.

Aktivieren und anwenden:

sudo ln -s /etc/nginx/sites-available/00-catch-all /etc/nginx/sites-enabled/
sudo nginx -t && sudo systemctl reload nginx

Der Dateiname beginnt mit 00-, damit er in Verzeichnislistings zuerst erscheint. Das hat keinen Einfluss auf das Nginx-Verhalten (die default_server-Direktive steuert die Auswahl, nicht die Dateireihenfolge), erleichtert aber Menschen das Überblicken der Konfiguration.

Testen Sie den Catch-all, indem Sie eine Domain anfordern, die keinem Server Block entspricht:

curl -v -H "Host: not-my-domain.com" http://localhost

Sie sollten Empty reply from server sehen, da Nginx die Verbindung ohne Antwort geschlossen hat.

Wie richten Sie domainspezifisches Logging ein?

Jeder Server Block in dieser Anleitung enthält bereits domainspezifische Log-Direktiven. Domainspezifische Logs ermöglichen es, eine einzelne Website zu debuggen, ohne den Traffic aller anderen Domains durchsuchen zu müssen. Die Log-Pfade sind in jedem Server Block gesetzt:

access_log /var/log/nginx/site-one.com.access.log;
error_log /var/log/nginx/site-one.com.error.log;

Logs in Echtzeit verfolgen:

sudo tail -f /var/log/nginx/site-one.com.access.log

Oder journalctl für die Hauptprozess-Logs von Nginx verwenden (Startfehler, Reload-Fehler):

journalctl -u nginx -f

Nginx verwaltet die Log-Rotation automatisch über /etc/logrotate.d/nginx. Die Standardrichtlinie rotiert Logs täglich und behält sie 14 Tage lang. Kein zusätzlicher Aufwand erforderlich.

Welche häufigen Server-Block-Probleme gibt es und wie werden sie behoben?

Symptom	Ursache	Lösung
Die Standard-"Welcome to Nginx"-Seite erscheint für alle Domains	default-Symlink noch in sites-enabled/	sudo rm /etc/nginx/sites-enabled/default && sudo systemctl reload nginx
Falsche Website wird für eine Domain ausgeliefert	Doppelter server_name in mehreren Blöcken oder kein exakter Treffer gefunden	`sudo nginx -T
Fehler could not build server_names_hash	Domainnamen zu lang für den Standard-Hash-Bucket	server_names_hash_bucket_size 128; im http {}-Block in /etc/nginx/nginx.conf hinzufügen
Änderungen nach dem Bearbeiten der Konfiguration nicht wirksam	Vergessen zu reloaden	sudo nginx -t && sudo systemctl reload nginx
bind() to 0.0.0.0:80 failed	Ein anderer Prozess (Apache, altes Nginx) belegt Port 80	`sudo ss -tlnp
Symlink erstellt, Website lädt aber nicht	Symlink zeigt auf falschen Pfad (relativ statt absolut)	Löschen und neu erstellen: sudo ln -sf /etc/nginx/sites-available/site-one.com /etc/nginx/sites-enabled/

Fehlersuche mit nginx -T

Wenn sich eine Website nicht wie erwartet verhält, die vollständig zusammengeführte Konfiguration ausgeben:

sudo nginx -T 2>&1 | grep -A 5 "server_name"

Dies zeigt jeden Server Block mit seinem server_name-Wert und lässt genau erkennen, was Nginx geladen hat und in welcher Reihenfolge. Alle include-Direktiven werden aufgelöst, sodass Sie die reale Konfiguration sehen, nicht nur die Dateien auf der Festplatte.

Nächste Schritte

Ihre Server Blocks liefern jetzt mehrere Domains über HTTP aus. Der nächste Schritt ist das Hinzufügen von TLS-Zertifikaten, damit diese Websites über HTTPS erreichbar sind.

Einen umfassenderen Blick auf die Verwaltung von Nginx auf einem VPS bietet die übergeordnete Anleitung.

---

Copyright 2026 Virtua.Cloud. Alle Rechte vorbehalten. Dieser Inhalt ist ein Originalwerk des Virtua.Cloud-Teams. Vervielfältigung, Wiederveröffentlichung oder Weiterverbreitung ohne schriftliche Genehmigung ist untersagt.