Automatische Benachrichtigungen bei 4xx-HTTP-Status

Dieser Artikel erklärt, warum Sie Benachrichtigungen erhalten, wenn eine bei uns gehostete URL mit einem 4xx‑HTTP‑Status antwortet, und welche ersten Maßnahmen Sie ergreifen können. Wir überwachen hierfür die Status-Codes: 400, 401, 403, 404. Sie erhalten eine automatische Benachrichtigung zum Zeitpunkt der ersten Beobachtung des entsprechenden Status-Codes, und anschließend dann alle 48 Stunden.

Hintergrund

4xx‑Antworten entstehen typischerweise durch fehlerhafte Anfragen (Client‑Verhalten), fehlende Ressourcen oder durch absichtliche Einstellungen (z. B. ACLs). Als Hosting‑Provider können wir solche kundenseitigen Konfigurationen nicht ohne Ihre Zustimmung ändern, da dies Ihre Einstellungen außer Kraft setzen würde. Gerne unterstützen wir Sie jedoch mit Infrastrukturprüfungen (DNS, TLS, Load‑Balancer) und stellen auf Wunsch Log‑Auszüge bereit.

Warum maxcluster in der Regel nicht eigenständig eingreift

Es gibt verschiedene Gründe, warum wir in der Regel nicht eigenständig eingreifen. Einige Beispiele:

• Client‑seitige Fehler (z.B. fehlerhafte Requests, fehlende Authentifizierung) müssen in der Regel vom Client korrigiert werden.
• Fehlende "Ressourcen": Ein 404 bedeutet häufig, dass die angefragte Webseite, Datei oder der Pfad nicht existiert. Mit "Ressourcen" sind hier Webseiten, Dateien oder Pfade gemeint, die in Ihrer Verantwortung liegen.
• Gewollte Konfigurationen (z.B. ACLs, Dateirechte, Applikations‑Policies) sind bewusste Einstellungen Ihrerseits; ein Eingriff würde diese Absicht aufheben.

Aufbau und Inhalt der automatischen Benachrichtigung

Sie erhalten von uns eine automatisch generierte Benachrichtigung. Diese ist wie folgt aufgebaut und soll Ihnen einen schnellen Überblick über den erkannten Fehlerzustand geben, damit Sie gegebenenfalls zeitnah reagieren können.

• Betreff: C-xxx - Fehler beim Abruf Ihrer Webseite - Status-Code 4xx erkannt
• Versandzeitpunkt: Zeitpunkt der Beobachtung.
• Keine Log‑Excerpts in der automatischen Mail; Log‑Auszüge erhalten Sie auf Support‑Anfrage.

Beispiel‑Benachrichtigung

Beispielbild E-Mail für Status 401:

Ursachen für einen 4xx-HTTP-Status und wann maxcluster helfen kann

Im Folgenden finden Sie eine Übersicht der von uns überwachten 4xx-HTTP-Statuscodes und deren Ursache:

• 400 Bad Request: Ungültige Anfrage (falsches Encoding, zu große Header/Body, fehlerhafte Parameter). Die Ursache ist zumeist der Client oder eine fehlerhafte Proxy‑Weitergabe.
• 401 Unauthorized: Fehlende oder ungültige Authentifizierungsdaten (abgelaufene Tokens, fehlende Header). Zugriffsbeschränkungen per Passwortschutz, .htaccess Datei oder Probleme mit dem Identity‑Provider können die Ursache sein.
• 403 Forbidden: Zugriff verweigert trotz Authentifizierung (ACLs, Dateisystemrechte, serverseitige Policys). Häufig eine beabsichtigte Kundeneinstellung.
• 404 Not Found: Ressource nicht vorhanden (falscher Pfad, verschobene Artefakte, Routing/Rewrite‑Regeln).

Wir prüfen auf Wunsch Infrastrukturkomponenten (DNS, TLS, Load‑Balancer, Proxy) und analysieren Webserver-Regelwerke, Log‑Auszüge stellen wir auf Support‑Anfrage bereit. Änderungen an Ihrer Konfiguration führen wir nur nach Ihrer ausdrücklichen Freigabe durch.

Konkrete Prüf‑ und Troubleshooting‑Schritte

Folgende Schritte können Sie bereits eigenständig für eine erste Prüfung und Fehlersuche durchführen.

