.htaccess-Generator

Was ist .htaccess?

Die Datei .htaccess ist eine Konfigurationsdatei für Apache-Webserver. Damit lassen sich URL-Weiterleitungen, Sicherheits-Header, Caching-Regeln und mehr einstellen · ohne die Hauptserver-Konfiguration zu bearbeiten.

Häufige Fragen

Wo platziere ich die .htaccess-Datei?

Legen Sie sie in das Stammverzeichnis Ihrer Website (in der Regel public_html oder www). Die Regeln gelten für dieses Verzeichnis und alle Unterverzeichnisse.

Funktioniert das mit Nginx?

Nein. .htaccess ist Apache-spezifisch. Nginx nutzt seine eigene Konfigurationssyntax in nginx.conf oder Site-Konfigurationsdateien.

Kann .htaccess meine Site verlangsamen?

Apache prüft .htaccess bei jeder Anfrage, daher können sehr große Dateien Overhead verursachen. Bei Sites mit hohem Traffic ist es schneller, die Regeln in die Apache-Hauptkonfiguration zu verschieben.

Was .htaccess eigentlich ist

Eine .htaccess-Datei ist Apaches Konfigurationsdatei pro Verzeichnis. Der Name wird allgemein als Zusammenziehung von „hypertext access“ (Hypertext-Zugang) verstanden und spiegelt den ursprünglichen Hauptzweck der Datei wider, den Zugriff auf Hypertext-Dokumente zu beschränken. Legen Sie eine in ein beliebiges Verzeichnis, und die Direktiven gelten für dieses Verzeichnis und jedes darunterliegende Unterverzeichnis. Die Datei hat keinen Namen vor dem Punkt (sie ist eine Unix-Punktdatei, standardmäßig verborgen) und muss genau .htaccess heißen (kleingeschrieben, mit führendem Punkt), damit Apache sie unter der Standardeinstellung AccessFileName findet.

Es gibt echte Performance-Kosten. Apaches Dokumentation ist eindeutig: „Wenn AllowOverride so gesetzt ist, dass die Verwendung von .htaccess-Dateien erlaubt ist, sucht Apache in jedem Verzeichnis nach .htaccess-Dateien. Das Zulassen von .htaccess-Dateien verursacht daher Performance-Einbußen, ganz gleich, ob Sie sie tatsächlich nutzen oder nicht.“ Der Verzeichnisbaum wird bei jeder HTTP-Anfrage durchlaufen. Bei einer Anfrage an /var/www/html/foo/bar/baz.html prüft Apache per stat /.htaccess, dann /var/.htaccess, dann /var/www/.htaccess, dann /var/www/html/.htaccess und so weiter, selbst wenn keine dieser Dateien existiert. Apaches eigene Empfehlung lautet, wo möglich <Directory>-Blöcke der Hauptkonfiguration zu verwenden (die einmal beim Start geparst werden), und .htaccess für Hosting-Umgebungen zu reservieren, in denen Sie keinen Zugriff auf die Hauptkonfiguration haben.

Wann Sie es brauchen (und wann nicht)

Apache nennt zwei legitime Anwendungsfälle für .htaccess: Hosting-Anbieter, die Nutzern begrenzte Kontrolle ohne vollen Zugriff auf die Serverkonfiguration geben, und Fälle, in denen sich Direktiven zwischen Unterverzeichnissen unterscheiden müssen und der Bereitstellende nur das Dateisystem kontrolliert. Außerhalb davon empfiehlt die Dokumentation ausdrücklich, Regeln in <Directory>-Blöcke der Hauptkonfiguration zu verschieben.

nginx (der zweitbeliebteste Webserver) unterstützt .htaccess überhaupt nicht; er lehnt Konfigurationsdateien pro Verzeichnis aus Performance-Gründen bewusst ab, und die gesamte Konfiguration liegt in nginx.conf sowie etwaigen eingebundenen Site-Dateien. Wenn Ihr Projekt auf nginx läuft, hilft die Ausgabe dieses Generators nicht; Sie benötigen server- bzw. location-Blöcke in der nginx-Konfigurationsdatei. Caddy verwendet seine eigene Caddyfile-Syntax mit automatischem HTTPS über Let's Encrypt als Standard. LiteSpeed und OpenLiteSpeed unterstützen .htaccess aus Gründen der Apache-Kompatibilität. IIS verwendet web.config.

