Serverzugriffsprotokolle — Die Geschichte jedes Anfrages, die Ihre Anwendung erhalten hat
Jeder HTTP-Antrag, den Ihr Server verarbeitet, hinterlässt eine Zeile in der Zugriffslog-Datei. Hier erfahren Sie, wie Sie sie zeilenweise lesen und welche Muster beachten sollten.
Jeder HTTP-Request, den Ihr Server verarbeitet, hinterlässt eine Zeile in der Zugriffslog-Datei. Meistens liegen diese Dateien auf der Festplatte und wachsen schweigend, bis ein Speicherwarnsignal ausgelöst wird oder etwas im Produktionsumfeld schiefgeht. Dann wollen plötzlich alle diese Dateien lesen.
Hier ist eine einzelne Zeile aus einem Server, der das kombinierte Log-Format verwendet:
203.0.113.42 - jsmith [09/May/2026:14:32:11 +0000] "GET /api/users/profile HTTP/1.1" 200 1843 "https://example.com/dashboard" "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36"
Acht Felder. Jedes Feld ist ein Hinweis darauf, was passiert ist. Lassen wir uns von links nach rechts durchgehen.
Die Felder, ein für eins
1. Client-IP — 203.0.113.42
Die IP-Adresse, die die TCP-Verbindung zu Ihrem Server eröffnet hat. Dies ist nicht notwendig die IP-Adresse des Endbenutzers. Wenn Sie hinter einem Load Balancer, CDN oder Reverse Proxy (z. B. Nginx vor einer Node-App) stehen, ist dies die IP-Adresse des Proxys. Die echte Client-IP befindet sich in den X-Forwarded-For oder X-Real-IP Headers — und Sie müssen Ihr Log-Format explizit so konfigurieren, dass diese erfasst werden.
In Nginx sieht das so aus, als würden Sie $http_x_forwarded_for zu Ihrer log_format Direktive hinzufügen. In Apache verwenden Sie %{X-Forwarded-For}i. Wenn Sie dies überspringen und dann eine Missbrauchsanzeige erhalten oder einen schlechten Akteur blockieren müssen, werden Sie sich auf die IP-Adresse Ihres eigenen Load Balancers in jeder Log-Zeile beziehen.
2. Ident — -
Immer ein Bindestrich. Dieses Feld war ursprünglich für das Ergebnis einer identd-Abfrage bestimmt — ein altes Protokoll (RFC 1413), das es Servern ermöglichte, dem Betriebssystem des Clients zu fragen, wer das Prozessverbindung erzeugt hat. Niemand verwendet identd mehr. Das Feld existiert, weil das Common Log Format standardisiert wurde, als identd noch ein aktuelles Thema war. Überspringen Sie es.
3. Auth-User — jsmith
Der Benutzername, der bei HTTP-Basic-Auth oder Digest-Auth ausgefüllt wird. Für die meisten modernen Anwendungen — Token-Auth, Session-Cookies, JWTs — wird dies ein Bindestrich sein. Wenn Sie einen Admin-Bereich mit htpasswd schützen, zeigen fehlgeschlagene Anmeldungen als - nach einer 401-Status; erfolgreiche Anmeldungen zeigen den Benutzernamen.
4. Timestamp — [09/May/2026:14:32:11 +0000]
Die Zeit, zu der der Server den Request verarbeitet hat (nicht, wann er begonnen hat). Das Format ist . Der Zeitzone-Offset ist wichtiger, als man denkt — wenn Ihr App-Server in UTC läuft, aber Ihr APM- oder Warnungstool in einer lokalen Zeitzone, ist die Korrelation eines Anstiegs in den Logs mit einem bestimmten Incident eine Berechnung, die jedes Mal durchgeführt werden muss. Laufen Sie alles in UTC. day/Mon/year:HH:MM:SS timezone. Der Zeitzone-Offset ist wichtiger, als man denkt — wenn Ihr App-Server in UTC läuft, aber Ihr APM- oder Warnungstool in einer lokalen Zeitzone, erfordert die Korrelation eines Anstiegs in Protokollen mit einem bestimmten Vorfall immer wieder mathematische Umrechnungen. Laufen Sie alles in UTC.
5. Request-Line — "GET /api/users/profile HTTP/1.1"
Das informativste Feld. Drei Teile: die HTTP-Methode, der Pfad mit Query-String und die Protokollversion.
- Verfahren — GET, POST, PUT, DELETE, PATCH, HEAD, OPTIONS. Ungewöhnliche Methoden auf einem Endpoint sind wertvoll zu beachten.
- Pfad + Query-String — sagt Ihnen genau, was angefordert wurde. Query-Strings können Suchbegriffe, IDs und in schlechthin entworfenen APIs Authentifizierungstoken enthalten. Loggen Sie entsprechend.
- Protokoll — HTTP/1.0-Klienten in Ihren Logs im Jahr 2026 sind entweder alte Integrationslösungen oder etwas, das ein altes Client-Verhalten vortäuscht. HTTP/2 und HTTP/3 werden in Ihren Logs als diese Versionen geloggt, wenn Ihr Server sie unterstützt.
6. Status-Code — 200
Der HTTP-Status, den der Server zurückgibt. Dies ist das Urteil-Feld.
2xx— Erfolg. Der Request wurde erfolgreich verarbeitet.3xx— Umleitung. Der Client muss an einen anderen Ort gehen.4xx— Client-Fehler. Ungültige Anfrage, fehlende Authentifizierung, nicht gefunden. Kann legitimes Nutzungverhalten oder Erkundung sein.5xx— Server-Fehler. Ihre App ist abgestürzt, hat abgelaufen oder hat ungueltige Daten zurückgegeben. Untersuchen Sie diese immer.
Beim Abgleich eines Incidents filtern Sie zuerst nach 5xx . Dann schauen Sie auf die Zeitstempel der ersten 500 — das ist der Zeitpunkt, an dem das Problem begann. Alles davor ist die Vorgeschichte; alles danach ist der Auswirkungsbereich.
7. Bytes-Gesendet — 1843
Die Größe des Antwortkörpers in Bytes, ohne die Headers zu zählen. Ein Bindestrich bedeutet null Bytes (typisch für 304 Not Modified Antworten — der Client hat bereits den Inhalt). Ungewöhnlich große Werte auf Endpunkten, die typischerweise einige hundert Bytes zurückgeben, sind ein Warnzeichen. Ein authentifizierter Benutzer, der einen „mein Profil“-Endpunkt aufruft und 40MB erhält, ist entweder ein Bug oder jemand, der eine Datenexport-Funktion missbraucht.
8. Referer — "https://example.com/dashboard"
Woher der Client kam, bevor dieser Request gestartet wurde — die URL im Browser-Header. (Das HTTP-Spezifikation hat 1996 einen Fehler gemacht und wir sind damit konfrontiert.) Direkte Verbindungen, Buchmärkte und Anfragen aus nativen Apps kommen mit einem leeren Referer. Dieses Feld existiert nur im kombinierten Log-Format; das ursprüngliche Common Log Format endet bei Bytes-Gesendet. Referer Header. (Die HTTP-Spezifikation hat es 1996 falsch geschrieben und wir sind damit gefangen.) Direkte Verkehr, Lesezeichen und Anfragen aus nativen Apps kommen mit einem leeren Referer ein. Dieses Feld existiert nur im kombinierten Log-Format; das ursprüngliche Common Log Format endet bei den gesendeten Bytes.
Referer-Spam — falsche Referer-Header in massiven Anfragen, die versuchen, in Ihren Analysen sichtbar zu werden — war früher häufiger, ist heute jedoch fast ein Verfall. Dennoch lohnt es sich, diese aus Ihren Aggregatstatistiken zu filtern.
9. User-Agent — "Mozilla/5.0 (Windows NT 10.0; Win64; x64)…"
Die Identifikation des Clients. User-Agents sind leicht zu fälschen, daher behandeln Sie dies als Hinweis, nicht als Tatsache. Legitime Webkrawler identifizieren sich meist ehrlich: Googlebot/2.1 (+http://www.google.com/bot.html), Bingbot/2.0. Scrapers, die Browser simulieren, senden die vollständige Mozilla/5.0 Chrome-Kette. Curl sendet curl/8.x außer jemand überschreibt es mit -A.
Muster, die zu beobachten sind: identische User-Agent-Zeichen, die gleichzeitig auf denselben Endpunkten mit Maschinen-Geschwindigkeit auftreten, oder ein User-Agent, das sich als iOS Safari ausgibt, aber Anfragen in einem Muster macht, das kein menschlicher Browser machen würde (keine Bilder, keine CSS, sequentielle Produktseite-Krawling).
Muster, die in jedem Log auftauchen
Die Vulnerabilitäts-Scan
Ein einzelner IP-Adresse oder ein kleiner Subnetz, das Dutzende von Pfaden in schneller Folge anfordert: /.env, /wp-login.php, /phpmyadmin, /admin/config.yml, /.git/config. Alle geben 404 zurück. Dies ist ein automatischer Scanner, der eine Liste durchläuft, kein gezieltes Angriff. Sie laufen ständig gegen alle öffentlichen IPs.
Die richtige Frage ist nicht „warum scannen sie mich“ — sondern „gab es unter diesen Pfaden einen 200 zurück?“. Wenn /.env auf Ihrem Server 200 zurückgibt, ist das das echte Problem.
# Check if any sensitive paths actually returned 200
grep -E '"(GET|POST) /(wp-login\.php|\.env|\.git/config|phpmyadmin|admin)' access.log | awk '$9 == 200'
Kredenz-Stealing
Hochfrequente POST-Anfragen an Ihr Login-Endpunkt, fast alle mit 401, aus einer verteilten Menge von IP-Adressen. Das Kennzeichen ist das Muster: gleicher Endpunkt, konstanter Antwortinhalt (die Fehlerseite), viele verschiedene Quell-IPs, die denselben ASN teilen. Die Antwortzeiten sind ebenfalls konstant — automatisierte Anmeldesuchen laufen mit konstanter Geschwindigkeit, um Rate-Limiting zu vermeiden.
# Count POST /login attempts with 401 status by source IP
awk '$6 == "\"POST" && $7 == "/api/login" && $9 == "401" {print $1}' access.log \
| sort | uniq -c | sort -rn | head -20
Der 404-Sprung nach einer Bereitstellung
Sie bereiten eine neue Version bereit. 404-Sprünge steigen. Alte Links in E-Mails, Buchmärkten und externen Seiten zeigen auf URLs, die nicht mehr existieren. Das ist normal — aber wenn die 404-Sprünge auf URLs auftauchen, die sollten in der neuen Version existieren, ist das eine Routing-Regression. Vergleichen Sie die 404-Pfade mit Ihren Route-Definitionen.
Langsame Antwortkonzentration
Das Standard-Log-Format enthält keine Antwortzeit. Sie müssen es hinzufügen: In Apache fügen Sie %D (Mikrosekunden) zu Ihrer LogFormat; in Nginx fügen Sie $request_time zu Ihrer log_format Block hinzu. Sobald Sie es haben:
# Nginx: show requests slower than 3 seconds (request_time in last field)
awk '{if ($NF+0 > 3) print $0}' /var/log/nginx/access.log | head -20
Wenn langsame Anfragen in einem bestimmten Zeitfenster konsolidiert sind, ist das eine Konfliktsituation — ein Cron-Job, ein Batch-Prozess oder eine Sicherung, die die Datenbank belastet. Wenn ein bestimmter Pfad konstant langsam ist, unabhängig von der Zeit, ist das eine langsame Abfrage oder eine blockierende I/O-Aufruf, der profilierbar ist.
Ein Incident aus den Logs debuggen
Die Zugriffslog ist eine Zeitachse. Wenn ein Benutzer berichtet, dass „etwas um 15 Uhr kaputt gegangen ist“, tun Sie folgendes:
- Filtern auf das Zeitfenster 14:50–15:10
- Suchen Sie nach dem ersten 5xx — das ist der Zeitpunkt, an dem es begann
- Prüfen Sie, was in den Minuten davor geschah: gab es eine Bereitstellung? Eine Konfigurationsänderung? Eine Zertifikat-Neuinstallation?
- Prüfen Sie, welche Pfade 5xx erhalten — ist es alles oder nur ein Endpunkt?
- Prüfen Sie die Bytes-Gesendet bei erfolgreichen Antworten vor und nach dem Zeitpunkt — gab es etwas, das plötzlich abgeschnitten wurde?
Einige Fehlermuster, die zu kennen sind:
- 502-Sprung — Ihr upstream ist abgestürzt (App-Server-Krach, Verbindungspool ausgelaufen, Datenbank ist abgestürzt). Die 502s beginnen zu einem genauen Zeitpunkt.
- Umleitungsschleife — 301/302 von derselben IP an denselben Pfad wiederholt. Meistens eine falsche HTTPS-Redirect-Konfiguration oder ein Cloudflare-SSL-Einstellung, die mit der App-Redirect-Logik konfliert.
- 200 mit null Bytes — Status 200, aber Bytes-Gesendet ist 0 oder
-. Ihre App hat den Request akzeptiert, hat eine Exception aufgegriffen und hat eine leere Antwort zurückgegeben. Klassisches Beispiel für unverarbeitete Fehler. - 413-Sprung — Clients senden Anfragen mit Körperinhalten über Ihre Grenze. Entweder ist Ihre Grenze zu niedrig für den Anwendungsfall oder jemand testet Upload-Vulnerabilitäten.
Wenn Sie mit Logs in mehreren Formaten arbeiten — Apache Common, Apache Combined, Nginx Standard, benutzerdefinierte Formate — die Zugriffslog-Formatter können die Felder parsen und annotieren, sodass Sie nicht jedes Mal mental die Feldpositionen abgleiten müssen, wenn Sie zwischen Servern wechseln.
Log-Verwaltung, die Sie nicht einrichten werden
- Log-Rotation —
logrotatekonfiguriert, um täglich zu rotieren, zu komprimieren und 14–30 Tage zu speichern. Ohne diese wächstaccess.logbis der Speicher voll ist. Das passiert im Produktionsumfeld. - Zentrale Logging — Sobald Sie mehr als einen Server haben, ist das Tailen einzelner Log-Dateien nicht skalierbar. Senden Sie sie an Loki + Grafana, Elasticsearch oder ein verwaltetes Dienst. Ein strukturiertes JSON-Log-Format macht die Abfrage viel einfacher als das Parsen von CLF mit awk.
- Zugriffskontrolle auf rohe Logs — Log-Dateien können Parameter mit Tokens, Benutzer-Personal-Informationen (PII) und internen Pfaden enthalten. Machen Sie sie nicht weltlesbar. Seien Sie bewusst über die Log-Verweilzeit, wenn Sie unter GDPR oder ähnlichen Vorschriften stehen.
- Sensible Query-Parameter nicht protokollieren — Wenn Ihre App Authentifizierungstoken oder Passwörter als URL-Parameter akzeptiert (es sollte nicht sein, aber manche Legacy-APIs tun es), filtern Sie sie auf Log-Ebene, bevor sie auf die Festplatte gelangen.
Erweiterungen installieren
IO-Tools zu Ihrem Lieblingsbrowser hinzufügen für sofortigen Zugriff und schnellere Suche
恵 Die Anzeigetafel ist eingetroffen!
Anzeigetafel ist eine unterhaltsame Möglichkeit, Ihre Spiele zu verfolgen. Alle Daten werden in Ihrem Browser gespeichert. Weitere Funktionen folgen in Kürze!
Unverzichtbare Tools
Alle Neuheiten
AlleAktualisieren: Unser neuestes Werkzeug wurde am Juni 10, 2026 hinzugefügt
