Tailscale vs WireGuard: An Honest Comparison With Our Own Measurements (2026)

Tailscale vs WireGuard is a lopsided comparison, which is exactly why so many people search for it. WireGuard is a VPN protocol: a small, fast piece of software that connects two machines with encryption once each knows the other’s keys. Tailscale is a product that uses WireGuard and handles everything around it: distributing keys, assigning addresses, finding devices, punching through routers and firewalls. So the real question isn’t “which one is better”. It’s this: do you want to do the management yourself, or do you want someone to do it for you?

Most comparisons stop at feature lists. We wanted to know what the difference looks like in numbers. On 4 October 2026 we measured three setups side by side between two of our servers (Hetzner Nuremberg and Hetzner Helsinki, about 24 ms apart): the bare connection, a kernel WireGuard tunnel, and Tailscale with a self-hosted Headscale as its control server. Three findings up front:

1. Throughput was almost a tie: kernel WireGuard around 670 Mbit/s, Tailscale between 475 and 750 Mbit/s. And, to our surprise, Tailscale used no more CPU per gigabyte transferred than kernel WireGuard. If anything, slightly less.

2. When we artificially blocked the direct path, Tailscale fell back to its relay network and kept working. At 18 Mbit/s instead of 600. It works, but it’s a different service at that point.

3. Even with our own control server, the Tailscale client opened connections to Tailscale-operated servers on its own. Why that happens and how to turn it off is further down.

Tailscale vs WireGuard: the short version

If you only have a minute:

• WireGuard is the protocol and the kernel software. Free, open source, part of the Linux kernel since 5.6 (2020). You write one config file per device with keys, IP addresses and the endpoint of the other side. Every new participant means editing the files on every device it should talk to.
• Tailscale is a service that sets up WireGuard connections automatically. You install the client, log in, done. The client fetches the list of other devices from the control server, exchanges keys, looks for a direct path and falls back to a relay when no direct path exists.
• Headscale is an open-source reimplementation of the Tailscale control server. You use the normal Tailscale clients, but the management runs on your own server.

In all three cases the data itself is encrypted with WireGuard. Tailscale can’t see your traffic; private keys never leave the devices. What Tailscale sees and controls is who is allowed to talk to whom. We’ll come back to that, because it’s the part that usually gets lost in security discussions.

What is WireGuard?

WireGuard is a VPN protocol that Jason A. Donenfeld started building in 2015. It was designed as a counterpoint to OpenVPN and IPsec: a few thousand lines of code instead of hundreds of thousands, fixed modern cryptography (Curve25519, ChaCha20-Poly1305, BLAKE2s) instead of a menu of dozens of ciphers, and no negotiation about which algorithms to use. Something that has nothing to negotiate can’t be talked down to something weak.

On our Ubuntu server the kernel module is 55 KB (compressed) and the wg management tool is 100 KB. That’s all it takes.

A WireGuard connection consists of exactly three things:

1. A key pair per device (wg genkey, wg pubkey).
2. An interface configuration: your own private key, your own tunnel IP, a port.
3. A list of peers: the other side’s public key, its tunnel IPs (AllowedIPs) and, if known, where to reach it (Endpoint).

Here’s what that looks like in practice. These are the exact commands we used for the measurement:

# On both servers: generate keys
umask 077
wg genkey > private.key
wg pubkey < private.key > public.key

# Server B (Helsinki) listens
ip link add wg0 type wireguard
wg set wg0 listen-port 51820 private-key private.key \
  peer <PUBKEY_OF_A> allowed-ips 10.99.0.1/32
ip addr add 10.99.0.2/24 dev wg0
ip link set wg0 up

# Server A (Nuremberg) connects
ip link add wg0 type wireguard
wg set wg0 private-key private.key \
  peer <PUBKEY_OF_B> endpoint 203.0.113.20:51820 allowed-ips 10.99.0.2/32
ip addr add 10.99.0.1/24 dev wg0
ip link set wg0 up

ping 10.99.0.2

That’s the whole tunnel. The first ping, including the key handshake, took 59 ms for us; after that, round-trip time was 24.5 ms, only 0.6 ms above the direct connection (23.8 ms). For permanent use you put the same thing into /etc/wireguard/wg0.conf and start it with systemctl enable --now wg-quick@wg0.

