hostingASWebhosting-Ratgeber
VPS und Server

Server-Logfiles lesen: Fehler und Bots erkennen

Wo Access- und Error-Logs liegen, wie eine Logzeile aufgebaut ist und wie Sie mit wenigen Befehlen 404-Fehler, Serverfehler, Crawler und Angriffsversuche finden.

Redaktion HostingASStand:

Server-Logfiles zeigen Ihnen, was auf Ihrer Website tatsächlich passiert: welche Adressen aufgerufen werden, welche davon Fehler liefern, welche Crawler unterwegs sind und wo jemand nach Sicherheitslücken sucht. Das Access-Log protokolliert jeden einzelnen Zugriff, das Error-Log die Fehlermeldungen von Webserver und Anwendung. Mit etwas Übung lesen Sie beide in wenigen Minuten und finden Probleme, die Analysewerkzeuge im Browser nicht sehen. Welche Server-Varianten es gibt und was Sie dort selbst verwalten, erklärt der Bereich VPS und eigene Server.

Welche Logfiles es gibt

Logfile Inhalt Typischer Einsatz
Access-Log Jede Anfrage an den Webserver Fehlerseiten, Crawler, Traffic-Spitzen
Error-Log Fehler von Webserver und PHP Weiße Seiten, Serverfehler 500, fehlende Dateien
PHP-Fehlerlog Warnungen und Fehler der Anwendung Fehler nach Updates von CMS oder Erweiterungen
Mail-Log Versand und Empfang von E-Mails Nicht zugestellte Formular-Mails
Systemlogs Anmeldungen, Dienste, Firewall Nur auf eigenem Server, etwa SSH-Anmeldeversuche

Bei Shared Hosting sehen Sie meist nur Access- und Error-Log Ihrer eigenen Domains, oft im Kundenmenü als Download oder über SFTP im Ordner logs. Auf einem eigenen Linux-Server liegen die Webserver-Logs in der Regel unter /var/log/apache2/ oder /var/log/nginx/. Ältere Dateien werden regelmäßig rotiert und oft als .gz gepackt. Wie Sie sicher auf den Server zugreifen, zeigt der Ratgeber zu SSH und SFTP.

So ist eine Logzeile aufgebaut

Apache und Nginx schreiben das Access-Log standardmäßig in einem sehr ähnlichen Format, dem sogenannten Combined Log Format. Eine Zeile sieht etwa so aus:

203.0.113.24 - - [26/Oct/2026:09:14:32 +0100] "GET /ratgeber/ HTTP/2.0" 200 18432 "https://www.example.org/" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) ..."
Teil Beispiel Bedeutung
IP-Adresse 203.0.113.24 Absender der Anfrage, bei Proxys oder CDN eventuell deren Adresse
Identität, Benutzer - - Meist leer, nur bei HTTP-Anmeldung gefüllt
Zeitstempel [26/Oct/2026:09:14:32 +0100] Zeitpunkt mit Zeitzone
Anfrage "GET /ratgeber/ HTTP/2.0" Methode, Pfad und Protokoll
Statuscode 200 Ergebnis der Anfrage
Größe 18432 Übertragene Bytes ohne Header
Referrer "https://www.example.org/" Seite, von der der Besucher kam
User-Agent "Mozilla/5.0 ..." Selbstauskunft von Browser oder Bot

Liegt ein CDN oder Reverse Proxy vor dem Server, steht im Log unter Umständen dessen IP-Adresse statt der des Besuchers. Die echte Adresse wird dann in einem eigenen Header weitergereicht und muss in der Serverkonfiguration gezielt ins Log übernommen werden.

Statuscodes richtig deuten

Code Bedeutung Was Sie prüfen sollten
200 Erfolgreich ausgeliefert Nichts, solange es die erwartete Seite ist
301, 308 Dauerhafte Weiterleitung Ob das Ziel stimmt und keine Ketten entstehen
302, 307 Vorübergehende Weiterleitung Ob sie wirklich nur vorübergehend sein soll
304 Nicht verändert, Browser nutzt Cache Normal und erwünscht
403 Zugriff verweigert Rechte, Sperrregeln, Firewall
404 Nicht gefunden Kaputte Links, alte Adressen ohne Weiterleitung
410 Dauerhaft entfernt Ob die Entfernung beabsichtigt ist
429 Zu viele Anfragen Ratenbegrenzung greift, eventuell auch bei erwünschten Bots
500 Interner Serverfehler Error-Log zur selben Uhrzeit
502, 503, 504 Gateway-Fehler, nicht verfügbar, Zeitüberschreitung PHP-Prozesse, Auslastung, Wartungsmodus

