{"slug":"connection-types","title":"Connection types","tags":["tailscale"],"agent_summary":"Last validated: Jan 7, 2026","trigger_phrases":[],"runnable":false,"markdown":"\r\n# Connection types\r\n\r\nLast validated: Jan 7, 2026\r\n\r\nTailscale [connects devices](https://tailscale.com/docs/how-to/connect-to-devices) within a Tailscale network (known as a [tailnet](https://tailscale.com/docs/concepts/tailnet)) using three connection types:\r\n\r\n- **Direct connections**: Devices send packets directly to each other using UDP.\r\n- **DERP relayed connections**: Devices send packets through [DERP servers](https://tailscale.com/docs/reference/derp-servers).\r\n- **Tailscale Peer Relay connections**: Devices send packets through another device in the same tailnet acting as a relay.\r\n\r\nAll three options are end-to-end [encrypted](https://tailscale.com/docs/concepts/tailscale-encryption) with [WireGuard](https://tailscale.com/docs/concepts/wireguard). The primary difference between them is performance, not security. Direct connections usually provide the lowest latency and highest throughput, while relayed connections are a fallback when direct connectivity isn't possible.\r\n\r\n## [How Tailscale establishes connections](https://tailscale.com/docs/reference/connection-types\\#how-tailscale-establishes-connections)\r\n\r\nIn a typical scenario, two devices in a tailnet follow a standard sequence when negotiating a [connection between them](https://tailscale.com/docs/reference/device-connectivity).\r\n\r\nThe following example scenario shows this sequence of events between two devices connected to the same tailnet, named `device-a` and `device-b`. Because both devices are connected to the tailnet, they each have a connection to the closest DERP server to help them negotiate and establish connections to other tailnet devices.\r\n\r\n1. `device-a` starts a connection to `device-b`.\r\n2. `device-a` connects to the DERP server that `device-b` is already using.\r\n3. `device-a` sends the connection request to `device-b` through a DERP server.\r\n4. Devices exchange direct-connection details using their connected DERP servers.\r\n1. `device-a` sends a request for direct connection details.\r\n2. `device-b` responds with its direct connection details.\r\n5. Both devices perform NAT traversal. They try various NAT traversal strategies to establish a direct UDP tunnel between themselves.\r\n1. If NAT traversal succeeds, `device-a` and `device-b` establish a direct (peer-to-peer) connection. They don't need to relay packets through a third device (such as a DERP server or a peer relay server).\r\n2. If the devices can't establish a direct connection, they try to connect using a Tailscale Peer Relay server. For this to be possible, the tailnet must have at least one peer relay device that both `device-a` and `device-b` can access.\r\n3. If there's no available peer relay, the devices remain connected using the DERP server to relay packets between them.\r\n6. Tailscale periodically re-checks if it can establish a direct connection or a peer relay connection.\r\n\r\nAll connections start as relayed through a DERP server, and Tailscale then tries to upgrade them to a direct connection. If that fails, Tailscale tries to connect them using a peer relay. If that fails, the connection remains relayed through the DERP server.\r\n\r\n## [Direct connections](https://tailscale.com/docs/reference/connection-types\\#direct-connections)\r\n\r\nA direct connection is a peer-to-peer connection between two tailnet devices where they can send packets directly to each other over UDP. In most cases, a direct connection is preferable to a relayed connection because it offers higher throughput and lower latency.\r\n\r\nTailscale's ability to establish a direct connection depends on its [NAT traversal logic](https://tailscale.com/blog/how-nat-traversal-works) and the network configuration of the devices. In most environments, Tailscale successfully establishes direct connections, but some network configurations (hard NAT) can prevent this and force Tailscale to use relayed connections instead.\r\n\r\n## [Relayed connections](https://tailscale.com/docs/reference/connection-types\\#relayed-connections)\r\n\r\nA relayed connection is a connection between two devices that is relayed through an intermediate host instead of going directly between the devices. Tailscale uses two kinds of relayed connections:\r\n\r\n- DERP relayed connections: Use Tailscale's DERP servers as relays.\r\n- Tailscale Peer relay connections: Use another device in the same tailnet as the relay.\r\n\r\n### [DERP connections](https://tailscale.com/docs/reference/connection-types\\#derp-connections)\r\n\r\nTailscale operates a worldwide fleet of [DERP servers](https://tailscale.com/docs/reference/derp-servers). These servers primarily:\r\n\r\n- Help devices discover each other and negotiate connection details.\r\n- Facilitate the transition between connection types (for example, from relayed to direct).\r\n- Provide a fallback connection when a direct connection isn't possible.\r\n\r\nAny device that can open an HTTPS connection to an arbitrary host can build a tunnel using DERP relays. DERP servers are reliable but have limited quality of service ( [QoS](https://www.fortinet.com/resources/cyberglossary/qos-quality-of-service)) characteristics, so they are generally slower than direct connections and may offer lower maximum throughput.\r\n\r\nBecause of this, using a relayed connection when a direct connection would be possible is one of the most common causes of [performance issues](https://tailscale.com/docs/reference/troubleshooting/connectivity).\r\n\r\n### [Peer relay connections](https://tailscale.com/docs/reference/connection-types\\#peer-relay-connections)\r\n\r\nPeer relay connections use [Tailscale Peer Relays](https://tailscale.com/docs/features/peer-relay) to relay traffic through another device in the same tailnet when a direct connection between two devices isn't possible.\r\n\r\nPeer relay connections are usually faster than DERP connections because they avoid the extra latency of routing traffic through a geographically distant DERP server. However, they still introduce more latency than a fully direct connection, because traffic must pass through an additional hop.\r\n\r\n## [Determine your connection type](https://tailscale.com/docs/reference/connection-types\\#determine-your-connection-type)\r\n\r\nYou can determine which connection type you're using by communicating between devices and then inspecting [`tailscale status`](https://tailscale.com/docs/reference/tailscale-cli#status) or [`tailscale ping`](https://tailscale.com/docs/reference/tailscale-cli#ping).\r\n\r\n### [Using `tailscale status`](https://tailscale.com/docs/reference/connection-types\\#using-tailscale-status)\r\n\r\nRun [`tailscale status`](https://tailscale.com/docs/reference/tailscale-cli#status) and examine the connection information for the peer device.\r\n\r\n- If the output contains \"`direct`\", the connection is direct.\r\n- If the output includes \"`relay`\", the connection is relayed through a DERP server.\r\n- If the output includes \"`peer-relay`\", the connection is relayed through a peer relay device.\r\n\r\nThe following output shows an example of a direct connection:\r\n\r\n```markup\r\n100.113.160.82 device-a tagged-devices linux active; offers exit node; direct 140.82.13.138:41641\r\n```\r\n\r\nThe following output shows an example of a relayed connection using a DERP server:\r\n\r\n```markup\r\n100.104.93.78 localhost-0 user@ android active; relay \"tor\"\r\n```\r\n\r\n### [Using `tailscale ping`](https://tailscale.com/docs/reference/connection-types\\#using-tailscale-ping)\r\n\r\nYou can also use [`tailscale ping`](https://tailscale.com/docs/reference/tailscale-cli#ping) to determine if you can establish a direct connection from your current device to another device in the tailnet.\r\n\r\n#### [Direct connection example](https://tailscale.com/docs/reference/connection-types\\#direct-connection-example)\r\n\r\nThe following output shows an example of `your-device` connected directly to `another-device`:\r\n\r\n```markup\r\n> user@your-device:~$ tailscale ping another-device\r\npong from another-device (100.113.160.82) via DERP(nyc) in 130ms\r\npong from another-device (100.113.160.82) via DERP(nyc) in 37ms\r\npong from another-device (100.113.160.82) via DERP(nyc) in 50ms\r\npong from another-device (100.113.160.82) via DERP(nyc) in 38ms\r\npong from another-device (100.113.160.82) via 140.82.13.138:41641 in 35ms\r\n```\r\n\r\nHere, the first few packets go through the nearest DERP server while Tailscale negotiates a direct connection. After the direct connection is established, subsequent packets go directly to the destination.\r\n\r\n#### [Peer relayed connection example](https://tailscale.com/docs/reference/connection-types\\#peer-relayed-connection-example)\r\n\r\nThe following output shows an example of `your-device` connected to `another-device` using a peer relay server:\r\n\r\n```markup\r\n> user@your-device:~$ tailscale ping another-device\r\npong from another-device (100.97.143.93) via DERP(lax) in 40ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 4ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 5ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 3ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 4ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 5ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 4ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 4ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 4ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 3ms\r\ndirect connection not established\r\n```\r\n\r\n#### [DERP relayed connection example](https://tailscale.com/docs/reference/connection-types\\#derp-relayed-connection-example)\r\n\r\nThe following output shows an example of `your-device` connected to `another-device` using a DERP server as a relay:\r\n\r\n```markup\r\n> user@your-device:~$ tailscale ping another-device\r\npong from another-device (100.104.93.78) via DERP(tor) in 53ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 196ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 50ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 214ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 273ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 274ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 282ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 273ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 76ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 152ms\r\ndirect connection not established\r\n```\r\n\r\n## [Why Tailscale can't always use direct connections](https://tailscale.com/docs/reference/connection-types\\#why-tailscale-cant-always-use-direct-connections)\r\n\r\nTailscale can't always establish a direct connection between devices. And if network conditions change, it's possible for an existing direct connection to fall back to a relayed connection if a direct connection is no longer possible. The most common scenarios that prevent direction connections include blocked UDP packets and hard NAT scenarios.\r\n\r\n### [Blocked UDP packets](https://tailscale.com/docs/reference/connection-types\\#blocked-udp-packets)\r\n\r\nTo establish a direct connection, a device must be able to send and receive UDP packets. If something on the network blocks direct UDP connections, devices can't establish direct connections, but they can still use relayed connections using a [Tailscale Peer Relay server](https://tailscale.com/docs/features/peer-relay) or a DERP server.\r\n\r\nIn these cases, to prevent relayed connections, work with your network or service provider to allow outbound and return UDP traffic.\r\n\r\n### [Hard NAT](https://tailscale.com/docs/reference/connection-types\\#hard-nat)\r\n\r\n[Hard NAT](https://tailscale.com/docs/reference/device-connectivity#hard-nat) scenarios make establishing direct connections difficult, and sometimes impossible. Hard NAT refers to a network scenario in which a device is behind a gateway with two characteristics that break peer-to-peer connections: each outbound connection gets its own port mapping that only accepts replies from that specific destination, and each connection uses a different external port that outside devices cannot predict. Tailscale can't establish a direct connection if both devices are behind a hard NAT.\r\n\r\nBut, even when a device is behind a hard NAT, you can take steps to improve the chances of establishing a direct connection.\r\n\r\n#### [Home and small office networks](https://tailscale.com/docs/reference/connection-types\\#home-and-small-office-networks)\r\n\r\nOn many routers, there are settings you can adjust to make direct connections more likely. For example, you can enable NAT-PMP or UPnP port mapping on your router to give Tailscale more predictable, reachable ports. This facilitates static port mapping to keep port numbers predictable. Predictable port numbers make it easier for Tailscale to reliably establish direct connections through a firewall.\r\n\r\nBy default, opening UDP port `41641` on a device's public IP address ensures a direct connection from any peer device, where possible. You can change this port number by passing `--port=` to [`tailscaled`](https://tailscale.com/docs/reference/tailscaled). On Linux, you can set this in `/etc/defaults/tailscaled`.\r\n\r\n#### [Cloud platforms and NAT gateways](https://tailscale.com/docs/reference/connection-types\\#cloud-platforms-and-nat-gateways)\r\n\r\nMany cloud platforms, such as [AWS](https://tailscale.com/docs/reference/reference-architectures/aws), use NAT gateways that can behave like hard NATs. When devices are behind these gateways, relayed connections are often the result.\r\n\r\nTo improve the odds of direct connections, you can:\r\n\r\n- Expose public IP addresses (dynamic or static) for your Tailscale devices.\r\n- Ensure that UDP port `41641` is not blocked.\r\n\r\nIf you can't make these changes, you can set up a [Tailscale Peer Relay](https://tailscale.com/docs/features/peer-relay) server to relay communication between your devices. A peer relay server is generally faster than a DERP server and runs within your own infrastructure (so there's no need to traverse gateways or egress traffic).\r\n\r\n#### [Exit nodes and Terraform](https://tailscale.com/docs/reference/connection-types\\#exit-nodes-and-terraform)\r\n\r\nFor devices such as [exit nodes](https://tailscale.com/docs/features/exit-nodes) that intentionally egress through a NAT gateway, you can use Tailscale's Terraform templates to:\r\n\r\n- Route incoming traffic through the public interface.\r\n- Route outgoing traffic through the NAT gateway.\r\n\r\nContact the Tailscale Solutions Engineering team at `se@tailscale.com` for assistance deploying this. This enables the egress traffic to have a predictable public IP address, but the ingress traffic establishes a direct connection to the exit node. This pattern also applies for other Tailscale connectors, including subnet routers and app connectors.\r\n\r\n![Project Logo](https://cdn.brandfetch.io/tailscale.com/fallback/lettermark/theme/dark/h/256/w/256/icon?c=1bfwsmEH20zzEfSNTed)\r\n\r\nAsk AI\r\n\r\nreCAPTCHA\r\n\r\nRecaptcha requires verification.\r\n\r\nprotected by **reCAPTCHA**\r\n","html":"

Connection types

\n

Last validated: Jan 7, 2026

\n

Tailscale connects devices within a Tailscale network (known as a tailnet) using three connection types:

\n\n

All three options are end-to-end encrypted with WireGuard. The primary difference between them is performance, not security. Direct connections usually provide the lowest latency and highest throughput, while relayed connections are a fallback when direct connectivity isn't possible.

\n

How Tailscale establishes connections

\n

In a typical scenario, two devices in a tailnet follow a standard sequence when negotiating a connection between them.

\n

The following example scenario shows this sequence of events between two devices connected to the same tailnet, named device-a and device-b. Because both devices are connected to the tailnet, they each have a connection to the closest DERP server to help them negotiate and establish connections to other tailnet devices.

\n
    \n
  1. device-a starts a connection to device-b.
    2. \n
  2. device-a connects to the DERP server that device-b is already using.
    3. \n
  3. device-a sends the connection request to device-b through a DERP server.
    4. \n
  4. Devices exchange direct-connection details using their connected DERP servers.
    5. \n
  5. device-a sends a request for direct connection details.
    6. \n
  6. device-b responds with its direct connection details.
    7. \n
  7. Both devices perform NAT traversal. They try various NAT traversal strategies to establish a direct UDP tunnel between themselves.
    8. \n
  8. If NAT traversal succeeds, device-a and device-b establish a direct (peer-to-peer) connection. They don't need to relay packets through a third device (such as a DERP server or a peer relay server).
    9. \n
  9. If the devices can't establish a direct connection, they try to connect using a Tailscale Peer Relay server. For this to be possible, the tailnet must have at least one peer relay device that both device-a and device-b can access.
    10. \n
  10. If there's no available peer relay, the devices remain connected using the DERP server to relay packets between them.
    11. \n
  11. Tailscale periodically re-checks if it can establish a direct connection or a peer relay connection.
    12. \n
\n

All connections start as relayed through a DERP server, and Tailscale then tries to upgrade them to a direct connection. If that fails, Tailscale tries to connect them using a peer relay. If that fails, the connection remains relayed through the DERP server.

\n

Direct connections

\n

A direct connection is a peer-to-peer connection between two tailnet devices where they can send packets directly to each other over UDP. In most cases, a direct connection is preferable to a relayed connection because it offers higher throughput and lower latency.

\n

Tailscale's ability to establish a direct connection depends on its NAT traversal logic and the network configuration of the devices. In most environments, Tailscale successfully establishes direct connections, but some network configurations (hard NAT) can prevent this and force Tailscale to use relayed connections instead.

\n

Relayed connections

\n

A relayed connection is a connection between two devices that is relayed through an intermediate host instead of going directly between the devices. Tailscale uses two kinds of relayed connections:

\n\n

DERP connections

\n

Tailscale operates a worldwide fleet of DERP servers. These servers primarily:

\n\n

Any device that can open an HTTPS connection to an arbitrary host can build a tunnel using DERP relays. DERP servers are reliable but have limited quality of service ( QoS) characteristics, so they are generally slower than direct connections and may offer lower maximum throughput.

\n

Because of this, using a relayed connection when a direct connection would be possible is one of the most common causes of performance issues.

\n

Peer relay connections

\n

Peer relay connections use Tailscale Peer Relays to relay traffic through another device in the same tailnet when a direct connection between two devices isn't possible.

\n

Peer relay connections are usually faster than DERP connections because they avoid the extra latency of routing traffic through a geographically distant DERP server. However, they still introduce more latency than a fully direct connection, because traffic must pass through an additional hop.

\n

Determine your connection type

\n

You can determine which connection type you're using by communicating between devices and then inspecting tailscale status or tailscale ping.

\n

Using tailscale status

\n

Run tailscale status and examine the connection information for the peer device.

\n\n

The following output shows an example of a direct connection:

\n
100.113.160.82 device-a tagged-devices linux active; offers exit node; direct 140.82.13.138:41641\n
\n

The following output shows an example of a relayed connection using a DERP server:

\n
100.104.93.78 localhost-0 user@ android active; relay \"tor\"\n
\n

Using tailscale ping

\n

You can also use tailscale ping to determine if you can establish a direct connection from your current device to another device in the tailnet.

\n

Direct connection example

\n

The following output shows an example of your-device connected directly to another-device:

\n
> user@your-device:~$ tailscale ping another-device\r\npong from another-device (100.113.160.82) via DERP(nyc) in 130ms\r\npong from another-device (100.113.160.82) via DERP(nyc) in 37ms\r\npong from another-device (100.113.160.82) via DERP(nyc) in 50ms\r\npong from another-device (100.113.160.82) via DERP(nyc) in 38ms\r\npong from another-device (100.113.160.82) via 140.82.13.138:41641 in 35ms\n
\n

Here, the first few packets go through the nearest DERP server while Tailscale negotiates a direct connection. After the direct connection is established, subsequent packets go directly to the destination.

\n

Peer relayed connection example

\n

The following output shows an example of your-device connected to another-device using a peer relay server:

\n
> user@your-device:~$ tailscale ping another-device\r\npong from another-device (100.97.143.93) via DERP(lax) in 40ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 4ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 5ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 3ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 4ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 5ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 4ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 4ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 4ms\r\npong from another-device (100.97.143.93) via peer-relay(192.168.64.2:7777:vni:1) in 3ms\r\ndirect connection not established\n
\n

DERP relayed connection example

\n

The following output shows an example of your-device connected to another-device using a DERP server as a relay:

\n
> user@your-device:~$ tailscale ping another-device\r\npong from another-device (100.104.93.78) via DERP(tor) in 53ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 196ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 50ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 214ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 273ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 274ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 282ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 273ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 76ms\r\npong from another-device (100.104.93.78) via DERP(tor) in 152ms\r\ndirect connection not established\n
\n

Why Tailscale can't always use direct connections

\n

Tailscale can't always establish a direct connection between devices. And if network conditions change, it's possible for an existing direct connection to fall back to a relayed connection if a direct connection is no longer possible. The most common scenarios that prevent direction connections include blocked UDP packets and hard NAT scenarios.

\n

Blocked UDP packets

\n

To establish a direct connection, a device must be able to send and receive UDP packets. If something on the network blocks direct UDP connections, devices can't establish direct connections, but they can still use relayed connections using a Tailscale Peer Relay server or a DERP server.

\n

In these cases, to prevent relayed connections, work with your network or service provider to allow outbound and return UDP traffic.

\n

Hard NAT

\n

Hard NAT scenarios make establishing direct connections difficult, and sometimes impossible. Hard NAT refers to a network scenario in which a device is behind a gateway with two characteristics that break peer-to-peer connections: each outbound connection gets its own port mapping that only accepts replies from that specific destination, and each connection uses a different external port that outside devices cannot predict. Tailscale can't establish a direct connection if both devices are behind a hard NAT.

\n

But, even when a device is behind a hard NAT, you can take steps to improve the chances of establishing a direct connection.

\n

Home and small office networks

\n

On many routers, there are settings you can adjust to make direct connections more likely. For example, you can enable NAT-PMP or UPnP port mapping on your router to give Tailscale more predictable, reachable ports. This facilitates static port mapping to keep port numbers predictable. Predictable port numbers make it easier for Tailscale to reliably establish direct connections through a firewall.

\n

By default, opening UDP port 41641 on a device's public IP address ensures a direct connection from any peer device, where possible. You can change this port number by passing --port=<number> to tailscaled. On Linux, you can set this in /etc/defaults/tailscaled.

\n

Cloud platforms and NAT gateways

\n

Many cloud platforms, such as AWS, use NAT gateways that can behave like hard NATs. When devices are behind these gateways, relayed connections are often the result.

\n

To improve the odds of direct connections, you can:

\n\n

If you can't make these changes, you can set up a Tailscale Peer Relay server to relay communication between your devices. A peer relay server is generally faster than a DERP server and runs within your own infrastructure (so there's no need to traverse gateways or egress traffic).

\n

Exit nodes and Terraform

\n

For devices such as exit nodes that intentionally egress through a NAT gateway, you can use Tailscale's Terraform templates to:

\n\n

Contact the Tailscale Solutions Engineering team at se@tailscale.com for assistance deploying this. This enables the egress traffic to have a predictable public IP address, but the ingress traffic establishes a direct connection to the exit node. This pattern also applies for other Tailscale connectors, including subnet routers and app connectors.

\n

\"Project

\n

Ask AI

\n

reCAPTCHA

\n

Recaptcha requires verification.

\n

protected by reCAPTCHA

\n"}