Ruhiges IT-Forum

Hallo,
ich habe seit einiger Zeit ein Problem, das ich einfach nicht lösen kann.
Wenn ich die Homepage des Servers über HTTP aufrufe, funktioniert alles einwandfrei; sie lädt sofort. Über HTTPS dauert es jedoch mindestens zehn Sekunden, bis ich überhaupt die Anmeldemaske sehe.
Das Starten der Konsole (die auf HTTPS verweist) funktioniert problemlos, aber ich erhalte gelegentlich Timeouts auf der WUA-Seite bei bestimmten Clients (nicht immer denselben) mit der Fehlermeldung „THttpClientSocket.OpenBind(wapt1.xxx.xxx.com:443): Ist ein Server unter dieser Adresse:Port verfügbar? [remoteip=] [#3 Nicht gefunden]“. In den

Nginx- und Wapt-Logs ist nichts Auffälliges zu finden. Hat jemand eine Idee, woran das liegen könnte?

Ich habe den Eindruck, dass das Problem nach dem Update von Version 2.5 auf 2.6 aufgetreten ist.

Vielen Dank.

WAPT 2.6.1.17576,
Debian 12 Server
, erstellter Rechner: Windows 11 24h2

Wenn das Problem mit HTTPS zusammenhängt, vermute ich, dass es an fehlenden Flags auf der CPU-Seite liegt.

Sie können das Ergebnis Ihrer Bestellung zurücksenden!

Code: Alle auswählen

cat /proc/cpuinfo |grep flags

Dort :

Code: Alle auswählen

root@WAPT1:~# cat /proc/cpuinfo |grep flags
flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology cpuid tsc_known_freq pni ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm cpuid_fault pti
flags           : fpu de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx lm constant_tsc nopl xtopology cpuid tsc_known_freq pni ssse3 cx16 sse4_1 sse4_2 x2apic popcnt aes hypervisor lahf_lm cpuid_fault pti

Dies ist eine Proxmox-VM, CPU-Typ x86-64-V2-AES, Maschinentyp i440fx

Kommandant

Vincent38 schrieb: ↑24. Nov. 2025 - 11:55 Uhr Es handelt sich um eine Proxmox-VM, CPU-Typ x86-64-V2-AES, Maschinentyp i440fx

Es wäre interessant zu sehen, ob AES emuliert wird (was Strom verbraucht).

Sie können auf Host-CPU umschalten, um zu sehen, ob

Code: Alle auswählen

cat /proc/cpuinfo |grep flags

bezieht sich immer auf aes

Tatsächlich ist das AES verschwunden, aber das hat das Problem nicht gelöst.

Code: Alle auswählen

root@WAPT1:~# cat /proc/cpuinfo |grep flags
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat umip md_clear flush_l1d arch_capabilities
vmx flags       : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid shadow_vmcs pml
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ss ht syscall nx pdpe1gb rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid tsc_known_freq pni pclmulqdq vmx ssse3 fma cx16 pdcm pcid sse4_1 sse4_2 x2apic movbe popcnt tsc_deadline_timer aes xsave avx f16c rdrand hypervisor lahf_lm abm 3dnowprefetch cpuid_fault invpcid_single pti ssbd ibrs ibpb stibp tpr_shadow vnmi flexpriority ept vpid ept_ad fsgsbase tsc_adjust bmi1 hle avx2 smep bmi2 erms invpcid rtm rdseed adx smap xsaveopt arat umip md_clear flush_l1d arch_capabilities
vmx flags       : vnmi preemption_timer posted_intr invvpid ept_x_only ept_ad ept_1gb flexpriority apicv tsc_offset vtpr mtf vapic ept vpid unrestricted_guest vapic_reg vid shadow_vmcs pml
root@WAPT1:~#

Dieses Problem gab es (meines Wissens) in Version 2.5 nicht, aber ich erinnere mich nicht, dass ich während der Migration auf 2.6 irgendetwas auf der VM-/OS-Seite geändert hätte.
Vielleicht gab es ein Problem bei der Migration? Vor allem, da ich mich zu erinnern meine, vor ein paar Tagen etwas Merkwürdiges mit dem Zertifikat (einem selbstsignierten) bemerkt zu haben, als ich nach der Ursache suchte, aber leider kann ich mich nicht mehr erinnern, wie oder welchen Befehl ich verwendet habe, um dieses Merkwürdige zu sehen.

Ich hatte vor, zu Testzwecken ein neues Zertifikat zu erstellen, konnte aber die entsprechende Vorgehensweise nicht finden.

Zum Glück hatte ich mich daran erinnert, nach diesem Fehler gegoogelt zu haben, und konnte ihn daher in meinem Verlauf finden. Das Zertifikat ist bis 2033 gültig, aber es erscheint die Meldung „CRL-Validierungsfehler im Zertifikat“.
Ich muss bei der Migration einen Fehler gemacht haben; ich hatte schon immer Schwierigkeiten, diese Zertifikatsprobleme zu verstehen.

Vincent38 schrieb: ↑24. Nov. 2025 - 12:54 Uhr AES ist zwar verschwunden, aber das hat das Problem nicht gelöst.

aes ist tatsächlich vorhanden

Das ist es also nicht.

Eine der größten Änderungen zwischen Version 2.5 und 2.6 ist die Clientzertifikatsauthentifizierung.

Ich sehe eigentlich nicht, was die Sache verlangsamen könnte.

Okay, gut, ich lasse es jetzt gut sein. Da Debian 13 jetzt verfügbar ist, sichere ich den Server und installiere ihn neu, in der Hoffnung, dass das Problem damit behoben ist.

Zwei Fragen:

Mir geht langsam der Speicherplatz aus, weil noch alte Windows-Updates auf dem Server sind. Wird der Ordner `/var/www/waptwua/` beim Backup automatisch bereinigt? Lädt Wapt dann die benötigten Dateien erneut herunter?

In der Wiederherstellungsanleitung ist von einer Standardinstallation die Rede, aber ist es notwendig, `postconf.sh` auszuführen?
Vor allem, da der Server nach dem Import der alten Daten neu gestartet werden muss?

Okay, ich habe noch keine Neuinstallation durchgeführt, aber seltsamerweise verschwand das Problem nach dem gestrigen Update des WAPT-Servers

; keine Verzögerungen oder Timeouts mehr.
Wir können dieses Thema schließen!

Ruhiges IT-Forum

Langsamer Zugriff auf die Server-Startseite/Timeout während Aktualisierungen

Langsamer Zugriff auf die Server-Startseite/Timeout während Aktualisierungen

Betreff: Langsamer Zugriff auf die Server-Startseite/Timeout bei Aktualisierungen

Betreff: Langsamer Zugriff auf die Server-Startseite/Timeout bei Aktualisierungen

Betreff: Langsamer Zugriff auf die Server-Startseite/Timeout bei Aktualisierungen

Betreff: Langsamer Zugriff auf die Server-Startseite/Timeout bei Aktualisierungen

Betreff: Langsamer Zugriff auf die Server-Startseite/Timeout bei Aktualisierungen

Betreff: Langsamer Zugriff auf die Server-Startseite/Timeout bei Aktualisierungen

Betreff: Langsamer Zugriff auf die Server-Startseite/Timeout bei Aktualisierungen

Betreff: Langsamer Zugriff auf die Server-Startseite/Timeout bei Aktualisierungen