No access console via /portal

[depedro-ai]

Hey there! 👋 Thanks for taking the time to report this bug — we appreciate it!

Please keep in mind: PegaProx is developed and maintained entirely by volunteers in our free time. We do our best, but we can't work magic 🪄 — please be patient, we'll get to your issue as soon as we can.

Want to help keep PegaProx alive?

• ⭐ Star the project — it's free and helps a lot!
• 💖 Become a Sponsor — helps us dedicate more time to development
• 🤝 Contributing code or docs is always welcome too!

---

Describe the bug

connecting via console in /panel mode to whatever vm.

Steps to Reproduce

1. access https://xxx:5000/panel
2. access console, connecting....
3. Proxmox error COnnection timeout

Expected behavior

Environment

• PegaProx Version: 0.9.13
• Installation Method:
• OS: Debian12
• Browser: Whatever
• Behind Reverse Proxy? no
• UI?

Logs

Screenshots

pegaprox_support_20260614_055747.zip

Checklist

• [x ] I have searched existing issues to make sure this is not a duplicate
• [ x] I am using the latest version of PegaProx

[mkellermann97]

Thanks depedro-ai. Without a reverse proxy the VM console doesn't ride the web port: the VNC WebSocket listens on <mainPort>+1 (:5001 for a :5000 install) and the shell/terminal on +2 (:5002), so the browser has to reach <host>:5001 directly. A timeout (rather than "connection refused") means packets to :5001 are being dropped — almost always a firewall or port-forward that only exposes :5000. Quick test from a client machine: curl -vk https://<host>:5001/ — a healthy instance answers instantly with HTTP 426 Upgrade Required; if it just hangs, that port is blocked. Two ways to fix it: open 5001+5002 to your clients, or run PegaProx behind a reverse proxy so every console rides the single 443/5000 port (there's a worked example in examples/nginx.conf). Tell me what the curl test returns and we'll take it from there. If PegaProx is useful to you, opencollective.com/pegaprox keeps the volunteer lights on. — Marcus

[mkellermann97]

Thanks for the support bundle, depedro-ai — it confirmed you're on PVE 9.1.7, which pointed me straight at it. The client-portal console wasn't passing the Proxmox vncproxy ticket through to the WebSocket handler the way the main UI does, so on PVE 9.1.x — where every vncproxy call mints a fresh random VNC password — the server issued a second ticket whose password no longer matched the one noVNC already had, and the console just hung. Fixed on the Testing branch (it now reuses the original ticket, and also routes through the main port when you're behind a reverse proxy); it'll ship in the next release, so please update and retest then. One honest caveat from your bundle: there was no server-side trace of the console socket actually arriving, so if it still times out after the update, run the :5001 reachability check from my note above — that would point to the port being blocked rather than this bug. opencollective.com/pegaprox keeps the volunteer lights on if PegaProx is useful to you. — Marcus

[depedro-ai]

Thanks Marcus, that makes sense. I’ll update to the Testing branch and retest the client-portal console. If it still hangs after the update, I’ll run the :5001 reachability test from a client machine to confirm whether the WebSocket port is being blocked. El dom, 14 jun 2026 a las 9:54, mkellermann97 ***@***.***>) escribió:

…

*mkellermann97* left a comment (PegaProx/project-pegaprox#547) <#547 (comment)> Thanks for the support bundle, depedro-ai — it confirmed you're on PVE 9.1.7, which pointed me straight at it. The client-portal console wasn't passing the Proxmox vncproxy ticket through to the WebSocket handler the way the main UI does, so on PVE 9.1.x — where every vncproxy call mints a *fresh* random VNC password — the server issued a second ticket whose password no longer matched the one noVNC already had, and the console just hung. Fixed on the Testing branch (it now reuses the original ticket, and also routes through the main port when you're behind a reverse proxy); it'll ship in the next release, so please update and retest then. One honest caveat from your bundle: there was no server-side trace of the console socket actually arriving, so if it *still* times out after the update, run the :5001 reachability check from my note above — that would point to the port being blocked rather than this bug. opencollective.com/pegaprox keeps the volunteer lights on if PegaProx is useful to you. — Marcus — Reply to this email directly, view it on GitHub <#547?email_source=notifications&email_token=BPN6HVDWFTE6XH5TIDLLRM347ZK2XA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZQGEYTANJSHE2KM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4701105294>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BPN6HVDW3H5OP3PDTES2NML47ZK2XAVCNFSNUABGKJSXA33TNF2G64TZHMYTCMZWGYYDSNRVGU5US43TOVSTWNBWGU4DCMBQGIZTRILWAI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- DePedro,

[depedro-ai]

Hi Marcus, regarding the port reachability: this is from the same LAN, not through an external firewall or NAT, and there should be no filtering towards the PegaProx host IP. I cant reach port 5001: Failed to open a WebSocket connection: invalid Connection header: keep-alive. You cannot access a WebSocket server directly with a browser. You need a WebSocket client. El dom, 14 jun 2026 a las 9:18, mkellermann97 ***@***.***>) escribió:

…

*mkellermann97* left a comment (PegaProx/project-pegaprox#547) <#547 (comment)> Thanks depedro-ai. Without a reverse proxy the VM console doesn't ride the web port: the VNC WebSocket listens on <mainPort>+1 (:5001 for a :5000 install) and the shell/terminal on +2 (:5002), so the browser has to reach <host>:5001 directly. A *timeout* (rather than "connection refused") means packets to :5001 are being dropped — almost always a firewall or port-forward that only exposes :5000. Quick test from a client machine: curl -vk https://<host>:5001/ — a healthy instance answers instantly with HTTP 426 Upgrade Required; if it just hangs, that port is blocked. Two ways to fix it: open 5001+5002 to your clients, or run PegaProx behind a reverse proxy so every console rides the single 443/5000 port (there's a worked example in examples/nginx.conf). Tell me what the curl test returns and we'll take it from there. If PegaProx is useful to you, opencollective.com/pegaprox keeps the volunteer lights on. — Marcus — Reply to this email directly, view it on GitHub <#547?email_source=notifications&email_token=BPN6HVBDUHYEWE4YJ76MTRD47ZGS3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZQGEYDENJSGYY2M4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4701025261>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BPN6HVHWKPIQZLXMB35CPJT47ZGS3AVCNFSNUABGKJSXA33TNF2G64TZHMYTCMZWGYYDSNRVGU5US43TOVSTWNBWGU4DCMBQGIZTRILWAI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

-- DePedro,

[mkellermann97]

Good data — and actually good news: that message (invalid Connection header: keep-alive / "you need a WebSocket client") is the WebSocket server answering you. Opening :5001 straight in a browser sends a plain Connection: keep-alive request, which the console socket correctly refuses — noVNC does the real Upgrade handshake instead. So :5001 is reachable and the server is up, which rules out the firewall I suspected earlier (my mistake there). That means your console failure is the bug I fixed yesterday: on PVE 9.1.x the portal was triggering a second vncproxy whose VNC password no longer matched the one noVNC held, so the session died. The fix is on Testing (7f6f78d) and ships in the next release — once you update, the portal console should connect; ping me here if it still fails after that and I'll dig deeper. opencollective.com/pegaprox keeps the volunteer lights on if PegaProx is helping you. — Marcus

[depedro-ai]

Thanks very much. I wait for the release and told my boss to do a big donation. DavidDePedro El El dom, 14 jun 2026 a las 16:48, mkellermann97 ***@***.***> escribió:

…

*mkellermann97* left a comment (PegaProx/project-pegaprox#547) <#547 (comment)> Good data — and actually good news: that message (invalid Connection header: keep-alive / "you need a WebSocket client") is the WebSocket server *answering* you. Opening :5001 straight in a browser sends a plain Connection: keep-alive request, which the console socket correctly refuses — noVNC does the real Upgrade handshake instead. So :5001 is reachable and the server is up, which rules out the firewall I suspected earlier (my mistake there). That means your console failure is the bug I fixed yesterday: on PVE 9.1.x the portal was triggering a second vncproxy whose VNC password no longer matched the one noVNC held, so the session died. The fix is on Testing (7f6f78d) and ships in the next release — once you update, the portal console should connect; ping me here if it still fails after that and I'll dig deeper. opencollective.com/pegaprox keeps the volunteer lights on if PegaProx is helping you. — Marcus — Reply to this email directly, view it on GitHub <#547?email_source=notifications&email_token=BPN6HVH23FLJKYPFHWQWM7T4723M3A5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZQGIYDQOJWHEYKM4TFMFZW63VGMF2XI2DPOKSWK5TFNZ2KYZTPN52GK4S7MNWGSY3L#issuecomment-4702089690>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BPN6HVCJ43D54ZHZJ2ZJL7T4723M3AVCNFSNUABGKJSXA33TNF2G64TZHMYTCMZWGYYDSNRVGU5US43TOVSTWNBWGU4DCMBQGIZTRILWAI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[mkellermann97]

Appreciate that, David — genuinely, no obligation, but it does help keep the lights on. The fix is queued for the next release; ping me right here the moment you're on the new build and we'll confirm the console's behaving. Have a good one. — Marcus