And this is where you see what WireGuard does not do:

• It doesn’t distribute keys. You copy public keys by hand or with your own script.
• It doesn’t find paths. If both sides sit behind a router without port forwarding, no connection happens.
• It has no users, no groups, no permissions. Whoever holds the key is in, and can reach anything the firewall behind it allows.
• It doesn’t know a device was lost. You have to remove the key from every peer yourself.

With two servers none of that matters. With ten devices, three of which are laptops hopping between Wi-Fi networks, it becomes work.

What is Tailscale?

Tailscale is a Canadian company and also the name of its product. The client (tailscaled) runs on every device, sets up WireGuard connections to every other device in your network (Tailscale calls it a “tailnet”) and gives each device a stable address from the 100.64.0.0/10 range.

The key difference from a classic VPN: there is no central VPN server that all data passes through. The coordination server only distributes information: which devices exist, what their public keys are, which addresses they might currently be reachable on, and what they’re allowed to do with each other. The data itself flows directly from device to device. That’s called a mesh network.

What Tailscale adds on top of WireGuard:

• Login through existing accounts (Google, Microsoft, GitHub, your own OIDC provider) instead of key files.
• NAT traversal: clients try many paths at once to establish a direct connection even behind home routers and mobile carrier NAT.
• DERP relays: when no direct path works, the (still encrypted) packets travel through relay servers operated by Tailscale.
• ACLs: rules like “laptops in group dev may reach port 22 on servers tagged prod”.
• MagicDNS: devices are reachable by name instead of IP.
• Exit nodes and subnet routers: one device forwards traffic to the internet or into an entire local network.
• Tailscale SSH, Funnel, Serve: extras that go beyond plain networking.

One important detail for this comparison: on Linux, Tailscale does not use the WireGuard kernel module. It uses its own WireGuard implementation written in Go, running in user space (wireguard-go). For a long time this was considered Tailscale’s big weakness: slower, more CPU. That’s exactly what we wanted to check.

Video: Tony Teaches Tech sets up a self-hosted WireGuard server on a VPS step by step. Good for getting a feel for how much manual work plain WireGuard involves.

What is the difference between Tailscale and WireGuard?

The table sums up what we measured and looked up. Measurements come from our test on 4 October 2026, prices from Tailscale’s pricing page on the same day.

The heart of it is in the last two rows: WireGuard gives you encryption and nothing else. Tailscale gives you management, and in exchange you hand over part of the control.

Our test setup

So you can judge the numbers, here’s the setup without any polish:

• Sender: our development server at Hetzner in Nuremberg, 12 vCPUs, Ubuntu 24.04, kernel 6.8.
• Receiver: a Hetzner Cloud server in Helsinki, 4 vCPUs (AMD EPYC Genoa), Ubuntu 24.04, kernel 6.8. It runs a production trading service and another WireGuard tunnel. We didn’t touch either.
• Tool: iperf3 3.16, TCP, 10 seconds per run, multiple runs.
• WireGuard: kernel module, wireguard-tools 1.0.20210914, separate interface wgtest0 on UDP port 51999.
• Tailscale: client 1.102.4 (official static package), running on both sides as a separate process with its own state directory and TUN interface.
• Control server: Headscale 0.29.4, only for this test, on the Nuremberg server, firewalled so only the Helsinki server could reach it.
• CPU measurement: /proc/stat on the receiver before and after each run. From that, the total CPU time the system was busy, divided by gigabytes transferred. This includes iperf3 itself, so it’s a system figure, not a pure tunnel figure.

Afterwards we removed everything: interfaces, processes, the temporary firewall rule, state directories. The production tunnel in Helsinki kept handshaking normally the whole time.

One small stumble, because it can happen to anyone: when restarting the test Headscale we killed it with pkill -f "headscale serve -c ...". That pattern was also in the command line of our own shell, so pkill killed that too. Since then we write PIDs to a file and kill precisely. The same thing already happened to us during our Caddy vs Nginx comparison, so apparently it doesn’t stick the first time.

Is Tailscale slower than WireGuard?

Short answer: not meaningfully in our test. Long answer, with numbers:

What stands out:

1. The line itself fluctuates a lot. Without a tunnel, results ranged from 484 to 756 Mbit/s with plenty of TCP retransmits (up to 1,310 per run). This is a cross-border path over the public internet, not a lab cable.
2. Kernel WireGuard was the most consistent. Every run between 648 and 689 Mbit/s, zero retransmits in the first run. Quite possibly the tunnel changes packet sizing in a way that leads to fewer drops. That’s a guess; we didn’t dig further.
3. Tailscale varied more, slightly below WireGuard on average, above it in its best run. At our roughly 600 to 700 Mbit/s, the gap is irrelevant for almost any real use.

The old rule of thumb, “Tailscale runs in user space, so it’s slower”, dates from a time when wireguard-go processed every packet individually. Over the past few years Tailscale has added segmentation and coalescing offloads (GSO/GRO) for TUN and UDP that bundle many small packets into large ones. On current hardware and kernels the gap has shrunk a lot. At multi-gigabit speeds, in a data center or on a LAN, things may look different. We didn’t measure that.

CPU usage: the surprising part

Throughput alone doesn’t tell you much if one side burns an entire core to get there. So we measured the receiver’s CPU time per gigabyte transferred:

So encryption costs roughly three to nine times what plain transfer costs, whichever option you pick. Kernel WireGuard does its decryption in kernel soft interrupts; Tailscale does it in its own process. Bottom line: on this machine Tailscale was not more expensive, if anything slightly cheaper. During the runs, top showed the Tailscale process in Helsinki at 100 % of one core, meaning one of four cores fully busy. On a small machine with one or two cores, you’ll feel that.

We phrase this carefully because the measurement has limits: one pair of machines, one path, single-stream TCP, virtual machines sharing hardware with neighbours. On a Raspberry Pi or a router with a weak CPU the ratio probably looks different, because per-packet context switches weigh more there.

The finding that almost ruined a measurement

Two Tailscale runs suddenly needed 28 to 31 CPU-seconds per GB, double the usual. A look at tailscale status explained it:

100.64.0.1  ts-hel  tstest  linux  active; direct 10.99.0.2:41699

10.99.0.2 is the address of our WireGuard test tunnel. Tailscale had discovered the new interface, advertised the address as a possible path to the other side, and since that path worked, Tailscale traffic was flowing through the WireGuard tunnel. Double encryption, double CPU load, no error message. Once we tore the test tunnel down, Tailscale switched back to the public IPv6 address on its own.

That’s not a Tailscale bug; it’s exactly what Tailscale promises: “I’ll find a way.” But it also means: if you run Tailscale alongside other VPNs, check with tailscale status which path is actually in use. A tunnel inside a tunnel goes unnoticed day to day; it just makes everything a bit slower and more expensive.

Latency and MTU

Round-trip times (20 pings, 200 ms apart):

• direct: 23.8 ms average
• WireGuard: 24.5 ms
• Tailscale: 30.0 ms average, but with one 128 ms outlier; without it, also around 24.5 ms. tailscale ping reported 26 ms.

Both tunnels cost less than a millisecond. The Tailscale outlier came while the client was re-evaluating paths.

A detail rarely mentioned in comparisons: the MTU (maximum packet size) differs. WireGuard defaults to 1420 bytes, Tailscale to 1280 bytes. Tailscale deliberately picks the smallest size IPv6 guarantees so packets don’t get fragmented over mobile networks and nested tunnels. Smaller packets mean slightly more overhead, but fewer of those connections that “sort of hang” because large packets silently vanish along the way.

What happens when no direct path is possible?

This is the situation Tailscale was really built for: two devices, both behind routers, neither with a port forwarded. With plain WireGuard there’s no connection then; at least one side has to be reachable.

We recreated this by dropping, via nftables on the Nuremberg server, every UDP packet to and from the other side’s Tailscale port. After about 20 seconds the client reported:

100.64.0.1  ts-hel  tstest  linux  active; relay "hel"
pong from ts-hel (100.64.0.1) via DERP(hel) in 29ms

The connection kept running, through a Tailscale DERP server in Helsinki. Latency only rose slightly to 29 ms, because the relay happens to sit in the same city as the target. Throughput, however:

18 Mbit/s through the relay, instead of roughly 600 Mbit/s direct.

