This situation defies explanation as "the problem" seems to not only happen by itself but also by some unknown parameters.
The end result is the Proxmox Web Interface loading then not loading.
The errors below are reproducible ERR_CONTENT_LENGTH_MISMATCH could be related due openssl or other related issues
I've ran into this before and found this to be particular to the MTU not being set consistenly, not this time though.
The files are double-triple check to be there in /usr/share/javascript and have 644 permission all over.
I've ran into this issue before. This time again it seems to be originating from Proxmox itself not by some mishap or network misalignment.
Feedback and or a how-to-fix is appreciated. Even better would be for this to be fixed in what may be code.
-- situation
- proxmox server running since +2 years
- switch in place since 1 year
- laptop connects to switch which connects to proxmox (no prior issues)
- was done to see if the network connectivity is okay using wireshark ( packets flow as expected )
- was done to see if packets are arriving and returning on the servers side (they do and match wireshark at client side)
- to see if the webpage loads by running the debugger (F12) ( page loads normal yet somewhat slow )
- clear the browser cache
- restart the browser
- align the MTU across switch ports, network interface, bridges
- unplug and plug-in of network cables
- align the MTU across switch ports, network interface, bridges
- reboot the proxmox server
- switch interfaces up/down
- unplug and plug-in of network cables
- restart services
- move firewall rules with 8006 higher up in the firewall rulebase
- run the browser in safe-mode (firefox) but this did not last long
- the culprit is likely senchui (ext-all.js) which is at verion 7.6 while proxmox works with version 7.0
- there are errors similar to the "ERR_CONTENT_LENGTH_MISMATCH" for sencha ui on the internet
SOLUTION for now
this is currently not understood as a sensible solution but works nonetheless
- set the MTU for the bridge connected to the physical interface where the IP is listening to 1500
- yes, to 1500 instead of anything higher, do read the caveat below
- yes, the web interface is not listening on the IP or any IP associated with the bridge interface
- the web interface is listening to an IP associated to the physical interface which is also hosting the bridge interface
- this is necessary even if all other interfaces and bridges are aligned to listen on the higher MTU
- if the MTU on your network is higher than 1500 set the bridge interface to MTU - 40 , that should work
Last edited: