Drei Ausfälle in drei Tagen beim Hoster Fritz Managed IT: was beim Betrieb einer WordPress-Seite zu Speicherlimits, Backups, Firewalls und Bots zählt

Das Wichtigste in Kürze

  • Am 29. Oktober 2026 sperrte die Hosting-Software das Portal steuerratschlag.eu: Es belegte 36,3 GB, das Paket erlaubt 25 GB. Grund waren alte Backups, allein ein Archiv hatte 17,2 GB.
  • Am 31. Oktober 2026 endete jede Anmeldung im WordPress-Dashboard mit „Internal Server Error“: Die Firewall ModSecurity des Hosters brach Seiten über 1 MB ab, ein Analyse-Plugin hatte das Dashboard aufgebläht.
  • Ein KI-Assistent fand die Ursache im Fehlerprotokoll, nach dem Abschalten des Plugins lief die Anmeldung wieder.
  • Ebenfalls am 31. Oktober 2026 fiel die Seite erneut zeitweise aus: Bots aus Rechenzentrumsnetzen fragten sie teils mehr als zehnmal pro Sekunde ab. Eine Sperre von elf Netzen in der Serverdatei .htaccess beendete die Überlastung.

Das Finanzportal steuerratschlag.eu war innerhalb von drei Tagen dreimal nicht nutzbar. Zweimal griffen Schutzmechanismen des Hosters Fritz Managed IT – ausgelöst durch Ballast auf der eigenen Seite. Beim dritten Mal überlasteten Bots den Server.

Erst war die Seite komplett offline, dann gab es keinen Zugang mehr zum WordPress-Backend, schließlich brach sie unter automatisierten Massenabrufen zusammen. In eigener Sache: steuerratschlag.eu gehört wie NETZ-TRENDS zum Herausgeber Dr. K. Korosides. Wir schildern den Fall, weil er typisch ist für viele kleine WordPress-Seiten bei Hostern in Deutschland – und weil die Fehlermeldungen kaum verraten, was wirklich los ist.

Anzeige

Ausfall 1: Speicher zu 142 Prozent voll

Am späten Abend des 29. Oktober 2026 lieferte steuerratschlag.eu nur noch den Fehler „503 Service Unavailable“. Statische Dateien wie die robots.txt kamen noch an, WordPress selbst nicht mehr. In der Verwaltungsoberfläche Plesk stand das Abonnement auf „Gesperrt“.

Was ist Plesk?

Plesk ist eine Verwaltungsoberfläche für Webserver, auf Englisch „Control Panel“. Über sie verwaltet man im Browser, was sonst Befehle auf dem Server erfordern würde: Domains und E-Mail-Postfächer anlegen, Dateien im Dateimanager hochladen, umbenennen oder löschen, Datenbanken, Backups und Sicherheitszertifikate verwalten, die Protokolle des Webservers lesen. Ein „Abonnement“ ist in Plesk ein gebuchtes Hosting-Paket mit festen Grenzen, etwa für den Speicherplatz.

Warum Hoster so etwas brauchen

Ein Hoster betreibt auf einem Server oft Hunderte Websites verschiedener Kundinnen und Kunden. Die dürfen nicht an die Systemverwaltung des ganzen Servers (Root-Zugang), sollen ihren eigenen Bereich aber selbst pflegen können – ohne für jede Kleinigkeit den Support anzurufen. Ein Control Panel trennt die Kundenbereiche sauber voneinander, setzt die gebuchten Grenzen durch und automatisiert Routinearbeit: neue Pakete einrichten, Zertifikate verlängern, Sicherheitsupdates einspielen. Eine eigene Software dafür zu entwickeln, lohnt sich nur für große Anbieter. Kleinere Hoster kaufen deshalb Lizenzen bei Plesk oder dem Konkurrenten cPanel. Es gibt auch kostenlose Open-Source-Alternativen wie ISPConfig oder Froxlor, die aber mehr Fachwissen beim Betrieb verlangen.

Wie verbreitet Plesk ist

