Network Error Logging

Network Error Logging (NEL) meldet die Requests, die im Browser deiner Besucher scheitern: DNS-Fehler, abgelehnte Verbindungen, Timeouts, TLS-Fehler und 4xx- oder 5xx-Antworten.

EinrichtenCopy Anchor Link

Zwei Response-Header auf deinem Origin schalten die Reports ein. Header, Server-Beispiele, Prüfung und Fallen stehen im Guide Network Error Logging einrichten.

Die Seite Network Error LoggingCopy Anchor Link

Die Seite liegt in der Sidebar unter Fehler → Network Error Logging, unter /errors/nel. Sie hat drei Tabs, der Tab steht in der URL.

• Übersicht: die HTTP-Fehler des Servers, 5xx oben, 4xx darunter. Die Kacheln für 5xx und 4xx zeigen zuerst die Reports, die betroffenen Besucher daneben. Überall sonst steht Betroffene Besucher vorn, mit dem Anteil an allen Besuchern. Das Diagramm stapelt Nach Klasse oder Nach Code.
• Wo sie scheitern: eine Karte pro Dimension, alle auf einmal. Statuscodes, Seiten, Serveradressen, Länder, Netzwerke, Seiten und Hosts, Geräte, Browser, OS, Traffic und Versionen, sobald ein Browser gefiltert ist.
• Seiten und Hosts ist zugleich der Setup-Check. Jede Site zeigt ihren letzten Report.
• Verbindungsfehler: standardmäßig zugeklappt. Jeder Typ wird mit seinem üblichen Niveau verglichen, markiert werden ein kaputtes Zertifikat und ein Anstieg bei abgelehnten Verbindungen, Timeouts oder unbekannten Hosts. Jeder Typ hat sein eigenes + und -.
• Pfade: erst die Hosts, darin jeweils ihre Pfade.
• Reports: eine Tabelle aller NEL-Reports mit Zeit, Typ, Status, Zeit bis zum Fehler, Request, Seite, Gerät, Browser, Besucher und Land. Sie zeigt 25, 50 oder 100 pro Seite, sortiert nach jeder Spalte und lässt sich als Markdown oder CSV kopieren. Gruppieren kannst du nach Besucher, Seite oder Request-URL, nach den meisten Reports oder den neuesten; eine Gruppe klappt direkt zu ihren Reports auf. Eine Zeile öffnet alle gespeicherten Felder, und die Adresse verlinkt darauf.

Filtern geht wie auf den anderen Seiten: + neben einem Wert filtert darauf, - schließt ihn aus, und die Lupe öffnet die Reports der Zeile. Die Kacheln 5xx und 4xx filtern eine ganze Statusklasse. Die Filter der Seite (Status, Fehlertyp, Host, Pfad, Seite, Serveradresse) stehen im Filter-Panel unter Nur auf dieser Seite und bleiben in der URL. Typ hinzufügen bietet jeden bekannten Fehlertyp an, die des Zeitraums zuerst. Abgebrochene Ladevorgänge sind ausgeblendet, auf der Seite und in der Journey eines Besuchers, jeweils mit einem Schalter zum Einblenden.

Die Journey eines Besuchers unter Visitors zeigt seine NEL-Reports zwischen den Seitenaufrufen, in zeitlicher Reihenfolge und jeweils als solche markiert.

KlassenCopy Anchor Link

Jeder Report hat eine Klasse, nel_class, abgeleitet aus seinem Typ. In Klammern steht das Label im Dashboard.

FehlertypenCopy Anchor Link

Das Dashboard zeigt einen lesbaren Namen, in den Details jedes Reports steht der Typ des Browsers. Jeder Typ hat die Klasse connection, sofern seine Zeile nichts anderes sagt. Wiederholt heißt, dass Chromium den Request nach dem Report erneut schickt.

Server hat geantwortetCopy Anchor Link

NamensauflösungCopy Anchor Link

VerbindungCopy Anchor Link

TLSCopy Anchor Link

HTTP/2 und HTTP/3Copy Anchor Link