URL-Rewriting und das kanonische HTTPS-Muster

Die meiste nicht-triviale .htaccess-Arbeit nutzt mod_rewrite, Apaches regelbasierte URL-Rewriting-Engine auf Basis von erweiterten regulären POSIX-Ausdrücken. Die Grundform ist RewriteRule pattern substitution [flags], optional vorangestellt von einer oder mehreren RewriteCond-Bedingungen. Der Standardblock zum Erzwingen von HTTPS:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Die Flags [L,R=301] bedeuten „dies ist die letzte Regel in dieser Runde“ und „antworte mit HTTP 301 Moved Permanently“. Ein 301 ist die richtige Wahl für dauerhafte Weiterleitungen, Suchmaschinen geben Link-Equity weiter und Browser cachen aggressiv. Verwenden Sie 302 (Found) nur für wirklich vorübergehende Weiterleitungen, bei denen Sie nicht möchten, dass der Wechsel gecacht wird.

Hinter einem Load Balancer oder Reverse Proxy, der TLS terminiert, sieht der Ursprungsserver reines HTTP, selbst wenn der Browser des Nutzers auf HTTPS läuft; eine naive Regel RewriteCond %{HTTPS} off leitet dann endlos weiter. Die Lösung besteht darin, stattdessen den weitergeleiteten Header zu prüfen: RewriteCond %{HTTP:X-Forwarded-Proto} !https. Cloudflares Modus „Flexible SSL“ (das CDN spricht HTTP mit dem Ursprung, während der Nutzer HTTPS verwendet) ist die häufigste Ursache dieser Weiterleitungsschleifen-Falle.

Wählen Sie zwischen Kanonisierung mit oder ohne www mit einem ähnlichen Muster. Legen Sie einen kanonischen Hostnamen fest, für SEO (vermeidet Probleme mit doppeltem Inhalt) und für den Cookie-Geltungsbereich (eine www-Subdomain erhält standardmäßig andere Cookies als die Apex-Domain).

Komprimierung und Caching

mod_deflate komprimiert textuelle Antworten per gzip und reduziert die Übertragungsgröße bei Text/HTML/CSS/JS drastisch. Umschließen Sie den Block mit <IfModule mod_deflate.c>, damit er die Site auf Servern, auf denen das Modul nicht geladen ist, nicht zum Absturz bringt. Brotli (mod_brotli) ist der moderne Ersatz und verwendet dasselbe Muster.

mod_expires setzt die Header Expires und Cache-Control: max-age. Die weit verbreitete Syntax „access plus 1 year“ bedeutet, dass das Asset ab dem Moment, in dem der Nutzer es abgerufen hat, ein Jahr lang gecacht werden darf. Ein langes max-age ist für gehashte Asset-Dateinamen richtig (app.abc123.js); ein kürzeres max-age ist für HTML und alles Veränderliche richtig. Für feinere Kontrolle ist Header set Cache-Control "public, max-age=31536000, immutable" für gehashte Dateien die moderne beste Praxis.

Wissenswerte Sicherheits-Header

