Ein irres Problem mit dem Redirect (Umleitung) von Apache – leitet auf www.www

9 Kommentare Autor: Jürgen (jdo)

Ich habe meine Website auf einen eigenen root-Server mit Linux umgezogen und gestern von mehreren Leuten den Hinweis bekommen, dass ein Redirect oder eine Umleitung nicht so funktioniert wie es oder sie soll. Vielen Dank dafür!!!

Ich verstehe das Problem immer noch nicht und es ist derzeit nur ein Workaround am Laufen. Ich beschreibe das Problem mal und vielleicht kann mir jemand helfen.

Redirects wurden getestet

Vor dem Umzug auf den VPS habe ich eine schlafende Domain dort hingezogen und ausprobiert, wie das mit Apache und so weiter funktioniert. Da klappt es auch, bei bitblokes.de nicht. Hier was ich für beide Domains gemacht habe:

  • Bei Strato liegt die Domain, zeigt aber mit einem A-Record auf den root-Server.
  • Es gibt einen Virtual Host für die Domain angelegt
  • Mit Certbot ein Zertifikat geholt
  • Angegeben, dass alle Zugriffe auf https umgeleitet werden sollen
  • Eine Umleitung / einen Redirect angelegt, dass alle nicht-www-Zugriffe auf www umgeleitet werden sollen.

Das passiert nun

Rufe ich die eine Domain über http://www.<name>.dewww.<name>.de, https://<name>.de auf, werden alle drei Aufrufe brav auf https://www.<name>.de umgeleitet.

Mache ich das mit bitblokes.de, dann funktioniert die Umleitung nur bei https://bitblokes.de und http://bitblokes.de. Gebe ich aber https://www.bitblokes.de ein, dann macht mit das doofe System daraus https://www.www.bitblokes.de und ich finde den Fehler nicht.

Ich habe schon die .htaccess der anderen Domain auf bitblokes.de kopiert und nur den Domänennamen angepasst. Neustart, service apache2 reload und der ganze Mist nutzen alles nichts. Das System leitet immer auf https://www.www.bitblokes.de um.

Redirect springt auf www.www

Redirect springt auf www.www

Eine Recherche im Internet hat sich eher als mager erwiesen. Ich habe an ganz wenigen Stellen gefunden, dass einige das Problem erwähnen – zum Beispiel bei stackoverflow. Aber auch diese Lösung führt bei mir nicht zum gewünschten Erfolg.

Redirect des Certbot

Der Certbot oder Let’s Encrypt macht folgenden Eintrag im Virtual Host (vor dem abschließenden </VirtualHost>):

RewriteEngine on
RewriteCond %{SERVER_NAME} =bitblokes.de [OR]
RewriteCond %{SERVER_NAME} =www.bitblokes.de
RewriteRule ^ https://www.%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

Sowohl in der funktionierenden Domain als auch in der .htaccess-Datei von bitblokes.de befindet sich am Anfang noch dieses Schnipsel.

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.bitblokes.de/$1 [L,R=301]

RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://www.bitblokes.de/$1 [L,R=301]
</IfModule>

Wobei es völlig irrelevant ist, ob ich das rauslasse oder einfüge und ich habe auch schon dutzende andere Beispiele ausprobiert, die ich so im Internet gefunden habe. Das Ergebnis bleibt gleich.

Kruder Workaround für den Redirect oder die Umleitung

Was bisher als einzige Lösung funktioniert, ist eine Umleitung vor dem Redirect, den Let’s Encrypt eingerichtet hat. Ganz ideal ist das nicht, aber es kommt kein Fehler und ist ebenfalls nur eine Umleitung. Leite ich Zugriffe von https://www.bitblokes.de direkt auf https://www.bitblokes.de vor allen andere Umleitungen, dann klappt es. Bei der anderen Domain ist das nicht notwendig und ich frage mich, warum das so ist:

Mein Virtual Host sieht am Ende nun so aus:

RewriteEngine on

RewriteCond %{HTTP_HOST} ^www\.bitblokes\.de [NC]
RewriteRule ^(.*)$ https://www.bitblokes.de/$1 [L,R=301]

RewriteCond %{SERVER_NAME} =bitblokes.de [OR]
RewriteCond %{SERVER_NAME} =www.bitblokes.de
RewriteRule ^ https://www.%{SERVER_NAME}%{REQUEST_URI} [END,NE,R=permanent]

Das funktioniert – nachdem ich den Cache und die Cookies im Browser gelöscht habe. Der merkt sich alte Umleitungen dummerweise auch noch.

  1. Hilft das vielleicht jemand anderem, der ebenfalls Probleme mit einer Umleitung oder einen Redirect auf www.www hat.
  2. Hat jemand schon so ein ähnliches Problem gehabt und kann mir erklären, woran das liegt oder was ich falsch gemacht habe? Bei der anderen Domain funktioniert es auch und die Einrichtung war identisch.