Antwort nicht lesbarCopy Anchor Link

Besucher und UnbekanntesCopy Anchor Link

Die W3C-Spezifikation nennt außerdem dns.unreachable, http.protocol.error und http.failed, die Chromium nie schickt. fastmon verwirft ok, den Report eines erfolgreichen Requests, und sxg.*, Reports zu Signed Exchanges.

Einen Report lesenCopy Anchor Link

• Jede Site hat ein Grundrauschen aus abandoned, tcp.reset, tcp.closed, tcp.aborted, h2.ping_failed und unknown. Besucher gehen, während noch etwas lädt, und Mobilfunknetze verlieren Verbindungen.
• Ein plötzlicher Anstieg von tcp.refused oder tcp.timed_out heißt, dass der Server keine Verbindungen mehr annimmt oder beantwortet.
• unknown hat keine Ursache. Das Report-Format hat kein Feld für Chromiums Fehlercode. Ein Netzwechsel, ein vom HTTP/2-Server abgelehnter Request und ein gescheiterter QUIC-Handshake landen alle als unknown.
• Ein Report beweist nicht, dass ein Besucher den Fehler gesehen hat. Bei Typen mit Wiederholung meldet Chromium zuerst und schickt den Request dann erneut, oft mit Erfolg. Scheitert auch die Wiederholung, kommt ein weiterer Report, ein Fehler kann also mehrere Reports hinterlassen.
• Resets, geschlossene und abgebrochene Verbindungen und leere Antworten wiederholt Chromium nur auf einer wiederverwendeten Verbindung, die noch keine Header bekommen hat. Jeder 4xx- und 5xx-Status außer 408 und 421 kam so beim Browser an, wie er gemeldet ist.

Sites hinter mehreren AdressenCopy Anchor Link

Zwei Ingress-Knoten, ein CDN oder IPv4 neben IPv6 legen mehrere Adressen hinter einen Namen. Der Browser speichert die Policy zusammen mit der Adresse, von der sie kam. Fällt eine Adresse aus, schickt nur noch die andere die Policy, und die Fehler der toten Adresse kommen als dns.address_changed ohne Status und Dauer an.

• Steigt die Klasse downgraded auf so einer Site, fällt eine Adresse aus.
• server_ip nennt die Adresse, an die ein Request ging. Die Karte Serveradressen oder eine Aufschlüsselung der downgraded-Reports nach server_ip zeigt die ausgefallene.
• Eine Fehlerseite ohne Header von der anderen Adresse geht verloren, der Ingress muss sie also auf jede Antwort setzen. Prüf das an einem 404, wie unter Prüfen.

Gespeichert wird nur eine öffentliche server_ip. Siehe Datenschutz → NEL-Reports.

GrenzenCopy Anchor Link

• Nur Chromium-Browser. Jede Zahl ist eine Untergrenze.
• Besucherzahlen brauchen store_stitch. Eine Site ohne zählt bei den Reports mit, nicht aber bei Betroffene Besucher, und die Seite nennt sie.
• Eine kleinere failure_fraction macht die Besucherzahl zur Untergrenze.
• Ein Netzwechsel trennt den Besucher. Ein Report bekommt seine Besucher-ID beim Upload, ein Report aus einem neuen Netz passt also nie zu den Seitenaufrufen davor.
• Die ID rotiert täglich. Ein Report, der nach der Rotation hochgeladen wird, kann bei einem neuen Besucher landen.

APICopy Anchor Link

Alle drei Routen nehmen dieselben filters, darunter error_type, nel_class, status_code_range, server_ip, host, path und page_url samt exclude. Jede andere Analytics-Route lehnt diese Filter mit 422 ab.

Die Zählungen sind mit 1 / failure_fraction gewichtet, einzelne Reports nicht. Ohne error_type-Filter zählt jeder Typ mit, auch abandoned. Visitor-Detail und Checkout-Journeys liefern nel_reports neben pages und events: fehlt das Feld, wurde nicht nachgesehen, [] heißt keine Reports.