502 Bad Gateway Fehler: Was er bedeutet und wie Sie ihn beheben

Was ist ein 502 Bad Gateway Fehler?

Ein 502 Bad Gateway ist ein HTTP Statuscode. Er meldet, dass ein Server in der Rolle eines Gateways oder Reverse Proxys vom dahinterliegenden Upstream Server eine ungültige Antwort erhalten hat. Ihr Browser erreicht die Seite also, doch die Eingangstür bekommt von der Anwendung keine brauchbare Antwort.

Wir sind ein Team für digitales Marketing und Webentwicklung, kein Hostinganbieter. Die technischen Erklärungen beruhen daher auf MDN, RFC 9110 und der offiziellen Dokumentation von nginx, PHP und Cloudflare. Unser Ziel ist einfach: Wenn Ihre Seite einen 502 zeigt, sollen Sie wissen, wo der Fehler entsteht und was Sie der richtigen Stelle mitteilen.

Im Alltag begegnet Ihnen der 502 Bad Gateway Fehler als "502 Bad Gateway", "Bad Gateway" oder "HTTP Error 502". Manchmal hilft ein Neuladen, manchmal dauert der Fehler dagegen Stunden, deshalb brauchen Sie einen Plan. Dieser Leitfaden behandelt die Ursachen, die Reihenfolge der Diagnose und getrennte Schrittlisten für jede Rolle.

Wer muss einen 502 Fehler beheben: Besucher, Websitebetreiber oder Serveradministrator?

In der Praxis liegt die Lösung meist auf der Serverseite. MDN beschreibt den Statuscode als Serverfehler, den Betreiber und Administratoren untersuchen sollten. Allerdings gibt es eine Ausnahme: Läuft die Seite bei anderen Besuchern und Sie nutzen ein VPN oder ein eigenes Netzwerk Setup, kann das Problem bei Ihnen liegen.

Die drei Rollen lassen sich so trennen:

• Besucher: Laden Sie die Seite neu, schalten Sie das VPN ab, probieren Sie ein anderes Netz und informieren Sie den Betreiber.
• Websitebetreiber: Prüfen Sie die letzte Änderung, Plugins, Theme und CDN Einstellungen, und melden Sie sich dann mit den richtigen Angaben beim Hoster.
• Serveradministrator: Kontrollieren Sie die Verbindung zwischen Reverse Proxy und Anwendung, den Dienststatus, die Logs und die Ressourcenlimits.

Beim Shared Hosting liegt die Administratorrolle nämlich beim Anbieter. Wenn Sie also cPanel ohne Root Zugriff nutzen, richten sich die Befehle weiter unten an Ihren Hoster und nicht an Sie.

Wie läuft eine Anfrage zwischen Reverse Proxy und Upstream ab?

Bei einer modernen Website endet eine Anfrage daher selten auf einer einzigen Maschine. Der Besucher erreicht zunächst ein CDN oder direkt den Webserver. Eine Eingangstür wie nginx oder Apache reicht die Anfrage dann an PHP FPM, Node.js oder einen anderen Anwendungsserver weiter. Diese hintere Schicht heißt Upstream.

Also entsteht der 502 genau bei dieser Übergabe. Die Eingangstür funktioniert, doch der Upstream ist ausgefallen, verweigert die Verbindung, bricht sie ab oder sendet eine unlesbare Antwort. Folglich meldet die Eingangstür, sie habe eine ungültige Antwort erhalten.

Stellen Sie sich die Kette so vor:

1. Zunächst sendet der Besucher eine Anfrage vom Browser.
2. Dann nimmt ein CDN oder Reverse Proxy sie entgegen.
3. Danach geht die Anfrage an die Anwendungsschicht, etwa PHP FPM, Node.js oder Python.
4. Zudem spricht die Anwendung mit einer Datenbank oder einem anderen Dienst.
5. Schließlich läuft die Antwort auf demselben Weg zurück.

Bei mehreren Upstreams sieht das Bild allerdings etwas anders aus. Dann verteilt ein Load Balancer oder nginx Anfragen auf Server, die gesund wirken. Laut nginx Dokumentation reicht proxy_next_upstream standardmäßig bei Fehlern und Zeitüberschreitungen die Anfrage an den nächsten Server weiter. Fallen alle Upstreams aus, sieht der Besucher dennoch einen 502 oder einen ähnlichen Fehler.

