HTTP 502 und 503 entlang des Requestwegs analysieren

Was die beiden Statuscodes aussagen

Der Status 502 bezeichnet nach RFC 9110 einen Gateway- oder Proxyfehler bei einer Antwort aus einem vorgelagerten Dienst. 503 beschreibt eine vorübergehende Nichtverfügbarkeit, beispielsweise durch Überlast oder Wartung. Die Website kann denselben Status jedoch über unterschiedliche Komponenten ausliefern. Ein vorgeschalteter Dienst, der Webserver oder die Anwendung selbst kann beteiligt sein. Der sichtbare Code ist deshalb der Ausgangspunkt einer Untersuchung. Er enthält keine eindeutige Diagnose wie „zu wenig RAM“ oder „Plugin defekt“.

Ein Browserbild allein reicht für die Einordnung nicht. Notieren Sie die vollständige URL ohne sensible Parameter, den Zeitpunkt samt Zeitzone, die HTTP-Methode und die beobachtete Antwort. Prüfen Sie, ob nur eine Aktion betroffen ist oder auch rein lesende Seitenaufrufe scheitern. Ein Dateiupload, eine Anmeldung und eine Startseite führen unterschiedliche Arbeitsschritte aus. Halten Sie außerdem fest, aus welchem Netz und über welche Adressfamilie der Fehler beobachtet wurde. So kann ein nur über IPv6 sichtbares Problem von einem allgemeinen Anwendungsfehler getrennt werden.

Die Fehlergrenze vor einer Änderung suchen

Skizzieren Sie den tatsächlichen Requestweg der Domain. Unter Plesk kann die Verarbeitung abhängig von den konkreten Einstellungen über nginx, Apache und einen PHP-Handler laufen. Eine allgemeine Plattformbeschreibung ist kein Beleg für diesen Host. Prüfen Sie die Domainkonfiguration und die zugehörigen Logs. Der Ratgeber zum nginx-Apache-Requestweg unterstützt die Einordnung. Wenn ein vorgeschalteter Proxy die Fehlermeldung erzeugt, verdient die Verbindung zum nächsten Dienst Aufmerksamkeit. Wenn die Anwendung selbst 503 setzt, ist der Schwerpunkt anders.

Prüfen Sie unabhängige Pfade: eine statische Datei, eine einfache dynamische Seite und die konkret betroffene Aktion. Antworten statische Inhalte weiterhin, ist die komplette Netz- und Webserverspur weniger wahrscheinlich als eine auf dynamische Verarbeitung begrenzte Störung. Das bleibt eine Arbeitshypothese, kein Beweis. Ein Cache kann dynamische Inhalte als gespeicherte Datei beantworten und das Bild verschieben. Dokumentieren Sie deshalb, ob der getestete Pfad gecacht sein kann. Eine gezielte bekannte Testseite ist hilfreicher als zufälliges Neuladen verschiedener URLs.

Zeiten und Anfragen in Logs zusammenführen

Die Plesk-Dokumentation zum Domain-Logbrowser beschreibt den Zugang zu Websiteprotokollen. Wählen Sie zuerst einen engen Zeitraum um den bekannten Fehler. Suchen Sie nach derselben URL, Methode und gegebenenfalls einer vorhandenen Requestkennung. Access-Log und Error-Log liefern unterschiedliche Informationen. Das eine zeigt den beobachteten Anfrageabschluss, das andere konkrete Fehlerereignisse. Ein Log ohne passenden Treffer beweist nicht automatisch, dass die Anfrage nie dort war; Filter, Rotation und Zeitdarstellung können die Suche beeinflussen.

Bewahren Sie relevante Originalzeilen mit ihrem Kontext auf. Eine allein kopierte letzte Zeile kann den vorausgehenden Verbindungsfehler oder eine vorherige Änderung auslassen. Vermeiden Sie zugleich unbeschränkte Logexporte. URLs, Cookies oder Token können sensible Angaben enthalten. Für eine Supportübergabe genügt häufig ein kleiner bereinigter Ausschnitt mit Domain, Zeitfenster und dem genauen Symptom. Die Bereinigung darf technische Bedeutungen nicht verfälschen. Markieren Sie ersetzte Werte erkennbar, damit ein fehlender Parameter nicht mit einer tatsächlich leeren Angabe verwechselt wird.

