Proxmox Default Port 8006 and Every Other Port It Uses

Proxmox VE’s default port is TCP 8006. The web GUI and the whole API listen there over HTTPS, so after installation you browse to https://<node-ip>:8006 and log in as root in the PAM realm. SSH stays on 22, SPICE on 3128, corosync on UDP 5405-5412 and live migration on TCP 60000-60050. Proxmox Backup Server uses 8007.

The short version:

• A human needs exactly one port: 8006. Everything else on this page is machine talking to machine.
• The browser console rides on 8006 too. noVNC is a WebSocket to pveproxy on 8006, which relays it to a per-session VNC proxy on 5900-5999 on the node itself. Only SPICE clients connect directly, to 3128.
• Corosync uses UDP 5405-5412, not the 5404/5405 pair older guides still list, and it is the one service where a firewall mistake takes the cluster down rather than one guest.
• Nothing here belongs on the public internet. Not 8006, not 22, and certainly not corosync.
• Guest ports are a separate problem. Your web server’s port 443 is filtered at the guest firewall level, not by the host list below.

Default ports for each Proxmox product

“The Proxmox port” depends on the product. Each one serves its web interface and API over HTTPS on a fixed default port:

VE and Mail Gateway both claim 8006, so they cannot share one IP address. Mail Gateway also takes SMTP: internet mail on 25, and mail from your own servers on its internal port, 26 by default.

The full Proxmox VE port list

These are the ports Proxmox VE itself listens on, as documented in the firewall chapter of the administration guide (version 9.2.13, checked October 2026):

Add these if you run the matching service:

Port by port, and what breaks without it

8006, the web interface. pveproxy terminates TLS here and it is the only port a person genuinely interacts with. It is also the first thing an internet-wide scanner fingerprints a Proxmox host by, which is the argument for reaching it over a VPN rather than a port forward. If you want it behind a reverse proxy, the proxy only needs to forward 8006 and pass the WebSocket Upgrade and Connection headers through; the official nginx example proxies nothing else and serves both the web interface and the noVNC console.

5900-5999, the VNC console relay. Each console session gets a VNC proxy on a port in this range on the node, torn down afterwards, and pveproxy relays the browser’s WebSocket on 8006 to it. Your browser never connects to this range directly, so a reverse proxy or an upstream firewall does not need to open it. The default ruleset still allows it from the management IPSet, so leave that built-in rule alone. If the GUI works but the console spins forever behind a proxy, check that the proxy passes WebSocket upgrades on 8006 before you go looking for certificate problems.

3128, the SPICE proxy. The spiceproxy daemon listens here. Only relevant if you use SPICE rather than noVNC, which mostly means desktop guests with a local virt-viewer. Safe to leave closed if nobody uses it.

22, sshd. Beyond shell access, the cluster manager chapter requires an SSH tunnel on TCP 22 between nodes, and Proxmox uses SSH for some migration modes and tunnelled operations. The join is the exception older guides get wrong: by default pvecm add authenticates against the existing node’s API on 8006, and only the legacy --use_ssh join needs root SSH login. Blocking 22 between cluster members still breaks the cluster. Blocking it from the internet is simply correct.

111 (UDP), rpcbind. Present because of the NFS client stack. Nothing outside the host normally needs it, and on a node that mounts no NFS storage it is a candidate for closing outright.

25, sendmail. Outbound only, for the notification mail that tells you a backup failed or an HA service moved. It only matters as an egress rule, and it is worth having: a Proxmox host that cannot email you is a Proxmox host whose failures you find out about late.

5405-5412 (UDP), corosync. This is the range to get right. Corosync 3 with the kronosnet transport uses this range rather than the two-port arrangement older guides describe: link 0 uses 5405 and each additional link defaults to 5405 plus its link number (corosync.conf(5)), and Proxmox supports up to 8 links, hence eight ports. Corosync is also latency-sensitive rather than bandwidth-hungry (the cluster docs ask for under 5 ms between nodes), which is why the Proxmox cluster setup guide argues for a dedicated link and why sharing the corosync path with backup traffic causes quorum flapping that looks like a network fault. A firewall rule that silently drops these packets does not produce an error message; it produces a node that fences itself.

60000-60050 (TCP), live migration. Guest memory pages and, for local-disk migrations, disk contents cross on this range. It only needs to be open between cluster nodes. If migrations fail at “starting VM … on remote node” with no obvious cause, this range is the first thing to check. It matters a great deal to Proxmox high availability, because HA relocation depends on the same path.

