Zum Inhalt springen
clausvb.de

HTTP 500 nach einer .htaccess-Änderung: so grenzt du es ein

Der Ablauf, mit dem sich ein 500er nach einer Konfigurationsänderung in wenigen Minuten eingrenzen lässt – ohne zu raten.

Zuletzt geprüft:

Das Wichtigste

  • Die Ursache steht im error.log des Hosts, nicht im Browser. Ohne diesen Blick ist jede Suche Raten.
  • Häufigste Ursache: eine Direktive, die AllowOverride nicht freigibt – nicht ein Syntaxfehler.
  • Zweithäufigste Ursache: ein IfModule-Block für ein Modul, das gar nicht geladen ist, mit Direktiven ausserhalb des Blocks.
  • Halbierungsverfahren statt Zeile für Zeile: die Datei in zwei Hälften auskommentieren führt schneller zum Ziel.

Ein 500er nach dem Speichern der .htaccess ist unangenehm, weil er sofort wirkt und im Browser nichts erklärt. Mit dem folgenden Ablauf ist die Ursache meist in fünf Minuten gefunden.

Schritt 1: ins Log sehen

Der Browser zeigt bewusst keine Details. Die eigentliche Meldung steht im Fehlerlog:

tail -n 30 /var/log/apache2/error.log
# oder je nach Hoster
tail -n 30 ~/logs/error_log

Typische Meldungen und was sie bedeuten:

MeldungBedeutung
Invalid command 'X'Direktive unbekannt – Modul fehlt oder Tippfehler
not allowed hereAllowOverride gibt diese Gruppe nicht frei
Expected </IfModule> but saw </IfModule>Block nicht sauber geschlossen
RewriteRule: cannot compile regular expressionFehler im regulären Ausdruck
Options not allowed hereAllowOverride Options fehlt

Ohne Zugriff auf das Log bleibt nur Schritt 2.

Schritt 2: halbieren statt durchlesen

Statt Zeile für Zeile:

  1. Die untere Hälfte der Datei auskommentieren. Fehler weg? Dann steckt er unten.
  2. Die betroffene Hälfte erneut halbieren.
  3. Wiederholen, bis eine Zeile übrig bleibt.

Bei 60 Zeilen sind das sechs Durchgänge statt sechzig.

Zum Auskommentieren reicht ein # am Zeilenanfang. Bei mehrzeiligen Blöcken muss jede Zeile ein # bekommen – ein auskommentiertes <IfModule> mit offenem </IfModule> erzeugt einen neuen Fehler.

Die drei häufigsten Ursachen

1. Direktive nicht freigegeben. Die Regel ist korrekt, das Modul geladen – trotzdem 500. Dann steht AllowOverride in der Serverkonfiguration auf einem Wert, der die Gruppe der Direktive nicht einschliesst:

Direktivebenötigt
RewriteRule, Redirect, ErrorDocumentFileInfo
AuthType, AuthUserFile, RequireAuthConfig
OptionsOptions
DirectoryIndexIndexes

Auf Shared Hosting kann man das nicht selbst ändern – hier hilft nur eine Anfrage beim Anbieter oder eine andere Lösung.

2. Modul nicht geladen. Der IfModule-Block ist genau dafür da:

<IfModule mod_expires.c>
  ExpiresActive On
  ExpiresDefault "access plus 2 days"
</IfModule>

Der Fehler passiert, wenn eine Direktive ausserhalb des Blocks steht und das Modul fehlt. Dann erzeugt die eine Zeile den 500er, während der Block daneben harmlos übersprungen wird.

3. Kodierung und Zeilenenden. Eine unter Windows gespeicherte Datei mit CRLF und einem BOM am Anfang bringt Apache aus dem Tritt:

file .htaccess
# soll sein: ASCII text
# problematisch: with CRLF line terminators / with BOM

# reparieren
sed -i 's/\r$//' .htaccess

Das BOM ist besonders tückisch, weil es unsichtbar ist und die erste Direktive unlesbar macht.

Schritt 3: prüfen, bevor es live geht

Wer Serverzugriff hat, prüft die Syntax vorab:

apachectl configtest

Das prüft allerdings nur die Serverkonfiguration, nicht die .htaccess. Für die gibt es zwei praktikable Wege:

  • Lokaler Apache-Container mit demselben Verzeichnisaufbau und derselben Datei.
  • Zweite Domain oder ein Unterverzeichnis auf demselben Hosting als Testfläche.

Beides ist ein paar Minuten Aufwand und ersetzt die Suche unter Zeitdruck.

Vorsorge

  • Vor jeder Änderung eine Kopie: cp .htaccess .htaccess.bak-$(date +%F).
  • Die Datei ins Repository legen, dann zeigt der Diff die Änderung.
  • Änderungen einzeln machen und dazwischen die Seite aufrufen.
  • Regeln kommentieren – in sechs Monaten weiss niemand mehr, wofür eine Bedingung da war.

Der Aufbau der Datei und die Bedeutung der einzelnen Direktiven stehen im .htaccess-Leitfaden.

Häufige Fragen

Ich sehe keine Fehlermeldung, nur eine weisse Seite. Was tun?

Ein 500er zeigt aus Sicherheitsgründen keine Details im Browser. Die Meldung steht im error.log des Hosts – bei den meisten Anbietern im Kundenbereich oder unter logs im Kontoverzeichnis. Ohne dieses Log lässt sich die Ursache nur durch Ausprobieren finden.

Kann ein 500er auch von PHP kommen?

Ja. Ein Syntaxfehler in PHP oder ein fataler Fehler erzeugt denselben Statuscode. Die Unterscheidung gelingt über das Log: Apache-Fehler stehen im error.log des Webservers, PHP-Fehler je nach Konfiguration dort oder in einem eigenen PHP-Fehlerlog.

Passend dazu