• X-Frame-Options: SAMEORIGIN: verhindert, dass die Seite in einem <iframe> auf anderen Ursprüngen eingebettet wird. Weitgehend abgelöst durch CSP frame-ancestors.
• Content-Security-Policy: die moderne Hauptverteidigung gegen XSS und Clickjacking. Ein Einstieg: default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self'. Mit der Zeit verschärfen.
• Strict-Transport-Security (HSTS), weist den Browser an, mit Ihrer Domain ausschließlich HTTPS zu sprechen. max-age=31536000; includeSubDomains ist die typische Basis. Fügen Sie preload nur hinzu, wenn Sie sicher sind, dass HTTPS dauerhaft ist; einmal in die HSTS-Liste des Browsers vorgeladen, ist die Entfernung schwierig.
• X-Content-Type-Options: nosniff: verhindert, dass Browser den Content-Type-Header in Frage stellen. Der Header hat nur einen Wert.
• Referrer-Policy: strict-origin-when-cross-origin: der moderne Standard; sendet die vollständige URL bei Anfragen desselben Ursprungs, nur den Ursprung bei ursprungsübergreifenden Anfragen und nichts bei einem Downgrade von HTTPS auf HTTP.
• Permissions-Policy: steuert Browserfunktionen wie Kamera, Mikrofon, Standortbestimmung. Ersetzte den älteren Feature-Policy-Header.
• X-XSS-Protection: weitgehend veraltet. Der Filter wurde aus Chrome entfernt und existierte in Firefox nie; moderne Sicherheit setzt auf CSP. Viele alte Anleitungen liefern ihn noch für veraltetes IE mit, auf neuen Seiten kann er bedenkenlos weggelassen werden.

Verbergen, was nicht ausgeliefert werden sollte

Zwei Einzeiler zur Sicherheitshärtung zahlen sich aus:

• Options -Indexes: deaktiviert automatisch generierte Verzeichnislisten, wenn es keine index.html gibt. Viele Distributionen werden mit standardmäßig aktivierter Verzeichnisindizierung ausgeliefert; ein versehentlich ungeschütztes Verzeichnis sollte seinen Inhalt nicht ins Web preisgeben.
• Punktdateien und Versionsverwaltungs-Metadaten blockieren. Ein Block <FilesMatch "^(\.htaccess|\.htpasswd|\.env|\.git.*)$"> mit Require all denied hält Angreifer davon ab, .env (das oft DB-Passwörter und API-Schlüssel enthält) oder .git/config (das Remote-URLs und manchmal Zugangsdaten offenlegt) herunterzuladen. Bedrohungsberichte von Akamai und SANS dokumentieren die Offenlegung von .env als eines der häufigsten Lecks auf Anwendungsebene der 2020er-Jahre.

Apache 2.4 ersetzte die ältere Syntax Order Allow,Deny durch die übersichtlichere Require-Direktivenfamilie, Require all granted, Require all denied, Require ip 192.0.2.0/24, Require not ip 198.51.100.5. Die alte Syntax funktioniert aus Gründen der Abwärtskompatibilität weiterhin, ist aber als veraltet dokumentiert.

Häufige Fallstricke

• mod_rewrite muss aktiviert sein, und zwar auf Serverebene. Unter Debian/Ubuntu: sudo a2enmod rewrite && sudo systemctl restart apache2. Ohne es wird jede RewriteRule stillschweigend übersprungen.
• AllowOverride ist entscheidend. Wenn die Hauptkonfiguration AllowOverride None für Ihr <Directory> hat, wird jede Direktive in Ihrer .htaccess stillschweigend ignoriert. AllowOverride All erlaubt alles; AllowOverride FileInfo AuthConfig erlaubt nur Rewriting und Authentifizierung, was für die meisten Anwendungsfälle ausreicht.
• Ein einziger Tippfehler legt die gesamte Site lahm. Apache gibt für jede Anfrage an den betroffenen Verzeichnisbaum einen 500 Internal Server Error zurück, bis die Datei behoben ist. Testen Sie immer zuerst in einer Staging-Umgebung; behalten Sie eine Sicherungskopie namens .htaccess.bak; halten Sie SSH-/FTP-Zugang bereit, damit Sie eine defekte Datei aus der Ferne umbenennen können. Beobachten Sie /var/log/apache2/error.log auf Syntaxmeldungen.
• Endlose Weiterleitungsschleifen. Browser begrenzen Weiterleitungsketten auf etwa 20 Sprünge und zeigen ERR_TOO_MANY_REDIRECTS. Die häufigsten Ursachen: eine HTTPS-Weiterleitungsregel, die auf einem Server hinter einem TLS-terminierenden Proxy läuft (verwenden Sie %{HTTP:X-Forwarded-Proto}); www- und HTTPS-Regeln in der falschen Reihenfolge, die doppelte Weiterleitungen verursachen; Cloudflares Modus Flexible SSL.
• Das Flag [L] startet die Rewrite-Engine mit der umgeschriebenen URL von oben neu. Wenn dann eine spätere Regel passt, kann das Verhalten überraschen. Verwenden Sie [END] (Apache 2.3.9+), wenn Sie wirklich einen harten Stopp wollen.
• Der Kontext pro Verzeichnis entfernt den führenden Schrägstrich. In .htaccess passt RewriteRule ^index\.html$ home.html; RewriteRule ^/index\.html$ nicht. Das bringt jeden zu Fall, der eine Regel aus einem Beispiel der Hauptkonfiguration kopiert.
• Einige Direktiven sind in .htaccess verboten: <VirtualHost>, <Directory>, <Location>, Listen, ServerName sind nur in der Hauptkonfiguration zulässig. Die Datei pro Verzeichnis gilt bereits implizit für ihr eigenes Verzeichnis.

