You go to https://your-host:8006 and nothing loads. The Proxmox web interface is down, and because that’s how you normally manage everything, it feels like the whole host is dead. It usually isn’t — your VMs are almost certainly still running. The management layer has a problem, and the management layer is fixable from SSH in a few minutes.
This guide is a diagnostic order, not a single fix, because “GUI won’t open” has several distinct causes: the pveproxy service stopped, the root disk filled up, a certificate broke, a firewall is blocking port 8006, or the cluster lost quorum. Work through them in order and you’ll find which one it is. Steps target Proxmox VE 8.x.
The key thing to internalize first: SSH is your way back in. As long as you can reach the host on port 22, the GUI being down is an inconvenience, not a disaster.
First, confirm what’s actually broken
Before restarting anything, narrow down the failure. The symptom tells you where to look.
Symptom → likely cause
| Page never loads / connection refused | pveproxy stopped, or port 8006 blocked by a firewall/network. |
|---|---|
| Connection times out | Network path to the host is down, or the host itself is unreachable. |
| Certificate warning / TLS error | Self-signed or broken certificate. Often acceptable, sometimes needs regenerating. |
| Loads but login fails | pvedaemon issue, or authentication backend problem. |
| Logs in but can't save changes | Cluster lost quorum — /etc/pve is read-only. |
| Blank page after login | Browser cache, or a half-broken pveproxy. Clear cache, restart pveproxy. |
Get a shell on the host to investigate. From your machine:
# SSH in — this works even when the GUI is down
ssh root@your-host-ipIf SSH also fails, the problem is bigger than the GUI (host down or network), and that’s where to focus first.
Step 1: Check and restart the services
The web interface is served by pveproxy, with pvedaemon handling the API and logins behind it. If pveproxy isn’t running, the page won’t load at all.
# is pveproxy running, and what did it log?
systemctl status pveproxy
# restart the web proxy
systemctl restart pveproxy
# if logins or API calls are also failing, restart the daemon too
systemctl restart pvedaemonsystemctl status pveproxy is the most useful single command here — it tells you whether the service is running and shows the last few log lines, which often name the exact problem (a cert error, a failed bind, a missing file).
If the service won’t start and the status output mentions a specific file or error, that’s your next lead. Two of the most common are a full disk and a bad certificate — covered next.
Step 2: Check whether the root disk is full
This is the cause people overlook, and it’s common. Proxmox services need to write to disk, and the cluster config filesystem (pmxcfs, mounted at /etc/pve) is especially sensitive. When the root filesystem hits 100%, pveproxy and friends can’t write and the GUI stops responding.
# check filesystem usage — look for root at or near 100%
df -hIf / (or the root LV) is full, free space before anything else:
# vacuum the systemd journal down to a smaller size
journalctl --vacuum-size=200M
# find large files under /var (logs, leftover dumps)
du -h --max-depth=1 /var | sort -hOld backup dumps left in /var/lib/vz/dump, bloated logs, and a runaway journal are the usual offenders. Clear enough to get breathing room, then restart pveproxy.
Step 3: Deal with certificate problems
If the connection reaches pveproxy but the browser throws a TLS/certificate error, or pveproxy’s status log mentions the certificate, the problem is the host’s TLS cert.
A fresh Proxmox install uses a self-signed certificate, which always triggers a browser warning. That warning is expected — you click through it (Advanced → proceed) and log in normally. It doesn’t mean anything is broken.
A genuinely broken or missing certificate (corrupted, deleted, or expired custom cert) needs regenerating. Proxmox can rebuild its node certificates:
# regenerate the cluster/node certificates, then restart the proxy
pvecm updatecerts --force
systemctl restart pveproxyThe certificate files live under /etc/pve/local/. If you installed a custom certificate (for example via ACME/Let’s Encrypt) and it expired or got mangled, regenerating falls back to the self-signed pair so you can at least get in, then you can sort the proper certificate out afterward.
Step 4: Check the firewall and port 8006
If pveproxy is running, the disk is fine, and the cert is okay, but you still can’t reach the page, something is blocking the connection on port 8006.
Confirm the host is actually listening:
# is something listening on 8006?
ss -tlnp | grep 8006If pveproxy is listening locally but you can’t reach it from your machine, the block is between you and the host — a host firewall rule, a network ACL, or the Proxmox firewall. Check the Proxmox firewall status:
# datacenter/host firewall status
pve-firewall statusBe careful here: if you recently enabled the Proxmox firewall without an allow rule for 8006 (and for SSH on 22), you can lock yourself out of the GUI. The fix is to add a rule permitting management access from your network, or temporarily stop the firewall from the shell while you sort the rules out.
Step 5: In a cluster, check quorum
If the GUI loads and you can log in but changes won’t save or operations hang, on a clustered host the cause is often quorum, not pveproxy.
Without a majority of votes, the shared config filesystem /etc/pve goes read-only to prevent split-brain. You can browse, but you can’t create or edit anything.
# check quorum on a clustered node
pvecm statusLook for Quorate: Yes. If it says No, the GUI is working fine — the cluster has lost majority, and you need to restore enough nodes (or fix the corosync network) to regain quorum before the interface behaves normally again. This is a cluster problem wearing a GUI costume.
Quick recovery checklist
When the GUI is down and you want a fast path through the likely causes, run these from an SSH session in order.
GUI-down recovery order
- ssh in — confirm the host is reachable at all
- df -h — rule out a full root disk, free space if needed
- systemctl status pveproxy — see if it's running and what it logged
- systemctl restart pveproxy (and pvedaemon if logins fail)
- ss -tlnp | grep 8006 — confirm it's listening; check firewall if not
- pvecm status — on a cluster, confirm quorum if changes won't save
Most GUI outages are one of these five: stopped service, full disk, bad cert, blocked port, or lost quorum. Going through them in this order finds the cause without guesswork.
Wrapping up
A Proxmox GUI that won’t open is rarely as bad as it looks. SSH in, rule out a full root disk, restart pveproxy and pvedaemon, then check the certificate, port 8006, and — on a cluster — quorum. Your VMs keep running the whole time, and the CLI (qm, pct, pvesm) lets you manage everything while you fix the front end.
The two causes worth preventing are a full root disk and a self-inflicted firewall lockout. If you keep filling the disk with old backups, tighten retention with scheduled VM backups or move them off-host. For cluster-related GUI quirks tied to quorum, creating a Proxmox cluster explains the voting behavior, and Proxmox High Availability explained covers how quorum ties into recovery. For more walkthroughs, browse the Proxmox guides.
