Apache ServerName - So konfigurierst du vHosts richtig

Hinter apache servername steckt in der Praxis fast immer die ServerName-Direktive von Apache, also der Hostname, unter dem sich der Server oder ein einzelner Virtual Host nach außen meldet. Genau diese Einstellung entscheidet mit darüber, welche Website bei einer Anfrage ausgeliefert wird, welche Weiterleitungen korrekt gebaut werden und ob Apache mit mehreren Domains auf einer IP sauber arbeitet. Ich zeige hier, wie der Eintrag funktioniert, wie er sich von ServerAlias unterscheidet und worauf ich bei DNS, vHosts und Reverse Proxies achte.

Was ServerName in Apache wirklich steuert

ServerName ist nicht bloß ein Etikett für die Konfiguration. Apache nutzt den Wert, um sich selbst zu identifizieren, einen Virtual Host eindeutig zuzuordnen und bei Weiterleitungen oder Verzeichnispfaden den Namen zu wählen, der im Browser sichtbar wird. Fehlt die Direktive, versucht Apache, den Hostnamen aus dem System abzuleiten. Das funktioniert oft irgendwie, aber selten so präzise, wie man es in einer produktiven Umgebung braucht.

Wichtig ist dabei die Unterscheidung zwischen dem Hauptserver und einem einzelnen vHost. Außerhalb von setzt du eine globale Identität für den Hauptserver. Innerhalb eines Virtual Hosts definierst du den kanonischen Namen genau für diese Website. Ich trenne diese beiden Ebenen in der Praxis immer bewusst, weil sich sonst schnell unklare Fallbacks und schwer nachvollziehbare Weiterleitungen einschleichen.

Die entscheidende Konsequenz ist simpel: ServerName ist Teil der Routing-Logik, nicht nur ein Informationsfeld. Genau deshalb lohnt es sich, die Konfiguration bewusst aufzubauen, bevor man an Alias-Namen oder Redirects denkt.

So setzt du den Hostnamen sauber in der Konfiguration

Die Syntax ist direkt: ServerName [scheme://]domain-name|ip-address[:port]. In den meisten Fällen reicht ein voll qualifizierter Domainname im jeweiligen Virtual Host. Ich setze den Eintrag immer als klaren, extern sichtbaren Namen und nicht als internen Spitznamen, weil spätere Weiterleitungen und Debugging dadurch deutlich einfacher werden.

    ServerName example.de
    ServerAlias www.example.de
    DocumentRoot /var/www/example.de/public

Wenn die Seite öffentlich per HTTPS ausgeliefert wird, denke ich den äußeren Eintrittspunkt mit. Hinter SSL-Offloading oder einem Reverse Proxy sollte der Hostname die öffentliche URL widerspiegeln, nicht die interne Backend-Adresse. Genau an dieser Stelle verhindern ein sauber gesetztes Schema und ein passender Port, dass Apache spätere Links oder Redirects mit dem falschen Ziel baut.

Für eine globale Grundeinstellung genügt im Kern ein einzelner, eindeutiger Name im Hauptserver. In komplexeren Umgebungen setze ich zusätzlich pro vHost einen eigenen kanonischen Namen, damit jede Website eindeutig zugeordnet bleibt. Sobald dieser Grundstein gelegt ist, muss ich nur noch klären, welche alternativen Namen auf denselben Inhalt zeigen.

Wie ServerName, ServerAlias und DNS zusammenspielen

Apache arbeitet bei namebasierten Virtual Hosts nicht rein „namenorientiert“, sondern zuerst mit dem besten IP- und Port-Treffer. Erst danach vergleicht der Server ServerName und ServerAlias mit dem Hostheader aus der Anfrage. Das ist der Punkt, an dem viele Konfigurationen überraschend kippen: DNS kann korrekt sein, aber wenn der passende Alias fehlt, landet die Anfrage trotzdem im Default-VHost.

Ein typisches Beispiel aus dem Alltag ist die Kombination aus example.de und www.example.de. Wenn nur einer der beiden Namen in der Apache-Konfiguration auftaucht, wirkt die Seite auf dem anderen Hostnamen schnell „kaputt“, obwohl DNS sauber konfiguriert ist. Ich setze deshalb Alternativnamen nur dann ein, wenn sie wirklich erreichbar sein sollen, und nicht als Sammelbecken für alles, was irgendwie ähnlich aussieht.

Wenn mehrere Domains denselben Server teilen, ist diese Trennung aus kanonischem Namen, Alias und Inhalt der wichtigste Stabilitätsfaktor. Genau an dieser Stelle entstehen die meisten Fehler im Alltag, weshalb ich die Prüfroutine gleich mitdenke.

Die häufigsten Fehler und wie du sie schnell erkennst

Die meisten Probleme rund um den Hostnamen sind keine exotischen Apache-Bugs, sondern schlichte Konfigurationslücken zwischen DNS, vHost und Port. Wenn ich ein Setup prüfe, schaue ich zuerst auf diese Punkte:

• ServerName fehlt vollständig und Apache fällt auf einen abgeleiteten Systemnamen zurück.
• www und Apex-Domain wurden nicht beide berücksichtigt.
• Der Port im -Block passt nicht zur öffentlichen Erreichbarkeit.
• Ein Hostname wurde direkt im -Eintrag verwendet, obwohl seine Auflösung beim Start fehlschlägt.
• Der erste passende Virtual Host wird als Default genommen, weil kein sauberer Hostname-Match greift.

Für die Diagnose nutze ich als Erstes:

apachectl -S

Der Befehl zeigt, wie Apache die Konfiguration tatsächlich interpretiert, welche IPs und Namen zusammengehören und welcher vHost als Standard greift. Auf Windows entspricht das httpd.exe -S. Genau dieser Blick spart oft mehr Zeit als stundenlanges Raten in den einzelnen Konfigurationsdateien.

Wenn die Ausgabe nicht zu dem passt, was ich erwartet habe, ist das für mich ein klares Signal: Nicht an der Anwendung suchen, sondern zuerst an der vHost-Zuordnung. Sobald diese Ebene stimmt, werden Redirects und Dokumentpfade deutlich berechenbarer.

Warum UseCanonicalName hinter Proxys und bei Redirects zählt

ServerName bestimmt den Namen, UseCanonicalName bestimmt, wo Apache diesen Namen hernimmt, wenn er selbst URLs oder Umleitungen baut. Bei On verwendet Apache den in der Konfiguration gesetzten Hostnamen. Bei Off nimmt er den Host aus der Anfrage. Bei DNS greift er auf eine Reverse-DNS-Auflösung zurück. Ich nutze DNS im Alltag nur sehr bewusst, weil die Abhängigkeit von der Namensauflösung zusätzliche Unsicherheit bringt.

Hinter einem Reverse Proxy, einem Load Balancer oder einem SSL-Offloading-Setup achte ich zusätzlich darauf, dass der öffentliche Hostname und der öffentliche Port korrekt abgebildet werden. Sonst sehen Weiterleitungen zunächst richtig aus, bis der erste absolute Link auf die interne Backend-Adresse zeigt. Wenn Portnummern in Redirects ebenfalls eine Rolle spielen, ist außerdem UseCanonicalPhysicalPort ein Thema, das man nicht blind ignorieren sollte.

Die saubere Regel lautet für mich: Apache soll nach außen exakt den Namen zeigen, den der Browser wirklich verwendet. Alles andere rächt sich spätestens dann, wenn eine Anwendung eigene Redirects, Login-Links oder Canonical-URLs erzeugt.

Ein belastbarer Standard für neue Apache-Hosts

Wenn ich eine neue Instanz aufsetze, gehe ich immer nach demselben Muster vor:

• Ich setze zuerst einen globalen, eindeutigen ServerName.
• Danach bekommt jeder Virtual Host genau einen kanonischen Namen.
• ServerAlias nutze ich nur für echte Alternativnamen wie www oder definierte Subdomains.
• DNS, öffentliche URL und Apache-Konfiguration prüfe ich gemeinsam.
• Vor dem produktiven Start lasse ich apachectl -S gegen die fertige Konfiguration laufen.

Wenn diese fünf Punkte stimmen, ist die Konfiguration nicht nur lauffähig, sondern auch nachvollziehbar. Genau das macht im Alltag den Unterschied zwischen einer sauberen Webserver-Installation und einer, die nur scheinbar funktioniert, bis die erste Domain, Weiterleitung oder SSL-Schicht geändert wird.