WireGuard uses UDP port 51820 by default, set by the ListenPort line of the server config (wg0.conf). It never uses TCP, and 51820 is a convention you can change to any free UDP port. 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's Endpoint. This guide covers the default, how to change it, and how to open and forward it correctly.
Check your own setup: the WireGuard port checker compares your router's WAN address with your public IP to spot CGNAT (where no port forward can work), then writes the forwarding rule and the firewall commands for ufw, firewalld, nftables, iptables, Windows or OpenWrt.
If the checker finds CGNAT, no forward will ever work from home: the fix is to host the server on a VPS with its own public IPv4, for example a HostPapa Unmanaged VPS Lite (affiliate link, 2.95 $ a month on a 3-year term, then the regular rate) or a Contabo Cloud VPS (affiliate link), from 5.50 € a month on a 24-month term as read on 17 October 2026. Choosing a host? Compare the best VPS for a VPN and Contabo vs Hetzner vs OVH on the price actually billed. HostPapa's Lite plan is the smallest one here: 1 core, 1 GB RAM, 25 GB NVMe and 4 TB transfer, unmanaged (root SSH on Ubuntu or Debian, no control panel, you install WireGuard yourself), enough for a WireGuard server for a few devices, 30-day money-back guarantee, read on 28 October 2026.
Tired of troubleshooting? If what you need is a working VPN rather than your own server, a ready-made app skips ports, keys and handshakes entirely: Proton VPN (Black Friday offer on Plus, checked on 28 October 2026; the order page shows the price for your country) or NordVPN connect in two minutes (affiliate links). If you want to keep your own tunnel, the fix is below.
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:
| Port | Protocol | Role |
|---|---|---|
| 51820 | UDP | WireGuard's default (standard) listening port |
| Any 1-65535 | UDP | A custom port you choose with ListenPort |
| 443 | UDP | Common alternative to slip past restrictive firewalls |
| 51821 | UDP | Usual port for a second tunnel (wg1) next to wg0 |
No ListenPort | UDP | Random port picked at startup: fine for a client, never for a server |
| Any | TCP | None: WireGuard has no TCP mode |
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.
Generate your WireGuard configs here
Type your server address, choose the number of devices, then scan each QR code from the app.
All keys are generated in your browser (Curve25519 / X25519). Nothing is sent to our servers - your config stays 100% private.
Free, no account: up to 250 clients, each .conf with its QR code, and one ZIP with every file.
Optional. Enter the LAN subnet behind the server and/or behind a client that acts as a site gateway (a router, a Raspberry Pi, a NAS). The generator adds each LAN to the server's AllowedIPs, gives every peer the routes to the other LANs, and writes the forwarding rules on the gateways. Leave a field empty for a normal client.
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.
If you want a ready-made ruleset instead of typing these lines, our paid WireGuard Self-Hosting Kit (9 USD) includes an nftables.conf that accepts the WireGuard UDP port and SSH and drops the rest. The table comparing 51820, 443, 53 and 123/udp for restrictive networks is also in our free WireGuard Cheat Sheet (5-page PDF, direct download, no sign-up).
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:
- the firewall rule (allow the new UDP port),
- the router forward (if applicable),
- the
Endpointline 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.
★ Nuremberg GDPR datacenter · ✓ Dedicated IPv4 included · 200 Mbit/s port
A VPS with a public IP - no router forwarding needed → ContaboPublic IPv4 · You control the firewall and port · Host WireGuard reachably from anywhere→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. What a WireGuard port does give you is silence: it never answers a packet that was not computed with the server's public key, so there is no login page for an attacker to probe. The Ivanti Connect Secure zero-day chain of October 2026 shows what that saves you from.
No server, just a blocked network? If you are trying to get your own laptop through hotel, office or campus Wi-Fi that drops WireGuard, a VPN app with a built-in obfuscation mode does the wrapping for you: Proton VPN has Stealth, an obfuscated TLS tunnel available on every plan including Free, and NordVPN has NordWhisper, which makes VPN traffic resemble regular web traffic and now runs its Obfuscated Servers (affiliate links). Against state-level DPI, a private server wrapped with Xray REALITY holds better; our anti-DPI guide compares both routes.
Paid plan, Black Friday 2026: Proton's partner offer, checked on 28 October 2026, is VPN Plus at $2.49/month over 2 years ($59.76 for the first 24 months, then $83.88 per year), with a 30-day money-back guarantee and 10 devices. The order page shows the price for your country, and Proton does not publish an end date.
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 4 at EUR 5.50/month gives you full root and a public IP, and the step-by-step Contabo + WireGuard setup covers the rest.
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.
Related guides
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.
★ Nuremberg GDPR datacenter · ✓ Dedicated IPv4 included · 200 Mbit/s port
Self-host your VPN on your own VPS → ContaboFull root access · public IPv4 · pick your region→


