Wenn mehrere Domains auf dieselbe Anwendung zeigen, entscheidet die server_name-Konfiguration darüber, ob Nginx Anfragen sauber zuordnet oder unnötig kompliziert macht. Genau an dieser Stelle entstehen die meisten Fehler: falscher Hostname, falsches Zertifikat, unerwarteter Default-Server oder ein Redirect, der nicht zur gewünschten Hauptdomain passt. Ich zeige hier, wie man mehrere Domains in einem Serverblock sinnvoll bündelt, wann Wildcards wirklich helfen und warum HTTPS dabei etwas mehr Planung braucht.
Die wichtigsten Punkte auf einen Blick
- Mehrere Domains gehören in Nginx einfach in eine
server_name-Zeile, wenn sie denselben Inhalt ausliefern sollen. - Der erste Name ist der primäre Servername, aber der Default-Server wird über
listenbestimmt, nicht überserver_name. - Für HTTPS muss das Zertifikat alle verwendeten Hostnamen abdecken oder per SNI das passende Zertifikat liefern.
- Wildcards sind für Subdomains praktisch, reguläre Ausdrücke nur für Sonderfälle mit klarem Muster.
- Bei vielen Domainnamen werden Hash-Parameter und eine klare Redirect-Strategie schnell relevant.
Wie Nginx die passende Website auswählt
Nginx entscheidet nicht zuerst nach der Reihenfolge in deiner Konfiguration, sondern nach einem festen Matching-Verfahren. Zuerst prüft er die IP-Adresse und den Port aus der listen-Direktive, danach den Host-Header gegen die server_name-Einträge der passenden Serverblöcke. Das ist der Punkt, den man verstehen muss, bevor man mehrere Domains in einem Block zusammenfasst.
In der Praxis läuft die Auswahl so:
-
Exakter Hostname hat Vorrang, etwa
example.de. -
Wildcard mit führendem Stern folgt danach, etwa
*.example.de. -
Wildcard mit abschließendem Stern wird ebenfalls berücksichtigt, etwa
mail.*. - Reguläre Ausdrücke kommen zuletzt und werden in der Reihenfolge ihres Auftretens geprüft.
Der Default-Server ist dabei eine Eigenschaft des Ports, nicht der Domain. Wenn also keine passende Domain gefunden wird, landet die Anfrage nicht automatisch im Block mit dem „ersten“ Namen, sondern im für diesen Port definierten Default-Server. Genau deshalb trenne ich in sauberen Setups immer zwischen Domain-Matching und Fallback-Verhalten. Wenn das sitzt, wird auch die eigentliche Konfiguration deutlich entspannter.
Eine saubere Grundkonfiguration für mehrere Domains
Wenn derselbe Inhalt unter mehreren Hostnamen erreichbar sein soll, reicht oft ein einziger Serverblock mit mehreren Namen in server_name. Das ist die einfache, robuste Variante für Alias-Domains, Marken-Domains oder Umzüge mit paralleler Erreichbarkeit. Ich würde sie immer dann wählen, wenn die Domains technisch auf dieselbe Anwendung, dasselbe Verzeichnis und dieselbe Zertifikatslogik zeigen.
server {
listen 80;
listen 443 ssl;
server_name beispiel.de www.beispiel.de beispiel.com www.beispiel.com;
ssl_certificate /etc/ssl/certs/beispiel.pem;
ssl_certificate_key /etc/ssl/private/beispiel.key;
root /var/www/beispiel;
index index.html index.htm;
}Der erste Name in der Liste ist der primäre Servername. Das ist vor allem dann relevant, wenn Nginx absolute Redirects baut oder du Logik an den Hauptnamen koppeln willst. Für Leser und Suchmaschinen ist aber meistens eine einzige kanonische Domain sinnvoller als zwei gleichwertige Varianten. Deshalb arbeite ich oft mit einem zweiten Schritt: Der Alias wird nicht nur mitbedient, sondern sauber auf die Hauptdomain umgeleitet.
server {
listen 80;
server_name beispiel.com www.beispiel.com;
return 301 https://beispiel.de$request_uri;
}Diese Trennung ist in der Praxis oft besser als ein „alles in einem“-Ansatz, weil sie Duplicate Content vermeidet und Klarheit in die Infrastruktur bringt. Sobald mehrere Subdomains oder Spezialfälle ins Spiel kommen, lohnt sich der Blick auf Wildcards und reguläre Ausdrücke.
Wann Wildcards und reguläre Ausdrücke helfen
Ich setze Wildcards nur dann ein, wenn die Namensstruktur wirklich regelmäßig ist. Für jede andere Situation sind exakte Namen meist leichter zu warten und weniger fehleranfällig. Das gilt besonders in Umgebungen, in denen Domains später noch ergänzt werden oder unterschiedliche Teams an derselben Nginx-Konfiguration arbeiten.
| Variante | Beispiel | Wann sinnvoll | Stärke | Grenze |
|---|---|---|---|---|
| Exakter Name |
beispiel.de, www.beispiel.de
|
Die üblichen Hostnamen einer Website | Sehr eindeutig und leicht zu prüfen | Wird bei vielen Domains schnell lang |
| Wildcard | *.beispiel.de |
Viele Subdomains mit gleichem Muster | Kurz und flexibel | Deckt nur eine Ebene ab |
| Wildcard kombiniert | .beispiel.de |
Hauptdomain und Subdomains gemeinsam | Praktisch für einheitliche Regeln | Kann zu breit werden, wenn man nicht sauber plant |
| Regex | ~^www\d+\.beispiel\.de$ |
Hostnamen mit erkennbarem Sondermuster | Maximale Flexibilität | Schwerer lesbar, erstes passendes Muster gewinnt |
Reguläre Ausdrücke nutze ich nur dann, wenn sie echten Mehrwert bringen, etwa bei stark strukturierten Subdomain-Schemata oder bei Migrationen mit Übergangslogik. Sie sind mächtig, aber sie verstecken schnell Komplexität. Genau deshalb ist die Reihenfolge hier wichtig: Exakt vor Wildcard, Wildcard vor Regex. Wer das ignoriert, baut sich unnötig schwer nachvollziehbare Host-Regeln.
Für typische Webserver-Setups ist die Mischung aus exakten Namen und einer gezielt eingesetzten Wildcard die beste Balance. Danach kommt fast immer die nächste Hürde: HTTPS.
Warum HTTPS bei mehreren Domains mehr Planung braucht
Bei HTTPS reicht es nicht, den Hostnamen nur in Nginx einzutragen. Der TLS-Handshake läuft vor dem eigentlichen HTTP-Request, und der Server muss also schon vorher wissen, welches Zertifikat er präsentieren soll. Moderne Clients lösen das normalerweise über SNI, also die Übermittlung des gewünschten Servernamens während des Handshakes. Alte oder spezielle Clients können dabei aber aus dem Rahmen fallen.
Für mehrere Domains auf derselben IP gibt es in der Praxis drei saubere Wege:
- Ein Zertifikat mit mehreren SAN-Einträgen, wenn die Domains bewusst zusammengehören.
- Ein Wildcard-Zertifikat, wenn viele Subdomains einer Zone abgedeckt werden sollen.
- Getrennte IPs oder getrennte Zertifikate, wenn die Trennung technisch oder organisatorisch wichtiger ist als Komfort.
Ein Wildcard-Zertifikat ist dabei nicht grenzenlos: Es deckt nur eine Ebene ab. *.beispiel.de passt also zu www.beispiel.de, aber nicht zu shop.eu.beispiel.de und nicht zur nackten Hauptdomain. Wer mehrere konkrete Domains bündelt, fährt mit einem Zertifikat mit mehreren Namen oft besser. Wenn mehrere Serverblöcke dasselbe Zertifikat verwenden, lege ich die Zertifikatsdirektiven gerne auf http-Ebene, damit Nginx nicht unnötig mehrere Kopien derselben Datei verwalten muss.
Wichtig ist außerdem: Wenn ein Zertifikat nicht zu allen eingesetzten Hostnamen passt, sieht der Besucher nicht „ein kleines Warnsignal“, sondern im Zweifel sofort einen Vertrauensfehler. Gerade bei Domain-Migrationen wird das gern unterschätzt. Und genau da entstehen dann die vermeidbaren Support-Tickets.
Typische Fehler, die später Zeit kosten
Die meisten Probleme bei mehreren Domains sind keine Nginx-Magie, sondern Konfigurationsfehler mit klarer Ursache. Ich sehe immer wieder dieselben Muster, und sie kosten unnötig Zeit, wenn man sie nicht früh prüft.
- Der falsche Default-Server fängt Requests ab, die keinen passenden Hostnamen haben.
- www und Non-www werden nicht gemeinsam gepflegt, obwohl beide Varianten erreichbar sein sollen.
- Ein Alias zeigt auf denselben Inhalt, aber der kanonische Redirect fehlt.
- Zu viele Regex-Regeln machen die Auswahl schwer vorhersehbar.
- Bei langen Hostnamen fehlen passende Hash-Parameter, und Nginx meldet Probleme beim Aufbau der Hash-Tabellen.
Für den letzten Punkt sind zwei Direktiven relevant: server_names_hash_bucket_size und server_names_hash_max_size. Laut Nginx-Dokumentation liegen die Standardwerte je nach Cacheline-Größe bei 32, 64 oder 128 für die Bucket-Größe und bei 512 für die maximale Hash-Größe. Das reicht in vielen Setups völlig aus, aber bei sehr vielen oder sehr langen Namen kann eine Anpassung nötig werden. Ich würde das nicht voreilig drehen, sondern erst dann, wenn Nginx es tatsächlich anmahnt.
Ein weiterer Klassiker sind Requests ohne Host-Header. Wenn du solche Anfragen nicht akzeptieren willst, kannst du sie gezielt abfangen und mit return 444; schließen. Das ist kein Muss, aber in sauber abgesicherten Setups oft vernünftig. Mit etwas Disziplin bei Default-Server, Redirects und Zertifikaten vermeidest du die meisten Fehler schon im Vorfeld.
So bleibt das Setup auch bei wachsenden Domainbeständen beherrschbar
Wenn ich eine Nginx-Konfiguration langfristig wartbar halten will, entscheide ich zuerst über den kanonischen Hostnamen und erst danach über die technische Auslieferung. Das klingt simpel, macht aber den größten Unterschied: Eine Domain ist führend, die anderen sind Alias oder Subdomain, und diese Rolle bleibt in der Konfiguration sichtbar. Dadurch wird sofort klar, wo Redirects hingehören und wo echter Inhalt ausgeliefert wird.
Mein Praxisansatz sieht meist so aus:
- Eine Hauptdomain definieren und konsequent als Ziel für Redirects verwenden.
- Mehrere Hostnamen nur dann in einem Serverblock bündeln, wenn Inhalt und Verhalten identisch sind.
- Wildcards nur dort einsetzen, wo das Domainmodell sie wirklich rechtfertigt.
- Bei HTTPS zuerst die Zertifikatsabdeckung klären, dann die Nginx-Blöcke sauber aufbauen.
- Änderungen immer mit
nginx -tprüfen und mit einem gezieltencurl-Test gegen den Hostnamen verifizieren.
nginx -t
curl -I -H 'Host: beispiel.de' http://127.0.0.1Genau so bleibt ein Setup mit mehreren Domains nachvollziehbar, auch wenn später weitere Marken, Subdomains oder Migrationspfade dazukommen. Wer die Struktur früh klar zieht, spart sich im Betrieb die meiste Zeit, und zwar nicht bei der ersten Änderung, sondern bei der fünften oder zehnten. Für mich ist das der eigentliche Wert einer guten server_name-Konfiguration: Sie ist nicht nur korrekt, sondern auch noch nach Monaten verständlich.
