Tailscale details a round of client and data-plane speedups
Tailscale published a blog post detailing a set of performance improvements to its client and data plane. On Linux and Android, the client now avoids copying small packets into oversized buffers: the underlying wireguard-go implementation only offers a single 64 KiB buffer to unpack incoming traffic, so even a typical 1 KiB packet used to be copied into a full 64 KiB allocation every time. Tailscale now leaves packets where they land inside a single large read instead of copying them, which alone produced roughly a 5% speed-up in many network configurations, according to the company. Shortening packet queues freed additional memory, which Tailscale says it redirected toward subnet routers and app connectors.
That freed capacity enabled a new multi-queue system for subnet routers, app connectors and exit nodes. These nodes previously processed all traffic through a single ordered pipeline shared across every connection, so a busy subnet router (for example one fronting a cloud deployment with hundreds of peers) could become a bottleneck. The new system gives each stream of packets its own lane, with lanes running in parallel across CPU cores, which Tailscale says raises aggregate capacity and lowers the delay between receiving and forwarding packets, with the biggest gains for app connectors and exit nodes serving many short-lived connections. Alex Valiushko, a member of technical staff at Tailscale, said: "This translates into lower latency, essentially faster processing of data from the moment we read it off the wire to the moment we send it to the OS." The company also described using Linux's writev capability to pass multiple pieces of packet data to the kernel in one operation instead of copying and combining them first, cutting memory copies and write operations.
Separately, Tailscale is rolling out netmap caching to speed up startup when the control plane is hard to reach, such as on bad airplane Wi-Fi or in a filtered hotel network. Normally a device connects to Tailscale's control plane in about 100 milliseconds on a typical network to fetch a "network map" describing reachable peers; on poor connections that can take much longer or fail outright. With caching enabled, each device stores a copy of its netmap on disk and can use it to connect to other devices directly (Tailscale does not see this traffic) while it keeps trying to reach the control plane for updated information. Caching only works if the device has connected to the tailnet at least once before, and requires persistent disk storage, so Tailscale suggests skipping it on exceptionally large tailnets (where cache updates can generate heavy disk traffic) or on devices with slow or wear-sensitive storage like SD cards. Claus Lensbøl, also a member of technical staff, said: "Bad network conditions, that's really the space where people can get a lot of utility out of netmap caching." Tailscale says it has observed tailnets with poor control-plane reachability start sending data-plane traffic one to two orders of magnitude faster on a "warm" cache start than a "cold" one.
On timing, Tailscale says the Linux/Android memory reduction is expected in the v1.104 client, while the multi-queue system for subnet routers and app connectors is planned for a release after v1.104, with the broader multi-queue technology targeted for the second half of 2026. The Linux/Android throughput gains were only partially implemented as of spring 2026, with the rest planned for a release after v1.104. Netmap caching is currently available behind a feature flag and is expected to become the default in v1.104 after further testing, with mobile clients getting it in a later release. The post also mentions earlier Tailscale work that pushed wireguard-go throughput past 10Gb/s on bare metal and increased UDP throughput over 4x using segmentation offloads, and closes by noting the company is exploring a Tailscale-aware performance monitoring and testing toolkit, citing gaps in existing tools around per-endpoint installation requirements, protocol support for QUIC and HTTP/3, and visibility into whether a connection uses DERP, a direct path, or a peer relay.
Key facts
- Avoiding copies of small packets into 64 KiB buffers on Linux/Android gave roughly a 5% speed-up in many configurations
- A new multi-queue system gives subnet routers, app connectors and exit nodes parallel lanes per connection instead of one shared pipeline, cutting latency, with broader multi-queue technology targeted for the second half of 2026
- Netmap caching stores a device's network map on disk so it can reach peers even when Tailscale's control plane (normally reachable in about 100 milliseconds) is slow or unreachable, giving one to two orders of magnitude faster startup on a warm cache versus cold
- Memory reduction is expected in the v1.104 client, multi-queue and the rest of the throughput gains in a release after v1.104, and netmap caching is expected to become default in v1.104 after currently running behind a feature flag
- Earlier Tailscale work had already pushed wireguard-go past 10Gb/s on bare metal and raised UDP throughput over 4x via segmentation offloads
Why it matters
Tailscale positions itself as a mesh VPN built for performance-sensitive workloads, from continuous integration and agentic workflows to remote development and robotic edge devices. This post is a status update on several concrete engineering changes meant to cut memory overhead, raise throughput on busy nodes, and shorten startup delays on unreliable networks, rather than a single headline feature.
Who it affects
The changes mainly benefit self-hosted infrastructure roles inside a tailnet: subnet routers, app connectors and exit nodes that handle many concurrent connections. Netmap caching benefits any device that regularly connects over poor or filtered networks, such as travel Wi-Fi or restrictive hotel networks, and the small-packet memory fix applies to Linux and Android clients specifically.
How to use it
Netmap caching is already available as a feature flag in the current Tailscale client for users who want to try it now, with plans to enable it by default in v1.104 after further testing; mobile support is expected in a later release. The Linux/Android memory reduction is expected in v1.104, while the multi-queue system for subnet routers and app connectors, along with the remaining throughput gains, are planned for a release after v1.104, with the multi-queue technology broadly targeted for the second half of 2026. Tailscale recommends against enabling netmap caching on exceptionally large tailnets or on devices with slow or wear-sensitive storage like SD cards.
How solid is it
This is a first-party account from Tailscale's own blog, including on-the-record quotes from two named staff members, Alex Valiushko and Claus Lensbøl. The company does not disclose benchmark methodology, test hardware, or workload details behind the 5% and earlier 4x figures, and gives no numeric figure for the multi-queue or writev gains themselves, so the claims should be read as vendor-reported rather than independently verified.
Risks and caveats
Several of the described improvements are not yet fully shipped: multi-queue support and part of the Linux/Android throughput work are planned for a release after v1.104, with no specific calendar date given. Netmap caching only works if a device has connected to the tailnet at least once before, requires persistent disk space, and Tailscale itself advises against it on exceptionally large tailnets or wear-sensitive storage due to potential disk traffic.
“Bad network conditions, that's really the space where people can get a lot of utility out of netmap caching. [A device client says], 'You know what? We haven't talked to control yet. We'll probably get there soon. In the meantime, you can still start doing something.'”
— Claus Lensbøl, member of technical staff at Tailscale