Weitere Fragen

Wohin genau gehört die Datei?

In das Verzeichnis, dessen Inhalt Sie steuern möchten. Die meisten Nutzer von Shared Hosting legen sie in das Document Root ihrer Site, public_html/, www/ oder htdocs/, je nach Anbieter. Apache durchläuft dann den Verzeichnisbaum und wendet die Regeln auf dieses Verzeichnis und jedes darunterliegende Unterverzeichnis an.

301 oder 302, welche Weiterleitung soll ich verwenden?

301 Moved Permanently für dauerhafte Umzüge. Suchmaschinen übertragen Link-Equity auf die neue URL; Browser cachen die Weiterleitung aggressiv. Verwenden Sie dies für Fälle nach dem Motto „Wir haben diese Seite für immer verschoben“. 302 Found für vorübergehende Weiterleitungen, der Browser cacht nicht und Suchmaschinen übertragen kein Ranking. Verwenden Sie 302 nur, wenn der Umzug wirklich vorübergehend ist; standardmäßig 302 statt 301 zu nehmen ist eines der häufigsten SEO-Eigentore.

Wie schütze ich ein Verzeichnis mit einem Passwort?

Erstellen Sie eine .htpasswd-Datei mit dem Kommandozeilenwerkzeug htpasswd (es speichert Zeilen der Form username:bcrypt-hash) und legen Sie sie außerhalb Ihres Web-Roots ab. Dann in .htaccess: AuthType Basic, AuthName "Restricted Area", AuthUserFile /full/path/to/.htpasswd, Require valid-user. Der Browser zeigt jedem, der das Verzeichnis besucht, eine System-Eingabeaufforderung für Basic-Auth. Das ist das klassische Apache-Muster; für ernsthafte Authentifizierung sollten Sie stattdessen ein Login-System auf Anwendungsebene in Betracht ziehen.

Funktioniert das mit WordPress?

WordPress wird mit einem eigenen .htaccess-Block ausgeliefert (zwischen den Markierungen # BEGIN WordPress und # END WordPress), der Permalinks verarbeitet. WordPress überschreibt alles innerhalb dieser Markierungen, wenn Sie die Permalink-Einstellungen speichern. Fügen Sie Ihre eigenen Regeln außerhalb der WordPress-Markierungen hinzu (typischerweise darüber), damit sie die automatische Neuerzeugung überstehen.

Werden Daten an einen Server gesendet?

Nein. Der Generator ist JavaScript, das Direktivenblöcke anhand Ihrer Kontrollkästchen zusammensetzt; die Ausgabe wird in Ihrem Browser erstellt. Nichts über Ihre Domain oder gewählten Optionen verlässt die Seite; das Werkzeug funktioniert offline, sobald es geladen ist.

Verwandte Tools