Laut dem Statistikdienst W3Techs (Stand 1. November 2026) läuft Plesk auf 41,4 Prozent der Websites, bei denen sich die Verwaltungsoberfläche von außen erkennen lässt. Häufiger ist nur hPanel, die hauseigene Oberfläche des Großhosters Hostinger, mit 54,2 Prozent; cPanel kommt auf 1,8 Prozent. Je größer die Website, desto häufiger ist Plesk: Unter den 1.000 meistbesuchten Websites mit erkennbarer Oberfläche liegt der Anteil bei 84,6 Prozent. Bei den meisten Websites lässt sich die Oberfläche allerdings gar nicht erkennen – die Zahlen beschreiben also nur einen Ausschnitt des Marktes. Plesk läuft auf Linux- und Windows-Servern.

Wer dahintersteht

Plesk entstand um 1999/2000 im russischen Nowosibirsk und gehörte danach unter anderem zu SWsoft und Parallels. Heute entwickelt es die Plesk International GmbH mit Sitz in Schaffhausen (Schweiz). Sie gehört zur Unternehmensgruppe WebPros, zu der auch cPanel zählt; Mehrheitseigentümer von WebPros ist seit 2020 der Finanzinvestor CVC Capital Partners (Firmengeschichte).

✔ Was für Plesk spricht

  • Bedienung im Browser, auch ohne Kenntnisse der Kommandozeile.
  • Viele Werkzeuge in einem Paket, etwa ein WordPress Toolkit für Updates und Sicherungen.
  • Eingebaute Schutzfunktionen wie die Web-Firewall ModSecurity und automatische IP-Sperren nach verdächtigen Zugriffen – genau die Mechanismen, die bei steuerratschlag.eu gegriffen haben.
  • Ein Notzugang zu den Dateien, wenn WordPress selbst streikt: Über den Dateimanager ließ sich das störende Plugin abschalten, obwohl das Backend nicht erreichbar war.

✘ Was an Plesk kritisiert wird

  • Steigende Lizenzpreise: Laut einer Auswertung des Branchendienstes webhosting.today stiegen die Listenpreise von 2020 bis 2024 je nach Paket um rund 50 bis 60 Prozent. Der Hoster IONOS führte 2025 für Kundinnen und Kunden mit virtuellem Server eine Plesk-Gebühr von 5 Pfund pro Monat ein und begründete das mit deutlich höheren Lizenzkosten (The Register). Diese Kosten landen am Ende bei den Website-Betreibern.
  • Wenig Wettbewerb: Plesk und cPanel, die beiden bekanntesten Lizenz-Oberflächen, gehören zum selben Konzern.
  • Sicherheitslücken: Eine große Software auf vielen Servern ist ein attraktives Angriffsziel. 2012 nutzten Angreifer eine Lücke in älteren Plesk-Versionen, laut Berichten waren rund 50.000 Domains betroffen.
  • Undurchsichtige Fehler: Die Schutzfunktionen greifen automatisch, sagen aber oft nicht, warum. Bei steuerratschlag.eu zeigten Sperre, Firewall-Abbruch und IP-Sperre nur nichtssagende Fehlerseiten – die Ursache stand jeweils erst in den Protokollen.

Für steuerratschlag.eu war Plesk bei allen drei Ausfällen das entscheidende Werkzeug: Dort standen Speicherverbrauch, Fehler- und Zugriffsprotokolle.

Anzeige
Anzeige

Der Grund stand in Plesk: Die Seite belegte 36,3 GB, in der Statistik als 35,4 GB Webspace geführt – 142 Prozent des Kontingents von 25 GB im Paket „Web Einsteiger“. Plesk kann ein Abonnement bei Überschreitung automatisch sperren – eine Standardfunktion der Software, die der Hoster für seine Pakete einstellt.

Der Speicher war fast vollständig mit Sicherungskopien belegt: ein Komplett-Backup des Plesk-Werkzeugs „WP Toolkit“ vom 28. Oktober mit 17,2 GB, dazu Sicherungen des Plugins UpdraftPlus aus den Jahren 2020 und 2026 mit zusammen mehr als 11 GB. Nach dem Aufräumen am 30. Oktober belegte die Seite noch 4,3 GB, rund 17 Prozent des Kontingents.

Ausfall 2: Firewall blockt das Dashboard

