---
title: "Why WireGuard uses UDP, and what happens when a network blocks it"
description: "WireGuard only speaks UDP. Why a tunnel over TCP fights itself, what a blocked handshake looks like, and what to do when a network turns WireGuard away."
section: "Guides"
group: "How the technology works"
source: https://wrapvpn.com/en/guides/why-wireguard-uses-udp
last_reviewed: 2026-11-03
---

# Why WireGuard uses UDP, and what happens when a network blocks it

You're at a conference, the guest Wi-Fi loads the schedule without complaint, and your VPN just keeps trying. No error, no explanation. The reason goes back to a choice WireGuard made on purpose: it only travels as UDP.

TL;DR: WireGuard sends everything as UDP, the internet's no-frills delivery service, because a tunnel built on TCP ends up with two layers of error correction fighting each other. The cost is that a network which blocks UDP, or recognises WireGuard's first message, can turn it away without a word, and there's no TCP mode to fall back on. Mobile data or another network is the quickest way round, and on Android and Windows, WrapVPN can also connect with a disguised form of WireGuard at locations that offer it.

## Postcards and phone calls

Almost everything on the internet travels in one of two ways. TCP is like a phone call where the other person repeats back everything you say. Each piece of data is numbered, the receiver confirms what arrived, anything missing is sent again, and it all comes out in the right order. When pieces start going missing, TCP assumes the line is busy and slows down.

UDP is more like a stack of postcards. Each one is addressed and posted on its own, with no confirmation, no resending and no promise about the order they arrive in. If a card goes missing, UDP neither knows nor cares. Whatever is written on the cards has to sort that out for itself.

That sounds worse, but it's often exactly what you want. A video call would rather skip a lost moment than freeze while it's resent, and a quick name lookup would rather ask again than set up a whole conversation. Both usually travel as UDP, and so does a growing share of web traffic.

WireGuard travels as UDP and nothing else. To see why, and what it costs, we'll follow one morning at a conference venue: the guest Wi-Fi, your phone, and a VPN that won't connect.

## Why a tunnel shouldn't ride on TCP

Start with what goes through a VPN tunnel. Your browser, your email and most of your apps already use TCP for their own connections, each with its own numbering, confirmations and resending. The tunnel's job is to carry those packets, sealed, to the exit server.

Now imagine the tunnel itself were a TCP connection. On a crowded conference network, a packet goes missing. The tunnel's TCP holds back everything behind it until the lost piece has been resent, so every connection inside waits, including ones that had nothing to do with it. Meanwhile, those inner connections notice their own data is late, assume it was lost and send it again. The copies join the same queue, both layers slow down to be polite, and things get worse rather than better.

Engineers call this TCP meltdown, and it's why tunnels built on TCP can feel fine on a good connection and fall apart on a bad one. Picture a phone call where both people repeat every sentence back, and then start repeating the repetitions.

WireGuard sidesteps the whole problem by carrying your packets as UDP. A packet lost on the way is lost once, the connection it belonged to recovers in its own way, and everything else carries on. WireGuard's own documentation says plainly that tunnelling over TCP is left out on purpose, because of how badly TCP inside TCP performs.

The postcard model suits WireGuard in other ways too. There's no connection to tear down when your phone's address changes, which helps the tunnel survive a move from Wi-Fi to mobile data, and a server can simply ignore any card it doesn't recognise.

## What a block looks like from your side

Back at the venue. You join the guest Wi-Fi, open your VPN and tap Connect. Your phone sends the first message of WireGuard's handshake to the exit server as a single UDP packet, and waits for the reply.

The venue's firewall drops it. Usually nothing comes back at all: UDP doesn't confirm delivery, and a firewall that's discarding traffic rarely bothers to explain itself. The server never even sees the message.

To WireGuard, a lost message and a slow one look exactly the same, so it does the patient thing. After five seconds without a reply, it builds a fresh first message with new one-off keys and tries again. It keeps that up for about a minute and a half, and starts over whenever one of your apps has something new to send.

Silence is normal in WireGuard's world, which makes a block harder to spot. A WireGuard server never answers a message it can't verify, so even a healthy one says nothing to strangers. There's no 'connection refused' to report, only a reply that never arrives. If you run WireGuard yourself, wg, the command-line tool that comes with it, shows the tell-tale pattern: data sent, nothing received and no handshake at all.

*wg show, when the handshake never comes back*

```
peer: <the server's public key>
  endpoint: 203.0.113.10:51820
  allowed ips: 0.0.0.0/0, ::/0
  transfer: 0 B received, 2.89 KiB sent
```

## Why some networks turn WireGuard away

There are two quite different reasons, and they call for different fixes.

