Logfiles finden und lesen: Plesk und cPanel

Die Logfiles deiner Domain siehst du ohne Root-Zugang: das Zugriffs-Log, das Fehler-Log des Webservers und die PHP-Fehler — im Hosting-Panel oder per SSH in deinem Webspace. Dieser Artikel zeigt, wo sie in Plesk und cPanel liegen, wie du sie liest und welche Logs nur auf Server-Ebene existieren.

Welche Logs es gibt

Log	Was drinsteht	Wann du es brauchst
Access-Log	Jeder Aufruf: IP, Zeit, URL, HTTP-Status, Browser	Wer ruft was auf? Woher kommt die Last? Welche URL liefert 404 oder 500?
Error-Log	Fehler des Webservers und PHP-Fehler (Fatal error, Warning, Timeout, fehlende Datei)	Weiße Seite, Fehler 500, Seite lädt nicht
Anwendungs-Log	Was die Anwendung selbst schreibt — Exceptions, Cron-Läufe, Integrationen	Fehler, die die Anwendung abfängt und deshalb nie beim Webserver ankommen

Die ersten beiden schreibt der Webserver pro Domain, das dritte liegt im Verzeichnis der Anwendung (siehe unten).

Schritt für Schritt

Plesk

Im Panel

1. Öffne Websites & Domains und wähl die Domain.
2. Klick auf Protokolle. Plesk zeigt Access- und Error-Log aller Quellen (Apache, nginx, PHP) in einer gemeinsamen Ansicht, neueste Einträge zuerst.
3. Grenz über das Filter-Feld ein — nach Text (Fatal, eine URL, eine IP), nach Quelle oder nach Zeitraum.
4. Aktivier Echtzeit-Aktualisierung, wenn du den Fehler gerade reproduzierst: Lad die Seite im zweiten Tab neu, die Einträge erscheinen live.
5. Über Protokolle verwalten lädst du einzelne Dateien herunter und stellst die Rotation ein (Größe, Anzahl aufbewahrter Dateien).

Per SSH

Die Dateien liegen im Verzeichnis logs deines Webspace:

~/logs/access_log            HTTP-Zugriffe (Apache)
~/logs/access_ssl_log        HTTPS-Zugriffe (Apache)
~/logs/proxy_access_log      HTTP-Zugriffe (nginx, vorgeschaltet)
~/logs/proxy_access_ssl_log  HTTPS-Zugriffe (nginx, vorgeschaltet)
~/logs/error_log             Fehler von Apache und PHP
~/logs/proxy_error_log       Fehler von nginx

Rotierte Dateien heißen error_log.processed oder tragen ein Datum bzw. .gz am Ende.

cPanel

Im Panel

1. Öffne im Bereich Metriken den Punkt Fehler. cPanel zeigt die letzten 300 Einträge des Fehler-Logs für dein Konto, neueste zuerst.
2. Lad die Seite nach dem Reproduzieren des Fehlers neu — die Ansicht aktualisiert sich nicht von allein.
3. Öffne Metriken → Unformatierter Zugriff (Raw Access), um das Access-Log einer Domain als Datei herunterzuladen.
4. Setz dort das Häkchen bei Protokolle archivieren, wenn ältere Access-Logs erhalten bleiben sollen — sonst hält cPanel nur den laufenden Monat vor.

Per SSH

~/access-logs/<domain>        laufendes Access-Log, eine Datei pro Domain
~/logs/                       archivierte Access-Logs (nur bei aktivierter Archivierung, gepackt)
~/public_html/error_log       PHP-Fehler, sofern die Anwendung dorthin schreibt

Das Fehler-Log des Webservers selbst gibt es auf cPanel nicht als Datei in deinem Webspace — nur über die Panel-Ansicht Fehler.

Logs im Terminal lesen

Die drei Befehle, mit denen du fast alles findest — Pfade aus dem Tab oben einsetzen:

# Neueste Einträge live mitlesen (Beenden mit Strg+C)
tail -f ~/logs/error_log

# Nur Zeilen mit einem Suchbegriff, die letzten 20
grep -i "fatal" ~/logs/error_log | tail -n 20

# Alle Aufrufe mit Status 500 im Access-Log zählen
grep -c ' 500 ' ~/logs/access_ssl_log

Gepackte Rotationsdateien liest zgrep mit derselben Syntax. Für die Auswertung ganzer Access-Logs nach Besuchern, URLs und Bots ist GoAccess das bessere Werkzeug als grep.

Anwendungs-Logs

Fehler, die deine Anwendung selbst abfängt, tauchen im Webserver-Log nicht auf. Dafür gibt es eigene Dateien im Verzeichnis der Installation:

