@Melone145 dein curl-Test misst leider die falsche Seite. curl schickt von sich aus kein
Accept-Encoding: gzip, du hast also den unkomprimierten Weg gemessen und der war ja nie kaputt. Interessanter wärs mit
curl -k --compressed -o /dev/null -w '%{size_download} %{size_request}\n' https://deinepve:8006/pve2/js/pvemanagerlib.js gewesen, und dass das jetzt mit COMPRESSION=0 geht passt ja auch dazu.
Was mich aber stutzig macht: du hast in #11
pve-manager reinstalliert und danach pveproxy nie neu gestartet. pveproxy hält die statischen Dateien im Speicher, wenn der Worker noch mit dem alten Stand läuft und die Datei sich ändert, kann ein Längen-Mismatch rauskommen. Der
systemctl restart pveproxy steckte ja in deinem Fix mit drin. Kann also sein, dass nicht die Kompression schuld war sondern nur der alte Worker. Nimm die Zeile aus
/etc/default/pveproxy mal wieder raus, pveproxy neu starten, Cache im Browser leeren und schau ob es läuft. Wenn ja, hast du deine Antwort und brauchst die Kompression gar nicht ausknipsen. Wenns dann wieder weiß wird, ist es wirklich der gzip-Pfad und dann würd ich gucken was dazwischen sitzt, du gehst ja direkt über eine öffentliche IP drauf.
Btw, die GUI mit 8006 offen im Netz würd ich nicht stehen lassen, da klopfen die Bots ziemlich schnell an.