Allgemein: Replizieren Sie die Anfrage mit curl und prüfen Sie Header, Response‑Body und Status. Eine Beschreibung, um alternativ die Browser‑Developer‑Console zu nutzen, finden Sie weiter unten.

• 400 - schnelle Checks

1. Replizieren Sie die Anfrage mit curl:
2. bash curl -i -X GET 'https://example.de/pfad?param=wert' -H 'User-Agent: curl'
3. Prüfen Sie Encoding, URL‑Länge und Header‑Größen sowie, ob ein Proxy/Load‑Balancer Header verändert.
4. Falls ein Reverse‑Proxy oder Cache vorgelagert ist: Regeln und Rewrite‑Einstellungen prüfen.

• 401 - schnelle Checks

1. Prüfen Sie den Auth‑Header (z. B. Authorization: Bearer <token>).
2. Überprüfen Sie Token‑Gültigkeit/Expiry, Identity‑Provider‑Logs und die Server‑Uhrzeit (Clock Drift).
3. Test mit curl (Auth‑Header simulieren):
4. bash curl -i -H 'Authorization: Bearer <TOKEN>' 'https://example.de/geschuetzt'
   

• 403 - schnelle Checks

1. Prüfen Sie ACLs, Dateisystemrechte und Anwendungspolicies.
2. Prüfen Sie WAF‑Logs; eine WAF kann legitime Anfragen blockieren.
3. Bei vorgelagerten CDN: Prüfen Sie CDN-Zugriffsregeln, Edge‑Rules und Cache/Purge-Einstellungen (CDN-Konfiguration liegt in Ihrer Verantwortung).

• 404 - schnelle Checks
  1. Prüfen Sie Pfad/Route, Deployment‑Artefakte und Dateisystempfade.
  2. Überprüfen Sie Rewrite-/Redirect‑Regeln und Virtual‑Host‑Konfiguration.
  3. Leeren Sie gegebenenfalls den CDN‑Cache, falls ein CDN verwendet wird (CDN‑Konfiguration prüfen Sie bitte selbst).

Alternative: Browser‑Developer‑Console

Statt curl können Sie die Developer‑Tools Ihres Browsers verwenden, um eine Anfrage interaktiv nachzuvollziehen und zusätzliche Infos (Headers, Payload, Cookies, Timing) zu sehen.

• Öffnen: Drücken Sie F12 oder Ctrl+Shift+I (Cmd+Opt+I auf macOS) und wechseln Sie zum Reiter Network.
• Einstellungen: Aktivieren Sie Preserve log und Disable cache (während DevTools offen), damit die Anfrage vollständig protokolliert wird.
• Reproduzieren: Führen Sie die Aktion im Browser aus (Seite neu laden oder Formular absenden). Filtern Sie ggf. nach Host/Pfad oder XHR.
• Auswahl: Klicken Sie auf die betroffene Anfrage und prüfen Sie:
  • Status: HTTP‑Statuscode (z. B. 400).
  • Headers: Request URL, Method, Query String Parameters, Request Headers (z. B. Content-Type, Authorization, Cookies).
  • Payload / Form Data: Gesendete Body‑Daten (JSON, FormData), Encoding und Größe.
  • Response / Preview: Antwort-Inhalt und eventuelle Fehlermeldungen vom Server.
  • Timing: Dauer und einzelne Phasen (DNS, Connect, TTFB) zur Einordnung von Netzwerkproblemen.
• Nützliche Aktionen:

• • Rechtsklick → Copy → Copy as cURL (oder Copy as fetch) – so können Sie die exakt gleiche Anfrage per Shell oder Script erneut ausführen.
  • In Chrome: Rechtsklick → Edit and Resend (bei unterstützten Requests) zum schnellen Anpassen und erneuten Senden innerhalb der DevTools.
  • In Firefox: Rechtsklick → Resend / Edit and Resend (ähnlich verfügbar).

Quick‑Tipps 

• Prüfen Sie Content-Type und ob das Request‑Body‑Encoding mit dem vom Server erwarteten Format übereinstimmt. 
• Achten Sie auf ungewöhnlich große Header oder Cookies (können zu Code 400 führen).
• Wenn die DevTools einen Proxy/Redirect zeigt, folgen Sie der Redirect‑Kette und prüfen Sie Zwischenantworten. 
• Kopieren Sie die Anfrage als cURL, um sie außerhalb des Browsers (mit curl -i ...) zu reproduzieren und Header/Body gezielt zu ändern.

