Shopware zeigt einen Fehler 500: wo die Ursache steht und was Sie Ihrem Dienstleister schicken
Bei einem Fehler 500 sehen Besucher nur „An Error Occurred“. Die eigentliche Meldung steht meist im Shopware-Log — in einer Datei je Tag, mit Uhrzeit in UTC — und manchmal nur im Log von Webserver oder PHP. Wie Sie sie finden, lesen und weitergeben, nachgestellt in Shopware 6.6 und 6.7.
Ein Fehler 500 hilft niemandem weiter. Besucher sehen eine fast leere Seite, und auch der Betreiber erfährt daraus nichts. Das ist Absicht: Im Produktivmodus verrät Shopware keine Details nach außen. Die Meldung dazu steht in einem Log — meist im Log von Shopware, manchmal nur im Log von Webserver oder PHP.
Wir haben einen Fehler 500 am 27.10.2026 in Shopware 6.6.10.6 und 6.7.2.2 absichtlich ausgelöst, mit einem Testplugin, das auf jeder Seite der Storefront eine Ausnahme wirft. Beide Versionen verhielten sich gleich. Die Log-Konfiguration und die Zeitzone haben wir am 30.10.2026 im Quelltext der aktuellen Versionen 6.7.15.1 und 6.6.10.30 nachgelesen; sie sind unverändert.
Was Besucher sehen
Status 500 und eine Seite mit der Überschrift „An Error Occurred: Internal Server Error“. Keine Meldung, keine Datei, kein Hinweis auf die Ursache. Das liegt am Produktivmodus, eingestellt über APP_ENV=prod in der Datei .env oder .env.local des Shops.
Wo das Log liegt
Im Verzeichnis var/log/ der Shopware-Installation. Im Produktivmodus schreibt Shopware in der Standardkonfiguration je Tag eine eigene Datei. Hat der Shop eine eigene Log-Konfiguration, kann der Name abweichen:
var/log/prod-2026-10-27.log
Im Entwicklungsmodus heißt die Datei dev.log.
So finden Sie die jüngste Datei und die letzten Fehler, mit Befehlen, die nur lesen und nichts verändern. Sie laufen im Hauptverzeichnis des Shops; das Datum im Dateinamen ersetzen Sie durch das des Fehlers:
ls -lt var/log/ | head -n 5
tail -n 50 var/log/prod-2026-10-27.log
grep -E "\.(CRITICAL|ERROR):" var/log/prod-2026-10-27.log | tail -n 20
Der erste Befehl zeigt die zuletzt geschriebenen Logdateien, der zweite die letzten 50 Zeilen einer Datei, der dritte nur die Zeilen der Ebenen CRITICAL und ERROR, davon die letzten 20. Den Entwicklungsmodus brauchen Sie dafür nicht, und im laufenden Shop sollten Sie ihn auch nicht einschalten. Laut der Log-Konfiguration im Kern schreibt Shopware im Produktivmodus nur Meldungen der Ebene error oder höher. Hinweise und Warnungen landen in dieser Standardkonfiguration nicht im Log. Das hält es klein; dafür fehlt dort, was vor dem Fehler geschah.
Die entscheidende Zeile lesen
In unserem Test stand im Log diese Zeile (gekürzt):
[2026-10-27T12:12:18+00:00] request.CRITICAL: Uncaught PHP Exception RuntimeException: "Pixup-Testfehler: absichtlich ausgeloest" at Fehler.php line 7
| Teil | Bedeutung |
|---|---|
[2026-10-27T12:12:18+00:00] | Zeitpunkt, in UTC — in der Winterzeit eine Stunde weniger als die deutsche Uhrzeit |
request.CRITICAL | Kanal und Ebene: ein Fehler bei einem Seitenaufruf, schwerwiegend |
RuntimeException | Art der Ausnahme |
"Pixup-Testfehler: …" | die eigentliche Meldung |
at Fehler.php line 7 | Fundstelle: nur Dateiname und Zeile |
Den vollständigen Pfad nennt derselbe Logeintrag weiter hinten, in der Form [object] (RuntimeException(code: 0): … at /…/Fehler.php:7). Er ist ein Hinweis, aber kein Beweis. Liegt die Datei unter custom/plugins/ oder unter vendor/ eines Herstellers, ist das ein Indiz für eine Erweiterung: Die Fundstelle zeigt, wo der Fehler sichtbar wurde, nicht zwingend, wer ihn verursacht hat. Gewissheit bringt erst eine Gegenprobe in einer Testkopie. Liegt die Datei im Kern, verrät die Zeile allein den Verursacher nicht: Einen Aufrufstapel schreibt die Standardkonfiguration nicht ins Log. Dann hilft es, den Fehler in einer Testkopie im Entwicklungsmodus nachzustellen, der die Details anzeigt.
Wenn das Shopware-Log nichts zeigt
Nicht jeder Fehler 500 landet im Shopware-Log. Scheitert die Anfrage, bevor Shopware ein Log schreiben kann — etwa an einem PHP-Fehler beim Start, an fehlenden Schreibrechten auf var/log oder an einem vollen Datenträger —, steht dort nichts. Dann helfen das Fehlerlog des Webservers und das PHP-Log beim Hosting weiter. Auch eine eigene Log-Konfiguration des Shops kann Meldungen an einen anderen Ort schreiben.
Was Sie Ihrem Dienstleister schicken
Damit niemand raten muss, genügen fünf Angaben:
- Adresse, an der der Fehler auftritt — oder „alle Seiten“.
- Zeitpunkt mit Zeitzone.
- Die Logzeile mit
CRITICALoderERROR— sie ist lang und enthält hinten den Pfad der Fundstelle. Vorher schwärzen, siehe unten. - Letzte Änderung: Update, neues Plugin, geänderte Einstellung, Umzug.
- Zugang: Wer kann auf
var/logund die Konsole zugreifen?
In unserem Test war die Ursache ein Plugin. Nach bin/console plugin:deactivate und bin/console cache:clear antwortete der Shop wieder mit Status 200. Wie man bei Fehlern nach einem Update den Verursacher eingrenzt, beschreibt der Ratgeber Plugin-Fehler nach einem Shopware-Update.
Wer für solche Fälle noch keinen Ansprechpartner hat: Auf der Seite Shopware Support beschreiben wir, wie wir Shops betreuen.
Der Fehler 500 verrät nach außen nichts; Meldung und Fundstelle stehen meist im Shopware-Log, sonst im Log von Webserver oder PHP. Eine geschwärzte Zeile, ein Zeitpunkt in UTC und die letzte Änderung sind ein guter Einstieg.
Häufige Fragen
- Kann ich den Fehler im Browser sehen?
- Nicht im Produktivmodus, und das ist richtig so: Fehlermeldungen können interne Pfade und Daten verraten. Den Entwicklungsmodus mit Details sollte man nur in einer Testumgebung einschalten, nie im laufenden Shop.
- Warum steht im Log eine andere Uhrzeit?
- Shopware stellt die Zeitzone von PHP beim Start auf UTC, unabhängig von der Einstellung des Servers. In der Winterzeit liegt die deutsche Uhrzeit eine Stunde, in der Sommerzeit zwei Stunden darüber.
- Das Log ist leer, der Fehler bleibt. Was dann?
- Dann liegt die Ursache möglicherweise vor Shopware: im Webserver, in PHP selbst oder wegen fehlender Rechte. Prüfen Sie das Fehlerlog des Webservers und von PHP beim Hosting.
- Was soll ich meinem Dienstleister schicken?
- Die Adresse, an der der Fehler auftritt, den Zeitpunkt, die passende Zeile aus dem Log — sie ist lang und enthält hinten den Pfad der Fundstelle — und was zuletzt geändert wurde: Update, Plugin, Einstellung. Vorher schwärzen: E-Mail-Adressen, Namen, Anschriften, Bestellnummern, IP-Adressen, Passwörter, Zugangsdaten zur Datenbank, API-Schlüssel und Tokens. Schicken Sie nur den Ausschnitt um den Fehler, nicht die ganze Datei.
- Darf ich APP_ENV kurz auf dev stellen?
- Im laufenden Shop nicht. Der Entwicklungsmodus ist langsamer, zeigt Details öffentlich an und schreibt sehr viel ins Log. Für die Suche in einer Testkopie ist er dagegen nützlich.