Möglicherweise stehe ich auch komplett auf dem Schlauch und sehe vor lauter Umzug den Wald vor lauter Bäumen nicht. Ich bin im Moment auf jeden Fall erst einmal froh, dass es funktioniert. Ich würde es aber trotzdem gerne verstehen.

Wie teste ich die Redirects oder Umleitung? Kann ich das verfolgen?

Ja, das geht und zwar mit curl. Der nachfolgende Befehl zeigt Dir genau, was der Browser so empfängt und wann welche Umleitung zieht.

curl --verbose --head --location https://www.bitblokes.de

Das ist recht praktisch, wenn Du einen Redirect verfolgen oder debuggen willst. Mit curl und dem Befehl oben kannst Du alle möglichen Kombinationen testen und nachsehen, ob Dir das Ergebnis taugt. Dabei kann Dir der Cache im Browser auch keinen Strich durch die Rechnung machen.




 Alle Kommentare als Feed abonnieren

9 Kommentare zu “Ein irres Problem mit dem Redirect (Umleitung) von Apache – leitet auf www.www”

  1. Schroeffu says:

    Was steht denn bei "ServerName" und "ServerAlias" zu Beginn in der *.conf?

    Bei dir müsste m.E. stehen
    ServerName bitblokes.de
    ServerAlias http://www.bitblokes.de

    Viele machen das gerade anders herum aber das ist denke ich "falscher" (www. ist auch im Lets Encrypt Zertifikat nur ein Alias), vielleicht einfach mal ausprobieren 🙂

    • Schroeffu says:

      Huch! ServerAlias natürlich ohne http://, entweder hat mein Smartphone das eben ungewollt auto vervollständigt oder dein WordPress 😀

    • jdo says:

      Das steht da so drin, ja.

      Der Witz ist ja, dass es bei der anderen Domain funktioniert und die ist genau gleich eingerichtet.

  2. Schroeffu says:

    Noch ein Hinweis, der mir eben eingefallen ist: Eigentlich braucht es für WordPress in der Apache site.conf keine extra Umleitung non-www nach http://www., das macht WordPress selbst. Dazu einfach die SiteUrl in den Apache Einstellungen auf entweder http://www.domain.de oder nur domain.de Einstellen.

    Ich persönlich mag es, bei IT-Webseiten das www weglassen, diese Besucher wissen dass www. überflüssig ist.
    Hingegen eine Website die sich beispielsweise um ein Restaurant handelt, macht www. Sinn, da hier die Kundschaft noch heute denkt www. gehört zu einer Webadresse dazu 🙂

    • jdo says:

      hm? Bei mir hat das WordPress noch nie selbst gemacht. Vorher konnte ich die Seite sowohl mit als auch ohne www erreichen.

      Das www ist halt schon immer drin und da gibt es einige Sachen, die ich ändern müsste, was nicht mit einer Umleitung funktioniert. Eine Altlast und auf eine Umstellung habe ich keine große Lust.

  3. Jens says:

    Das allererste Beispiel zeigt doch schon das Problem: wenn Server-Name gleich bitblokes.de oder wenn Server-Name gleich http://www.bitblokes.de ist, dann leite um zu http://www.%{SERVER_NAME}... Jetzt setz mal für Server-Name http://www.bitblokes.de ein: http://www.www.bitblokes.de.

    Ich würde certbot da nichts automatisch machen lassen und die Rewrites manuell und nur an einer Stelle einstellen.

    • jdo says:

      Warum geht es dann bei der anderen Domain, die genau gleich konfiguriert ist?

  4. Malte says:

    Also für mich ist das beschriebene Verhalten genau das was ich auch erwarten würde, in beiden Fällen.
    Mit RewriteCond %{SERVER_NAME} =bitblokes.de [OR] und RewriteCond %{SERVER_NAME} =www.bitblokes.de matchst du ja beide Fälle, sowohl mit als auch ohne www. Und dann packst du vorne noch ein www. davor. Ich hab das gerade bei kurz getestet und das Phänomen tritt auch auf.

    Mit deinem Workaround RewriteCond %{HTTP_HOST} ^www\.bitblokes\.de [NC] testest du ja ob der Host mit www anfängt und leitest in diesem Fall um auf die https Variante. Mit dem L als Flag ignoriert er dann die folgenden Regeln.

    Ohne es getestet zu haben sollte das Snippet mit dem Ifmodule alleine ausreichen. Deaktiviere das andere einmal (Wenn eine Umleitung daraus greift und es weiter oben steht, evaluiert er den Rest nicht mehr, wegen dem L).
    Außerdem würde ich immer mit temporären Umleitungen testen, da sich die permanenten tatsächlich im Browser festsetzen. Dann hilft nur warten.

    • jdo says:

      Wie gesagt verstehe ich nicht ganz, warum es bei der anderen Domain funktioniert.