Was wir liefern, wenn Sie uns einschalten

Bei folgenden Punkten können wir Sie unterstützen oder Informationen bereitstellen:

• Infrastruktur‑Checks (DNS, TLS, Load‑Balancer, Proxy) und Erklärung gefundener Probleme.
• Webserver‑Log‑Analysen und Hinweise auf Access‑Regeln, die Anfragen beeinträchtigen.
• Auf Anfrage: Log‑Auszüge mit relevanten Zeitstempeln (werden nicht automatisch in Mails versendet).

Allgemeiner Hinweis für geplante Wartungsfenster

Bitte informieren Sie uns frühzeitig über von Ihnen geplante Wartungsfenster, nicht nur wenn es dadurch zu beabsichtigten Einschränkungen in der Verfügbarkeit Ihrer Website kommen kann. 

Viele Applikationen zeigen zwar während eines Wartungsmodus eine normale Webseite als Hinweis an, verbinden diese aber mit HTTP-Codes, die nicht dem normalen Aufruf (200/301/302) entsprechen. Zumeist wird dabei ein 503 (Service Unavailable) ausgegeben.

Die Kenntnis über Ihr Wartungsfenster hilft uns, gemeinsam mit Ihnen zielgerichteter zu agieren. 

Glossar

• 200 – OK: Direkte Bearbeitung erfolgreich
• 301 – Moved Permanently: Hinweis auf eine dauerhafte Verlegung an einen neuen Ort, der im „Location“-Header mitgeteilt wird
• 302 – Found (Moved temporarily): Die angefragte Ressource steht unter dem im „Location“-Header angegebenen Ort bereit, der eigentliche Aufruf bleibt aber gültig.
• 4xx – Sammlung von HTTP-Status-Codes im Bereich 400–499, die auf Client-seitige Fehler hinweisen.
• 400 – Bad Request: Ungültige Anfrage (fehlerhafte Syntax, falsches Encoding, zu große Header/Body).
• 401 – Unauthorized: Fehlende oder ungültige Authentifizierungsdaten (z. B. fehlender oder abgelaufener Token).
• 403 – Forbidden: Zugriff verweigert trotz gültiger Authentifizierung (ACLs, serverseitige Policies).
• 404 – Not Found: Angeforderte Ressource nicht vorhanden oder Pfad falsch.
• ACL (Access Control List): Regeln, welche Zugriffsrechte für Ressourcen festlegen.
• CDN (Content Delivery Network): Netz aus Edge‑Servern zur Auslieferung und Zwischenspeicherung von Inhalten
• cURL: Kommandozeilenwerkzeug zum Erzeugen und Testen von HTTP-Anfragen.
• Developer Console / DevTools: Browser-Werkzeug zum Debugging von Netzwerk, JavaScript und Performance.
• Edge-Server: Ein Server „am Rand“ des Netzwerks, nahe bei den Nutzerinnen und Nutzern. Er liefert oft zwischengespeicherte Inhalte schneller aus und entlastet den Ursprungsserver; er kann dabei Antworten oder Weiterleitungen beeinflussen.
• Header: HTTP-Metadaten einer Anfrage/Antwort (z. B. Content-Type, Authorization, Cookies).
• HTTP-Status-Code: Der Server teilt dem Client mittels des HTTP-Status-Codes mit, ob und wie eine Anfrage beantwortet werden konnte.
• Payload / Request Body: Gesendete Nutzlast bei POST/PUT/PATCH‑Anfragen (JSON, FormData, etc.).
• Ressource: In diesem Kontext das Ziel der Anfrage – z. B. eine Webseite, eine Datei, ein Bild oder ein API-Endpunkt. Wenn die Ressource nicht vorhanden ist, liefert der Server häufig einen 404.
• Reverse Proxy: Vermittler zwischen Client und Backend (kann Header verändern, Load‑Balancing übernehmen).
• TTFB (Time To First Byte): Zeit bis zum Empfang des ersten Bytes der Antwort - wichtig für Performance-Analysen.
• WAF (Web Application Firewall): Filter/Firewall zur Erkennung und Blockierung schädlicher HTTP-Anfragen.