Adding a Stable Relay Node to Your Tailscale Network with a VPS

In some network environments, Tailscale direct connections are unstable, and the default official DERP servers add high latency. If you already have a public VPS in your tailnet, you can configure it as a Peer Relay node so other devices route through it — latency is far lower than DERP, and throughput is close to direct connections.

This article documents the actual setup process, including a few pitfalls we hit.

Background: Tailscale’s Two Relay Mechanisms

DERP (Designated Encrypted Relay for Packets) is Tailscale’s fallback relay. It runs over HTTPS/WebSocket and is globally distributed, but latency is constrained by geographic location and official server load.

Peer Relay is a new mechanism introduced in v1.86 that uses ordinary nodes inside the tailnet as relays over native WireGuard UDP, offering lower latency and higher throughput. The connection priority is:

In other words, once Peer Relay is configured, Tailscale will prefer it when a direct connection fails, instead of detouring through DERP.

Prerequisites

• The VPS has joined the tailnet (ran tailscale up)
• Tailscale version >= 1.86 (confirm with tailscale version)
• The cloud provider’s security group allows the UDP port

The VPS used in this article is on Alibaba Cloud, behind NAT (eth0 has an internal IP; the public IP is mapped through the security group).

Step 1: Allow the Current User to Run tailscale Without sudo

tailscale set requires root by default; configure passwordless sudo once:

All subsequent tailscale set commands then work without sudo.

Step 2: Enable Peer Relay and Advertise Static Endpoints

--relay-server-port specifies the UDP port to listen on, and --relay-server-static-endpoints tells other nodes where to reach this relay.

Pitfall: If you later run tailscale up (e.g., to apply tags), these two settings get reset and you’ll need to re-run the two commands above.

Verify the configuration took effect:

The output should include:

Verify that tailscaled is listening:

Step 3: Open the Security Group Port

In the cloud provider console, add an inbound rule to the VPS security group:

The VPS’s local firewall (iptables/ufw) usually needs no extra configuration — tailscaled handles it.

Verify port reachability from your local machine:

Step 4: Configure ACL Authorization

Peer Relay must be explicitly authorized in the tailnet’s access control policy. Go to Tailscale admin console → Access Controls and make two changes in the JSON editor:

1. Add tagOwners (uncomment and fill in):

2. Add a new entry under grants:

Save and it takes effect immediately.

Step 5: Tag the VPS

Pitfall: tailscale set has no --advertise-tags flag — you must use tailscale up:

After tagging, the node’s owner changes from your user account to the tag, and it shows up in tailscale status as <your-vps>.xxx.ts.net instead of user@. This is normal.

Note: tailscale up resets the relay configuration (see the pitfall in Step 2), so after tagging you need to re-run:

Verifying the Result

From another device, ping the VPS node:

Expected output:

You can see the connection path negotiation: the first hop goes through DERP, then switches to Peer Relay (latency drops from 1.89s to 269ms), and finally upgrades to a direct connection.

Summary

The whole configuration boils down to a few key points:

1. tailscale set --operator=$USER for passwordless sudo
2. Set the relay port and static endpoints
3. Allow the UDP port in the security group
4. Add tagOwners and relay grants to the ACL
5. Tag with tailscale up --advertise-tags=tag:relay-server
6. Re-apply the relay config after tagging (because tailscale up resets it)

Once configured, Tailscale will automatically use the Peer Relay when appropriate — no client-side changes needed.