8007, Proxmox Backup Server. PBS runs its own web interface and API on 8007 over HTTPS, and backup traffic from every node you back up goes there too. The next section covers who needs to reach it; setup and datastore layout are in the Proxmox Backup Server guide.

Ceph, 3300 / 6789 / 6800-7568. Monitors listen on 3300 for the v2 messenger protocol and 6789 for legacy v1. OSD, MDS and manager daemons bind dynamically inside the 6800-7568 range, with each OSD potentially using several ports, so Ceph’s own documentation recommends opening the whole range on the storage network rather than trying to pin individual daemons. This traffic should never be on the same network as anything else; the reasoning is in Proxmox Ceph vs ZFS replication.

Proxmox Backup Server ports

Proxmox Backup Server needs one inbound port: TCP 8007. The proxmox-backup-proxy daemon serves the web UI, the whole API and the backup and restore traffic there over HTTPS, while the privileged proxmox-backup daemon listens on 127.0.0.1:82 only and never needs a rule, per the PBS service daemon docs. Add SSH on 22 for shell access.

Three kinds of client reach 8007: every Proxmox VE node with a backup job pointed at the datastore, admin browsers at https://<ip-or-dns-name>:8007, and any second PBS that pulls from this one in a sync job. In push mode the direction reverses and this box connects out.

If PBS is published on a different port, for example through NAT, each client can be told so. The PVE pbs storage type has an optional port property, documented as “use this port instead of the default one, i.e. 8007” (storage reference). Sync remotes take --port in proxmox-backup-manager remote create (command reference). The backup client accepts a server:port:datastore repository such as 192.168.55.55:1234:mydatastore, or --port, or PBS_PORT, with IPv6 addresses in square brackets.

Proxmox VE’s built-in firewall rules do not include 8007. A PBS guest with its firewall on, or a PBS on a node whose firewall is on, needs an explicit rule such as IN ACCEPT -p tcp -dport 8007 -source 192.168.2.0/24. What to send it and how long to keep it is the job of the backup strategy guide.

Can you change the Proxmox port from 8006?

No, not through any setting. The pveproxy man page documents a listen address and ALLOW_FROM/DENY_FROM access lists in /etc/default/pveproxy, but no port option, and when a user asked on the Proxmox forum in 2022, staff answered with a link to the nginx reverse-proxy wiki page. To serve the GUI on 443, put a proxy in front of 8006.

Patching the Perl sources is possible, but a forum regular in that thread warned that upgrades can revert the edit and lock you out of the GUI. The supported route is the official nginx example, which keeps pveproxy on 8006:

1. Add a server block with listen 443 ssl; that reuses the node certificate (/etc/pve/local/pve-ssl.pem and /etc/pve/local/pve-ssl.key), plus a listen 80 default_server; block that rewrites everything to HTTPS.
2. Give the 443 block this location. The Upgrade and Connection headers are what keep the noVNC console working:

location / {
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_pass https://localhost:8006;
    proxy_buffering off;
    client_max_body_size 0;
    proxy_connect_timeout  3600s;
    proxy_read_timeout  3600s;
    proxy_send_timeout  3600s;
    send_timeout  3600s;
}

3. Run nginx -t, restart nginx, then use systemctl edit nginx.service to add Requires=pve-cluster.service and After=pve-cluster.service under [Unit], because the certificates live in /etc/pve.

The lighter alternative from the same thread is a NAT redirect as a post-up line under the interface in /etc/network/interfaces:

post-up iptables -t nat -A PREROUTING -d <your-ip> -p tcp --dport 443 -j REDIRECT --to-port 8006 || true

It adds no daemon but closes nothing, so 8006 stays reachable unless you add another rule. On a cluster, the man page advises against binding pveproxy to one address with LISTEN_IP; restrict 8006 with the firewall or the access lists instead.

Proxmox GUI on port 8006 not loading?

Work outward from the node. Confirm the address starts with https://, because pveproxy serves 8006 over HTTPS only; then confirm pveproxy is running and listening; then check its access lists and the firewall; only then suspect the network between you and the node. In order:

1. The URL. https://<node-ip>:8006, using the address set in the installer, as how to install Proxmox VE shows. An http:// address will not reach it.
2. The service. Check systemctl status pveproxy and ss -tlnp | grep 8006. If it is down, run systemctl restart pveproxy.service spiceproxy.service.
3. IPv6-only binding. With net.ipv6.bindv6only set to 1, the man page says pveproxy accepts IPv6 clients only, which shuts out an IPv4 browser. Remove the sysctl, or set LISTEN_IP="0.0.0.0" in /etc/default/pveproxy.
4. Access lists and firewall. Check ALLOW_FROM/DENY_FROM in /etc/default/pveproxy, and, if the datacenter firewall is on, that your workstation is in the management IPSet.
5. The path. Run nc -zv <node> 8006 from your workstation. If it connects, the problem is the browser or TLS; if not, recheck steps 2 to 4. A node that answers on nothing belongs in common Proxmox problems and fixes.