Zwei Tage später, am 31. Oktober, lud die Seite für Besucher wieder normal. Die Anmeldung im WordPress-Backend scheiterte aber: Nach dem Klick auf „Anmelden“ erschien eine nackte Fehlerseite „Internal Server Error“ mit dem Hinweis, man solle den Administrator unter „root@localhost“ kontaktieren – ein Standardtext des Webservers Apache, der nichts erklärt.

Screenshot aus dem Server-Fehlerprotokoll von steuerratschlag.eu vom 31.10.2026: ModSecurity meldet „Response body too large (over limit of 1048576)“ für /wp-admin/index.php, gefolgt von „Internal error“
Ausschnitt aus dem Server-Fehlerprotokoll von steuerratschlag.eu vom 31. Oktober 2026: Die Firewall ModSecurity bricht die Auslieferung des WordPress-Dashboards ab, weil die Seite größer als 1.048.576 Byte (1 MB) ist. IP-Adressen und Kennungen hat die Redaktion entfernt. Screenshot: NETZ-TRENDS.

Die Ursache stand im Fehlerprotokoll des Servers. Die Anmeldung selbst funktionierte. Erst beim Laden des Dashboards griff die Web-Firewall ModSecurity, die auf dem Server mit einem Regelwerk des Anbieters Comodo läuft. Sie meldete „Response body too large (over limit of 1048576)“: Die Seite war größer als 1 MB, die Firewall brach ab.

Aufgebläht hatte das Dashboard das Plugin Query Monitor. Es ist ein Werkzeug für Entwickler, das Datenbankabfragen, PHP-Fehler und weitere Diagnosedaten an jede Backend-Seite anhängt. Für angemeldete Admins hängt es an jede Backend-Seite ein großes Analysefenster an, mit allen Datenbankabfragen, Hooks (Andockstellen für Erweiterungen) und Skripten. Bei einer Seite mit vielen Plugins wie steuerratschlag.eu kommt das leicht über die Grenze von 1 MB. Normale Besucher/-innen bekommen dieses Fenster nie zu sehen – deshalb lief die Website selbst ganz normal, nur das Dashboard nicht. Laut Dateidatum war Query Monitor am 27. Oktober 2026 installiert oder aktualisiert worden, zwei Tage vor den Problemen.

Ganz sicher war die Diagnose zunächst nicht. Die übrigen Verdächtigen schieden aus: In den Must-Use-Plugins (mu-plugins, Erweiterungen, die WordPress immer automatisch lädt) lagen nur drei kleine, harmlose Dateien, auch sonst fiel im Plugin-Ordner nichts auf. Ob Query Monitor gerade aktiv war, ließ sich nicht direkt prüfen: Die Datenbank war in Plesk nicht verfügbar, und das WordPress Toolkit von Plesk öffnete sich nicht.

Abgeschaltet wurde das Plugin deshalb ohne Backend-Zugang: Claude benannte im Dateimanager von Plesk den Ordner „query-monitor“ in „query-monitor_deaktiviert“ um. Findet WordPress den Plugin-Ordner nicht mehr, deaktiviert es das Plugin sofort – und der Schritt lässt sich jederzeit rückgängig machen, indem man den alten Namen zurücksetzt. WordPress zeigt danach eventuell kurz den Hinweis, das Plugin sei deaktiviert worden, weil die Datei nicht existiert. Das ist normal. Für den Fall, dass der Login weiter hängt, standen als Nächstes die Plugins Jetpack und Site Kit auf der Liste. Das war nicht mehr nötig: Nach dem Umbenennen klappte die Anmeldung sofort wieder. Im Alltag wird Query Monitor nicht gebraucht und bleibt aus.

Einordnung: Wie streng ist 1 MB?

Die Musterkonfiguration von ModSecurity sieht sogar nur 512 KB vor – der Server von steuerratschlag.eu erlaubt also das Doppelte. Für Seiten über der Grenze empfiehlt die Musterkonfiguration allerdings, den Rest ungeprüft durchzulassen („ProcessPartial“), damit legitime Seiten nicht kaputtgehen. Auf dem Server von steuerratschlag.eu führte die Überschreitung laut Protokoll dagegen zum Abbruch.

