Skip to content

Why Tailscale NAS File Transfers Are Slow

Diagnose 1–2MB/s NAS transfers over Tailscale by checking direct versus DERP relay paths, NAT, UDP, iperf, storage, SMB, and file count.

WarpSend Engineering Reviewed by Charlie Updated 6 min read

A NAS transfer over Tailscale can be much slower than the connection advertised at either site. Start by identifying the active path: direct, peer-relayed, or DERP-relayed. Then compare network throughput with the actual file copy to locate the remaining limit.

For example, a sustained 1.5 MB/s carries about 12 Mbps and needs roughly 7.7 days for a decimal 1 TB payload. That arithmetic makes it worth checking the path and the sender’s upload capacity before changing file-service settings.

Step 1: Determine direct, peer-relay, or DERP

Tailscale documents three connection types:

  • Direct: packets travel directly between the devices over UDP.
  • Peer relay: traffic passes through another device in the tailnet.
  • DERP relay: traffic passes through a Tailscale DERP server when a direct or peer-relay path is unavailable.

All three are end-to-end encrypted with WireGuard. Tailscale says direct connections normally provide the lowest latency and highest throughput, while relayed paths are fallbacks and may be slower.

Generate traffic, then inspect:

tailscale status
tailscale ping <peer-name-or-IP>

Look for direct, relay, or peer-relay. Read Tailscale’s current Connection types documentation for examples.

Do not stop after the first ping. Tailscale connections can begin through DERP while the devices negotiate a direct path.

StatusPathNormal expectationNext action when slow
directEndpoint to endpoint over UDPLowest latency and usually highest throughputTest internet direction, CPU, storage, SMB, and file pattern
peer-relayThrough a relay device in the same tailnetExtra hop, often faster than DERPMeasure relay bandwidth and latency; verify relay placement and capacity
relayThrough a Tailscale DERP regionReliable fallback with throughput fairness limitsRun netcheck; investigate blocked UDP, hard NAT, firewall, and path to the DERP region

Tailscale’s 2026 documentation says every connection starts relayed and attempts to upgrade to direct, then peer relay, with DERP as the remaining fallback. Do not classify the path until traffic has had time to negotiate.

Step 2: If relayed, investigate why

Tailscale identifies hard NAT and blocked UDP as common reasons a direct connection cannot be established. It recommends tailscale netcheck for connectivity troubleshooting.

tailscale netcheck

Review:

  • whether UDP is available;
  • NAT mapping behavior on both sites;
  • whether the device is behind multiple routers or carrier-grade NAT;
  • firewall rules and endpoint security software;
  • IPv4 and IPv6 reachability; and
  • whether a peer relay is appropriate for the environment.

Tailscale’s Device connectivity page explains the NAT matrix and its peer-relay fallback. Its DERP server documentation explains the relay role and encryption model.

Tailscale also publishes a poor tailnet performance runbook that uses tailscale ping, tailscale status, and tailscale netcheck to separate relay and internet-path problems. Peer relays require supported clients and deliberate configuration; they are infrastructure, not a checkbox that makes every slow route direct.

Do not open ports blindly. Make network changes only when they fit your security policy and you understand which device owns the path.

Step 3: Measure raw throughput over the same path

Run a network throughput test between the actual endpoints. Test both directions because a home or branch connection can be asymmetric.

Using iperf3, a minimal comparison is:

# Destination test endpoint
iperf3 -s

# Source sends to destination
iperf3 -c <tailscale-IP> -t 30

# Destination sends back to source
iperf3 -c <tailscale-IP> -R -t 30

# Compare aggregate throughput with four flows
iperf3 -c <tailscale-IP> -P 4 -t 30

ESnet’s iperf3 manual documents reverse mode and parallel streams. Run the same commands over the ordinary LAN or public route where policy permits. Keep the endpoint hardware and test duration constant.

The purpose is not to produce an impressive number. It is to answer:

  • Can the path carry more than 1.5MB/s without SMB or file metadata?
  • Does the reverse direction behave differently?
  • Is performance stable for several minutes?
  • Does the result change when Tailscale becomes direct?

If raw network throughput is also 1.5MB/s, changing the file copier is unlikely to solve the root cause.

If four streams are much faster than one, record that result rather than declaring the path fixed. It suggests a single-flow or CPU limitation; SMB or another application may still use a different flow pattern.

Step 4: Test storage locally

On the source NAS, measure a local sequential read from the relevant volume. On the destination, measure a local sequential write. Watch DSM Resource Monitor for CPU, memory, disk utilization, and network flow.

Background tasks matter:

  • RAID rebuild or reshape;
  • data scrubbing;
  • Hyper Backup;
  • indexing and thumbnail generation;
  • antivirus scanning;
  • snapshots or cleanup; and
  • a nearly full or degraded storage pool.

If local storage cannot sustain the target rate, a direct Tailscale path will not change that.

Step 5: Separate SMB from the tunnel

SMB adds its own request, metadata, signing, encryption, client, and implementation behavior. Latency affects an interactive filesystem differently from a raw throughput test.

Compare:

  1. one large file over SMB;
  2. a folder of many small files over SMB;
  3. the same workloads with another approved transfer method; and
  4. local SMB without Tailscale.

This identifies whether the problem is the route, SMB over distance, or file count.

Step 6: Check the slower internet direction

Remote downloads from the NAS consume the NAS site’s upload capacity. If the NAS site uploads at 20Mbps, the best possible payload rate is about 2.5MB/s before overhead.

Run speed tests from both sites, but treat them as context rather than proof. The speed-test server is not the remote NAS and may follow a different route.

Step 7: Consider CPU and encryption cost

Older NAS models can become CPU-bound when handling encrypted tunnels, SMB signing or encryption, checksums, and file services at the same time. Watch per-process CPU during a sustained transfer.

A CPU limit often appears as a stable throughput ceiling with one core or process saturated while the disks and network remain underused.

Step 8: Test the real file pattern

One large video file amortizes setup work. Tens of thousands of small files repeatedly open, inspect, create, write metadata, and close. Across a higher-latency path, those round trips multiply.

Read Why Transferring Thousands of Small Files Is So Slow for the protocol-level explanation.

When a transfer-specific tool helps

After the raw path and storage are understood, a transfer-specific tool may improve the operational behavior:

  • automatic resume instead of restarting;
  • persistent transfer sessions;
  • batching or parallel handling of small files;
  • direct endpoint transfer rather than interactive remote filesystem access; and
  • job history and verification.

WarpDirect is one option between supported endpoints. It establishes its own transfer route rather than sending SMB through the tailnet. That makes it a useful A/B test, not a guaranteed cure. Compare the same endpoints and files, and keep the Tailscale path if it already meets the requirement. For NAS-heavy sites, the multi-site NAS setup shows how endpoints and recurring jobs are managed together.

A compact diagnostic checklist

  1. Check tailscale status and tailscale ping.
  2. Run tailscale netcheck if relayed.
  3. Measure raw throughput in both directions.
  4. Measure local source reads and destination writes.
  5. Compare local SMB with remote SMB.
  6. Test one large file and a small-file folder.
  7. Watch CPU, disk utilization, and background tasks.
  8. Change one layer at a time.

Keep the connection type and direction with each measurement. They explain why two transfers between the same devices can produce different results. If these copies are part of keeping two Synology sites aligned, the comparison of Synology replication methods helps decide between a one-off transfer, a sync job and Snapshot Replication.

Tailscale, ESnet, and Synology documentation were checked on August 6, 2026. Connection types and peer-relay requirements have changed over time, so use current client versions and documentation when reproducing the test.

Frequently asked questions

Why is my Tailscale NAS transfer only 1.5MB/s?

Common causes include a DERP-relayed path instead of a direct connection, hard NAT or blocked UDP, slow sender upload, destination storage, SMB behavior over latency, CPU limits, packet loss, and a workload containing many small files. Check the connection type before changing applications.

How can I tell whether Tailscale is using DERP?

Generate traffic between the devices, then inspect tailscale status or tailscale ping. Tailscale documents direct, relay, and peer-relay indicators. Use tailscale netcheck when a relayed path needs further investigation.

Is a DERP connection insecure?

No. Tailscale states that direct, DERP-relayed, and peer-relayed connections are end-to-end encrypted with WireGuard. The primary difference is performance and path, not whether the relay can decrypt the traffic.

Will a different file-transfer tool fix a slow Tailscale route?

Not necessarily. First fix or understand the network and storage ceilings. A transfer-specific tool may improve resume, batching, or long-distance behavior, but it cannot create bandwidth that the endpoints or route do not have.