Webseite fällt aus "„proxy_fcgi:error“ - Hat Jevents was damit zu tun?

    Joomla Version
    5.4.2
    PHP Version
    PHP 8.3.x
    Hoster
    alfahosting

    Ich habe eine Webseite (Provider hosting) die immer wieder auch mal längere Zeit ausfällt (5 min bis 6+ h), bzw nicht erreichbar ist. (403 fehler glaub ich)
    Kontakt mit dem Provider ist da. Er erklärt mir, dass die Meldungen aus dem error_log:
    "[proxy_fcgi:error] [pid 3530021:tid 140520105957120] (70007)The timeout specified has expired:....."
    PHP-Anfragen nicht rechtzeitig beantwortet wurden oder die Verbindung vom PHP-Prozess unerwartet beendet werden..

    Teilweise steht hinter dieser Meldung nichts weiter.
    Sehr oft, bei den vielen Meldungen im errorlog, steht aber auch eine Pfadangabe der Komponente Jevents.
    Beispiele:
    Termine
    Termine
    Kindersportgruppe des SSV


    Das Problem geht schon eine Weile, ist aktuell nur recht häufig. Der umzug zu "Cloudpit" sollte nichts damit zu tun haben...
    Welche Skripte die lange laufen, blockieren oder ungewöhnlich viele Ressourcen benötigen könnten das sein ? Wie könnte ich als Amateur weiter einkreisen...

    Der Provider schreibt auch:
    Das 110% CPU-Limit und die 512 MB RAM, reichen im aktuellen Tarif da immer wieder mal nicht aus und so "fällt die Seite aus"
    Mit einer Änderung des Vertrages kann man das umgehen, aber das behebt ja nicht den Problemursprung.

    Auf der Webseite sind keine verrückte Komponentne installiert, kein admintool oder ander "Verbesserungsdinge".
    Andere Hinweise auf Erweiterungen sind nicht zu finden...

    installiert sind: akeeba,BA-monkey, EJB (noch), JCE, Phocca gallery, Phoca Download, , Regular Labs - Tabs & Accordions (aktuelle versionen)

    und Jevent 3.6.97 natürlich...
    Ein grosseer Besucheraufwand, Benutzer login oder so, hat auch nichts damit zu tun, den gibt es nicht. zeitlich auch völlig wahllosser ausfall...
    Gruss Marco

    ... bis zum Spiel!
    Gruss Marco L.

    Viviana, du meinst die access_log oder access_ssl_log ?
    Kann man die hier mal posten?

    so was wie meta-externalagent taucht da auf... aber eben immer wieder links von jevent...
    vor dem umzug auf cloudpit (bei alfahosting) waren in einer htaccess schon mal paar IP adressse geblockt. hat aber eher schlecht als recht funktioniert... aktuell ist die htaccess nicht aktiviert...

    114.119.144.29 - - [02/Feb/2026:06:36:15 +0100] "GET /index.php/termine/eventsnachtag/2023/10/22/87 HTTP/1.1" 200 44898 "https://www.ssv1863sayda.de/index.php/termine/monatskalender/2023/10/87" "Mozilla/5.0 (Linux; Android 7.0;) AppleWebKit/537.36 (KHTML, like Gecko) Mobile Safari/537.36 (compatible; PetalBot;+https://webmaster.petalsearch.com/site/petalbot)" PHP-Handler:plesk-php83-fpm Remoteport(vom Nginx):61450

    oder
    57.141.20.0 - - [02/Feb/2026:05:53:06 +0100] "GET /index.php/bildergalerie/40-jahr-2024 HTTP/1.1" 503 1362 "-" "meta-externalagent/1.1 (+https://developers.facebook.com/docs/sharing/webmasters/crawler)" PHP-Handler:- Remoteport(vom Nginx):31216

    ... bis zum Spiel!
    Gruss Marco L.

    Eventuell nützlich:

    https://www.joomla.de/wissen/joomla-…ormanceprobleme

    Zitat von eumel1602

    ...aktuell ist die htaccess nicht aktiviert...

    Sollte man eigentlich möglichst immer aktiviert haben wenn die Website öffentlich zugänglich ist, weil auch einige Sicherheitsvorkehrungen darin enthalten sind.

    Wenn die Website mal nicht geht, kannst auch zum testen mal schauen ob sich derlei Seiten:

    ssv1863sayda.de/index.php/impressum?template=cassiopeia

    ssv1863sayda.de/index.php/impressum?tmpl=component

    dann auch nicht aufrufen lassen. Dies sind ja Seiten die entweder mit Cassiopeia(Link1) oder mit wenig sonstigem "Balast"(Link2) geladen werden...

    Ich hatte das Problem bei einer Kundenseite mit JFilters, die Bots haben alle möglichen Filter-Kombinationen aufgerufen und dadurch Unmengen an Traffic verursacht. Ich könnte mir vorstellen, dass es bei JEvents ähnlich ist. Die KI-Bots haben die Sperre in robots.txt ignoriert, ich musste sie in der htaccess blockieren.

    Ich benutze manchmal einen uralten, lokalen Link-Checker: Xenu. Wenn ich den auf eine Seite mit jEvents loslasse, prüft der auch zigtausende Links, die offenbar von Jevents kommen. Möglicherweise laufen die Bots in die gleiche Falle.

    Deshalb würde ich dem Rat von drmenzelit folgen und die Bots per .htaccess aussperren.

    Freundliche Grüße aus Wächtersbach, Rolf Dautrich

    Zitat von eumel1602

    so was wie meta-externalagent taucht da auf... aber eben immer wieder links von jevent...

    Viviana hat es gesagt: meta ist extrem aggressiv und hatte bei uns vorletztes Jahr jede einzelnen über JEvents verwalteten Event mehrmals pro Sekunde über mehrer IP-Adressen abgefragt. Das Datentransfervolumen war dann teilweise 400 GB am Tag groß und der Provider (IONOS) hat dann unsere Seite einig Tage wegen Überlastung gesperrt. Geholfen hat zunächst die Sperrung der IP-Adressen über die htaccess. Das ist leider eine mühsame Arbeit aber nach unserer Erfahrung der einzige Weg.

    Das Gute: meta beachtet offenbar die robots.txt - das hilft spürbar

    Das Schlechte: es gibt noch viele weitere agressive Datendiebe: Chinesen, Vietnamesen, US-Americaner, Briten, Franzosen, OpenAI, . . .

    Im Zusammenhang mit JEvents wird überall jeder einzelen Event abgefragt. Diese Erfahrung haben auch andere machen müssen (hat hier im Forum auch jemand in den letzten Tagen berichtet) . Bei uns ist das besonders gravierend, da wir als Tanzsportverein ein sehr große Zahl von Veranstaltungen haben.

    Aber wir haben es im Griff - u.a. durch regelmäßige Kontrolle der log-Files und Update der htaccess bei Bedarf.

    Gruß

    Heinz

    "Wer es nicht versucht schafft es auch nicht."

    Zitat von eumel1602

    Kann mir einer den bevorzugten code nennen um sie auzuschließen... ? ich geh mal on den IPs aus oder?

    Dazu folgendeer Nachtrag: die Anweisung zur Sperrung wäre Require not ip IP-Adresse

    Das hat allerdings den Nachteil, dass für jede einzelne IP.Adreese eine Anweisung in die htaccess eingetragen werden müsste. Sinnvoll ist daher die Sperrung ganzer IP-Bereiche wie z.B. durch Require not ip 62.113.113.0/24. Dadurch werden in diesem Beispiel gleich mal 255 IP-Adressen von Huawei gesperrt. (Trotzdem waren bei Huawei immer noch ca. 25 dieser Anweisungen erforderlich)

    Die IP-Bereiche lassen sich ermitteln über https://www.whois.com/whois/ für IP4. Leider werden hier IP6-Adressen nicht analysiert. Die Syntax einer Bereichsdefinition wird entweder auch dort angegeben oder kann ermittel werden über https://iamroot.tech/cidr/.

    IP6-Adressen werden übrigens sehr häufig von deutschen Telekomfirmen (Telekom, Vodafone, Deutsche Glasfaser, ...) verwendet und die sollten nicht gesperrt werden, da sonst die Webseite im Zweifel nicht mehr errichbar ist. Ich benutze dazu sehr zuverlässig https://www.geolocation.com/

    Gruß

    Heinz

    "Wer es nicht versucht schafft es auch nicht."

    Wenn du diese IP-Adresse bei whois.com eingibst erhälst du u.a. die Information über den gesamten von hetzner genutzten Bereich

    Code
    % Abuse contact for '116.203.208.0 - 116.203.223.255' is '@hetzner.com'

    Damit ist klar, dass der Bereich 116.203.213.0 bis 116.203.213.255 zu hetzner gehört. Beide Werte eingegegeben bei https://iamroot.tech/cidr/ als lower und upper address ergibt als cidr-code

    116.203.213.0/24

    und als Anweisung für die htaccess

    Require not ip 116.203.213.0/24

    Du kannst natürlich auch beide Werte aus whois.com benutzen, also 116.203.213.0 und 116.203.223.255, erhälst dann aber als cidr-code 116.203.192.0/18 und bist damit erst einmal ausserhalb des von whois angegebenen Bereiches und weisst halt nicht, wenn du unnötigerweise ebenfalls aussperrst. Da hilft dann nur ausprobieren bzw. prüfen. Im konkreten Fall wäre das ebenfalls hetzner und ein Sperrung würde keine Seiteneffekte haben, was im Zweifel unangenehm wird, wenn sich z.B. Nutzer der Telekom oder Vodafone beschweren, dass sie nicht mehr auf die Webseite zugreifen können.

    Will damit sagen, dass geprüft werden muss, wer hinter der IP-Adresse steckt. hetzner habe ich persönlich nicht ausgeschlossen, da nur selten (im Vergleich zu den Chinesen etc.) bei uns zugegriffen wird. Das kann aber auch am Charakter der Webseite liegen.

    Gruß

    Heinz

    "Wer es nicht versucht schafft es auch nicht."