Ein einzelner 404 ist kein Problem. Auffällig wird es, wenn dieselbe Adresse häufig 404 liefert, vor allem mit einem Referrer von Ihrer eigenen Website oder von Suchmaschinen.

Fehler finden: die wichtigsten Befehle

Mit SSH-Zugang reichen einige Standardbefehle unter Linux und macOS. Ersetzen Sie access.log durch den Namen Ihrer Datei:

  • Häufigste 404-Adressen: awk '$9 == 404 {print $7}' access.log | sort | uniq -c | sort -rn | head -20
  • Alle Serverfehler mit Uhrzeit: awk '$9 ~ /^5/ {print $4, $7, $9}' access.log
  • Statuscodes im Überblick: awk '{print $9}' access.log | sort | uniq -c | sort -rn
  • Aktivste IP-Adressen: awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -20
  • Gepackte Archive durchsuchen: zcat access.log.2.gz | grep " 500 "
  • Live mitlesen: tail -f error.log

Die Spaltennummern gelten für das Standardformat. Hat Ihr Hoster das Format angepasst, verschieben sie sich, dann zählen Sie die Felder anhand einer Beispielzeile neu.

Ohne Kommandozeile helfen grafische Auswertungen. Viele Kundenmenüs bieten Statistiken auf Basis der Logs an, etwa mit AWStats oder Webalizer. Das Open-Source-Werkzeug GoAccess wertet Logs im Terminal oder als HTML-Bericht aus und zeigt Statuscodes, Besucher, Crawler und Bandbreite übersichtlich an.

Error-Log: der Schlüssel bei weißen Seiten

Liefert eine Seite einen Fehler 500 oder bleibt weiß, steht die Ursache fast immer im Error-Log oder im PHP-Fehlerlog. Suchen Sie nach dem Zeitpunkt des fehlerhaften Aufrufs. Typische Einträge sind:

  • Fatal error mit Dateipfad: Eine Erweiterung oder ein Theme ist nicht mit der PHP-Version kompatibel. Der Pfad verrät meist, welche.
  • Allowed memory size exhausted: Das PHP-Speicherlimit ist zu knapp oder eine Erweiterung arbeitet ineffizient.
  • Permission denied: Datei- oder Verzeichnisrechte stimmen nicht, häufig nach einem Umzug.
  • File does not exist: Eine Datei fehlt, etwa ein Bild aus einem alten Pfad oder ein gelöschtes Skript.
  • Upstream timed out: Bei Nginx mit PHP-FPM hat die Anwendung zu lange gebraucht.

Wann eine neue PHP-Version solche Fehler auslöst und wie Sie zurückschalten, steht im Ratgeber PHP-Version aktualisieren.

Bots erkennen und echte Crawler prüfen

Ein großer Teil der Zugriffe kommt nicht von Menschen. Suchmaschinen, KI-Crawler, SEO-Werkzeuge, Monitoring-Dienste und Scanner hinterlassen ihre Spuren im Access-Log. Den User-Agent kann jeder frei setzen, er ist also nur ein erster Hinweis. Ob ein Zugriff wirklich von einer Suchmaschine stammt, prüfen Sie über die IP-Adresse:

  1. Rückwärtsauflösung: host 66.249.66.1 liefert einen Hostnamen. Bei Googlebot endet er auf googlebot.com oder google.com.
  2. Vorwärtsauflösung: Den gefundenen Hostnamen erneut auflösen. Er muss auf dieselbe IP-Adresse zeigen.

Google beschreibt dieses Verfahren in seiner Dokumentation und veröffentlicht zusätzlich Listen seiner Crawler-IP-Bereiche. Andere große Suchmaschinen bieten vergleichbare Prüfwege. Gibt sich ein Zugriff als Googlebot aus, besteht die Prüfung aber nicht, handelt es sich um einen fremden Bot.

Für die Suchmaschinenoptimierung sind Logs besonders wertvoll: Sie zeigen, welche Seiten Crawler wie oft abrufen, ob sie Zeit auf Weiterleitungen, Parameter-URLs oder Fehlerseiten verschwenden und ob wichtige Seiten überhaupt besucht werden.

Angriffsversuche erkennen

