The console will not open: the interface works, so why does this one thing fail
A console that never connects while the rest of the interface is perfectly fine points at a small set of causes, and the most common one is a reverse proxy that forwards ordinary requests correctly and quietly refuses the connection the console actually needs.
AtlasPVE ·
This entry answers
- proxmox console not working
- proxmox console not loading
- proxmox console not opening
- proxmox console not working lxc
- proxmox novnc failed to connect to server
Everything else works. You log in, the tree loads, you can browse storage and start a machine. Then you open a console and it hangs, or fails immediately, or shows a connection error and nothing else.
That pattern is itself the clue. When the whole interface is broken, you have a general problem. When only the console is broken, you have a specific one, and the list of candidates is short.
The one that catches most people
The console does not use ordinary requests. It opens a long-lived connection that starts as a normal request and then asks to be upgraded into a persistent two-way channel.
Anything sitting between your browser and the server has to be willing to forward that upgrade. A reverse proxy in front of Proxmox VE will happily pass every normal page and every API call, so the interface looks perfect, and then drop the console because it was never told to handle that kind of connection.
The official example configuration is explicit about what is needed, and it is worth reading as a checklist rather than as a template to paste:
The upgrade has to be passed through. The proxy must forward the upgrade request rather than answering it itself.
Buffering has to be off. A proxy that collects a response before sending it on will hold an interactive stream forever, which looks exactly like a hang.
The timeouts have to be long. Default proxy timeouts are measured in seconds because ordinary requests are short. A console you leave open for an hour is not an ordinary request; the published example uses an hour on each timeout for exactly this reason.
If you put anything in front of Proxmox VE, check those three before looking anywhere else. The symptom does not tell you which of the three it is, and all three produce the same silence.
The certificate one
The console connection is a separate connection, so it faces the certificate question again on its own.
If the server uses a self-signed certificate and you clicked through the browser warning to reach the interface, that acceptance does not always carry to the console's connection. The page loads, the console does not, and no warning appears the second time because it is not a page load.
Visiting the address directly once and accepting the certificate properly usually resolves it. This is also a good reason to give the host a real certificate if it is reachable by more than one person.
When it is only containers
If virtual machine consoles work and container consoles do not, stop looking at proxies and networks. Containers do not emulate hardware; their console is a different mechanism with its own configuration, and the fault is on that side.
The reverse case is also informative: if the text console fails on one virtual machine and works on another, that is not a connection problem at all, it is the missing serial port covered elsewhere in this section.
When the viewer is not the one you expected
There is a datacenter setting that chooses the default console viewer, and it has a documented behaviour worth knowing: if the selected viewer is not available for that guest, it falls back to the graphical console.
That is a sensible design, and it also means a console that silently opens as something other than what you configured is not broken. It is telling you the thing you asked for was unavailable, in the quietest way possible.
A short order to work through
Try a console on the host itself, on its own address, without anything in between. If it works there, the problem is on the path, not in Proxmox VE, and the three proxy settings above are where to look.
If it fails there too, check whether it fails for every guest or just one. Every guest points at the server or the browser. Just one points at that guest's configuration.
Check the browser console for a connection error. It usually names the failure precisely, and it is faster than guessing.
What Atlas does
Atlas hands you Proxmox VE's own console, so a console that fails in Proxmox VE will fail through Atlas too. There is no separate path to try, and claiming otherwise would just add a second thing to debug.
What Atlas does change is how often you need one at all. A console you cannot open is only an emergency when it was your only way to do the work. Storage, network, updates, permissions and backups all have screens, so a broken console becomes a thing to fix on a calm afternoon rather than a wall you hit in the middle of something urgent.
Sources
Proxmox's own documentation. In English, and it has the final word on this subject.