The first is a network that blocks UDP altogether, or lets through little beyond ordinary web browsing. Guest networks are often set up this way to keep things simple, or to stop a few people using all the capacity. Hardly anyone notices, because browsers that try the newer UDP-based kind of web connection quietly fall back to TCP when it doesn't get through. WireGuard has no TCP to fall back to, so it stops at the door.

The second is a network that recognises WireGuard itself. WireGuard seals the contents of every packet, but it makes no attempt to hide what it is. Each message starts with a short label saying which kind of message it is, and the handshake messages always come in the same sizes, so equipment that inspects traffic can pick out a WireGuard handshake from its very first packet. It can't read anything inside; it just knows the shape. WireGuard's authors are clear that disguise isn't the protocol's job and belongs in a separate layer on top.

Which one you've hit matters. Against the first, any tunnel that travels as UDP is stuck. Against the second, the same tunnel in a different shape may well get through.

Sometimes it's neither. A sign-in page you haven't completed, or a signal too weak to hold a conversation, looks much the same from your phone. Our guide to why a VPN won't connect on some Wi-Fi networks takes those one at a time, so we won't repeat it here.

## Getting connected anyway

At the venue, the quickest test is also the quickest fix: turn off Wi-Fi and connect over mobile data. Mobile networks usually carry UDP without fuss, so if WrapVPN connects straight away, you know the guest Wi-Fi was the obstacle.

If your laptop needs to get online too, share your phone's connection and run WrapVPN on the laptop itself. A VPN on your phone covers your phone, not the devices borrowing its connection.

Another Wi-Fi network is the other option. The café across the road may be far less fussy than the venue, and most networks carry WireGuard without a second thought.

## WireGuard in disguise, and where disguise stops helping

For networks that recognise WireGuard and block it, there's AmneziaWG, an open-source variant of WireGuard built to be harder to spot. The encryption is the same. What changes is the shape: it sends a few packets of random filler before the handshake, pads the handshake messages so they no longer come in WireGuard's familiar sizes, and swaps WireGuard's recognisable message labels for values agreed in advance with the server.

WrapVPN's Android and Windows apps can connect with AmneziaWG at locations that offer it. Both have a switch in their settings to always use it, which is off by default because the disguise makes the connection a little slower. The Windows app also tries it on its own: when ordinary WireGuard gets no reply after a short wait, it moves the connection to AmneziaWG. Either way, the app shows which of the two you're connected with.

The limit is worth knowing before you're standing in a conference hall. AmneziaWG still travels as UDP, so on a network that blocks UDP altogether it's turned away just like plain WireGuard. Disguise helps where WireGuard's shape is the problem, not where UDP is.

It isn't a way round anyone's rules, either. If the network belongs to an employer or a school that doesn't allow VPNs, that's their call; use mobile data where that's permitted, or ask their IT team.

## The short version

WireGuard uses UDP because it's the right foundation for a tunnel: a lost packet is lost once, the connections inside recover on their own terms, and nothing has to be torn down when your phone moves. The price is that a network can turn it away in silence, with no TCP mode to retreat to, so when WrapVPN won't connect on a strict network, try mobile data first. For the rest of the story, from keys to the two-message handshake, read our guide to what WireGuard is.

## Questions

### Does WireGuard use TCP or UDP?

UDP, and only UDP. Every WireGuard packet, from the first handshake message to the last byte of a download, travels as UDP. There's no setting to change that, because the design deliberately leaves TCP out.

### Can you run WireGuard over TCP?

Not by itself. Separate tools can wrap WireGuard's UDP packets inside a TCP connection, but that's an add-on rather than part of WireGuard, and it brings back the trouble with carrying TCP inside TCP on a poor network. WrapVPN doesn't offer a TCP mode.

### Why does my VPN keep trying to connect but never connects?

Usually because the first message of the handshake is being dropped and no reply ever comes back. WireGuard keeps retrying every few seconds, and since nothing tells it why, there's no error to show. Try mobile data: if it connects there at once, the network you were on is the cause.

### Can a network tell that I'm using WireGuard?

Often, yes. It can't read what's inside your packets, but WireGuard's messages have a recognisable shape, and a handshake can be spotted from its first packet. Disguised variants such as AmneziaWG change that shape, which is why WrapVPN's Android and Windows apps can use it, at locations that offer it, on networks that block plain WireGuard.

### Is UDP less secure than TCP?

No. UDP and TCP only decide how packets are delivered, not how they're protected. WireGuard seals every packet and checks every one on arrival, so a forged, altered or replayed packet is thrown away whichever way it travelled.

---

Source: https://wrapvpn.com/en/guides/why-wireguard-uses-udp
Last reviewed: 2026-11-03