WireGuard Default Port: UDP 51820, and How to Change It

WireGuard's networking is refreshingly simple - but the one number that trips people up is the port. By default WireGuard listens on UDP 51820, and almost every "my self-hosted VPN won't connect" problem comes down to that port not being open, not being forwarded, or not matching the client config. This guide covers the default, how to change it, and how to open and forward it correctly.

WireGuard ports at a glance

The short answer: WireGuard uses UDP port 51820 by default - that is its standard port, set by the ListenPort line. There is no TCP mode at all. The ports that matter:

The client's Endpoint = <public-ip>:<port> must use the exact same port as the server's ListenPort - that mismatch is the single most common reason a self-hosted WireGuard tunnel won't connect.

Your VPN hides your IP. It does not hide your browser.

A correctly configured WireGuard tunnel replaces the address a site sees. It changes nothing about what your browser announces on its own: fonts, screen, time zone, graphics stack. That combination is often unique enough to follow you across sessions, tunnel or no tunnel.

Measure your own browser fingerprint, passive, no questions, no account, no email. It tells you how many browsers out of N look like yours, and which attribute makes you stand out.

The default: UDP 51820

WireGuard listens on UDP port 51820 by convention, set by the ListenPort line in the server's [Interface] section. Two things matter here:

• It's UDP, not TCP. WireGuard has no TCP mode at all. Firewalls or networks that block UDP will stop it cold.
• 51820 is just the default, not a rule - you can use any free UDP port from 1 to 65535.

Clients reach the server using the Endpoint = <public-ip>:51820 line in their own config. That port has to match the server's ListenPort exactly.

Picking a port: is 443/UDP worth it?

Any free UDP port from 1-65535 works, but a few choices are smarter than others:

• Keep 51820 for simplicity if your network doesn't filter UDP - it's the documented default and easiest to support.
• Use UDP 443 if you're on a restrictive network. Port 443 is the HTTPS port, and modern web traffic (HTTP/3 / QUIC) already runs over UDP 443, so a WireGuard tunnel there blends into normal-looking encrypted traffic and slips past many port-based blocks. It's the single most useful port change. Note this is port-level camouflage only - deep packet inspection can still fingerprint the handshake (see the stealth section below).
• Avoid ports below 1024 unless you have a reason; they're "privileged" and need root, with no upside here.

Opening the port in the firewall

On the server, the port must be allowed for UDP. With UFW:

sudo ufw allow 51820/udp
sudo ufw reload

With iptables it's -A INPUT -p udp --dport 51820 -j ACCEPT. This is the single most common cause of a server that "runs" but never accepts connections: the WireGuard service is up, but the firewall silently drops the packets.

Forwarding the port through a router

Where your server lives decides whether you also need port forwarding:

• On a VPS (a rented server with a public IP): no forwarding needed - the firewall rule is enough, because the public IP points straight at the machine.
• On a home server behind a router: add a port-forward rule in the router admin - forward UDP 51820 (external) to the server's local IP on UDP 51820 (internal). Without it, packets from the internet never reach the server.

Test from outside your network (e.g. a phone on mobile data, Wi-Fi off): a client should reach server-public-ip:51820. If it works on your LAN but not from outside, forwarding is the missing piece.

Changing the port

To use a different port, set it in the server's [Interface]:

[Interface]
ListenPort = 51821

Then restart the tunnel (systemctl restart wg-quick@wg0) and update everything that referenced the old port:

1. the firewall rule (allow the new UDP port),
2. the router forward (if applicable),
3. the Endpoint line in every client config.

Miss any one and clients won't connect. A self-hosted VPS makes all of this straightforward because you control the firewall and the public IP directly. If you're editing the config from scratch, our ready-to-use WireGuard config templates give you a correct [Interface]/[Peer] skeleton with the ListenPort and Endpoint lines already in the right place.

If you would rather not hand-edit any of this, an installer asks for the port once and writes all three places for you, that is what PiVPN does in a single command, on a Raspberry Pi or a Debian/Ubuntu VPS.

Verify the port is actually listening

Before blaming the client, confirm the server really listens on the port you think it does:

sudo wg show              # shows the interface and its listening port
sudo ss -lunp | grep 51820   # is something bound to UDP 51820?

wg show lists the active listening port; ss -lunp (note the u for UDP) proves a process is bound to it. If wg show reports a different port than your config, the service didn't reload after your edit - restart it. From another machine you can probe reachability with nc -uvz server-ip 51820, though UDP probes are unreliable, so a real client handshake is the definitive test.

Running more than one tunnel

Each WireGuard interface needs its own ListenPort. If you run, say, wg0 for general traffic and wg1 for a separate group of peers, give them distinct ports (e.g. 51820 and 51821), open and forward both, and point each client at the right one. Two interfaces sharing a port silently fail to start.

Does changing the port hide your VPN?

A non-default port reduces noise from bots that scan 51820, but it is not stealth. Deep packet inspection fingerprints WireGuard's distinctive UDP handshake regardless of the port number. If you need to get through a firewall that actively blocks or detects VPNs, you need obfuscation (wrapping the tunnel), not just a different port - see WireGuard with port knocking / stealth, or compare the tools that actually wrap the tunnel in sing-box vs Xray. For routing specific traffic or forwarding services through the tunnel, see port forwarding.

The bottom line

WireGuard uses UDP 51820 by default - UDP only, no TCP. To make a self-hosted server reachable: open the port for UDP in the firewall, forward it on the router if the server is behind one (a VPS with a public IP skips that), and make sure every client's Endpoint matches. Change the port if you like for less scan noise, but treat it as light hardening, not real stealth.

Once you have settled on a port, our free WireGuard config generator builds a matching server and client config in your browser, with the ListenPort and Endpoint already lined up.

When no port setting will help

Opening UDP 51820 only works if something can actually reach your server. Behind carrier-grade NAT, or on a router you do not control, there is no port to forward and no firewall rule that fixes it. A VPS with its own public IPv4 removes the question entirely: the port you open is the port the internet sees. A Contabo Cloud VPS 10 at EUR 5.50/month gives you full root and a public IP, and the step-by-step Contabo + WireGuard setup covers the rest.

Related guides

• MikroTik CVE-2026-14227: your WireGuard private key can be read, and disabling the API does not undo it

Changing the port only helps if the host itself does not filter it. Our cheapest-VPS comparison for WireGuard covers which providers leave UDP alone.

On a phone, the same port and firewall checks apply, but the failures look different and the tools are fewer: see WireGuard on iPhone for the three that account for most broken iOS tunnels.