Automatisierte Scanner probieren bekannte Schwachstellen auf Millionen Websites aus, unabhängig davon, welches System Sie verwenden. Typische Muster im Access-Log:

  • Aufrufe von /wp-login.php oder /xmlrpc.php in hoher Frequenz, auch auf Seiten ohne WordPress,
  • Suche nach Konfigurationsdateien wie /.env, /.git/config oder Backup-Dateien,
  • Aufrufe von Verwaltungswerkzeugen wie /phpmyadmin/,
  • Parameter mit SQL-Fragmenten oder Pfaden wie ../../etc/passwd,
  • sehr viele Anfragen einer einzelnen IP-Adresse in kurzer Zeit.

Solange diese Anfragen mit 404 oder 403 beantwortet werden, ist meist nichts passiert. Kritisch wird es, wenn ein verdächtiger Aufruf mit 200 beantwortet wird oder wenn unbekannte PHP-Dateien erfolgreich aufgerufen werden. Dann sollten Sie den Webspace auf veränderte Dateien prüfen. Gegenmaßnahmen von Ratenbegrenzung bis Web Application Firewall beschreibt der Bereich Hosting-Sicherheit.

Logfiles und Datenschutz

Access-Logs enthalten IP-Adressen und damit personenbezogene Daten. Für den sicheren Betrieb einer Website ist eine kurze Speicherung üblich. Achten Sie trotzdem auf diese Punkte:

  • Logs nur so lange aufbewahren, wie Sie sie für Betrieb und Sicherheit brauchen.
  • Wo möglich, IP-Adressen kürzen oder die Anonymisierung beim Hoster aktivieren.
  • Heruntergeladene Logs nicht unverschlüsselt weitergeben oder dauerhaft auf dem eigenen Rechner sammeln.
  • Die Verarbeitung in der Datenschutzerklärung beschreiben.

Wie Serverstandort, Auftragsverarbeitung und Datenschutz zusammenhängen, erklärt der Bereich Serverstandort und DSGVO.

Fazit

Logfiles sind die ehrlichste Datenquelle Ihrer Website. Das Access-Log zeigt Fehlerseiten, Crawler und Angriffe, das Error-Log die Ursachen für weiße Seiten und Serverfehler. Wer einmal im Monat die häufigsten 404- und 5xx-Einträge prüft, echte Suchmaschinen-Bots per DNS verifiziert und auffällige Muster im Blick behält, erkennt die meisten Probleme, bevor Besucher sie bemerken.

Häufige Fragen

Fragen und Antworten

Wo finde ich die Logfiles bei meinem Hoster?
Bei Shared Hosting meist im Kundenmenü unter einem Punkt wie Logs, Statistiken oder Protokolle, oft auch als Download. Mit SFTP oder SSH liegen sie häufig in einem Verzeichnis namens logs außerhalb des öffentlichen Webordners. Auf einem eigenen Linux-Server finden Sie sie in der Regel unter /var/log/apache2/ oder /var/log/nginx/.
Warum sind meine Logfiles nur wenige Tage alt?
Hoster rotieren Logfiles, das heißt, sie archivieren oder löschen ältere Einträge nach einer festen Frist. Das spart Speicherplatz und dient dem Datenschutz, weil Logs IP-Adressen enthalten. Wenn Sie längere Zeiträume auswerten wollen, laden Sie die Dateien regelmäßig herunter und beachten dabei die Löschfristen aus Ihrer Datenschutzerklärung.
Darf ich Logfiles mit IP-Adressen speichern?
Kurzfristig ist das für Betrieb und Sicherheit der Website üblich und wird meist auf ein berechtigtes Interesse gestützt. IP-Adressen gelten aber als personenbezogene Daten. Speichern Sie Logs deshalb nur so lange wie nötig, kürzen Sie IP-Adressen, wo es möglich ist, und erwähnen Sie die Verarbeitung in der Datenschutzerklärung. Im Zweifel klären Sie die Details mit einer Fachperson für Datenschutz.
Was bedeutet der Statuscode 499 im Nginx-Log?
499 ist ein Nginx-eigener Code und bedeutet, dass der Client die Verbindung geschlossen hat, bevor der Server antworten konnte. Häufen sich 499-Einträge bei bestimmten Seiten, antwortet die Anwendung dort vermutlich zu langsam.
Passt dazu

Weiterlesen

Zuletzt überarbeitet am 26. Oktober 2026 von der Redaktion HostingAS. Hinweise auf Fehler oder veraltete Angaben nehmen wir gern über das Kontaktformular entgegen.