Kurz gesagt: Das ausfallende Glied zu finden, ist die halbe Lösung.

Worin unterscheiden sich 502, 500, 503 und 504?

Alle vier Codes sind Serverfehler, bedeuten aber Unterschiedliches, daher lohnt der Blick aufs Detail. Nach RFC 9110 steht 502 dafür, dass ein Gateway von einem eingehenden Server eine ungültige Antwort erhält. Ein 504 heißt, dass keine rechtzeitige Antwort kam. Dagegen bedeutet ein 503, dass der Server wegen Überlast oder Wartung vorübergehend nicht antworten kann. Ein 500 schließlich ist der allgemeine Serverfehler.

Zu 500 und 503 haben wir eigene Beiträge. Deshalb fassen wir hier nur den Unterschied zusammen.

Laut MDN sendet ein Gateway einen 504, wenn es gar keine HTTP Antwort erhält. In der Praxis setzen manche Systeme diese Trennung jedoch anders um. Verlassen Sie sich daher auf den Satz im Log, nicht nur auf den Code.

Was sind die häufigsten Ursachen für einen 502 Bad Gateway Fehler?

Zunächst gilt: Die meisten Ursachen liegen in der Upstream Schicht. Die Liste unten nennt daher die Gründe, die offizielle Dokumentationen am häufigsten nennen. Die Reihenfolge ist keine Rangliste, denn sie ändert sich von Seite zu Seite.

• PHP FPM, Node.js oder der Anwendungsdienst ist abgestürzt oder nie gestartet.
• Der PHP FPM Prozesspool ist voll, und neue Anfragen stauen sich.
• Der Reverse Proxy zeigt auf eine falsche Adresse oder einen falschen Port.
• Die Anwendung bricht die Antwort ab oder sendet einen ungültigen Header.
• Der Arbeitsspeicher ist erschöpft, und das Betriebssystem hat die Anwendung beendet.
• Eine Firewall oder falsche Berechtigungen blockieren die Verbindung zwischen Proxy und Upstream.
• Das CDN kann den Ursprungsserver nicht erreichen.

Es gibt also keine einzelne Zauberlösung. Wer also einer Diagnosereihenfolge folgt, kommt viel schneller ans Ziel als durch Raten.

Wie prüfen Sie als Besucher einen 502 Fehler?

Klären Sie zunächst, ob das Problem bei Ihnen oder bei der Website liegt. Laden Sie die Seite einmal neu und öffnen Sie sie danach in einem privaten Fenster. Probieren Sie danach mobile Daten oder ein anderes Netz. Schlägt die Seite auch dort fehl, dann liegt das Problem am Server.

Hier eine kurze Checkliste:

1. Laden Sie die Seite neu und warten Sie einige Minuten.
2. Schalten Sie VPN, Proxy und Werbeblocker ab.
3. Testen Sie ein anderes Gerät oder Netz.
4. Prüfen Sie mit unserer DNS Abfrage, ob die Domain auf das richtige Ziel zeigt.
5. Bleibt das Problem bestehen, teilen Sie dem Betreiber oder Hoster die Uhrzeit des Fehlers mit.

Den Cache zu leeren hilft manchmal. Weil ein 502 vom Server kommt, löst das Leeren das Problem aber selten.

Was sollte ein Websitebetreiber zuerst versuchen?

Als Betreiber fragen Sie zuerst: Wann hat der Fehler begonnen, und was hat sich kurz davor geändert? Zum Beispiel löst ein Plugin Update, ein Theme Wechsel, ein neuer Cronjob oder ein Besucheransturm den Fehler oft aus.

Gehen Sie der Reihe nach vor:

1. Öffnen Sie das Hosting Panel und prüfen Sie die Ressourcen (CPU, RAM, Prozessanzahl).
2. Deaktivieren Sie das zuletzt aktualisierte Plugin oder Theme.
3. Kontrollieren Sie Wartungsmodus und Einstellungen der Sicherheits Plugins.
4. Nutzen Sie ein CDN, pausieren Sie es kurz und rufen Sie den Ursprungsserver direkt auf.
5. Notieren Sie Uhrzeit, Adresse und einen Screenshot des Fehlers.
6. Eröffnen Sie mit diesen Angaben ein Support Ticket.

