Plötzlicher Traffic-Anstieg: Was tun bei akuter Serverüberlastung (504-Fehler)?

Manchmal führt ein unerwartetes Ereignis – etwa eine Medienberichterstattung, eine virale Social-Media-Erwähnung oder eine große Marketingaktion – dazu, dass deine Website innerhalb kürzester Zeit ein Vielfaches des normalen Besucheraufkommens erhält. Das kann sowohl das Frontend als auch den Zugriff auf dein WordPress-Backend spürbar verlangsamen oder mit Fehlermeldungen wie 504 Gateway Timeout oder 508 Resource Limit Is Reached blockieren. Dieser Artikel zeigt dir, was du selbst tun kannst und wie dich unser Support in einer solchen Situation kurzfristig unterstützen kann.

Voraussetzungen

• Deine Website zeigt 504- oder 508-Fehler, insbesondere beim Zugriff auf /wp-admin.
• Du vermutest oder weißt, dass der Traffic gerade ungewöhnlich hoch ist (z. B. durch Presseberichte, Kampagnen oder Aktionen).
• Zugriff auf dein Plesk-Kundencenter bzw. Kontakt zum HostPress-Support.

Schritt-für-Schritt-Anleitung

1. Fehlerbild einordnen

Meldungen wie „upstream timed out“ oder „The timeout specified has expired“ in den Server-Protokollen deuten auf einen 504 Gateway Timeout hin: Der Server wartet zu lange auf eine Antwort und bricht die Anfrage ab, meist weil die zugewiesenen Ressourcen durch hohen Traffic ausgeschöpft sind. Die Protokolle findest du in deinem Plesk Panel.

Interne Ursache: PHP-FPM-Überlastung durch Cron- und Plugin-Aktivität

Nicht jede plötzliche Nichterreichbarkeit deiner Website geht auf einen externen Besucheransturm zurück. Genauso häufig entsteht eine Überlastung durch interne Hintergrundprozesse deiner eigenen WordPress-Installation – vor allem dann, wenn mehrere ressourcenintensive Funktionen gleichzeitig aktiv sind.

Typische Auslöser für interne Überlastung

• WP-Cron: Bei WordPress wird der Cron-Mechanismus standardmäßig bei jedem Seitenaufruf über wp-cron.php mitausgeführt. Bei vielen gleichzeitigen Aufrufen kann das die PHP-Prozesse zusätzlich belasten.
• admin-ajax.php: Plugins, die häufig asynchrone Hintergrundanfragen stellen (z. B. Live-Suchen, Statistiken, Formulare), erzeugen viele parallele Aufrufe dieser Datei.
• WooCommerce-REST-Aufrufe: Externe Anbindungen (z. B. Warenwirtschaft, Marktplatz-Sync) können in kurzer Zeit viele API-Anfragen auslösen.
• Kalender-/Event-Plugins: Plugins mit wiederkehrenden Hintergrundaufgaben (z. B. Terminaktualisierungen) laufen oft automatisiert und unbemerkt im Hintergrund.
• Gleichzeitige Plugin-Updates: Automatische Updates mehrerer Plugins zur gleichen Zeit beanspruchen zusätzlich PHP-Ressourcen.

Da HostPress mit PHP-FPM arbeitet, steht für die Verarbeitung von Anfragen nur eine begrenzte Anzahl paralleler PHP-Prozesse (max_children) zur Verfügung. Sind alle Prozesse durch die oben genannten Hintergrundaufgaben belegt, können reguläre Seitenaufrufe zeitweise nicht mehr verarbeitet werden – die Website wirkt dann komplett offline (z. B. mit der Fehlermeldung ERR_TIMED_OUT im Browser) oder liefert 503-/504-Fehler.

Was du selbst tun kannst

• Prüfe, ob du Plugins nutzt, die regelmäßig externe Daten synchronisieren (z. B. WooCommerce-Anbindungen, Event-/Kalender-Plugins), und ob sich deren Ausführungsintervall verringern lässt.
• Erwäge, den echten WP-Cron zu deaktivieren und stattdessen einen serverseitigen Cron-Job mit einem sinnvollen, festen Intervall einzurichten – dadurch wird Cron nicht mehr bei jedem einzelnen Seitenaufruf mitausgeführt.
• Plane größere manuelle Plugin- oder Theme-Updates nach Möglichkeit außerhalb der Stoßzeiten deiner Website ein.
• Wenn eine ähnliche Nichterreichbarkeit wiederholt auftritt, teile dem Support die betroffene Domain sowie den ungefähren Zeitpunkt mit – so kann anhand der Server-Logs die genaue Kombination aus Hintergrundprozessen identifiziert werden.

Wichtig zu wissen

Eine höhere Serverleistung (mehr CPU/RAM) allein löst dieses Problem nicht zuverlässig: Wenn eine ineffiziente Schleife oder eine sehr hohe Anzahl gleichzeitiger Hintergrundaufrufe die vorhandenen Ressourcen ausschöpft, wächst der Bedarf oft mit der verfügbaren Leistung mit. Wichtiger als eine reine Kapazitätserhöhung ist es, die auslösenden Hintergrundprozesse zu identifizieren und zu entschärfen.

