Vielen herzlichen Dank für die sehr naheliegende Lösung, obwohl es ja verpöhnt ist, wegen jedem kleinen Hüsterchen den Server neu zu starten. Aber in dem Fall kann ich mich nun um neue wichtigere Aufgaben kümmern.

Besten Dank nochmals und liebe Grüße !

Nach einem erneuten Reboot scheint es nun zu funktionieren - sehr gute Idee und vielen lieben Dank! Aber wie kann sowas sein?

Jolinar wrote: ↑Sat 6. Apr 2024, 20:55

goldene-zeiten wrote: ↑Sat 6. Apr 2024, 20:52 LIeber wäre mir, ich könnte den Fehler komplett beseitigen

Dann mach das doch

24unix wrote: ↑Sat 6. Apr 2024, 20:38 Lösung: IPv6 ans Laufen bringen

Der Hinweis wurde ja schon gegeben.
Wie sieht denn deine aktuelle Netzwerkkonfiguration aus?

Noch bin ich damit überfordert.

24unix wrote: ↑Sat 6. Apr 2024, 20:54 Wann hast Du den letzten reboot gemacht?

Vor wenigen Tagen, um auszuschließen, dass es daran liegt Aber das kann ich sehr gerne machen, um zu sehen, was dann passiert.

Zunächst einmal vielen lieben Dank, dass du dich der Sache annimmst. Den Workaround würde ich weniger gern wählen. LIeber wäre mir, ich könnte den Fehler komplett beseitigen. Bei einem anderen Root-Server von Ionos klappt es ja auch - nur eben beim Server seit wenigen Tagen nicht...

root@superbrain:~# ip a 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo valid_lft forever preferred_lft forever inet6 ::1/128 scope host valid_lft forever preferred_lft f...

Also die IP hat sich nicht geändert. Laut Fehlermeldung soll ja die Firewall schuld sein. Nun ist die Frage, ob es die von Ionos oder die von KeyHelp ist. Und vor allem: warum ging es bisher und nun nicht mehr?

Das scheint eine sehr interessante Fährte zu sein. Die IP lautet 2001:8d85f5::1 und tatsächlich kommt beim PIng:

Liebe KeyHelp-Freunde, auf einem Server von mir bekomme ich seit einigen Tagen eine Rückmeldung, dass im Grunde genommen alle Zertifikate nicht mehr neu erstellt werden können (wegen einem Problem mit der Firewall, welches es aber wohl vorher nicht gab): Failed to aquire a Let's Encrypt certificate ...

Tatsächlich verdichtet sich nun der Verdacht, dass es am OPCache liegt. Denn heute hatte ich mit einer unserer Hauptpräsenzen den gleichen Fehler (503) und die basieren alle auf TYPO3. Und als ich dann die Caches löschte, war der Fehler auch wieder weg. Doch wo fängt man da an zu suchen? Nichtsdesto...

Also doch das Plugin Wordpress deaktivieren? ;) Bisher habe ich es noch nicht geschafft, einen 503 von irgendeiner der Seiten zu bekommen. Bist du angemeldet wenn es passiert? Auch gesetzte Cookies für die Domain könnten einen Einfluss haben, siehe auch max_input_vars. Ok, dass Fezzi das Problem vo...

Seite laeuft hier fluessiger als je zuvor... Ich werde das Gefuehl nicht los dass da was in Deinem Caching der Seite nicht richtig funkt... Jetzt ist es ja seit gestern auch so, dass die Seite gut und performant läuft. Das ist dann nicht nur in Thailand sondern auch hier in Deutschland so. Warten w...

Nun lief die Seite mit den neuen Einstellungen für eine Stunde einwandfrei. Nun leider wieder nicht mehr. Da wird doch der Hund in der Pfanne verrückt.

Ich hatte mal ein aehnliches Problem.... Was bei mir geholfen hat war das aus tarieren der pm.max_requests ... diese also nicht auf 0 lassen (hatte ich vorher auch... und der Server hat ausreichend Ressourcen und wurde nicht ueberlastet) sondern sich antasten was am Besten funkt... Der Wert 500 mit...

Also der JIT war es wohl doch nicht nur allein: -- [Sun Feb 04 11:40:55.032231 2024] [proxy_fcgi:error] [pid 3727:tid 140535671907904] [remote 2a01:c22:6ff7:6e00:b976:8f2c:5bf1:8f96:52582] AH01067: Failed to read FastCGI header, referer: https://www.verlobung-und-hochzeit.info/wp-login.php?action=en...