Tritt der Fehler nur zeitweise auf, notieren Sie das zudem. Ein sporadischer 502 deutet zum Beispiel oft auf ein Ressourcenlimit oder Stoßzeiten hin. Ein dauerhafter 502 weist dagegen meist auf einen gestoppten Dienst oder eine defekte Konfiguration hin. Denn diese Unterscheidung ist die wertvollste Information für Ihren Hoster.

Mit einer regelmäßigen Backup Strategie haben Sie immer einen Weg zurück. Außerdem ist ein Backup der schnellste Ausweg bei Plugin Problemen.

Wo beginnt ein Serveradministrator die Diagnose?

Betreiben Sie einen eigenen VPS, ist die Reihenfolge somit einfach. Zunächst prüfen Sie, ob die Dienste laufen. Dann kontrollieren Sie, ob der Reverse Proxy den Upstream erreicht. Schließlich lesen Sie das Log. Die Befehle unten gehen von einer üblichen Aufteilung unter Debian oder Ubuntu aus, daher können Dienstnamen und Logpfade je nach Distribution abweichen.

sudo systemctl status nginx
sudo systemctl status php-fpm
sudo nginx -t
sudo tail -n 50 /var/log/nginx/error.log
ss -ltnp

Bei manchen Distributionen trägt der PHP FPM Dienst eine Versionsnummer im Namen. Den richtigen Namen finden Sie in der Ausgabe von systemctl list-units --type=service. Ebenso kann der Logpfad von nginx je nach Installation anders lauten.

Zwei Arten von Logzeilen helfen besonders:

• Connection refused: An dieser Upstream Adresse lauscht nichts.
• Prematurely closed connection: Der Upstream hat die Verbindung geschlossen, bevor er die Antwort beendet hat.

Die erste Zeile spricht also meist für einen gestoppten Dienst. Die zweite deutet auf einen Absturz oder einen beendeten Prozess hin.

Was passiert, wenn PHP FPM abstürzt oder der Pool voll läuft?

WordPress, Laravel und die meisten PHP Seiten laufen hinter nginx mit PHP FPM. Ist PHP FPM ausgefallen, erreicht nginx den Upstream nicht und liefert einen 502. Dasselbe passiert zum Beispiel, wenn der Socket von PHP FPM nicht zu dem passt, den nginx anspricht.

Tückischer ist allerdings ein voller Pool. Laut PHP Handbuch legt pm.max_children die Grenze für gleichzeitig bearbeitete Anfragen fest. Sind alle Prozesse belegt, müssen neue Anfragen warten. Dauert das lange, dann sehen Sie Zeitüberschreitungen und manchmal Verbindungsfehler.

Zeigt das PHP FPM Log dann eine Warnung wie "server reached pm.max_children setting", stößt der Pool an seine Grenze. Das heißt aber nicht, dass Sie den Wert einfach erhöhen sollten. Klären Sie stattdessen zuerst, warum ein langsames Skript oder eine langsame Abfrage die Prozesse so lange blockiert.

Zudem ist eine abweichende Lauschadresse eine häufige Ursache. Auf der PHP FPM Seite kann listen ein Unix Socket oder eine IP mit Port sein. Die Anweisung fastcgi_pass in nginx muss auf dieselbe Adresse zeigen. Ändern Sie nur eine Seite, ist ein 502 somit unvermeidlich.

Wie berechnen Sie pm.max_children?

Das PHP Handbuch nennt keine feste Zahl für pm.max_children. Stattdessen hängt der passende Wert vom Arbeitsspeicher des Servers und vom Verbrauch pro Prozess ab. Die Logik ist einfach: Sie teilen den Speicher, den Sie PHP geben können, durch den durchschnittlichen Verbrauch eines Prozesses.

Die folgenden Zahlen sind nur eine Beispielrechnung und keine Messung Ihrer Seite:

• Speicher, den Sie PHP auf dem Server geben können: 2 GB (Beispiel).
• Ein PHP FPM Prozess braucht im Schnitt etwa 50 MB (Beispiel).
• Ergebnis: etwa 40 Prozesse, also pm.max_children in der Nähe von 40.

