Ich bin sicher, dass die Ursache des Problems bei KeyHelp liegt
gute Frage
Server-Betriebssystem + Version
Ubuntu 24.04
Eingesetzte Server-Virtualisierung-Technologie
keine
KeyHelp-Version + Build-Nummer
25.1 (Build 3433)
Problembeschreibung / Fehlermeldungen
Hohe Antwortzeit einer Domain
Erwartetes Ergebnis
normale Antwortzeit
Tatsächliches Ergebnis
hohe Antwortzeit
Schritte zur Reproduktion
keine
Zusätzliche Informationen
nichts
wie ihr ja wisst, nutze ich kuma auf einem anderen server. Nun ist die Sache so, das Kuma für meine Hauptdomain eine normalen Ping (zwischen 28 und 60ms) liefert, aber meine Subdomain einen dauerhaften Ping zwischen 250 und 280ms. einen Ping von der Konsole des kuma-servers liefert das gleiche ergebnis. Der keyhelp-server und der kuma-server haben den gleichen Standort (Wolfsburg), also sollte es daran nicht liegen. Einen ping von der konsole des keyhelp-server zum kuma-server liefert auch niedrige Antwortzeiten. Nun die Frage, woran kann es liegen? die Subdomain ist nicht ausgelastet oder dergleichen.
Data Collector für Community Support
___
Ich verwende zwei verschiedene Schriftfarben in meinen Beiträgen /
I use two different font colors in my posts:
In dieser Farbe schreibe ich als Moderator und gebe moderative Hinweise oder begründe moderative Eingriffe /
In this color, I write as a moderator and provide moderative guidance or justify moderative interventions
In dieser Farbe schreibe ich als Community Mitglied und teile meine private Meinung und persönlichen Ansichten mit /
In this color, I write as a community member and share my personal opinions and views
BTW:
Wenn du auf deinem Server keine hochgeheimen Sachen betreibst, dann wäre es für uns hilfreich um dir zielführend zu helfen, wenn du uns die fragliche (Sub-)Domain verraten würdest.
Dann würden wir von extern die Ladezeiten überprüfen können, um dir so eine erste Fehleranalyse und mögliche Lösungsansätze anbieten zu können.
Data Collector für Community Support
___
Ich verwende zwei verschiedene Schriftfarben in meinen Beiträgen /
I use two different font colors in my posts:
In dieser Farbe schreibe ich als Moderator und gebe moderative Hinweise oder begründe moderative Eingriffe /
In this color, I write as a moderator and provide moderative guidance or justify moderative interventions
In dieser Farbe schreibe ich als Community Mitglied und teile meine private Meinung und persönlichen Ansichten mit /
In this color, I write as a community member and share my personal opinions and views
Jolinar wrote: ↑Wed 9. Jul 2025, 07:44
BTW:
Wenn du auf deinem Server keine hochgeheimen Sachen betreibst, dann wäre es für uns hilfreich um dir zielführend zu helfen, wenn du uns die fragliche (Sub-)Domain verraten würdest.
Dann würden wir von extern die Ladezeiten überprüfen können, um dir so eine erste Fehleranalyse und mögliche Lösungsansätze anbieten zu können.
ooops klar, kein Problem. die subdomain ist iucloud.uaena.info. die hauptdomain logischerweise www.uaena.info
und bevor jemand sagt: "ja normal bei cloudsoftware"... es finden keinerlei interaktionen mit der subdomain statt, weder von aussen noch von "innen" ;p
auch führt die sub keinerlei arbeiten aus im Hintergrund. nicht einmal einen cron oder dergleichen. laut monitoring ist es komplett ruhig.
ping iucloud.uaena.info
PING uaena.info (185.45.149.4) 56(84) bytes of data.
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=1 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=2 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=3 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=4 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=5 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=6 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=7 ttl=58 time=15.3 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=8 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=9 ttl=58 time=15.1 ms
ping uaena.info
PING uaena.info (185.45.149.4) 56(84) bytes of data.
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=1 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=2 ttl=58 time=15.6 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=3 ttl=58 time=17.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=4 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=5 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=6 ttl=58 time=15.3 ms
Wenn Dein Uptime Kuma nur Ping nutzt spielt es ja auch keine Rolle was auf der Domain läuft. Ping hat ja nichts mit Ladezeiten zu tun.
Mach einen Traceroute zu Domain und Subdomain. Ggf sieht man da mehr wo der Unterschied herkommt.
Mit freundlichen Grüßen / Best regards
Florian Cheno
**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
ping iucloud.uaena.info
PING uaena.info (185.45.149.4) 56(84) bytes of data.
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=1 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=2 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=3 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=4 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=5 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=6 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=7 ttl=58 time=15.3 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=8 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=9 ttl=58 time=15.1 ms
ping uaena.info
PING uaena.info (185.45.149.4) 56(84) bytes of data.
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=1 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=2 ttl=58 time=15.6 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=3 ttl=58 time=17.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=4 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=5 ttl=58 time=15.1 ms
64 bytes from 4.149.45.185.in-addr.arpa (185.45.149.4): icmp_seq=6 ttl=58 time=15.3 ms
Wenn Dein Uptime Kuma nur Ping nutzt spielt es ja auch keine Rolle was auf der Domain läuft. Ping hat ja nichts mit Ladezeiten zu tun.
Mach einen Traceroute zu Domain und Subdomain. Ggf sieht man da mehr wo der Unterschied herkommt.
jap löst die IP auf, haben ja beide dieselben. kuma fragt die domains direkt ab, keine ahnung wie. habe es übrigens mit uptimerobot getestet und habe dort das selbe Problem.
Der Monitor schaut per HTTPs
ja sorry, es ist eine HTTPs Anfrage (Nutze ich auch wegen der Zertifikatsüberprüfung, das geht mit Ping nicht). Verstehe trotzdem nicht warum die Antwortzeit in Kuma (und uptimerobot) bei der Subdomain so hoch ist (und nur bei der Subdomain). Hier noch einmal die Traceroute per Konsole auf dem Kuma-Server.
vergiss den Trace. Wenn du HTTPs nutzt hat es ganz einfach mit der Software zu tun die auf der Domain läuft. Der Webserver braucht einfach unterschiedlich lange, sieht man auch wenn man die Time to first byte misst:
vergiss den Trace. Wenn du HTTPs nutzt hat es ganz einfach mit der Software zu tun die auf der Domain läuft. Der Webserver braucht einfach unterschiedlich lange, sieht man auch wenn man die Time to first byte misst:
ahhh ich brauch dringend hilfe. meine 2te subdomain ist nicht mehr erreichbar. habe 2 bilder über ftp hochgeladen und normal nur mit dem "<img" in eine html eingebaut, also ganz harmlos. dann habe ich die subdomain refreshed und seitdem lädt sie ohne ergebnis. habe natürlich alles rückgängig gemacht, trotzdem lädt sie unendlich. habe den apache2 auch über konsole neu gestartet, keine Änderungen. Der Rest an hp und andere subdomains laufen normal. aber diese ist einfach nicht mehr erreichbar. Was nun? es kommt kein Fehler, nichts. unter /var/log/apache2/keyhelp/ habe ich alle logdateien angeschaut. keine Eintragungen an fehlern. gibt es irgendwo eine extra log datei für diese subdomain?
unter /var/log/apache2/keyhelp/ habe ich alle logdateien angeschaut. keine Eintragungen an fehlern. gibt es irgendwo eine extra log datei für diese subdomain?
Unter /var/log/apache2/keyhelp/ liegen nur die Zugriffsprotokolle von KeyHelp.
Logs für Domains und Subdomains liegen unter /home/users/<USERNAME>/logs/<DOMAIN>. Bequemer geht es direkt über die UI über die Domain-Übersicht unter Aktionen auf das entsprechende Icon für Logs ("Protokolle anzeigen") klicken.
Mit freundlichen Grüßen / Best regards
Alexander Mahr
**************************************************************
Keyweb AG - Die Hosting Marke
Neuwerkstr. 45/46, 99084 Erfurt / Germany http://www.keyweb.de - http://www.keyhelp.de
**************************************************************
unter /var/log/apache2/keyhelp/ habe ich alle logdateien angeschaut. keine Eintragungen an fehlern. gibt es irgendwo eine extra log datei für diese subdomain?
Unter /var/log/apache2/keyhelp/ liegen nur die Zugriffsprotokolle von KeyHelp.
Logs für Domains und Subdomains liegen unter /home/users/<USERNAME>/logs/<DOMAIN>. Bequemer geht es direkt über die UI über die Domain-Übersicht unter Aktionen auf das entsprechende Icon für Logs ("Protokolle anzeigen") klicken.
uff danke, konnte das Problem damit lösen. danke sehr. das Panel ist wirklich sehr bequem