Den Backendzustand kontrollieren

Wenn das Gateway den nächsten Dienst nicht erreichen kann, prüfen Sie dessen tatsächlichen Zustand. Läuft der betreffende Dienst? Lauscht er am vorgesehenen Port oder Socket? Passt der konfigurierte Pfad zum Domainhandler? Rechte und Besitzer eines Unix-Sockets können eine Verbindung verhindern, auch wenn der Prozess vorhanden ist. Veränderungen an PHP-Versionen oder Konfigurationen gehören deshalb in die Zeitleiste. Ein blindes Ändern von Rechten ist keine geeignete Diagnose. Es kann den Zugriff erweitern und zugleich die vom Verwaltungssystem erwartete Konfiguration beschädigen.

Für PHP-FPM liefert eine geschützte Statusansicht Informationen über den Pool. Die offizielle PHP-Dokumentation erläutert den Gegenstand dieser Anzeige. Falls sie in Ihrer Umgebung verfügbar ist, betrachten Sie Warteschlange und aktive Prozesse im Zusammenhang mit dem Fehlerzeitraum. Die Statusseite darf nicht öffentlich als Diagnoseseite erreichbar werden. Ein aktuell unauffälliger Pool schließt einen kurzen vergangenen Engpass außerdem nicht aus. Für sporadische Fehler sind zeitgebundene Messwerte und Logs nötig. Der PHP-FPM-Ratgeber behandelt die vertiefte Spur.

Wartung und Anwendungszustand berücksichtigen

Eine vorübergehende Sperre kann bewusst gesetzt sein. Prüfen Sie, ob gerade eine Wiederherstellung, ein Update oder eine angekündigte Wartung läuft. Plesk dokumentiert für bestimmte Restoreabläufe eine zeitweise Nichtverfügbarkeit. Eine Anwendung kann ebenfalls einen Wartungszustand ausliefern. Dann lautet die erste Frage, ob der geplante Ablauf noch läuft, abgeschlossen ist oder hängen geblieben ist. Entfernen Sie eine Sperre nicht allein deshalb, weil sie im Browser sichtbar stört. Ein zu früher Wiederzugriff kann Nutzer auf einen noch inkonsistenten Stand lassen.

Bei WordPress kommen fehlgeschlagene Änderungen, fehlerhafte Erweiterungen oder unvollständige Dateiübertragungen als Prüfspuren infrage. Halten Sie fest, welche Komponente zuletzt geändert wurde und ob die Änderung reproduzierbar mit dem Fehler zusammenfällt. Zeitliche Nähe ist ein Hinweis, aber noch keine Ursache. Prüfen Sie eine gezielte Rücknahme möglichst auf einer getrennten Kopie oder mit einem bekannten Sicherungspunkt. Der Update-Ratgeber zeigt den vorbereiteten Weg. Wahlloses Deaktivieren mehrerer Plugins erschwert dagegen die Zuordnung und kann zusätzlich Funktionen entfernen.

Überlast anhand einer Kette belegen

Überlast beschreibt ein Verhältnis zwischen ankommender Arbeit und verfügbarem Verarbeitungsspielraum. Eine hohe Anzahl Requests ist dabei nur ein Teil. Anfragen können langsam werden, weil eine Datenbank wartet, ein externer Dienst verzögert antwortet oder eine teure Aktion viele Prozesse bindet. Betrachten Sie daher Antwortdauer, Parallelität und Warteschlangen gemeinsam. Eine bloße Besucherzahl erklärt keinen Poolengpass. Auch Bots, Cronjobs und interne Aufrufe können Arbeit erzeugen. Der Kapazitätsratgeber führt die beteiligten Ressourcen zu einer nachvollziehbaren Bestandsprüfung zusammen.