Messen Sie den echten Durchschnitt zunächst im Live Betrieb. Nutzen Sie dafür top oder htop und schauen Sie auf den Speicher eines PHP FPM Kindprozesses. Lassen Sie danach Platz für Betriebssystem, Datenbank und Cache. Ein zu hoher Wert erschöpft den Speicher, und dann beendet das Betriebssystem Prozesse. Die Folge ist wieder ein 502.

pm = dynamic
pm.max_children = 40
pm.max_requests = 500

Auch die 500 ist ein Beispiel. Laut Handbuch kann pm.max_requests Prozesse neu starten, um Speicherlecks in Bibliotheken von Drittanbietern zu umgehen.

Wie wirken nginx Proxy Timeouts auf 502 und 504?

Laut nginx Dokumentation legt proxy_connect_timeout die Zeit für den Verbindungsaufbau fest, und proxy_read_timeout die Wartezeit zwischen zwei Lesevorgängen. Connect, Read und Send stehen standardmäßig auf 60 Sekunden. Für FastCGI heißen die passenden Anweisungen fastcgi_connect_timeout und fastcgi_read_timeout.

Die Werte blind zu erhöhen, ist daher keine Lösung. Ein langsames Skript 300 Sekunden warten zu lassen, hält den Besucher länger auf einer leeren Seite. Zudem bleiben die PHP Prozesse länger belegt. Suchen Sie daher zuerst die Ursache der Langsamkeit.

location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_connect_timeout 5s;
    proxy_read_timeout 60s;
}

Die Werte in diesem Ausschnitt sind Beispiele. Für wirklich lange Aufgaben wie Berichte ist eine Warteschlange im Hintergrund der gesündere Weg.

Beachten Sie noch ein Detail: Der Standard von proxy_next_upstream ist error timeout. Bei mehreren Upstreams versucht nginx es also bei diesen Ereignissen erneut. Gibt es nur einen Upstream, fehlt ein Ersatz, und der Fehler geht direkt an den Besucher.

Wie entsteht ein 502 bei Apache als Reverse Proxy?

Läuft Apache über mod_proxy als Reverse Proxy, gilt dieselbe Logik. Antwortet der Upstream nicht oder sendet er einen ungültigen Header, kann Apache einen 502 liefern. Laut offizieller Dokumentation gibt der Standardwert IsError der Anweisung ProxyBadHeader bei ungültigem Header einen 502 zurück.

Die Anweisung ProxyTimeout legt das Netzwerk Timeout für Proxy Anfragen fest. Die Dokumentation empfiehlt sie für einen langsamen oder fehlerhaften Anwendungsserver, der hängt, damit Apache sauber scheitert und nicht ewig wartet. Ihr Standardwert entspricht dem Wert von Timeout.

In Panels wie cPanel können Apache und nginx zusammen laufen. Dann kann der Fehler aus beiden Schichten stammen, weil beide Dienste Anfragen weiterreichen. Ohne die Logs erkennen Sie daher nicht, welche Schicht den 502 erzeugt hat. Haben Sie bei verwaltetem Hosting keinen Zugriff darauf, bitten Sie Ihren Anbieter um die passenden Zeilen.

Zudem finden Sie einen größeren Vergleich in unserem Beitrag zu OpenLiteSpeed und nginx.

Warum liefern Node.js, PM2 und Next.js Anwendungen einen 502?

Node.js Anwendungen laufen meist auf einem eigenen Port hinter nginx, denn so lassen sie sich leicht anbinden. Ist die Anwendung abgestürzt, weicht der Port ab oder konnte der Prozessmanager sie nicht neu starten, liefert nginx einen 502. In der Praxis ist das die häufigste Ursache für einen 502 Bad Gateway in der Node Welt.

Prüfen Sie diese Punkte der Reihe nach:

1. Läuft der Anwendungsprozess? Mit PM2 zeigt pm2 status das an.
2. Lauscht die Anwendung auf dem Port, auf den proxy_pass zeigt?
3. Lauscht die Anwendung nur auf IPv4 oder nur auf IPv6? Bei manchen Setups löst der Name localhost zu einer anderen Adresse auf, und die Verbindung scheitert.
4. Ist der Build nach dem letzten Deployment erfolgreich durchgelaufen?
5. Hat das System den Prozess wegen Speichermangel beendet?

Einzelheiten zur Einrichtung finden Sie in unseren Anleitungen zum Node.js Deployment mit nginx und systemd, zu PM2 für Node.js Anwendungen und zum Next.js Deployment auf einem VPS. Wir wiederholen das hier nicht, denn diese Beiträge behandeln es vollständig.