Gefunden hat die Ursache der KI-Assistent Claude des US-Unternehmens Anthropic, mit dem die Redaktion arbeitet. Er prüfte zunächst, ob die Seite von außen erreichbar ist, riet dann zum Test über eine andere Verbindung und las schließlich das Fehlerprotokoll in Plesk aus. Dort stand der entscheidende Eintrag.

Tipp: Ist die Plesk-Anmeldeseite echt?

Bei der Fehlersuche leitete Plesk zwischendurch auf seine Anmeldeseite um – eine Adresse, die auf den ersten Blick verdächtig lang aussieht. Sie lässt sich aber lesen: Vorne steht der Servername beim Hoster, dahinter „:8443“, der übliche Anschluss (Port) für die Plesk-Verwaltung, dann „login_up.php“, die Anmeldeseite von Plesk. Der lange Rest hinter „success_redirect_url=“ sagt Plesk nur, wohin es nach der Anmeldung weiterleiten soll, etwa in den Dateimanager eines bestimmten Ordners. Entscheidend ist allein, dass in der Adresszeile genau der eigene Servername des Hosters steht – sonst könnte es eine gefälschte Seite sein, die Zugangsdaten abgreifen will.

Ausfall 3: Bots überlasten den Server

Am Nachmittag des 31. Oktober 2026 war steuerratschlag.eu erneut zeitweise nicht erreichbar, zwischendurch erschien eine Fehlerseite 500, das WordPress-Backend reagierte extrem langsam. Naheliegender Verdacht: Der Speicher läuft wieder voll. Claude ging deshalb die typischen Ablageorte für Altlasten im Dateimanager von Plesk Ordner für Ordner durch. Der Ordner für WordPress-Backups und der Plesk-Papierkorb waren leer, im Ordner „wp-snapshots“ lag nur ein leerer Unterordner aus dem Jahr 2016, im Ordner des Backup-Plugins BackWPup drei Kleinstdateien mit zusammen unter 1 KB.

Der belegte Platz steckt fast vollständig in den Bildern seit 2014, die in Beiträgen verlinkt sind und deshalb bleiben müssen. Etwas Platz brächten nur noch 23 inaktive Themes (Designvorlagen) mit rund 70 MB und sechs inaktive Plugins. Nötig ist das bei 25 GB Kontingent nicht – und mit dem dritten Ausfall hatte der Speicher nichts zu tun.

Die Ursache stand in den Zugriffsprotokollen des Servers in Plesk: Die Seite wurde massiv von Bots abgefragt, also von automatisierten Programmen, teilweise mit mehr als zehn Seitenaufrufen pro Sekunde. Zwei Gruppen fielen auf:

  • Scraper-Bots (Programme, die Inhalte massenhaft abgreifen): Hunderte IP-Adressen klapperten alte Schlagwort-Seiten (/tag/…) ab, etwa zu Bausparkassen oder zum Steuerbetrug bei der Société Générale. Die Adressen stammten aus wenigen Rechenzentrumsnetzen.
  • Server aus dem Netz von Amazon: Dutzende Rechner riefen immer wieder dieselben neuen Artikel und Bilder ab, zum Teil mehrmals pro Sekunde.

Jeder dieser Aufrufe zwingt WordPress, die Seite neu aus der Datenbank zu berechnen. Bei einem kleinen Webhosting-Paket reicht diese Last, um den Server lahmzulegen.

Die Abhilfe: Claude sperrte in der .htaccess – der Steuerdatei des Webservers Apache – elf auffällige Rechenzentrumsnetze. Der Eintrag steht als markierter Block „Bot-Sperre“ ganz oben in der Datei und lässt sich jederzeit wieder entfernen. Echte Leser/-innen und die Suchmaschine Google sind davon nicht betroffen. Seit 17:15 Uhr tauchen die gesperrten Bots nicht mehr im Protokoll auf. Startseite, Anmeldung und Schlagwort-Seiten laden seitdem wieder in ein bis drei Sekunden.

IP-Sperren: Schutz mit Nebenwirkungen

Für den Herausgeber kam ein drittes Ärgernis hinzu: Nach seinen Angaben wurde der eigene Internetanschluss innerhalb einer Woche zweimal vom Server ausgesperrt. Die Seite lud dann über die eigene Leitung nicht mehr, während sie von anderen Anschlüssen aus erreichbar war. Erst über ein VPN (Virtual Private Network), das den Datenverkehr über einen anderen Server leitet, kam er wieder an das Backend.