Externe Ursache: 503/504-Fehler durch Bot- oder Crawler-Traffic

Neben echten Besucherspitzen und internen Hintergrundprozessen kann auch automatisierter Bot- oder Crawler-Traffic zu 503- bzw. 504-Fehlern führen. Zwei Muster kommen dabei besonders häufig vor:

Gefälschte Browser-Kennung (User-Agent-Spoofing) über viele IPs

Manche automatisierten Systeme geben sich über einen gefälschten Browser-User-Agent (z. B. eine aktuelle Chrome-Version) als normaler Besucher aus und verteilen ihre Anfragen über sehr viele wechselnde IP-Adressen (z. B. aus einem Residential-Proxy-Netzwerk). Da unser Sicherheitssystem Imunify360/WebShield vor allem IP-basiert arbeitet (ein Schwellenwert pro einzelner IP-Adresse), greift der automatische Schutz bei dieser Art von verteiltem Traffic oft nicht, weil jede einzelne IP für sich betrachtet unauffällig bleibt. Bei stärkeren Lastspitzen kann das zu 503-/504-Fehlern und in Kombination mit vielen parallelen PHP-Prozessen auch zu sogenannten PMEM-Faults (Überschreitung des Arbeitsspeicher-Limits deines Hosting-Pakets) führen, wodurch im Extremfall auch Hintergrundprozesse wie dein WordPress-Cronjob abgebrochen werden.

Crawler-Traps durch kombinatorische URL-Strukturen

Wenn deine Website sehr viele URL-Kombinationen erzeugt (zum Beispiel durch Filter-, Tag- oder Archivseiten mit nahezu unbegrenzten Kombinationsmöglichkeiten, etwa bei Podcast- oder Produktarchiven), kann ein Crawler – auch ein grundsätzlich seriöser KI- oder Suchmaschinen-Crawler – in dieser Struktur „hängen bleiben“ und binnen kurzer Zeit zehntausende technisch einzigartige URLs abrufen. Da praktisch jede dieser URLs neu ist, greift der Seiten-Cache nicht (jede Anfrage ist ein Cache-Miss), was die Serverlast massiv erhöht und zu 503-Fehlern führen kann – unabhängig von einem klassischen DDoS-Angriff.

Was du tun kannst

• Prüfe deine Server-Logs (bzw. lass sie vom Support prüfen) auf ungewöhnlich viele Anfragen mit demselben User-Agent oder auf einen sehr hohen Anteil einzigartiger URLs in einem bestimmten Bereich deiner Website.
• Grenze kombinatorische URL-Bereiche technisch ein, zum Beispiel über `noindex`-Angaben oder gezielte `Disallow`-Regeln in der robots.txt (siehe Artikel „Funktion der robots.txt“).
• Wenn du einen konkreten, schädlichen Bot anhand von User-Agent und/oder Referrer identifizieren kannst, wende dich mit den gesammelten Log-Daten (Zeitstempel, Anzahl Requests, Statuscodes) an den HostPress-Support. Wir können verdächtigen Traffic bei Bedarf serverseitig gezielt blockieren (z. B. auf Nginx-Ebene, noch vor Apache/PHP).
• Wichtig: Auf klassischen Shared-Hosting-Tarifen lassen sich einzelne Bot-User-Agents nicht selbst serverseitig sperren – dafür ist der Support nötig.

Hinweis: Diese Fälle sind von absichtlich blockierten KI-Crawlern (siehe Artikel „Warum blockiert mein Hosting KI-Crawler wie ChatGPT, Claude oder Perplexity?“) zu unterscheiden – hier geht es umgekehrt um automatisierten Traffic, der deinen Server ungewollt überlastet.

Vor dem Start einer Werbekampagne: Ist dein Caching aktiv?

Ein besonders häufiger und gut vermeidbarer Auslöser für eine plötzliche Serverüberlastung ist der Start einer bezahlten Werbekampagne (z. B. Google Ads, Social-Media-Ads) auf eine Landingpage, für die kein Seiten-Caching aktiv ist. Jeder Klick auf die Anzeige erzeugt dann eine komplett neue, ungecachte Anfrage, die vollständig von WordPress und der Datenbank neu berechnet werden muss. Bei hohem Klickvolumen kann das innerhalb weniger Minuten alle verfügbaren PHP-FPM-Prozesse blockieren und deine gesamte Website – nicht nur die Landingpage – offline nehmen.

Was diesen Fall zusätzlich verschärfen kann

• Ein Cookie-Consent-Banner-Plugin, das bei jedem Seitenaufruf zusätzliche, nicht cachebare Anfragen auslöst.
• Eine defekte oder falsch verlinkte Ziel-URL in der Kampagne: Läuft jeder einzelne Klick in einen Fehler oder ein Timeout, bleibt der zugehörige PHP-Prozess bis zum Ablauf der Wartezeit blockiert, statt die Anfrage schnell zu beenden – das verschärft die Überlastung zusätzlich erheblich.

Checkliste vor dem Kampagnenstart

1. Prüfe, ob für die Ziel-Landingpage das Seiten-Caching (z. B. HostPress RocketCache/WP Rocket) aktiv ist und tatsächlich greift.
2. Rufe die Ziel-URL der Kampagne selbst einmal auf und stelle sicher, dass sie fehlerfrei und ohne Timeout lädt.
3. Prüfe, ob ein Cookie-Consent-Banner oder ähnliche Plugins auf der Landingpage aktiv sind, die das Caching beeinträchtigen könnten.
4. Bei erwartetem sehr hohem Besucheraufkommen (z. B. großes Werbebudget, TV-Spot-Begleitung) kannst du zusätzlich vorab mit unserem Support sprechen, um kurzfristig mehr Server-Ressourcen einzuplanen (siehe Abschnitt „Temporäre Ressourcenerhöhung“ weiter unten).

Wenn die Website durch eine laufende Kampagne bereits überlastet ist

Folge in diesem Fall den Schritten weiter oben in diesem Artikel (Fehlerbild einordnen, Wartungsmodus, Support kontaktieren, temporäre Ressourcenerhöhung). Melde dich zusätzlich möglichst schnell auch bei der Stelle, die die Kampagne schaltet (Marketing-Team oder Agentur), damit die Kampagne pausiert oder die Ziel-URL angepasst werden kann, bis das Caching aktiviert ist.

2. Wartungsmodus als kurzfristige Entlastung aktivieren

Wenn ein Teil deiner Besucher vorübergehend auf eine einfache Hinweisseite umgeleitet werden kann, reduziert das die Serverlast spürbar. Aktiviere dazu den Wartungsmodus deiner Website. Das ersetzt keine dauerhafte Lösung, verschafft dir aber Zeit, um weitere Schritte einzuleiten.

3. Support kontaktieren und Situation schildern

Melde dich bei akuten Traffic-Spitzen zeitnah beim HostPress-Support und schildere kurz die Situation (z. B. Ursache des Traffic-Anstiegs, betroffene Domain, ob das Backend erreichbar sein muss). Teile uns mit:

• die genau betroffene Domain (falls du mehrere Domains/Umgebungen hast, gib an, welche nicht betroffen ist),
• ob du weiterhin Zugriff auf das Backend benötigst,
• eine grobe Einschätzung, wie lange die Situation voraussichtlich anhält.

4. Temporäre Ressourcenerhöhung

Bei akuten Lastspitzen kann der Support die zugewiesenen Server-Ressourcen (CPU/RAM) deines Hosting-Pakets kurzfristig erhöhen, um mehr gleichzeitige Anfragen verarbeiten zu können. Diese Erhöhung ist eine temporäre Kulanzmaßnahme für den akuten Ausnahmefall und kein dauerhafter Tarif-Upgrade-Ersatz. Bitte beachte: Bei Shared-Hosting-Umgebungen sind einer Ressourcenerhöhung technische Grenzen gesetzt.

5. Temporären Backend-Zugriff per IP-Beschränkung sichern

Wenn du dringend ins Backend musst, aber der allgemeine Andrang das verhindert, kann eine temporäre IP-Beschränkung helfen, die nur deine eigene IP-Adresse zum Zugriff zulässt. Dafür kann folgender Code-Block an den Anfang der .htaccess-Datei eingefügt werden (Platzhalter durch deine tatsächliche IP-Adresse ersetzen):

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{REMOTE_ADDR} !^123.123.123.123$
RewriteRule ^ - [R=503,L]
</IfModule>

Dadurch erhalten alle Besucher außer der angegebenen IP-Adresse eine 503-Meldung, während du selbst weiterhin normal auf die Seite zugreifen kannst. Entferne diesen Block wieder, sobald die Situation sich normalisiert hat.

6. Nach der Spitze: Ressourcen wieder zurücksetzen lassen

Sobald der Traffic wieder auf ein normales Niveau zurückgegangen ist, informiere den Support, damit die temporär erhöhten Ressourcen wieder auf den regulären Tarif zurückgesetzt werden können. Wenn du merkst, dass dein reguläres Besucheraufkommen dauerhaft gestiegen ist, sprich mit uns über einen passenden Tarif-Wechsel.

Fazit & Support-Hinweis

Ein plötzlicher Traffic-Anstieg lässt sich mit einer Kombination aus Wartungsmodus, temporärer Ressourcenerhöhung und gegebenenfalls einer IP-Beschränkung für den Backend-Zugriff meist gut überbrücken. Melde dich in einer solchen Situation frühzeitig bei unserem Support – je schneller wir über die Lage Bescheid wissen, desto gezielter können wir kurzfristig unterstützen.