That’s not a bug, it’s by design. The relays are a free fallback for every Tailscale user worldwide and they’re rate-limited. For SSH, an admin panel or occasional file access it’s plenty. For backups or media streaming it isn’t.

After we removed the block, the direct connection was back within 4 seconds, without us doing anything.

The practical lesson: if Tailscale “feels slow”, it’s almost always the relay. tailscale status shows relay instead of direct, and tailscale netcheck tells you why. Opening a UDP port on one side (41641 by default) or enabling IPv6 often fixes it. In our case, by the way, the direct connection ran over IPv6 even though both servers also have IPv4.

What happens when the control server goes down?

That’s the second question you should ask about any managed service. We simply stopped our test Headscale.

Existing connections kept working. Pings through the tunnel: 0 % loss, 25 ms. The devices already know each other, the WireGuard keys are exchanged, and the control server isn’t needed for traffic in flight.

Restarting the client during the outage was a different story. We restarted tailscaled on the Nuremberg server while Headscale was down. Result:

You are logged out. The last login error was: fetch control key:
  ... dial tcp ...:18780: connect: connection refused
load netmap from cache: netmap cache is not available

No control server, no list of peers, no connection: 100 % packet loss. Only when Headscale came back was the tunnel up again, 4 seconds later.

That’s the real price of Tailscale over WireGuard. A WireGuard tunnel depends only on its two ends. A Tailscale device that reboots exactly while the control server is unreachable stays offline. With Tailscale’s own cloud that’s rare, but it happens. With a self-hosted Headscale it’s on you, and during a Headscale maintenance window it’s entirely possible that the very server you wanted to log into reboots at the wrong moment.

Rule of thumb: the access you use to fix a broken server shouldn’t depend on a system that depends on that server. For emergencies we always keep direct SSH access with keys over the public address, protected by a firewall and fail2ban.

Is Tailscale secure? And is WireGuard more secure?

The encryption is the same in both cases: WireGuard. Tailscale can’t read your traffic; private keys stay on the devices. Tailscale says so itself, and it follows from the architecture.

The difference lies elsewhere. With WireGuard, you decide which public keys a device accepts. With Tailscale, the control server decides which keys and addresses get distributed to your devices. A compromised control server, a hijacked admin account or a stolen auth key can bring a foreign device into your network. That device can’t read other people’s traffic, but it can reach everything your ACLs allow.

Tailscale has countermeasures: Tailnet Lock (new devices must be signed by already-trusted devices, not just by the control server), short-lived single-use auth keys, and ACLs that should be much tighter than “everyone can reach everything”. In our test we used a reusable key valid for two hours, purely for convenience. In production, that’s exactly the kind of key you don’t want lying around in a script or environment variable.

Video: Devsplainers compares Tailscale, WireGuard and Headscale through the question of who actually controls the keys. That’s the right angle for the security question.

The connections we didn’t ask for

During the test we used ss -tnp to check who tailscaled was talking to. We expected only our own Headscale. In fact there were four connections:

1. to our Headscale (as expected),
2. to two Tailscale DERP relay servers (derp26b.tailscale.com, derp28d.tailscale.com),
3. to an address in the log.tailscale.com network.

Item 2 was our own configuration: we’d told Headscale to use Tailscale’s public relay map instead of running our own DERP server. That’s the default template and handy for a test. If you don’t want it, enable Headscale’s built-in DERP server and remove the Tailscale URL.

Item 3 is telemetry: by default the Tailscale client uploads diagnostic logs, even when it isn’t connected to Tailscale’s control server at all. You can turn this off with the --no-logs-no-support flag for tailscaled (or the environment variable TS_NO_LOGS_NO_SUPPORT=true). The name says it: you then get no support from Tailscale. With a Headscale setup you wouldn’t get it anyway.

We don’t mention this as an accusation. It’s documented. But if you choose Headscale to be “independent of Tailscale”, you should know that’s not the default state; it’s a configuration you have to actively build.

Headscale: Tailscale without the Tailscale cloud

Headscale is an independent open-source project that reimplements Tailscale’s control server. It isn’t developed by Tailscale, though by the project’s own account Tailscale employees contribute, and the official clients support third-party control servers via --login-server.

Here’s our test setup, trimmed to the essentials:

# Headscale (a single binary, 51 MB)
./headscale serve -c config.yaml

# Create a user and an auth key
./headscale users create team
./headscale preauthkeys create --user 1 --expiration 1h

# On every device
tailscale up --login-server=https://vpn.example.com --authkey=<KEY>

Our config file was 37 lines. From starting Headscale to the first successful ping between both servers took a few minutes; tailscale up itself took just under 2 seconds.

What Headscale does well: devices, users, auth keys, ACLs, MagicDNS, subnet routers and exit nodes, and a built-in DERP server. What’s missing or weaker: some newer Tailscale features (such as Funnel, which publishes services through Tailscale’s infrastructure), an official web UI (third-party projects exist), and of course Tailscale’s operational experience. Headscale also only supports clients above a minimum version; on startup ours announced it would reject clients older than 1.80. If you run Headscale, you have to keep an eye on both server and clients.

Who Headscale makes sense for: anyone who wants Tailscale’s convenience but doesn’t want their device list and permissions sitting with an third-party provider, or who has more than six people on the network and doesn’t want to pay per user. Who it doesn’t suit: anyone who specifically doesn’t want to look after yet another server. For them, the Tailscale cloud is the more honest choice.

How much does Tailscale cost?

As listed on the pricing page on 4 October 2026:

• Personal: $0, up to 6 users, unlimited user devices, 50 “tagged resources” (servers, exit nodes and the like) included. Non-commercial use only.
• Standard: $8 per user per month.
• Premium: $18 per user per month.
• Enterprise: custom pricing.
• Additional tagged resources: $1 each per month.

Billing is per user, not per device. If you create a tailnet with a custom company domain, you’re automatically put into a business trial. Prices change; when in doubt, Tailscale’s own page wins.

WireGuard and Headscale cost nothing beyond the server they run on. A small VPS is plenty for Headscale. What you pay instead is your time for setup, updates and debugging when something breaks. We’ve written separately about what a VPS is and what to look for when choosing one.

When WireGuard, when Tailscale?

Our measurements and what we run ourselves point to a fairly clear picture.

Use plain WireGuard if …

• you want to connect two or three fixed locations, at least one of which has a public address (server to server, office to data center, home server to VPS),
• you don’t want a dependency on another service, not even a self-hosted one,
• you need your own VPN gateway to the internet (the classic “VPN server”),
• the configuration rarely changes.

That’s exactly how our Helsinki server has been running a WireGuard tunnel to a partner project for months: two ends, one key pair, a keepalive every 25 seconds. There’s nothing to manage, so there’s no need for a management layer.

Use Tailscale (or Headscale) if …

• many devices need to talk to each other, especially laptops and phones on changing networks,
• devices sit behind NAT or CGNAT where you can’t forward ports (mobile, fibre with shared IPv4),
• several people need access and you want permissions per person or group,
• you want to add and remove devices quickly without editing every other config.

Use Headscale instead of the Tailscale cloud if …

• you want Tailscale’s convenience but want to control the device list yourself,
• you have more than six users and don’t want to pay per head,
• you run servers anyway and one more doesn’t matter.

Common mistakes we’ve seen (or made)

1. Tunnel inside a tunnel. Tailscale takes any working path, including through another VPN. Check with tailscale status.
2. Relay for bulk data. Backups over a relay run at a fraction of the speed. If you move a lot of data, make sure there’s a direct path (UDP port or IPv6).
3. Reusable auth keys in scripts. Convenient and dangerous. Prefer short-lived single-use keys or OAuth clients.
4. No ACLs. Tailscale’s default for a long time was “everyone can reach everyone”. Convenient, and the exact opposite of zero trust.
5. Tying your emergency access to the VPN. If SSH is only reachable via Tailscale and the control server is down while the server reboots, you’re locked out.
6. WireGuard: forgetting the port. WireGuard doesn’t respond to anything that isn’t correctly authenticated. A blocked UDP port therefore looks exactly like a wrong key: nothing happens. wg show then shows no “latest handshake”.
7. WireGuard: misunderstanding AllowedIPs. The field is both a routing table and a source filter. Put 0.0.0.0/0 there and all traffic goes through the tunnel, whether you meant it to or not.

What we didn’t measure

So nobody reads more into this article than is in it:

• Only one path (Nuremberg–Helsinki), only data center servers with good connectivity. Home connections, Wi-Fi and mobile behave differently.
• Only single-stream TCP. Many parallel connections, UDP applications or lots of tiny packets (VoIP, say) weren’t tested.
• No weak hardware. On a Raspberry Pi, a NAS or a router, the gap between kernel and user space may be much larger.
• No Windows, macOS or phone clients. There’s no kernel WireGuard in the Linux sense there; both options go through system interfaces.
• No long-term operation of Tailscale on our side. We built it for this test and tore it down.
• Not the Tailscale cloud itself, but Headscale. The client is identical, and so are the data paths. We didn’t test the availability or features of the real Tailscale control server.

Frequently asked questions

What is the difference between Tailscale and WireGuard?

WireGuard is a VPN protocol that connects two devices with encryption once both have been configured for each other. Tailscale is a service that uses WireGuard and takes over the configuration automatically: key distribution, address assignment, NAT traversal, relay fallback, users and permissions.

Is Tailscale based on WireGuard?

Yes. The encryption and packet format are WireGuard. On Linux, however, Tailscale doesn’t use the kernel module but its own Go implementation (wireguard-go) running in user space.

Is Tailscale slower than WireGuard?

Barely, in our measurement between Nuremberg and Helsinki: kernel WireGuard came in around 670 Mbit/s, Tailscale between 475 and 750 Mbit/s. Tailscale gets much slower when no direct connection is possible and traffic goes through a relay. For us that was 18 Mbit/s.

Does Tailscale use more CPU than WireGuard?

Not in our test. Per gigabyte transferred, Tailscale used 11 to 16 CPU-seconds on the receiver, kernel WireGuard around 15.5. On weak hardware that may differ.

Is Tailscale secure?

The encryption is WireGuard; Tailscale can’t read your traffic. The risk lies in management: whoever controls the control server, your admin account or an auth key can add devices to your network. Tailnet Lock, tight ACLs and short-lived keys reduce that considerably.

Can Tailscale see my traffic?

Not the content. Private keys stay on the devices. Tailscale does see metadata, though: which devices exist, when they’re online, which addresses they’re reachable on. Encrypted packets also pass through its relays when no direct path exists.

Is Tailscale free?

For personal, non-commercial use, yes: the Personal plan costs $0 for up to 6 users with unlimited devices (as of 4 October 2026). Business plans cost $8 or $18 per user per month.

What is Headscale?

Headscale is an open-source, self-hostable replacement for the Tailscale control server. You use the regular Tailscale clients but register them with your own Headscale using --login-server. Free, but you’re responsible for operation, updates and availability.

Does Tailscale work when the control server is unreachable?

Existing connections keep running; we tested that. A device that restarts while the control server is unreachable, however, won’t rejoin the network because it can’t load the list of peers.

Do I need port forwarding for Tailscale?

Usually not. Tailscale often gets through NAT and otherwise falls back to relays. Opening UDP 41641 or having working IPv6 helps you get a fast direct connection, though.

Do I need port forwarding for WireGuard?

Yes, at least one side must be reachable over UDP. If both sides are behind NAT without forwarding, plain WireGuard won’t connect.

Are there alternatives to Tailscale?

Yes, for example NetBird, ZeroTier, Nebula or Netmaker. NetBird and Netmaker are also built on WireGuard and can be self-hosted. ZeroTier and Nebula use their own protocols. We didn’t test them for this article.

Conclusion: two answers to two different questions

In the end, Tailscale vs WireGuard isn’t a question of speed. On our path both were equally fast, and on CPU usage Tailscale did a bit better than we expected. The difference is who keeps the list of participants.

With WireGuard you keep it yourself, in config files. That’s tedious once you have more than a handful of devices, but there’s nothing in between that can fail, be compromised or phone home. For server-to-server links and fixed sites, that’s hard to beat.

With Tailscale a control server keeps it. That’s what makes networks with lots of changing devices manageable at all, and relays rescue connections that WireGuard alone would never establish. In exchange your network depends on one more service, and you should know what it does by default (relays, logs) and what happens when it’s gone.

Headscale sits in between: Tailscale’s comfort, your control, your work.

If you’re setting up your first server right now, start with the basics: setting up a Linux server, understanding SSH and a clean firewall. A VPN is the next layer, not the first.