Unterscheiden Sie eine echte Lastspitze von einer ineffizienten Verarbeitung. Wenn dieselbe kleine Anfrage plötzlich wesentlich länger benötigt, kann schon unveränderte Last mehr gleichzeitig belegte Prozesse verursachen. Eine Erhöhung der Workerzahl behebt dann möglicherweise keinen Engpass, sondern verschiebt ihn zur Datenbank oder zum Speicher. Prüfen Sie zunächst, welche Anfragearten die verfügbare Kapazität binden. Falls die Umgebung keine ausreichenden Messwerte bietet, dokumentieren Sie diese Grenze und vereinbaren Sie eine befristete Erhebung. Erfunden wirkende Genauigkeit schadet der Diagnose mehr als ein offener Befund.

Timeouts an ihrem Zweck prüfen

Timeouts begrenzen bestimmte Warteabschnitte. Die nginx-Referenz zum Proxy-Modul beschreibt unterschiedliche Direktiven für Verbindungsaufbau und Antwortverarbeitung. Bevor Sie einen Wert verändern, klären Sie, welcher Abschnitt tatsächlich abbricht. Ein Verbindungsproblem wird durch längeres Warten auf Antwortdaten nicht behoben. Ein legitimer längerer Vorgang kann andere Anforderungen besitzen als ein hängender Hintergrunddienst. Die passende Einstellung folgt aus dem erwarteten Verhalten und den verfügbaren Ressourcen der gesamten Verarbeitungskette.

Längere Wartezeiten können zusätzliche gleichzeitig belegte Verbindungen erzeugen. Daher gehört zu jeder Änderung ein Vorher-Nachher-Vergleich mit derselben Prüfaktion. Bewahren Sie den bisherigen Wert auf, nennen Sie die Änderungsstelle und prüfen Sie, ob Plesk die Einstellung bei einer Konfigurationsneuerzeugung übernimmt. Änderungen an generierten Dateien können später verschwinden. Verwenden Sie einen für die jeweilige Verwaltung vorgesehenen Weg. Für die Abnahme zählen weniger Fehler, passende Laufzeiten und keine neue Ressourcenverschlechterung. Ein einmalig erfolgreicher Browseraufruf nach der Änderung genügt für diese Aussage nicht.

Eine begrenzte Entlastung kontrolliert einsetzen

Während einer akuten Störung kann eine gezielte Entlastung sinnvoll sein: eine bekannte problematische Aufgabe pausieren, einen laufenden Import stoppen oder eine auffällige Anfrageart begrenzen. Voraussetzung ist eine klare Zuordnung und ein kontrollierter Scope. Die Maßnahme darf nicht versehentlich andere Kundendomains beeinflussen. In einer geteilten Hostingumgebung benötigen globale Dienständerungen die zuständige Administration. Dokumentieren Sie, welche Nutzerfunktion vorübergehend eingeschränkt wird und woran eine erfolgreiche Entlastung erkennbar sein soll. Der nächste Prüfschritt muss bereits vor der Maßnahme feststehen.

Ein Neustart kann einen blockierten Zustand kurzfristig lösen und gleichzeitig relevante Beobachtungen entfernen. Erfassen Sie deshalb vorher erreichbare Statusdaten und Fehlermeldungen, soweit der Umfang und die Dringlichkeit es erlauben. Danach prüfen Sie genau denselben betroffenen Ablauf. Melden Sie das Ergebnis präzise: „Dienst neu gestartet, konkrete Aktion wieder möglich, Ursache noch offen.“ Diese Formulierung trennt Wiederherstellung und Erklärung. Wenn der Fehler wiederkehrt, steht ein nachvollziehbarer Verlauf zur Verfügung. Ein Neustart ohne Zeit- und Scopeprotokoll macht die nächste Runde dagegen unnötig schwer.

Ein Diagnosebeispiel ohne Scheingenauigkeit

