Status: CURRENT
Last reviewed: 31 August 2026
Applies to: Proxmox VE 8/9 cluster + Traefik v3.xTraefik can sit in front of multiple Proxmox nodes so a single hostname such as
proxmox.richay.aureaches whichever cluster node is available. Modern Traefik supports Proxmox shell/noVNC WebSockets without a special WebSocket middleware.
Why put a Proxmox cluster behind Traefik?
Each node in a Proxmox cluster provides the web interface, and Proxmox cluster management can be performed by connecting to any cluster node.
Instead of remembering:
https://10.10.10.1:8006
https://10.10.10.2:8006
https://10.10.10.3:8006I can use one address:
https://proxmox.richay.auTraefik then load balances the browser traffic between the available nodes.
Security: Proxmox is a management interface with control over your VMs, containers, storage and cluster. I recommend keeping this hostname private rather than publishing it to the open internet.
I use Tailscale Split DNS for this type of service so
proxmox.richay.auresolves only while I’m at home or connected to Tailscale. My guide is here: Tailscale Split DNS by Domain for Secure Home Server Access.
The old WebSocket workaround is no longer needed
The original version of this article added these request headers manually:
Upgrade: websocket
Connection: UpgradeThat is no longer required with current Traefik. Traefik v3 supports WebSocket and WebSocket Secure connections out of the box and automatically handles the protocol upgrade using normal HTTP routing.
So there is no need for a custom websocket-upgrade middleware just to make the Proxmox shell or noVNC console work.
Current Traefik dynamic configuration
This is the modern equivalent of my original config.yaml.
This example assumes your Proxmox nodes are using their normal cluster-generated HTTPS certificates and Traefik is connecting to them by IP address. Because those certificates are normally signed by the private Proxmox cluster CA, the example uses a dedicated ServersTransport with certificate verification disabled.
http:
routers:
proxmox:
entryPoints:
- "https"
rule: "Host(`proxmox.richay.au`)"
service: proxmox
tls: {}
services:
proxmox:
loadBalancer:
serversTransport: proxmox-transport
sticky:
cookie:
name: proxmox_lb
secure: true
httpOnly: true
sameSite: lax
servers:
- url: "https://10.10.10.1:8006" # Proxmox node 1
- url: "https://10.10.10.2:8006" # Proxmox node 2
- url: "https://10.10.10.3:8006" # Proxmox node 3
serversTransports:
proxmox-transport:
insecureSkipVerify: trueThat’s it. No manual WebSocket headers.
Why use a sticky cookie?
Traefik’s load balancer normally distributes requests between the backend servers. Enabling a sticky cookie keeps subsequent requests from the same browser session on the same Proxmox node where possible.
For a normal website that may not matter much, but for a management UI with long-running shell/noVNC connections I prefer keeping the browser pinned to one node during the session.
The example also marks Traefik’s affinity cookie as Secure and HTTPOnly.
About insecureSkipVerify
insecureSkipVerify: truedoes not disable HTTPS. Traffic between Traefik and Proxmox is still encrypted, but Traefik does not verify that the backend certificate is trusted and belongs to the expected server.That’s convenient for a trusted home management network, but it is weaker than actually trusting the Proxmox cluster CA.
Proxmox creates its own cluster CA by default and generates a node certificate for each node. The public cluster CA is stored at:
/etc/pve/pve-root-ca.pemIf you want proper backend certificate verification, copy only the public CA certificate to the Traefik host/container and use node hostnames that match the certificates.
For example:
http:
services:
proxmox:
loadBalancer:
serversTransport: proxmox-trusted
sticky:
cookie:
name: proxmox_lb
secure: true
httpOnly: true
# Use the actual DNS names present in your node certificates.
servers:
- url: "https://pve1.home.arpa:8006"
- url: "https://pve2.home.arpa:8006"
- url: "https://pve3.home.arpa:8006"
serversTransports:
proxmox-trusted:
rootCAs:
- /etc/traefik/certs/pve-root-ca.pemThis is the better option if you want end-to-end TLS verification rather than simply trusting the management LAN.
Do not copy the Proxmox cluster CA private key to Traefik. The public
pve-root-ca.pemcertificate is all Traefik needs to trust the cluster certificates.
HTTPS redirect
My old dynamic configuration attached an HTTPS redirect middleware to the router even though that router was already listening on the HTTPS entrypoint. That’s redundant.
If you want every request hitting port 80 to redirect to HTTPS, I prefer doing that once on the HTTP entrypoint in Traefik’s static/install configuration:
entryPoints:
http:
address: ":80"
http:
redirections:
entryPoint:
to: https
scheme: https
https:
address: ":443" Then every service can use the HTTPS entrypoint without carrying around its own redirect middleware.
Testing it
Open the single cluster hostname:
https://proxmox.richay.auLog into Proxmox and test:
- Normal cluster navigation.
- A node shell.
- An LXC console.
- A VM noVNC console.
They should work through the same Traefik route without any WebSocket-specific middleware.
If the normal web UI loads but consoles fail, check the browser developer tools for the WebSocket request and check the Traefik logs. Don’t immediately add fake Upgrade headers back in — modern Traefik already handles that part.
What happens when a node goes down?
Traefik can distribute requests across multiple Proxmox nodes, but this alone is not a full HA design. If the node your sticky cookie points to disappears, Traefik can select another backend when the failed backend is detected, but an existing shell/noVNC connection to the dead node will obviously be lost.
The reverse proxy gives you one convenient cluster URL. Proxmox clustering/HA is still what handles the actual guests and cluster state.
Archived note from the original article
ARCHIVED — old Traefik WebSocket middleware
The original article used a
websocket-upgradeHeaders middleware withUpgrade: websocketandConnection: Upgrade. That workaround has been removed from the active configuration because current Traefik handles WebSocket upgrades automatically.
References
- Traefik WebSocket documentation
- Traefik load balancer / sticky session documentation
- Traefik ServersTransport documentation
- Proxmox VE Administration Guide
- My Tailscale Split DNS guide
Much cleaner now — one cluster URL, sticky sessions, working shells, and no janky WebSocket header hack required 🙂
Straight to the point, Love It!