{"slug":"tailscale-peer-relays","title":"Tailscale Peer Relays","tags":["tailscale"],"agent_summary":"Last validated: Feb 4, 2026","trigger_phrases":[],"runnable":false,"markdown":"\r\n# Tailscale Peer Relays\r\n\r\nLast validated: Feb 4, 2026\r\n\r\nTailscale Peer Relays let you use devices in your Tailscale network (known as a [tailnet](https://tailscale.com/docs/concepts/tailnet)) as high-throughput relay servers when [direct connections](https://tailscale.com/docs/reference/connection-types) aren't possible due to network conditions such as [a strict NAT environment](https://tailscale.com/docs/reference/device-connectivity).\r\n\r\nNormally, Tailscale relies on its globally distributed [DERP servers](https://tailscale.com/docs/reference/derp-servers) to relay traffic when Tailscale can't establish direct connections between devices. While DERP servers are effective at relaying traffic, they can introduce additional latency, especially for high-throughput applications. When you configure a device as a peer relay, other devices in the same tailnet can use it to relay traffic for client-to-client connections when a direct connection isn't possible. Tailscale first attempts to use any available peer relays in the tailnet before falling back to DERP servers.\r\n\r\nThe following related video provides additional context and examples.\r\n\r\nGet full line speed with Tailscale Peer Relays - YouTube\r\n\r\nTap to unmute\r\n\r\n[Get full line speed with Tailscale Peer Relays](https://www.youtube.com/watch?v=wkBSjT1hO6k) [Tailscale](https://www.youtube.com/channel/UCcdv38QxPjSMqbt5ffLhJLA)\r\n\r\nTailscale68.5K subscribers\r\n\r\n## [Use cases](https://tailscale.com/docs/features/peer-relay\\#use-cases)\r\n\r\nPeer relays are particularly useful in scenarios where you can't establish direct connections between devices due to network restrictions and you require lower latency and higher throughput than what DERP servers can provide. Common use cases include:\r\n\r\n- **Access restricted infrastructure**: Accessing devices behind strict NATs or firewalls where direct connections are not possible, such as in certain corporate or cloud environments.\r\n- **File transfers**: When transferring large files between devices, peer relays can offer higher throughput, speeding up the transfer process.\r\n- **Media streaming**: For streaming high-definition video or audio between devices, peer relays can help maintain a smooth streaming experience with less buffering.\r\n\r\nPeer relays are not intended to replace DERP servers. They complement DERP by providing an additional option for relaying traffic within a tailnet, particularly when you require lower latency and higher throughput. DERP servers still play a crucial role in negotiating connections and providing fallback relay options when peer relays are unavailable.\r\n\r\n## [How it works](https://tailscale.com/docs/features/peer-relay\\#how-it-works)\r\n\r\nWhen you configure a device as a peer relay, it listens for incoming relay traffic on a specified UDP port. Other devices in the tailnet can then use this device to relay traffic for client-to-client connections when direct connections aren't possible.\r\n\r\nWhen a device attempts to connect to another device in the tailnet, it first checks if a direct connection is possible. If not, it looks for available peer relays in the tailnet. If a peer relay is available and accessible, the device establishes a connection through the peer relay. If no peer relays are available, the device falls back to using DERP servers to relay the traffic.\r\n\r\n## [Prerequisites](https://tailscale.com/docs/features/peer-relay\\#prerequisites)\r\n\r\nBefore you can use the peer relay feature, ensure you meet the minimum requirements for your Tailscale account and the devices you want to configure as peer relays:\r\n\r\n### [Account requirements](https://tailscale.com/docs/features/peer-relay\\#account-requirements)\r\n\r\nTo use the peer relay feature, you must have:\r\n\r\n- A Tailscale account with access to the tailnet where you want to set up peer relays.\r\n- At least one device in the tailnet that meets the peer relay device requirements.\r\n- An account with [Owner, Admin, or Network admin](https://tailscale.com/docs/reference/user-roles) permissions.\r\n\r\n### [Peer relay device requirements](https://tailscale.com/docs/features/peer-relay\\#peer-relay-device-requirements)\r\n\r\nA device must meet the following requirements to function as a peer relay:\r\n\r\n- A device running a supported operating system. You can use any operating system other than iOS, Apple TV, or Android.\r\n- Tailscale version 1.86 or later.\r\n- Sufficient network bandwidth and low latency to effectively relay traffic for other devices.\r\n- At least one configurable UDP port you can use for peer relay traffic. This port must be accessible from other devices in the tailnet. Refer to [security and access control](https://tailscale.com/docs/features/peer-relay#security-and-access-control) for more information about configuring network settings.\r\n\r\n### [Other tailnet devices requirements](https://tailscale.com/docs/features/peer-relay\\#other-tailnet-devices-requirements)\r\n\r\nDevices in the tailnet that use peer relays must meet the following requirements:\r\n\r\n- Access to the peer relay devices (through applicable [access control policies](https://tailscale.com/docs/features/access-control)).\r\n- Tailscale version 1.86 or later.\r\n- Access to the UDP port configured for peer relay traffic on the peer relay devices.\r\n\r\nThere are no operating system restrictions for devices that use peer relays; they can run any supported Tailscale operating system, including iOS and Apple TV.\r\n\r\n## [Get started](https://tailscale.com/docs/features/peer-relay\\#get-started)\r\n\r\nSetting up peer relay functionality in a tailnet involves two primary steps. First, you need to configure a device to act as a peer relay. Then, you need to create a [grant policy](https://tailscale.com/docs/features/access-control/grants) to permit other devices in the tailnet to use the peer relay.\r\n\r\n### [Step 1: Configure a device as a peer relay](https://tailscale.com/docs/features/peer-relay\\#step-1-configure-a-device-as-a-peer-relay)\r\n\r\nTo use the peer relay feature for faster relayed connections, you must configure at least one device in the tailnet to function as a peer relay. Only devices that meet the [peer relay requirements](https://tailscale.com/docs/features/peer-relay#peer-relay-device-requirements) and that you explicitly designate can act as peer relays.\r\n\r\nTo set up a device as a peer relay:\r\n\r\n1. On the device you want to configure as a peer relay, start the Tailscale client and authenticate it to your tailnet.\r\n\r\n2. Open a terminal or command prompt on the device.\r\n\r\n3. Use the [`tailscale set`](https://tailscale.com/docs/reference/tailscale-cli#set) command with the `--relay-server-port` option to specify the UDP port for peer relay traffic. For example, to configure the device to use UDP port `40000` for peer relay traffic, run the following command:\r\n\r\n\r\n\r\n\r\n\r\n\r\n\r\n```shell\r\ntailscale set --relay-server-port=40000\r\n```\r\n\r\n\r\nYou can also use the `--relay-server-static-endpoints` flag with the `tailscale set` command to specify additional [static endpoints](https://tailscale.com/docs/features/peer-relay#static-endpoints) to advertise to peer relay participants.\r\n\r\n### [Step 2: Create a peer relay policy](https://tailscale.com/docs/features/peer-relay\\#step-2-create-a-peer-relay-policy)\r\n\r\nBefore devices in the tailnet can use devices you designate as peer relays, you need to create a [grant](https://tailscale.com/docs/features/access-control/grants) policy that lets them do so. The grant policy uses the `tailscale.com/cap/relay` [application capability](https://tailscale.com/docs/features/access-control/grants/grants-app-capabilities) to specify which devices can use the peer relay functionality. You can create the grant policy using the admin console's JSON editor, the [visual policy editor](https://tailscale.com/docs/features/visual-editor), or the [Tailscale API](https://tailscale.com/docs/reference/tailscale-api).\r\n\r\nTo create a grant that enables peer relay capabilities using the JSON editor:\r\n\r\n1. Open the [Access controls](https://login.tailscale.com/admin/acls/file) page of the admin console.\r\n2. Select the **JSON editor** tab to update the tailnet policy file using JSON.\r\n3. Locate the `grants` section of the policy file.\r\n4. Add a policy to the `grants` section of the policy file that specifies the `src` (devices behind a restrictive NAT that need to be accessed through the peer relay), the `dst` (the peer relay device), and the `peer-relay` application capability. For example, the following example lets all devices with the tag `tag:us-east-vpc` use peer relays tagged with `tag:us-east-relays`.\r\n\r\n```json\r\n{\r\n \"grants\": [\\\r\n {\\\r\n \"src\": [\"tag:us-east-vpc\"], // Devices that can be accessed through the peer relay\\\r\n \"dst\": [\"tag:us-east-relays\"], // Devices functioning as peer relays for the src devices\\\r\n \"app\": {\\\r\n \"tailscale.com/cap/relay\": [] // The relay capability doesn't require any parameters\\\r\n }\\\r\n }\\\r\n ]\r\n}\r\n```\r\n\r\nYou can reference peer relay devices using [tags](https://tailscale.com/docs/features/tags), hostname, [IP set](https://tailscale.com/docs/features/tailnet-policy-file/ip-sets), or Tailscale IP addresses in the `dst` field of the access rule. The `app` field must include the `tailscale.com/cap/relay` capability to enable peer relay functionality for the specified devices. It does not require any additional parameters.\r\n\r\nAfter you create the peer relay grant policy, devices in the tailnet can start using the peer relay for client-to-client connections when direct connections aren't possible. When a device can't connect directly to another device, it first checks for available peer relays in the tailnet. If no peer relays are available, the device falls back to using DERP servers.\r\n\r\nAvoid using overly permissive targets for the `src` field of the grant policy (such as `*`). For example, using `*` would make all devices in the tailnet attempt to use the peer relay devices in the `dst`, potentially leading to unintended traffic routing and high latency. Instead, specify precise device [tags](https://tailscale.com/docs/features/tags), hostnames, or [IP sets](https://tailscale.com/docs/features/tailnet-policy-file/ip-sets) to limit which devices can use the peer relay.\r\n\r\nAs a rule of thumb, the `src` devices in the grant policy should typically be devices in a stable physical location behind a strict NAT or firewall that prevents direct connections. This typically includes devices in corporate networks or cloud environments. It usually does not include mobile devices or laptops that frequently change locations and network conditions.\r\n\r\n### [Step 3: Observe peer relay traffic](https://tailscale.com/docs/features/peer-relay\\#step-3-observe-peer-relay-traffic)\r\n\r\nGenerate traffic to test the peer relay configuration. Then, use the `tailscale status` command to monitor the device's status and verify that it is functioning as a peer relay. When a tailnet device uses a peer relay, the connection type of that device changes to `peer-relay`.\r\n\r\nRun the [`tailscale status`](https://tailscale.com/docs/reference/tailscale-cli#status) command and filter the output for `peer-relay` entries:\r\n\r\n```shell\r\ntailscale status | grep peer-relay\r\n```\r\n\r\nWhen a device is using a peer relay, it returns the device's connection type as `peer-relay` (instead of `direct` or `relay`). For example:\r\n\r\n```shell\r\n active; peer-relay ::vni:, tx rx \r\n```\r\n\r\nYou can also use the [`tailscale ping`](https://tailscale.com/docs/reference/tailscale-cli#ping) command to test connectivity between devices and observe whether the connection uses a peer relay.\r\n\r\n## [Disable Peer Relay](https://tailscale.com/docs/features/peer-relay\\#disable-peer-relay)\r\n\r\nTo disable peer relay for a device use the [`tailscale set`](https://tailscale.com/docs/reference/tailscale-cli#set) command with the `--relay-server-port` flag set to an empty string:\r\n\r\n```shell\r\ntailscale set --relay-server-port=\"\"\r\n```\r\n\r\n## [Examples](https://tailscale.com/docs/features/peer-relay\\#examples)\r\n\r\nExample scenarios in which you would use Tailscale Peer Relays include:\r\n\r\n- Accessing devices in a specific geographic region using peer relays located in that region to reduce latency.\r\n- Using peer relays to connect to devices behind strict NATs or firewalls where direct connections are not possible.\r\n- Setting up dedicated peer relay devices to handle high-throughput traffic for specific applications or services.\r\n\r\nThe following peer relay policy examples illustrate what the grant policy looks like in different scenarios.\r\n\r\n### [Use tagged peer relay devices](https://tailscale.com/docs/features/peer-relay\\#use-tagged-peer-relay-devices)\r\n\r\nThe following example lets all devices with the tag `tag:us-east-vpc` use peer relay devices tagged with `tag:us-east-relays` as underlay network relays when communicating with other devices on the tailnet. That means that other devices in the tailnet can use a device tagged with `tag:us-east-relays` as an underlay network relay when communicating with devices tagged with `tag:us-east-vpc`.\r\n\r\n```json\r\n{\r\n \"grants\": [\\\r\n {\\\r\n \"src\": [\"tag:us-east-vpc\"], // Devices behind a restrictive NAT that need to be accessed through the peer relay\\\r\n \"dst\": [\"tag:us-east-relays\"], // The devices functioning as peer relays for the src devices\\\r\n \"app\": {\\\r\n \"tailscale.com/cap/relay\": []\\\r\n }\\\r\n }\\\r\n ]\r\n}\r\n```\r\n\r\nFor this to work, you must also [configure the peer relay devices](https://tailscale.com/docs/features/peer-relay#step-1) using the `tailscale set` command and create a grant access control policy that permits overlay network access to devices with the `tag:us-east-vpc` tag.\r\n\r\nFor example, this grant policy lets all members of the tailnet access devices with the `tag:us-east-vpc` tag on TCP ports 80 and 443.\r\n\r\n```json\r\n{\r\n \"grants\": [\\\r\n {\\\r\n \"src\": [\"autogroup:member\"],\\\r\n \"dst\": [\"tag:us-east-vpc\"],\\\r\n \"ip\": [\"tcp:80\",\"tcp:443\"]\\\r\n }\\\r\n ]\r\n}\r\n```\r\n\r\n### [Use self as peer relay](https://tailscale.com/docs/features/peer-relay\\#use-self-as-peer-relay)\r\n\r\nIt's possible for devices to use themselves as a peer relay. The following example lets the device with the hostname `us-west-1` use itself as a peer relay. You might use this configuration in a scenario where you need to block all incoming ports to a device except for the UDP port used for peer relay traffic.\r\n\r\n```json\r\n{\r\n \"grants\": [\\\r\n {\\\r\n \"src\": [\"us-west-1\"],\\\r\n \"dst\": [\"us-west-1\"],\\\r\n \"app\": {\\\r\n \"tailscale.com/cap/relay\": []\\\r\n }\\\r\n }\\\r\n ]\r\n}\r\n```\r\n\r\nFor this to work, you must also [configure the device as a peer relay](https://tailscale.com/docs/features/peer-relay#step-1) using the `tailscale set` with the UDP port for peer relay traffic.\r\n\r\n## [Security and access control](https://tailscale.com/docs/features/peer-relay\\#security-and-access-control)\r\n\r\nPeer relays can only relay traffic for devices in the same tailnet. The grant rule that assigns the `tailscale.com/cap/relay` capability acts as the access control mechanism — a device without that grant can't allocate relay bindings on the peer relay. You don't need a separate network grant to the peer relay device itself.\r\n\r\nThe UDP port you configure for peer relay traffic must be open and accessible from other devices in the tailnet. For example, if you configure a peer relay to use UDP port `40000`, ensure that any firewalls or network security settings allow incoming traffic on that port.\r\n\r\n## [Static endpoints](https://tailscale.com/docs/features/peer-relay\\#static-endpoints)\r\n\r\nYou can use the `--relay-server-static-endpoints` flag with the [`tailscale set`](https://tailscale.com/docs/reference/tailscale-cli#set) command to specify one or more additional static endpoints for the peer relay to advertise to other tailnet devices. Doing so is useful in network environments where users use port forwarding or users use load balancers like AWS Network Load Balancer ( [NLB](https://aws.amazon.com/elasticloadbalancing/network-load-balancer/)). In these scenarios, the peer relay might not automatically discover all possible endpoints because it can't send outbound endpoint discovery packets over all possible paths.\r\n\r\nIt accepts a comma-separated list of `ip:port` pairs (or an empty string to not advertise any static endpoints). Each `ip:port` pair corresponds to an additional endpoint that the peer relay advertises to other tailnet devices.\r\n\r\n```shell\r\ntailscale set --relay-server-port= --relay-server-static-endpoints=\":,:\"\r\n```\r\n\r\nFor example, to configure the peer relay to advertise two additional static endpoints (`[2001:db8::1]:40000` and `192.0.2.2:40000`), you would run the following command:\r\n\r\n```shell\r\ntailscale set --relay-server-port=40000 --relay-server-static-endpoints=\"[2001:db8::1]:40000,192.0.2.2:40000\"\r\n```\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":"

Tailscale Peer Relays

\n

Last validated: Feb 4, 2026

\n

Tailscale Peer Relays let you use devices in your Tailscale network (known as a tailnet) as high-throughput relay servers when direct connections aren't possible due to network conditions such as a strict NAT environment.

\n

Normally, Tailscale relies on its globally distributed DERP servers to relay traffic when Tailscale can't establish direct connections between devices. While DERP servers are effective at relaying traffic, they can introduce additional latency, especially for high-throughput applications. When you configure a device as a peer relay, other devices in the same tailnet can use it to relay traffic for client-to-client connections when a direct connection isn't possible. Tailscale first attempts to use any available peer relays in the tailnet before falling back to DERP servers.

\n

The following related video provides additional context and examples.

\n

Get full line speed with Tailscale Peer Relays - YouTube

\n

Tap to unmute

\n

Get full line speed with Tailscale Peer Relays Tailscale

\n

Tailscale68.5K subscribers

\n

Use cases

\n

Peer relays are particularly useful in scenarios where you can't establish direct connections between devices due to network restrictions and you require lower latency and higher throughput than what DERP servers can provide. Common use cases include:

\n
    \n
  • Access restricted infrastructure: Accessing devices behind strict NATs or firewalls where direct connections are not possible, such as in certain corporate or cloud environments.
    • \n
  • File transfers: When transferring large files between devices, peer relays can offer higher throughput, speeding up the transfer process.
    • \n
  • Media streaming: For streaming high-definition video or audio between devices, peer relays can help maintain a smooth streaming experience with less buffering.
    • \n
\n

Peer relays are not intended to replace DERP servers. They complement DERP by providing an additional option for relaying traffic within a tailnet, particularly when you require lower latency and higher throughput. DERP servers still play a crucial role in negotiating connections and providing fallback relay options when peer relays are unavailable.

\n

How it works

\n

When you configure a device as a peer relay, it listens for incoming relay traffic on a specified UDP port. Other devices in the tailnet can then use this device to relay traffic for client-to-client connections when direct connections aren't possible.

\n

When a device attempts to connect to another device in the tailnet, it first checks if a direct connection is possible. If not, it looks for available peer relays in the tailnet. If a peer relay is available and accessible, the device establishes a connection through the peer relay. If no peer relays are available, the device falls back to using DERP servers to relay the traffic.

\n

Prerequisites

\n

Before you can use the peer relay feature, ensure you meet the minimum requirements for your Tailscale account and the devices you want to configure as peer relays:

\n

Account requirements

\n

To use the peer relay feature, you must have:

\n
    \n
  • A Tailscale account with access to the tailnet where you want to set up peer relays.
    • \n
  • At least one device in the tailnet that meets the peer relay device requirements.
    • \n
  • An account with Owner, Admin, or Network admin permissions.
    • \n
\n

Peer relay device requirements

\n

A device must meet the following requirements to function as a peer relay:

\n
    \n
  • A device running a supported operating system. You can use any operating system other than iOS, Apple TV, or Android.
    • \n
  • Tailscale version 1.86 or later.
    • \n
  • Sufficient network bandwidth and low latency to effectively relay traffic for other devices.
    • \n
  • At least one configurable UDP port you can use for peer relay traffic. This port must be accessible from other devices in the tailnet. Refer to security and access control for more information about configuring network settings.
    • \n
\n

Other tailnet devices requirements

\n

Devices in the tailnet that use peer relays must meet the following requirements:

\n
    \n
  • Access to the peer relay devices (through applicable access control policies).
    • \n
  • Tailscale version 1.86 or later.
    • \n
  • Access to the UDP port configured for peer relay traffic on the peer relay devices.
    • \n
\n

There are no operating system restrictions for devices that use peer relays; they can run any supported Tailscale operating system, including iOS and Apple TV.

\n

Get started

\n

Setting up peer relay functionality in a tailnet involves two primary steps. First, you need to configure a device to act as a peer relay. Then, you need to create a grant policy to permit other devices in the tailnet to use the peer relay.

\n

Step 1: Configure a device as a peer relay

\n

To use the peer relay feature for faster relayed connections, you must configure at least one device in the tailnet to function as a peer relay. Only devices that meet the peer relay requirements and that you explicitly designate can act as peer relays.

\n

To set up a device as a peer relay:

\n
    \n
  1. \n

    On the device you want to configure as a peer relay, start the Tailscale client and authenticate it to your tailnet.

    \n
    2. \n
  2. \n

    Open a terminal or command prompt on the device.

    \n
    3. \n
  3. \n

    Use the tailscale set command with the --relay-server-port option to specify the UDP port for peer relay traffic. For example, to configure the device to use UDP port 40000 for peer relay traffic, run the following command:

    \n
    4. \n
\n
tailscale set --relay-server-port=40000\n
\n

You can also use the --relay-server-static-endpoints flag with the tailscale set command to specify additional static endpoints to advertise to peer relay participants.

\n

Step 2: Create a peer relay policy

\n

Before devices in the tailnet can use devices you designate as peer relays, you need to create a grant policy that lets them do so. The grant policy uses the tailscale.com/cap/relay application capability to specify which devices can use the peer relay functionality. You can create the grant policy using the admin console's JSON editor, the visual policy editor, or the Tailscale API.

\n

To create a grant that enables peer relay capabilities using the JSON editor:

\n
    \n
  1. Open the Access controls page of the admin console.
    2. \n
  2. Select the JSON editor tab to update the tailnet policy file using JSON.
    3. \n
  3. Locate the grants section of the policy file.
    4. \n
  4. Add a policy to the grants section of the policy file that specifies the src (devices behind a restrictive NAT that need to be accessed through the peer relay), the dst (the peer relay device), and the peer-relay application capability. For example, the following example lets all devices with the tag tag:us-east-vpc use peer relays tagged with tag:us-east-relays.
    5. \n
\n
{\r\n  \"grants\": [\\\r\n    {\\\r\n      \"src\": [\"tag:us-east-vpc\"], // Devices that can be accessed through the peer relay\\\r\n      \"dst\": [\"tag:us-east-relays\"], // Devices functioning as peer relays for the src devices\\\r\n      \"app\": {\\\r\n        \"tailscale.com/cap/relay\": [] // The relay capability doesn't require any parameters\\\r\n      }\\\r\n    }\\\r\n  ]\r\n}\n
\n

You can reference peer relay devices using tags, hostname, IP set, or Tailscale IP addresses in the dst field of the access rule. The app field must include the tailscale.com/cap/relay capability to enable peer relay functionality for the specified devices. It does not require any additional parameters.

\n

After you create the peer relay grant policy, devices in the tailnet can start using the peer relay for client-to-client connections when direct connections aren't possible. When a device can't connect directly to another device, it first checks for available peer relays in the tailnet. If no peer relays are available, the device falls back to using DERP servers.

\n

Avoid using overly permissive targets for the src field of the grant policy (such as *). For example, using * would make all devices in the tailnet attempt to use the peer relay devices in the dst, potentially leading to unintended traffic routing and high latency. Instead, specify precise device tags, hostnames, or IP sets to limit which devices can use the peer relay.

\n

As a rule of thumb, the src devices in the grant policy should typically be devices in a stable physical location behind a strict NAT or firewall that prevents direct connections. This typically includes devices in corporate networks or cloud environments. It usually does not include mobile devices or laptops that frequently change locations and network conditions.

\n

Step 3: Observe peer relay traffic

\n

Generate traffic to test the peer relay configuration. Then, use the tailscale status command to monitor the device's status and verify that it is functioning as a peer relay. When a tailnet device uses a peer relay, the connection type of that device changes to peer-relay.

\n

Run the tailscale status command and filter the output for peer-relay entries:

\n
tailscale status | grep peer-relay\n
\n

When a device is using a peer relay, it returns the device's connection type as peer-relay (instead of direct or relay). For example:

\n
<tailscale-ip-address> <hostname> <user> <os> active; peer-relay <ip-address>:<udp-port>:vni:<vni-id>, tx <bytes-sent> rx <bytes-received>\n
\n

You can also use the tailscale ping command to test connectivity between devices and observe whether the connection uses a peer relay.

\n

Disable Peer Relay

\n

To disable peer relay for a device use the tailscale set command with the --relay-server-port flag set to an empty string:

\n
tailscale set --relay-server-port=\"\"\n
\n

Examples

\n

Example scenarios in which you would use Tailscale Peer Relays include:

\n
    \n
  • Accessing devices in a specific geographic region using peer relays located in that region to reduce latency.
    • \n
  • Using peer relays to connect to devices behind strict NATs or firewalls where direct connections are not possible.
    • \n
  • Setting up dedicated peer relay devices to handle high-throughput traffic for specific applications or services.
    • \n
\n

The following peer relay policy examples illustrate what the grant policy looks like in different scenarios.

\n

Use tagged peer relay devices

\n

The following example lets all devices with the tag tag:us-east-vpc use peer relay devices tagged with tag:us-east-relays as underlay network relays when communicating with other devices on the tailnet. That means that other devices in the tailnet can use a device tagged with tag:us-east-relays as an underlay network relay when communicating with devices tagged with tag:us-east-vpc.

\n
{\r\n  \"grants\": [\\\r\n    {\\\r\n      \"src\": [\"tag:us-east-vpc\"], // Devices behind a restrictive NAT that need to be accessed through the peer relay\\\r\n      \"dst\": [\"tag:us-east-relays\"], // The devices functioning as peer relays for the src devices\\\r\n      \"app\": {\\\r\n        \"tailscale.com/cap/relay\": []\\\r\n      }\\\r\n    }\\\r\n  ]\r\n}\n
\n

For this to work, you must also configure the peer relay devices using the tailscale set command and create a grant access control policy that permits overlay network access to devices with the tag:us-east-vpc tag.

\n

For example, this grant policy lets all members of the tailnet access devices with the tag:us-east-vpc tag on TCP ports 80 and 443.

\n
{\r\n  \"grants\": [\\\r\n    {\\\r\n      \"src\": [\"autogroup:member\"],\\\r\n      \"dst\": [\"tag:us-east-vpc\"],\\\r\n      \"ip\": [\"tcp:80\",\"tcp:443\"]\\\r\n    }\\\r\n  ]\r\n}\n
\n

Use self as peer relay

\n

It's possible for devices to use themselves as a peer relay. The following example lets the device with the hostname us-west-1 use itself as a peer relay. You might use this configuration in a scenario where you need to block all incoming ports to a device except for the UDP port used for peer relay traffic.

\n
{\r\n  \"grants\": [\\\r\n    {\\\r\n      \"src\": [\"us-west-1\"],\\\r\n      \"dst\": [\"us-west-1\"],\\\r\n      \"app\": {\\\r\n        \"tailscale.com/cap/relay\": []\\\r\n      }\\\r\n    }\\\r\n  ]\r\n}\n
\n

For this to work, you must also configure the device as a peer relay using the tailscale set with the UDP port for peer relay traffic.

\n

Security and access control

\n

Peer relays can only relay traffic for devices in the same tailnet. The grant rule that assigns the tailscale.com/cap/relay capability acts as the access control mechanism — a device without that grant can't allocate relay bindings on the peer relay. You don't need a separate network grant to the peer relay device itself.

\n

The UDP port you configure for peer relay traffic must be open and accessible from other devices in the tailnet. For example, if you configure a peer relay to use UDP port 40000, ensure that any firewalls or network security settings allow incoming traffic on that port.

\n

Static endpoints

\n

You can use the --relay-server-static-endpoints flag with the tailscale set command to specify one or more additional static endpoints for the peer relay to advertise to other tailnet devices. Doing so is useful in network environments where users use port forwarding or users use load balancers like AWS Network Load Balancer ( NLB). In these scenarios, the peer relay might not automatically discover all possible endpoints because it can't send outbound endpoint discovery packets over all possible paths.

\n

It accepts a comma-separated list of ip:port pairs (or an empty string to not advertise any static endpoints). Each ip:port pair corresponds to an additional endpoint that the peer relay advertises to other tailnet devices.

\n
tailscale set --relay-server-port=<port> --relay-server-static-endpoints=\"<ip-address-1>:<port>,<ip-address-2>:<port>\"\n
\n

For example, to configure the peer relay to advertise two additional static endpoints ([2001:db8::1]:40000 and 192.0.2.2:40000), you would run the following command:

\n
tailscale set --relay-server-port=40000 --relay-server-static-endpoints=\"[2001:db8::1]:40000,192.0.2.2:40000\"\n
\n

\"Project

\n

Ask AI

\n

reCAPTCHA

\n

Recaptcha requires verification.

\n

protected by reCAPTCHA

\n"}