Every stream through a subnet router, app connector or exit node goes down one lane today. Tailscale’s explanation is ordering: a receiving application must never see its own packets arrive out of order, so the whole path has been kept single-threaded. One reader, four crypto stages, a writer, shared by every connection on the node. The rework splits that into several lanes, scaled to the machine’s resources rather than to the number of peers, with each stream assigned a lane and staying on it. The lanes then run in parallel and the work spreads across cores. Tailscale says app connectors and exit nodes, which serve many short-lived connections, see the most benefit. It lands in a release after v1.104.
What ships first
Small packets were paying for big ones. Generic Receive Offload means the client has to be ready to accept 64 KiB at once, and wireguard-go offered a single 64 KiB buffer to unpack into, so a 1 KiB packet was copied into its own 64 KiB buffer every time. On Linux and Android the client now leaves each packet where it landed and records where it starts and ends inside the read. That alone is worth roughly 5% in many configurations. Shortening the packet queues freed more memory, and that memory paid for the multi-queue work.
On Linux, writev lets the client hand several pieces of packet data to the kernel in one call instead of copying them into one buffer first.
Netmap caching
A client starting up contacts the control plane, authenticates, and gets a network map, about 100 ms on a typical network. Netmap caching stores that map on disk so a device can reach the other devices before the control plane answers. Tailscale says tailnets with poor control-plane reachability go from a cold start to sending through the data plane one to two orders of magnitude faster on a warm cache.
The limits are real. The device has to have connected at least once to have a map at all, and it needs persistent disk to keep one. On exceptionally large tailnets, refreshing the cache means disk traffic; on SD cards and other wear-sensitive storage you may not want it enabled.
When
Memory reduction arrives in v1.104. Netmap caching is expected by default in v1.104, with mobile clients after that, and it is available now behind a feature flag. Multi-queue is planned for a release after v1.104, and the rest of the throughput work is partially landed from spring 2026 with the remainder after v1.104. All of it is Linux and, where applicable, Android.
My read
Netmap caching is the piece with a homelab use: it is the difference between your tailnet coming up on its own and waiting for someone else’s control plane to answer. Everything else here is throughput on hardware most people are not saturating.
The numbers are Tailscale’s, from Tailscale’s own test setups, and there is nothing to configure today.
Source: We’re making Tailscale faster