.htaccess: Redirects, HTTPS und Security-Header – Alltag, Fehler, Lösungen

[mo]

.htaccess: Kleines File, große Folgen​

Wirkt harmlos. Liegt oft unsichtbar im Webroot, ein paar Zeilen Code. Aber wehe, es passt was nicht – dann ist die Website offline. Ein Redirect zu früh, ein Rewrite zu scharf, Header falsch gesetzt. Schon war’s das mit der Erreichbarkeit.

Im Support trudeln immer dieselben Fehler ein: Weiterleitungen, HTTPS, Security-Header. Fast nie sind es abgefahrene Sonderfälle. Meist reicht eine falsche Bedingung oder ein Tippfehler. Einmal zu schnell gespeichert. Zack, 500er-Fehler. Klassiker.

Redirects mit .htaccess: Fehler, die immer passieren​

Redirects sind Alltag. Domainumzug, Relaunch oder der Versuch, endlich alles auf HTTPS umzubiegen. Zwei, drei Varianten, immer dieselben Stolperfallen:

- Redirect 301 vs. RewriteRule: Für simple Fälle reicht oft ein "Redirect 301". Wer URLs umbaut oder Bedingungen braucht, landet bei "RewriteRule". Da wird’s haarig. Schon ein vertauschtes Flag (L fehlt), und Apache schleift alles in die Endlosschleife. RewriteCond vergessen? Viel Spaß beim Debugging.

- Syntaxpatzer: Leerzeichen vergessen, Slash übersehen, Flag falsch geschrieben. Apache ist da humorlos. Beispiel: "RewriteRule ^old$ new [R=301]" – aber kein "L" dabei. Ergebnis: Endlos hin und her, Browser kapituliert irgendwann.

- Loop durch HTTPS-Redirect: Ganz beliebt. HTTPS erzwingen – aber ohne Bedingung. Die Folge: Der Server schickt sich selbst im Kreis. "RewriteCond %{HTTPS} off" fehlt? Schon läuft’s schief.

- Reihenfolge-Frust: Apache liest von oben nach unten. Erstes Match gewinnt. Steht die große Umleitung zu früh, kommt niemand mehr an die eigentliche Seite. Schon öfter erlebt: Nach Domainumzug alles weitergeleitet, aber vergessen, einzelne Pfade vorher abzufangen. Ergebnis: Seite weg.

In Agenturen reicht oft eine winzige Änderung. Wochenende vorbei, Kunde wundert sich, warum nichts mehr lädt. Ein Backup hilft – wenn es existiert. Sonst: Tippfehler suchen, Kaffee holen, Apache-Logs wühlen.

HTTPS erzwingen: Wie’s meistens läuft​

HTTPS ist gesetzt. Die meisten Hoster bieten einen Schalter. Gibt’s keinen? Dann muss .htaccess ran.

Typisch sieht die Umleitung so aus:

.htaccess
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ [URL=https://%{HTTP_HOST}%{REQUEST_URI}]%{HTTP_HOST}%{REQUEST_URI}[/URL] [L,R=301]

Worauf achten?

- RewriteEngine muss an sein. Klingt banal, fehlt aber öfter als gedacht.
- Bedingung checkt, ob schon HTTPS läuft – sonst Endlosschleife.
- 301-Redirect für Dauerhaftigkeit.

Fehler, die passieren:

- "%{https}" statt "%{HTTPS}" – Apache versteht Keins von beidem, aber das Zweite ist richtig.
- Flags vermurkst oder vergessen. L und R=301 durcheinandergebracht.
- Regeln beißen sich mit CMS oder Plugins. Dann greifen mehrere Redirects parallel. Ergebnis: Loop oder nichts geht mehr.

Wer HTTPS per .htaccess erzwingt, stolpert früher oder später über HSTS. Kommt gleich.

Security-Header: Viel hilft meistens wenig​

Mit .htaccess lassen sich HTTP-Security-Header setzen. Klingt nach Sicherheit, produziert aber oft Nebenwirkungen. Die Favoriten aus dem Support-Alltag:

- Content-Security-Policy (CSP): Schutz gegen XSS. Im Ernstfall blockiert’s aber alles, was nicht explizit erlaubt wurde. Fonts, externe Skripte, Analytics – alles weg. Ohne Testen keine Chance, dass noch alles läuft. CSP ist Hauptgrund für Support-Tickets nach Sicherheits-„Optimierungen“.

- Strict-Transport-Security (HSTS): Browser merken sich, dass nur noch HTTPS geht. Einmal gesetzt, nicht mal eben rückgängig zu machen. Erst auf einer Subdomain testen, sonst ist bei Fehlern die Seite für Monate nicht erreichbar.

- X-Frame-Options: Verhindert das Einbetten in Frames. Hilfreich gegen Clickjacking, aber eigene Widgets brechen dann manchmal.

- X-Content-Type-Options: "nosniff" schaltet Browser-Spielereien ab. Meist problemlos.

- Referrer-Policy: Wer mit Referrer-Infos arbeitet, sollte hier genau wissen, was los ist. Falscher Wert, und Analytics freuen sich nicht mehr.

Beispiel-Konfig:

.htaccess
Header set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header set X-Frame-Options "SAMEORIGIN"
Header set X-Content-Type-Options "nosniff"
Header set Referrer-Policy "no-referrer-when-downgrade"

Wichtig: mod_headers muss laufen. In der Praxis werden Security-Header gern einfach „aus dem Netz kopiert“. CSP besonders gern. Folge: Hälfte der Seite lädt nicht, Support darf’s richten.

Fehlerquellen: Was in der Praxis schiefgeht​

.htaccess ist zickig. Fehler fallen oft erst auf, wenn Apache gar nichts mehr ausliefert. Typische Baustellen:

- Syntaxfehler: Apache schweigt, Seite bleibt weiß. Manchmal gibt’s einen Hinweis im Error-Log. Meist aber nicht.

- Redirect/Rewrite verwechselt: Redirect ist simpel, Rewrite komplexer – und fehlerträchtiger. Wer beides mischt, landet schnell in der Sackgasse.

- Pfadprobleme: Absolute vs. relative Pfade – bei mehreren Domains gern verwechselt. Plötzlich landen Anfragen im Nirvana.

- Regel-Kollisionen: CMS- oder Server-Redirect plus .htaccess – ergibt oft Endlosschleife. Zwei Köche, kein Ergebnis.

- Kein Backup, keine Testumgebung: Direkt live geändert, kein Backup, kein Testsystem. Spart Zeit. Bis es kracht.

Praxisbeispiel: CMS-Umstellung, HTTPS-Redirect im Server UND in .htaccess. Ergebnis: Endlose Umleitung, niemand kommt mehr durch. Debugging im Blindflug.

Fazit: Kleinschrittig, Backup, Logs​

.htaccess regelt viel – und bricht schnell alles. Änderungen nur mit Backup. Regeln einzeln testen, Reihenfolge beachten. Redirects und HTTPS-Umleitungen trennen, Security-Header mit Vorsicht. Fehler? Apache-Logs anschauen, nicht raten.

Am Ende hilft: selbst probieren, eigene Fehler machen, draus lernen. Wer alles verstanden hat, liest eh längst im Apache-Handbuch. Oder fragt im Forum. Hauptsache, die Seite ist wieder online.

bye
mo