Anwendung	Log	Hinweis
WordPress	wp-content/debug.log	Nur mit WP_DEBUG_LOG in der wp-config.php — siehe Fehler nach PHP-Wechsel
Magento	var/log/system.log, var/log/exception.log, var/log/debug.log	exception.log zuerst prüfen
Shopware 6	var/log/prod-JJJJ-MM-TT.log	eine Datei pro Tag, außerdem Einstellungen → System → Logs im Admin
Nextcloud	data/nextcloud.log	auch unter Verwaltungseinstellungen → Protokollierung

Logs wachsen

debug.log und Magentos var/log/ können auf mehrere Gigabyte anwachsen und den Speicherplatz füllen. Debug-Logging nach der Fehlersuche wieder abschalten und alte Anwendungs-Logs regelmäßig löschen — die Webserver-Logs rotiert das Panel von selbst.

Was ohne Root nicht sichtbar ist

Einige Logs führt der Server zentral, nicht pro Domain. Die siehst du nicht selbst — dafür schauen wir per Ticket hinein:

• Mail-Log des Servers: Wurde eine Mail zugestellt, abgewiesen, verzögert? Auf cPanel zeigt E-Mail → Zustellung verfolgen einen Teil davon, auf Plesk gibt es keine Kundenansicht.
• PHP-FPM-Pool-Log: Prozess-Abbrüche, Timeouts des Pools (request_terminate_timeout), Speicher-Limits.
• Firewall- und Fail2ban-Log: Warum eine IP gesperrt wurde — siehe IP gesperrt.
• MySQL-Fehler- und Slow-Query-Log: Langsame Abfragen, Verbindungsabbrüche der Datenbank.
• Requests, die der Webserver vor dem Logging verwirft — etwa ein 413 bei zu großem Upload, siehe Upload-Limit erhöhen.

Nenn im Ticket Domain, Zeitpunkt und was du ausgelöst hast, dann finden wir den Eintrag schnell. Wer sich die Log-Analyse dauerhaft abnehmen lassen will, findet unter Rent an Admin den passenden Rahmen.

Wenn etwas schiefläuft

Das Error-Log ist leer, die Seite zeigt trotzdem einen Fehler

Die Anwendung fängt den Fehler ab und zeigt eine eigene Fehlerseite, ohne ihn an PHP durchzureichen — oder der Request kommt gar nicht bis PHP.

Lösung: Erst das Anwendungs-Log prüfen (Tabelle oben). Steht auch dort nichts, in der Browser-Konsole (F12 → Netzwerk) den HTTP-Status des fehlgeschlagenen Aufrufs ablesen.

Ein PHP-Fehler steht im Browser, aber nicht im Log

display_errors ist an und log_errors aus — PHP zeigt den Fehler an, statt ihn zu schreiben.

Lösung: In den PHP-Einstellungen der Domain (Plesk) log_errors auf on und display_errors auf off setzen. Fehler gehören ins Log, nicht auf die Webseite. Auf cPanel per Ticket.

tail: cannot open '~/logs/error_log': Permission denied

Die Datei gehört dem Webserver-Benutzer, nicht deinem SSH-Login — das kommt bei Domains vor, die einem anderen Abonnement zugeordnet sind.

Lösung: Mit dem SSH-Zugang des Abonnements einloggen, zu dem die Domain gehört. Im Zweifel die Zuordnung in Websites & Domains prüfen.

Die Einträge sind Stunden alt

Das Panel zeigt den Stand der letzten Rotation, oder die Datei wurde gerade rotiert und die neue ist noch leer.

Lösung: Per SSH direkt tail -f auf die Datei — das zeigt immer den aktuellen Stand. In Plesk zusätzlich die Echtzeit-Aktualisierung einschalten.

Verwandte Artikel

• Fehler nach PHP-Wechsel beheben — der Klassiker, bei dem das Error-Log die Antwort liefert.
• GoAccess: Zugriffe selbst analysieren — Access-Logs auswerten statt nur durchsuchen.
• Fehler 403/406: WAF blockiert eine Aktion — die ModSecurity-Regel steht im selben Log.
• SSH-Zugang einrichten — Voraussetzung für tail und grep.
• Upload-Limit erhöhen — ein Fehler, der bewusst in keinem Log steht.

Du kommst nicht weiter?

Du findest den Eintrag nicht, oder der Fehler sitzt in einem Log, das du nicht sehen kannst? Ticket im Kundencenter öffnen — mit Domain, Uhrzeit und der ausgelösten Aktion suchen wir auf Server-Ebene weiter.