Solche automatischen Sperren sind auf Hosting-Servern üblich und haben gute Gründe: Sie wehren Angriffe auf Anmeldeseiten ab, bei denen Bots massenhaft Passwörter durchprobieren. Fritz Managed IT nennt in seinem Kundenportal eine verhaltensbasierte Erkennung, Virenschutz und ein rund um die Uhr besetztes Sicherheitsteam. Wer jedoch selbst mehrfach falsche Zugangsdaten eingibt, kann zum Opfer dieser Schutzmechanismen werden – und muss die Freigabe beim Support beantragen, der laut Kundenportal montags bis freitags von 9 bis 17 Uhr erreichbar ist.

Auch am 31. Oktober traf es den Herausgeber erneut: Während steuerratschlag.eu von außen wieder normal lud, schlugen Abrufe aus seinem Browser sofort fehl, während netz-trends.de bei einem anderen Hoster erreichbar blieb. Wahrscheinlichste Erklärung: Die Firewall des Hosters hatte seine IP-Adresse nach den vielen Aufrufen des Tages gesperrt – durch das wiederholte Neuladen des Backends und die Prüfungen während der Fehlersuche. Solche Sperren lösen sich oft nach 15 bis 60 Minuten von selbst, sonst hilft eine Freigabe durch den Support.

Was sich daraus lernen lässt

Checkliste für WordPress-Seiten

  • Backups nie dauerhaft auf demselben Webspace liegen lassen, sondern extern speichern und nur wenige Sicherungen aufbewahren.
  • Speicherverbrauch regelmäßig in der Hosting-Oberfläche prüfen, nicht erst bei einer Sperre.
  • Entwickler-Plugins wie Query Monitor nur zur Fehlersuche einschalten und danach deaktivieren.
  • Bei „Internal Server Error“ zuerst das Fehlerprotokoll des Servers lesen – dort steht die Ursache, auf der Fehlerseite nicht.
  • Zugriffsprotokolle regelmäßig auf auffällige Bots prüfen und Rechenzentrumsnetze, die die Seite überfluten, per .htaccess sperren.
  • Ein verdächtiges Plugin ohne Backend-Zugang abschalten: im Dateimanager des Hosters den Plugin-Ordner umbenennen – rückgängig machen geht durch Zurückbenennen.
  • Bei Verdacht auf eine IP-Sperre die Seite über Mobilfunk oder eine andere Verbindung testen und die eigene IP-Adresse an den Support melden.

Alle drei Ausfälle sind inzwischen behoben. Folgenlos bleibt so etwas für ein Nachrichtenportal trotzdem nicht: Solange die Seite steht, fehlen Zugriffe und Werbeeinnahmen.

Häufige Fragen

Was bedeutet „503 Service Unavailable“?

Der Server ist erreichbar, kann die Seite aber gerade nicht ausliefern. Bei steuerratschlag.eu lag es an der automatischen Sperre wegen überschrittenen Speichers.

Was bedeutet „Internal Server Error“?

Fehler 500 heißt, dass beim Erzeugen der Seite etwas schiefging. Im Fall von steuerratschlag.eu brach die Firewall ModSecurity die Auslieferung ab, weil das Dashboard größer als 1 MB war.

Muss man Query Monitor löschen?

Nein. Es reicht, das Plugin nur bei Bedarf zu aktivieren. Im Alltag wird es nicht gebraucht.

Wie erkennt man, ob Bots eine Seite überlasten?

Im Zugriffsprotokoll (Access-Log) des Servers: Viele Aufrufe pro Sekunde aus wenigen Rechenzentrumsnetzen, oft auf alte Schlagwort- oder Archivseiten, sind ein typisches Zeichen. Normale Leser/-innen rufen nie mehrere Seiten pro Sekunde ab.

Quellen und Stand

Recherche- und Datenstand: 31. Oktober 2026.

Transparenz: Dieser Beitrag wurde mit Unterstützung künstlicher Intelligenz recherchiert und formuliert und ist zur menschlichen redaktionellen Prüfung vorgesehen.

Kommentar schreiben