Eine Redaktion beobachtet 503 beim Speichern langer Beiträge, während die Startseite erreichbar bleibt. Im gewählten Zeitfenster liegt zugleich ein umfangreicher Import. Die Untersuchung vergleicht zunächst eine bekannte ungecachte PHP-Seite und die konkrete Speicheraktion. Der Pool zeigt während der Wiederholung wenig freien Spielraum; der Import beansprucht mehrere Prozesse. Nach dem kontrollierten Pausieren des Imports gelingt dieselbe Speicherprüfung wieder. Das belegt eine Verbindung zum Arbeitsaufkommen im beobachteten Zeitraum. Es sagt noch nicht, ob der Import unnötig teuer ist oder die Kapazität für das gewünschte Parallelverfahren fehlt.

Die nächste Aufgabe besteht deshalb aus einer getrennten Analyse des Imports und einer Kapazitätsentscheidung. Möglicherweise genügt ein anderer Zeitplan; möglicherweise muss die Verarbeitung effizienter werden. Eine pauschale Empfehlung für mehr Arbeitsspeicher wäre ohne weitere Daten verfrüht. Das Beispiel zeigt, wie eine kleine Prüfkette zu einer konkreten Betriebsentscheidung führt. Die Beobachtungen sollten keine erfundene Testhistorie des Portals darstellen: Solche Szenarien sind gedankliche Arbeitsbeispiele, die Leser auf ihre eigene Umgebung übertragen und dort tatsächlich nachweisen müssen.

Die Übergabe an den Support vorbereiten

• Domain, Zeitraum, Zeitzone und betroffene Aktion exakt angeben.
• Statische und dynamische Prüfpfade samt Cachegrenze dokumentieren.
• Statuscode, erzeugende Schicht und verfügbare Originalmeldungen beilegen.
• Änderungen, Importe und Wartungszustände in einer kurzen Zeitleiste nennen.
• Bereits erfolgte Maßnahmen mit ihren tatsächlichen Ergebnissen festhalten.
• Nächste Prüfung und noch offene Ursachenspuren ausdrücklich benennen.

Verknüpfen Sie diese Angaben mit dem Incident-Runbook und einem Alarm aus der Überwachung. Ein guter Bericht macht erkennbar, an welcher Grenze die vorhandenen Zugriffe enden. Wenn nur der Anbieter einen zentralen Dienst prüfen kann, bekommt er eine eng eingegrenzte Frage. So kann die Unterstützung an der richtigen Stelle beginnen, während der Betreiber weiter den Nutzerzustand kontrolliert und die erfolgte Wiederherstellung anhand derselben Aktion abnimmt.

Fehlerantworten im Cache erkennen

Prüfen Sie bei scheinbar widersprüchlichen Ergebnissen, ob eine gespeicherte Antwort beteiligt ist. Eine ältere Fehlerseite kann weiter sichtbar bleiben, obwohl der Backendzustand bereits korrigiert wurde. Umgekehrt kann ein gespeicherter Erfolg einen aktuellen dynamischen Defekt verdecken. Nutzen Sie den für Ihre konkrete Cacheebene vorgesehenen Prüfweg und notieren Sie, welcher Aufruf bewusst ungecacht war. Ein zufällig veränderter Parameter ist nicht in jeder Konfiguration ein zuverlässiger Cacheausschluss. Entscheidend bleibt die dokumentierte Regel des tatsächlich eingesetzten Systems.

Nach einer Entlastung oder Korrektur vergleichen Sie deshalb einen passenden öffentlichen Aufruf mit der betroffenen dynamischen Handlung. Wenn beide erfolgreich sind, halten Sie Cachezustand und Zeitpunkt fest. Prüfen Sie bei bestehenden Fehlern vor einer erneuten Änderung, ob noch derselbe Auslöser vorliegt. Ein neuer Befund mit ähnlicher Fehlermeldung kann eine andere Grenze betreffen. Diese kurze Kontrolle verhindert, dass eine zuvor hilfreiche Maßnahme aus Gewohnheit wiederholt wird, obwohl sie zum aktuellen Zustand nicht mehr passt. Sie hilft ebenfalls, eine Supportantwort präzise zu bewerten und die Wiederherstellung als eigenständigen neuen Nachweis zu dokumentieren.