Wie diagnostizieren Sie einen 502 hinter Cloudflare oder einem CDN?

Laut Cloudflare Dokumentation bedeutet ein 502 oder 504, dass Cloudflare keinen Kontakt zu Ihrem Ursprungsserver herstellen kann. Den Fehler sehen Sie an zwei Orten, daher zählt das Aussehen der Seite. Ein Fehler vom Ursprungsserver erscheint auf einer Seite mit Cloudflare Branding. Einen Fehler, den Cloudflare selbst erzeugt, sehen Sie dagegen als leere Seite ohne Branding.

Diese Trennung zeigt Ihnen, wo Sie suchen müssen:

• Seite mit Branding: Das Problem liegt am Ursprungsserver. Arbeiten Sie daher mit Ihrem Hoster zusammen.
• Leere Seite ohne Branding: Die Ursache kann bei Cloudflare liegen. Ein Beispiel der Dokumentation ist zum Beispiel ein Ursprung, der gzip Inhalte liefert, ohne den Header content-length anzupassen.

Schreiben Sie an den Cloudflare Support, fragt man nach Uhrzeit und Zeitzone, der betroffenen URL und der Ausgabe von /cdn-cgi/trace Ihrer Domain. Das CDN kurz zu pausieren und direkt den Ursprung aufzurufen, zeigt ebenfalls, welche Schicht ausfällt.

Außerdem gilt: Teilen Sie die echte Adresse Ihres Ursprungsservers nicht öffentlich. Mit einem Werkzeug wie unserer IP Abfrage prüfen Sie nur Ihre eigenen Einträge.

Wie unterscheiden sich Cloudflare 520 bis 524 von einem 502?

Neben 502 und 504 nutzt Cloudflare eigene 52x Codes. Die offizielle Übersicht der 5xx Fehler erklärt jeden Code in einer Zeile. Bei allen empfiehlt sie, den Hoster mit Fehlercode, Uhrzeit und betroffener URL zu kontaktieren.

Kurz gesagt: Sehen Sie einen Code zwischen 520 und 526, nutzen Sie Cloudflare, und die Ursache liegt oft am Ursprung. Bei 525 und 526 prüfen Sie Ihr Zertifikat mit unserem SSL Check. Die Grundlagen erklären wir zudem im Beitrag zum SSL Zertifikat.

Wie lesen Sie die Zeilen im Fehlerlog?

Das Log ist die einzige Quelle, die die wahre Ursache eines 502 Bad Gateway Fehlers nennt. Das Fehlerlog von nginx hält ein Upstream Problem meist in einem Satz fest, der das Wort "upstream" enthält. Der hintere Teil des Satzes zeigt, in welcher Phase der Fehler auftrat.

• "Connection refused" und "while connecting to upstream": Die Verbindung scheiterte, weil der Dienst ausgefallen oder die Adresse falsch ist.
• "Upstream timed out" und "while reading response header": Der Upstream nahm die Verbindung an, sendete aber keinen Antwort Header. Ein langsames Skript oder ein hängender Prozess ist möglich.
• "Upstream prematurely closed connection": Der Upstream schloss die Verbindung vor Ende der Antwort. Denken Sie an einen Absturz oder Speichermangel.
• "Permission denied": Auf die Socket Datei besteht kein Zugriff, prüfen Sie also Benutzer und Gruppe.
• "No such file or directory": Die Socket Datei fehlt, weil PHP FPM nicht läuft oder der Pfad abweicht.

Der Zeitstempel neben der Zeile sollte somit zur Uhrzeit passen, zu der der Besucher den Fehler sah. Dann verlieren Sie sich nicht in alten, unpassenden Einträgen. Zudem ist es ein Warnsignal, wenn das Log sehr schnell wächst, denn ein sich wiederholender Fehler belastet den Server.

Diese Einträge zu lesen, setzt Root Zugriff voraus. Beim Shared Hosting bitten Sie daher Ihren Anbieter um die Zeilen im betreffenden Zeitfenster.

Was prüfen Sie bei einem 502 unter WordPress?

