Wer eine Webseite betreibt, kommt früher oder später mit URL-Weiterleitungen in Berührung. Vielleicht wurde eine Seite verschoben, die Verzeichnisstruktur geändert, eine neue Domain eingeführt oder eine Webseite vollständig auf HTTPS umgestellt. Damit Besucher, Suchmaschinen und bestehende Links weiterhin am richtigen Ziel ankommen, können Weiterleitungen direkt über den Apache-Webserver eingerichtet werden.
Apache stellt dafür mehrere Möglichkeiten bereit. Besonders wichtig sind die Direktive Redirect aus dem Modul mod_alias und die wesentlich flexiblere Rewrite-Engine mod_rewrite.
In diesem Beitrag schauen wir uns ausführlich an, wie URL-Weiterleitungen direkt in einer Apache-Konfigurationsdatei eingerichtet werden, wann Redirect sinnvoll ist und wann sich der Einsatz von RewriteRule empfiehlt.
Warum URLs überhaupt umleiten?
Nehmen wir an, eine Webseite war bisher unter folgender Adresse erreichbar:
https://www.example.de/alte-seite
Nach einer Umstrukturierung lautet die neue Adresse:
https://www.example.de/neue-seite
Die alte URL kann allerdings noch an vielen Stellen vorhanden sein:
- in Suchmaschinen
- in Browser-Lesezeichen
- in Dokumentationen
- in sozialen Netzwerken
- auf anderen Webseiten
- in internen Links
- in RSS-Feeds
- in E-Mails
Wird die alte Seite einfach gelöscht, erhalten Besucher möglicherweise einen HTTP-Fehler 404 Not Found.
Besser ist eine Weiterleitung:
/alte-seite
↓
/neue-seite
Der Webserver teilt dem Browser mit, dass sich die gewünschte Ressource an einer anderen Adresse befindet.
HTTP-Statuscodes für Weiterleitungen
Eine Weiterleitung besteht nicht nur aus einem Ziel. Der Webserver liefert gleichzeitig einen HTTP-Statuscode zurück.
Besonders häufig begegnet man den Statuscodes 301 und 302.
301 – Moved Permanently
Ein 301 signalisiert eine dauerhafte Weiterleitung.
Beispiel:
HTTP/1.1 301 Moved Permanently Location: https://www.example.de/neue-seite
Diese Variante eignet sich beispielsweise für:
- dauerhaft verschobene Seiten
- neue URL-Strukturen
- Domainumzüge
- dauerhafte HTTP-zu-HTTPS-Weiterleitungen
- dauerhaft geänderte Artikeladressen
Für Webseitenmigrationen ist 301 daher häufig die richtige Wahl.
302 – Found
Ein 302 beschreibt dagegen eine temporäre Weiterleitung.
Sie ist sinnvoll, wenn die ursprüngliche URL später wieder verwendet werden soll.
Beispielsweise:
/wartung
↓
/wartungsseite
Soll die Änderung dauerhaft bestehen bleiben, sollte in der Regel kein 302, sondern ein permanenter Redirect verwendet werden.
Wo werden Apache-Weiterleitungen konfiguriert?
Weiterleitungen können je nach Serverkonfiguration an unterschiedlichen Stellen eingerichtet werden.
Unter Debian und Ubuntu befinden sich VirtualHost-Konfigurationen beispielsweise typischerweise unter:
/etc/apache2/sites-available/
Eine Webseite könnte dort etwa folgende Konfigurationsdatei besitzen:
/etc/apache2/sites-available/example.conf
Aktivierte Konfigurationen werden normalerweise über:
/etc/apache2/sites-enabled/
eingebunden.
Zusätzlich können Apache-Direktiven – sofern vom Administrator erlaubt – über eine .htaccess-Datei definiert werden.
Bei einem selbst administrierten Server ist die zentrale Apache-Konfiguration beziehungsweise die VirtualHost-Konfiguration meist vorzuziehen. Apache muss dann nicht bei jedem Request nach .htaccess-Dateien suchen und deren Inhalt erneut berücksichtigen.
Einfache Weiterleitungen mit Redirect
Für einfache URL-Weiterleitungen bietet Apache die Direktive Redirect.
Sie gehört zum Modul:
mod_alias
Eine einfache permanente Weiterleitung kann beispielsweise so aussehen:
Redirect 301 /alte-seite https://www.example.de/neue-seite
Alternativ kann permanent verwendet werden:
Redirect permanent /alte-seite https://www.example.de/neue-seite
Die Weiterleitung kann direkt innerhalb eines VirtualHosts stehen:
<VirtualHost *:443>
ServerName www.example.de
Redirect 301 /alte-seite https://www.example.de/neue-seite
</VirtualHost>
Ruft ein Besucher nun
https://www.example.de/alte-seite
auf, erhält er eine permanente Weiterleitung auf:
https://www.example.de/neue-seite
Mehrere einzelne URLs weiterleiten
Wurde eine Webseite umstrukturiert, können mehrere Weiterleitungen definiert werden.
Beispielsweise:
Redirect 301 /linux-alt https://www.example.de/linux Redirect 301 /apache-alt https://www.example.de/apache Redirect 301 /kontakt-alt https://www.example.de/kontakt
Das ist besonders praktisch, wenn nur wenige bekannte URLs geändert wurden.
Bei sehr vielen oder systematisch aufgebauten Weiterleitungen wird diese Methode allerdings schnell unübersichtlich. Dann kommt mod_rewrite ins Spiel.
Eine komplette Domain umleiten
Ein typischer Anwendungsfall ist ein Domainwechsel.
Angenommen, die bisherige Webseite lief unter:
https://alte-domain.de
und soll künftig unter:
https://neue-domain.de
erreichbar sein.
Ein entsprechender VirtualHost könnte folgendermaßen aussehen:
<VirtualHost *:80>
ServerName alte-domain.de
ServerAlias www.alte-domain.de
Redirect permanent / https://neue-domain.de/
</VirtualHost>
Eine Anfrage an:
http://alte-domain.de/blog/apache
wird dadurch beispielsweise auf die neue Domain weitergeleitet.
Für eine vollständige Domainmigration sollte allerdings genau geprüft werden, wie Pfade, HTTPS, Subdomains und gegebenenfalls Query-Parameter behandelt werden sollen.
HTTP auf HTTPS umleiten
Einer der häufigsten Anwendungsfälle ist die Weiterleitung unverschlüsselter HTTP-Anfragen auf HTTPS.
Der HTTP-VirtualHost lauscht normalerweise auf Port 80:
<VirtualHost *:80>
ServerName example.de
ServerAlias www.example.de
Redirect permanent / https://example.de/
</VirtualHost>
Ruft jemand beispielsweise
http://example.de/linux/apache
auf, wird die Anfrage auf die HTTPS-Version der Webseite weitergeleitet.
Die eigentliche Webseite wird anschließend über einen separaten VirtualHost auf Port 443 bereitgestellt:
<VirtualHost *:443>
ServerName example.de
SSLEngine on
# weitere SSL- und Webseiten-Konfiguration
</VirtualHost>
In einer produktiven Umgebung gehören selbstverständlich noch die passenden Zertifikats- und TLS-Einstellungen dazu.
Weiterleitungen mit mod_rewrite
Redirect ist bewusst einfach gehalten. Sobald Bedingungen, reguläre Ausdrücke oder komplexere URL-Strukturen benötigt werden, ist mod_rewrite deutlich leistungsfähiger.
Zunächst muss die Rewrite-Engine aktiviert werden:
RewriteEngine On
Anschließend können Regeln definiert werden.
Ein einfaches Beispiel:
RewriteEngine On RewriteRule ^/alte-seite$ /neue-seite [R=301,L]
Die Regel leitet:
/alte-seite
auf:
/neue-seite
weiter.
Die Flags R und L
Am Ende einer RewriteRule stehen häufig sogenannte Flags:
[R=301,L]
R=301 bedeutet, dass Apache eine externe HTTP-Weiterleitung mit dem Statuscode 301 ausführen soll.
L steht für:
Last
Apache soll nach erfolgreicher Anwendung dieser Regel innerhalb des aktuellen Rewrite-Durchlaufs keine weiteren Regeln mehr verarbeiten.
Diese Kombination findet man daher sehr häufig:
[R=301,L]
Ganze URL-Strukturen umleiten
Die eigentliche Stärke von mod_rewrite zeigt sich bei dynamischen Regeln.
Angenommen, die bisherige Struktur lautet:
/blog/alt/apache /blog/alt/linux /blog/alt/debian
Die neue Struktur soll folgendermaßen aussehen:
/blog/neu/apache /blog/neu/linux /blog/neu/debian
Anstatt für jede URL eine eigene Weiterleitung einzurichten, kann eine Regel verwendet werden:
RewriteEngine On RewriteRule ^/blog/alt/(.*)$ /blog/neu/$1 [R=301,L]
Der Ausdruck:
(.*)
erfasst den restlichen Teil der URL.
Dieser wird über:
$1
wieder in das Ziel eingesetzt.
Damit wird beispielsweise:
/blog/alt/apache
automatisch zu:
/blog/neu/apache
und:
/blog/alt/debian
zu:
/blog/neu/debian
Weiterleitungen abhängig vom Hostnamen
Mit RewriteCond können zusätzliche Bedingungen definiert werden.
Ein klassisches Beispiel ist die Vereinheitlichung einer Domain.
Angenommen, alle Anfragen an:
www.example.de
sollen künftig auf:
example.de
zeigen.
Eine mögliche Konfiguration lautet:
RewriteEngine On
RewriteCond %{HTTP_HOST} ^www\.example\.de$ [NC]
RewriteRule ^/(.*)$ https://example.de/$1 [R=301,L]
RewriteCond definiert dabei die Bedingung, unter der die nachfolgende RewriteRule ausgeführt wird.
Das Flag:
NC
steht für:
No Case
Die Prüfung erfolgt also ohne Beachtung der Groß- und Kleinschreibung.
HTTPS mit mod_rewrite erzwingen
HTTP kann ebenfalls über mod_rewrite auf HTTPS umgeleitet werden:
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/(.*)$ https://%{HTTP_HOST}/$1 [R=301,L]
Damit wird geprüft, ob HTTPS aktiv ist.
Ist dies nicht der Fall, wird die Anfrage auf die entsprechende HTTPS-Adresse umgeleitet.
Bei einfachen VirtualHost-Konfigurationen ist ein schlichtes Redirect permanent häufig übersichtlicher. mod_rewrite lohnt sich insbesondere dann, wenn weitere Bedingungen berücksichtigt werden müssen.
Redirect oder RewriteRule?
Beide Methoden haben ihre Berechtigung.
Für eine einfache Weiterleitung wie:
/alte-seite → /neue-seite
ist Redirect meist leichter verständlich:
Redirect 301 /alte-seite https://www.example.de/neue-seite
mod_rewrite bietet sich dagegen an, wenn:
- reguläre Ausdrücke benötigt werden
- viele URLs einem gemeinsamen Muster folgen
- Bedingungen geprüft werden müssen
- Hostnamen berücksichtigt werden
- komplexe Migrationen durchgeführt werden
- URL-Strukturen dynamisch verändert werden sollen
Eine gute Grundregel lautet daher:
So einfach wie möglich konfigurieren und mod_rewrite erst einsetzen, wenn die zusätzliche Flexibilität tatsächlich benötigt wird.mod_rewrite unter Debian aktivieren
Falls das Modul noch nicht aktiviert wurde, kann dies unter Debian beziehungsweise Ubuntu mit a2enmod erfolgen:
sudo a2enmod rewrite
Anschließend sollte die Apache-Konfiguration überprüft werden:
sudo apachectl configtest
Ist alles korrekt, erscheint:
Syntax OK
Danach kann Apache neu geladen werden:
sudo systemctl reload apache2
Ein Reload ist einem vollständigen Neustart häufig vorzuziehen, weil die laufende Konfiguration möglichst unterbrechungsarm neu eingelesen wird.
VirtualHost aktivieren
Wurde beispielsweise eine neue Konfiguration unter:
/etc/apache2/sites-available/example.conf
angelegt, kann sie unter Debian mit:
sudo a2ensite example.conf
aktiviert werden.
Danach wieder:
sudo apachectl configtest
und:
sudo systemctl reload apache2
Bei Änderungen an produktiven Webservern sollte der configtest grundsätzlich vor dem Reload durchgeführt werden.
Weiterleitungen mit curl überprüfen
Nur weil eine Weiterleitung im Browser scheinbar funktioniert, bedeutet das noch nicht, dass sie technisch genauso arbeitet wie geplant.
Sehr hilfreich ist deshalb curl.
Beispielsweise:
curl -I https://www.example.de/alte-seite
Die Option -I sorgt dafür, dass nur die HTTP-Header abgefragt werden.
Eine funktionierende permanente Weiterleitung könnte beispielsweise so aussehen:
HTTP/1.1 301 Moved Permanently Location: https://www.example.de/neue-seite
Damit lässt sich unmittelbar erkennen, welchen Statuscode Apache ausliefert und welches Ziel im Location-Header angegeben wird.
Weiterleitung vollständig verfolgen
Mit:
curl -IL https://www.example.de/alte-seite
kann curl den Weiterleitungen folgen.
Das ist besonders hilfreich, wenn mehrere Redirects hintereinander stattfinden.
Beispielsweise:
http://www.example.de
↓
https://www.example.de
↓
https://example.de
Technisch funktioniert das zwar, optimal ist eine solche Redirect-Kette aber häufig nicht.
Besser wäre möglichst:
http://www.example.de
↓
https://example.de
Je weniger unnötige Weiterleitungen stattfinden, desto übersichtlicher und effizienter bleibt die Konfiguration.
Vorsicht vor Redirect-Loops
Eine fehlerhafte Konfiguration kann eine Endlosschleife erzeugen.
Beispielsweise:
/seite-a → /seite-b
und gleichzeitig:
/seite-b → /seite-a
Browser melden dann häufig Fehler wie:
ERR_TOO_MANY_REDIRECTS
Auch falsch formulierte HTTPS- oder Hostname-Regeln können solche Schleifen verursachen.
Deshalb sollten neue Rewrite-Regeln zunächst sorgfältig getestet werden.
301-Redirects nicht unüberlegt einsetzen
Browser und andere Clients können permanente Weiterleitungen zwischenspeichern. Dadurch kann es bei Tests irritierend sein, wenn eine bereits korrigierte Regel im Browser scheinbar weiterhin ausgeführt wird.
Bei umfangreichen Änderungen kann es deshalb sinnvoll sein, Weiterleitungen zunächst kontrolliert mit temporären Redirects zu testen und erst nach erfolgreicher Prüfung auf 301 umzustellen.
Dabei sollte allerdings darauf geachtet werden, temporäre Test-Redirects nicht versehentlich dauerhaft produktiv zu betreiben.
Apache-Logs bei Problemen prüfen
Funktioniert eine Weiterleitung nicht wie erwartet, helfen die Apache-Logs weiter.
Unter Debian befinden sich diese standardmäßig unter:
/var/log/apache2/
Besonders interessant sind:
/var/log/apache2/access.log
und:
/var/log/apache2/error.log
Live lassen sich neue Einträge beispielsweise mit folgendem Befehl beobachten:
sudo tail -f /var/log/apache2/error.log
Bei VirtualHosts können allerdings auch eigene Logdateien über ErrorLog und CustomLog definiert sein.
Typischer Workflow für neue Redirects
In der Praxis bietet sich ein klarer Ablauf an.
Zunächst wird die betreffende VirtualHost-Konfiguration bearbeitet:
sudo nano /etc/apache2/sites-available/example.conf
Anschließend wird beispielsweise eine Weiterleitung ergänzt:
Redirect 301 /alte-seite https://www.example.de/neue-seite
Danach folgt unbedingt der Syntaxcheck:
sudo apachectl configtest
Bei:
Syntax OK
kann Apache neu geladen werden:
sudo systemctl reload apache2
Zum Abschluss wird die Weiterleitung überprüft:
curl -I https://www.example.de/alte-seite
So lässt sich eine Änderung kontrolliert und nachvollziehbar durchführen.
Fazit
URL-Weiterleitungen gehören zu den grundlegenden Aufgaben bei der Administration eines Apache-Webservers. Sie werden bei Domainumzügen, geänderten Seitenstrukturen, HTTPS-Migrationen und zahlreichen anderen Änderungen benötigt.
Apache stellt dafür mit Redirect und mod_rewrite zwei leistungsfähige Werkzeuge bereit.
Für einfache und eindeutige Weiterleitungen sollte möglichst die unkomplizierte Variante verwendet werden:
Redirect 301 /alt https://www.example.de/neu
Sobald Bedingungen, reguläre Ausdrücke oder systematische Änderungen ganzer URL-Strukturen notwendig werden, bietet mod_rewrite wesentlich mehr Möglichkeiten:
RewriteEngine On RewriteRule ^/alt/(.*)$ /neu/$1 [R=301,L]
Unabhängig von der verwendeten Methode gilt: Vor einem Reload sollte die Apache-Konfiguration immer mit
apachectl configtest
überprüft werden. Anschließend lässt sich mit curl -I kontrollieren, welcher HTTP-Statuscode tatsächlich ausgeliefert wird und wohin der Webserver den Client weiterleitet.
Wer Redirects bewusst einsetzt, vermeidet unnötige 404-Fehler, erhält bestehende Links und sorgt dafür, dass Besucher und Suchmaschinen auch nach Änderungen der Webseitenstruktur zuverlässig am richtigen Ziel landen.