How to open a port on Proxmox, and at which level

With the datacenter firewall off, which is the documented default, nothing is filtered. Once it is on, opening a port means an IN ACCEPT rule where the traffic lands: /etc/pve/nodes/<nodename>/host.fw for a service on the node, /etc/pve/firewall/<VMID>.fw for one inside a guest. -dport takes a number, a service name, a range such as 80:85, or a comma-separated list:

[RULES]
IN ACCEPT -p tcp -dport 8007 -source 192.168.2.0/24
IN ACCEPT -p tcp -dport 9100:9110,9200 -source 192.168.2.0/24

Proxmox has three rule levels (datacenter, node and guest) that all have to agree before a rule takes effect. That machinery (IPSets, security groups, the management set, and safe defaults that keep you from locking yourself out) is the job of Proxmox firewall configuration, not this page.

The one port-specific thing worth repeating is the direction trap: the host firewall’s inbound chain (PVEFW-HOST-IN, visible in the iptables dump in this forum thread) is evaluated for traffic to the node itself, while guest traffic is filtered at the guest’s interface instead. Rules written at node level do not protect a VM, and rules written on a VM do not protect the API on 8006.

Verifying what is actually listening

Before writing rules, look at reality on the node:

ss -tulnp | sort -k5

That prints every listening socket with the owning process. On a fresh node you should see pveproxy on 8006, pvedaemon bound to localhost on 85, sshd on 22, rpcbind on 111, and corosync’s UDP sockets once the node has joined a cluster. Anything else listening on a public interface deserves an explanation. pvedaemon binding only to 127.0.0.1 is the expected and correct behaviour: it is the privileged API service, and pveproxy is what proxies authenticated requests to it.

To confirm a rule is doing what you think from outside, nc -zv <node> 8006 from an allowed host and from a disallowed one is faster than reading rule dumps.

What to expose to the internet

Nothing on this page. The honest recommendation for every one of these ports is a VPN or a WireGuard tunnel terminating on your network boundary, with the Proxmox management ports reachable only from inside it. A Proxmox host with 8006 forwarded is a credential-stuffing target with a full hypervisor behind it, and enabling two-factor authentication reduces but does not remove that exposure. If the boundary itself is what you are building, pfSenseLab covers that side.

Next steps

• Get the rules right before you get the ports right: Proxmox firewall setup.
• The interfaces those rules reference: Proxmox network bridges and VLANs.
• Why corosync wants its own link: Proxmox cluster setup: Corosync, quorum and QDevice.
• When a node stops answering on any port at all: common Proxmox problems and how to fix them.
• Building the whole stack in a sane order: the Proxmox VE homelab roadmap.

Related across the network

• Cloudflare Tunnel Setup: Your First Tunnel Step by Step — cloudflarezerotrust.org
• Cloudflare Tunnel Not Connected: Fixing Error 1033 — cloudflarezerotrust.org

FAQ

is proxmox port 8006 http or https

HTTPS only. pveproxy exposes the whole Proxmox VE API on TCP 8006 using HTTPS, so the address must start with https://. If you want a bare http:// address to work, a Proxmox staff member suggested on the forum a tiny nginx server on port 80 that returns a 301 redirect to https://$host:8006.

what is port 85 on proxmox

Port 85 is pvedaemon, the privileged half of the Proxmox VE API. The pvedaemon man page says it runs as root and listens on 127.0.0.1:85, so nothing outside the node can reach it and it needs no firewall rule. Proxmox Backup Server uses the same design, with its privileged daemon on 127.0.0.1:82.

do i need to open port 8007 on proxmox ve

Usually not. Port 8007 belongs to Proxmox Backup Server, and a Proxmox VE node only connects out to it during backups and restores. Open 8007 inbound on the PBS host, from every node you back up. A PVE node needs an inbound 8007 rule only when PBS runs on that node or in a firewalled guest.

what ports do proxmox cluster nodes need open between them

UDP 5405-5412 for corosync, TCP 22 for the SSH tunnel the cluster requires, TCP 60000-60050 for live migration, and TCP 8006, because the default pvecm add join talks to the existing node’s API. The cluster docs also ask for latency under 5 ms. Ceph clusters add 3300, 6789 and 6800-7568 on the storage network.