WordPress Betreiber sehen einen 502 meist nach einer Änderung an Plugin oder Theme. Erreichen Sie das Dashboard nicht, benennen Sie den Ordner wp-content/plugins per Dateimanager oder FTP um. Das deaktiviert alle Plugins und zeigt schnell, ob ein Plugin der Auslöser ist.

Probieren Sie diese Reihenfolge:

1. Suchen Sie das Plugin, das kurz vor dem Fehler ein Update erhielt, und deaktivieren Sie es.
2. Bleibt das Problem, stoppen Sie alle Plugins und schalten Sie sie einzeln wieder ein.
3. Dann wechseln Sie testweise zu einem Standard Theme.
4. Kontrollieren Sie im Hosting Panel PHP Version und Speicherlimit.
5. Prüfen Sie schwere Cronjobs, Backup Plugins und Importvorgänge.

Ein schweres Plugin kann viele PHP Prozesse lange blockieren. Dann füllt sich der Pool, und ein 502 folgt. Deshalb ist eine überschaubare Plugin Anzahl eine gute Gewohnheit für Sicherheit und Stabilität.

Besteht der Fehler weiter und Sie haben dennoch keinen Serverzugriff, geben Sie Ihre Erkenntnisse an den Anbieter weiter. Nehmen Sie stattdessen keine Änderungen ohne Backup vor, während Sie WordPress selbst reparieren wollen.

Wie wirkt sich ein 502 Bad Gateway Fehler auf SEO und Umsatz aus?

Ein kurzer 502 Bad Gateway Fehler schadet Ihren Rankings nicht, ein langer dagegen schon. Google Search Central schreibt, dass 5xx und 429 Fehler das Crawling vorübergehend verlangsamen. Anders gesagt: Der Rückgang der Crawlrate steht im Verhältnis zur Zahl der URLs mit Serverfehler. Die Einzelheiten stehen auf Googles Seite zu HTTP und Netzwerkfehlern.

Google erklärt dort zudem, dass indexierte URLs zunächst erhalten bleiben. URLs, die dauerhaft einen Serverfehler liefern, fallen mit der Zeit aus dem Index. Liefert der Server wieder 2xx, erhöht Google die Crawlrate schrittweise.

Im E-Commerce ist die Wirkung allerdings direkter. Liefert die Kasse einen 502, brechen Kunden daher den Kauf ab. Kaufen Sie Werbeverkehr ein, zahlen Sie dennoch für jeden Klick auf die defekte Seite. Betrachten Sie daher Ladezeit und Verfügbarkeit im Onlineshop gemeinsam. Das größere Bild zeigt unser Beitrag dazu, wie die Ladezeit SEO beeinflusst.

Bei geplanter Wartung oder vorübergehender Abschaltung ist ein 503 mit dem Header Retry-After richtiger als ein 502.

Wie verhindern Sie, dass der 502 Bad Gateway Fehler wiederkehrt?

Eine dauerhafte Lösung heißt, den Ausfall früh zu sehen und zu verhindern, dass ein einzelner Fehler die ganze Seite lahmlegt. Vieles davon erledigen Sie gemeinsam mit Ihrem Anbieter.

• Monitoring: Richten Sie einen Uptime Monitor ein, der Startseite und wichtige Seiten regelmäßig von außen prüft.
• Automatischer Neustart: Nutzen Sie systemd oder PM2, damit ein abgestürzter Dienst von selbst zurückkehrt.
• Ressourcenplanung: Stimmen Sie RAM und Zahl der PHP Prozesse auf den echten Verkehr ab.
• Caching: Cachen Sie häufig angefragte Seiten, um den Upstream zu entlasten. Unsere Beiträge zu OPcache und zu Redis und Memcached behandeln das.
• Sichere Deployments: Testen Sie Änderungen in einer Staging Umgebung, bevor Sie live gehen, und legen Sie immer ein Backup an.
• Versionen: Prüfen Sie vor dem Update, ob Plugin, Theme und PHP Version zusammenpassen.

Vergessen Sie außerdem Angriffsverkehr nicht. Eine ungewöhnlich hohe Zahl an Anfragen kann zum Beispiel PHP Prozesse aufbrauchen. Schichten wie Fail2ban und ModSecurity verringern diese Last.

Wann überlassen Sie die Arbeit besser Ihrem Hostinganbieter?

Unsere ehrliche Antwort: Gehört Serveradministration nicht zu Ihren Aufgaben, probieren Sie nicht selbst herum. Eine falsche Konfiguration kann nämlich aus einem Fehler mehrere machen. In den folgenden Situationen wenden Sie sich direkt an den Anbieter.

• Sie nutzen Shared Hosting oder einen verwalteten VPS und haben keinen Root Zugriff.
• Der Fehler betrifft den ganzen Server, und mehrere Ihrer Seiten fallen gleichzeitig aus.
• Die Logs zeigen Zeilen, die auf Festplatte, Speicher oder Netzwerkhardware hindeuten.
• Sie wollen zum ersten Mal eine Konfigurationsdatei in einem laufenden Shop bearbeiten.
• Sie riskieren eine falsche Änderung ohne Backup.

Zudem sollte die Supportqualität ein Kriterium bei der Hosterwahl sein. Diese Kriterien nennen wir im Leitfaden zur Auswahl von Webhosting.

Was gehört in ein Support Ticket an Ihren Hoster?

Fehlende Angaben bremsen den Support, deshalb sollten Sie konkret sein. Auch Cloudflare nennt in der eigenen Dokumentation, dass es Fehlercode, Uhrzeit und URL braucht. Derselbe Ansatz funktioniert also bei jedem Anbieter.

Fügen Sie Ihrem Ticket diese Angaben bei:

1. Beginn und Ende des Fehlers, mit Zeitzone.
2. Die genaue betroffene URL und ob der Fehler auf allen oder nur auf einzelnen Seiten auftritt.
3. Ein Screenshot der Fehlerseite.
4. Die Änderung, die Sie kurz vor dem Fehler vorgenommen haben, etwa ein Plugin, ein Theme oder ein Deployment.
5. Bei CDN Nutzung das Ergebnis beim direkten Aufruf des Ursprungs.
6. Einige passende Zeilen aus dem Fehlerlog, falls vorhanden.

Schreiben Sie keine Passwörter, Schlüssel oder privaten Daten in das Ticket. Teilen Sie Logzeilen, entfernen Sie daher vorher persönliche Daten.

Wie lesen Sie die Tabelle zur schnellen Diagnose?

Die Tabelle unten ordnet jedem Symptom eine wahrscheinliche Ursache und eine zuständige Person zu. Sie ist allerdings kein endgültiges Urteil, sondern ein Ausgangspunkt für die Diagnose.

Nutzen Sie die Tabelle wie eine Checkliste. Ist das Ergebnis unklar, verlassen Sie sich auf den Satz im Log.

Wie kann unser Team helfen?

Wir sind kein Hostinganbieter mit Serveradministration. Dennoch berühren Fehler wie ein 502 die Marketingseite, weil sie Ihre Sichtbarkeit und Ihr Werbebudget direkt beeinflussen. Fehlerzeiträume gemeinsam mit Suchverkehr und Werbedaten zu lesen, hilft zum Beispiel, den Verlust zu verstehen.

Planen Sie also eine neue Seite, finden Sie unser Webdesign. Für die technische Sichtbarkeit Ihrer bestehenden Seite bieten wir SEO Beratung. Für Ihren Onlineshop gibt es unsere E-Commerce Beratung. Bei Infrastrukturentscheidungen arbeiten wir deshalb mit Ihrem Anbieter zusammen und helfen Ihnen, die richtigen Anforderungen zu formulieren.

Zur Leistungsmessung ist unser Beitrag zum Test der Website Performance mit Google Lighthouse ein guter Start. Die Serverseite der Langsamkeit behandeln wir außerdem in Warum ist meine Website langsam.

Was sollten Sie sich zum 502 Bad Gateway Fehler merken?

Ein 502 sagt Ihnen, dass im Hintergrund etwas schiefgelaufen ist, und das Log sagt Ihnen, was. Schließen Sie zunächst die Besucherseite aus. Danach schauen Sie auf Dienststatus, Reverse Proxy Einstellungen und Ressourcenlimits. Nutzen Sie ein CDN, führt Sie die Unterscheidung zwischen Fehlerseiten mit und ohne Branding.

Außerdem braucht eine dauerhafte Lösung Monitoring, automatische Neustarts und eine realistische Ressourcenplanung. Serveradministration erfordert Fachwissen, daher gilt: Sind Sie unsicher, ist der Weg zu Ihrem Anbieter mit den richtigen Angaben der sicherste.