Tailscale Exit Node on a VPS: Ubuntu 24.04 Setup, Cost and Teardown

To run a Tailscale exit node on a VPS, install Tailscale on an Ubuntu 24.04 server, turn on IP forwarding, run sudo tailscale up --advertise-exit-node, approve the node under Edit route settings in the Tailscale admin console, and select it as the exit node on your phone or laptop. Websites then see the server’s IP address, and the café or hotel Wi-Fi sees only encrypted traffic.

Compared with a hand-built WireGuard server, Tailscale needs no open inbound port, creates and exchanges the keys for you, and falls back to relays over HTTPS when a network blocks UDP. This guide follows Tailscale’s official documentation as checked in October 2026 and adds the checks most guides skip: firewall rules, direct versus relayed connections, IPv6 and DNS. It prices a 7-day trip on a Quartz Q1 billed by the hour, $1.68 for all 168 hours, and ends with a clean teardown.

Key takeaways

• A Tailscale exit node on an Ubuntu 24.04 VPS takes five steps: deploy and secure the server, install Tailscale, enable forwarding in /etc/sysctl.d/99-tailscale.conf, run sudo tailscale up --advertise-exit-node, and approve Use as exit node in the admin console.
• Unlike a self-hosted WireGuard server, the node needs no open inbound port and no hand-written NAT rules; allowing UDP 41641 only helps devices connect directly instead of through DERP relays.
• On networks that block UDP, Tailscale still connects through DERP relays over HTTPS port 443, more slowly; tailscale ping shows whether a connection is direct or relayed.
• Clients send their DNS lookups to the exit node by default and cannot reach their local network until you enable the Allow LAN access option.
• For a trip, rent the server by the day on hourly billing, never more than the plan's monthly price in a billing period; afterwards switch every device to None, run sudo tailscale logout, remove the machine from the tailnet and delete the server, because a stopped server is still billed.

What is a Tailscale exit node?

By default, Tailscale only carries traffic between your own devices, which together form a private network Tailscale calls a tailnet. Your web browsing still leaves through whatever network you are on. An exit node changes that: one device offers the default routes 0.0.0.0/0 and ::/0, and every device that selects it sends all of its internet traffic there first, as it would with a classic VPN. Tailscale’s exit node documentation names untrusted coffee-shop Wi-Fi and reaching home-country services from abroad as typical reasons.

The encryption covers the stretch between your device and the server. From the server onward, your traffic leaves as ordinary internet traffic: the data center’s network carries it, and websites see the server’s IP address. HTTPS still protects the content, as it does at home.

Nothing switches on by accident. Tailscale requires three separate opt-ins: the device advertises itself as an exit node, an Owner, Admin or Network admin allows it in the admin console, and each client selects it. Exit nodes are available on every Tailscale plan, including the free Personal plan, which Tailscale’s pricing page offers for up to 6 users and non-commercial use as of October 2026. A team on a work trip needs a paid plan.

Where should the exit node run?

Any Linux, macOS, Windows, Android, iOS or tvOS device can act as an exit node, but the docs list different caveats for each:

Exit node on	How it routes	Stays available	IP address websites see	Better fit when
A Linux VPS	Kernel routing, Tailscale’s default Linux implementation	Around the clock, in a data center	The server’s data-center IP address, in its city	You travel, want to choose the city, and want nothing at home left running
A Linux box at home, such as a Raspberry Pi	Kernel routing	While your home power and internet stay up	Your home IP address	You mainly need services that expect your home connection, such as your bank
A macOS or Windows computer	Userspace; Tailscale calls it new and still being optimized	Only while the computer does not sleep	Your home or office IP address	You already leave that computer on
An Android phone	Userspace; the docs warn it “may be too slow for most cases”	Only while plugged in and online	The phone’s current network	A short test, not daily use

A VPS suits a trip: it never sleeps, it has a public IP address, which Tailscale’s performance guide lists as a way to make direct connections more likely, and you can delete it when you are home. A home exit node suits you better when sites must see your home IP address. Some banks and streaming services treat data-center IP addresses with extra caution, so a bank may ask you to confirm a login that comes from a VPS.

Tailscale exit node or your own WireGuard server?

Tailscale builds its tunnels with WireGuard, so the encryption is the same either way. The difference is who handles keys, ports and discovery. Our WireGuard VPN on a VPS guide builds the do-it-yourself version; this table compares the two for one traveler’s phone and laptop.

	Tailscale exit node on a VPS	Self-hosted WireGuard on a VPS
Inbound port on the server	None required; NAT traversal finds a path. Allowing UDP 41641 helps direct connections	A UDP port (51820 by convention) must be open
Networks that block UDP	Still connects through Tailscale’s DERP relays over HTTPS port 443, more slowly	Cannot connect; WireGuard runs over UDP only
Adding a device	Install the app and sign in; the app creates and exchanges keys	Generate a key pair, add a peer to the server config, move a file or QR code
Firewall and NAT on the server	Turn on IP forwarding; tailscaled adds its own forwarding and NAT rules	IP forwarding plus NAT and forward rules you write in UFW
Third parties	A Tailscale account. Its servers coordinate keys and, by default, collect each device’s connectivity logs (a device can opt out, at the cost of support); exit node destinations are not logged by default, and private keys never leave your devices	None beyond your host
Who can use it	Tailnet members your access policy allows	Anyone holding a peer’s private key
Better fit when	You have several devices or people, unpredictable networks, and no wish to manage keys	You want no third-party account and the fewest moving parts

Three other options are worth knowing:

• Your own control server. If you like Tailscale’s apps but not its hosted coordination server, the client can sign in to a self-hosted one such as Headscale with --login-server. That is a larger project than this guide; our WireGuard vs OpenVPN comparison explains when an overlay such as Tailscale, Headscale or NetBird beats both protocols run by hand.
• Exit nodes you do not run. Tailscale sells a Mullvad VPN add-on, still labeled beta in its docs, whose servers appear as extra exit nodes in many countries. Tailscale’s pricing page listed it at $5 a month for every 5 devices in October 2026.
• One browser, one hour. If only a laptop browser needs the server’s IP address, an SSH dynamic tunnel turns any server you can SSH into a SOCKS proxy, with no extra software.

What does a VPS exit node cost for a trip?

An exit node for one person is a light job: tailscaled encrypts and forwards packets, and nothing else runs. Tailscale’s performance guide adds that, in general, higher CPU clock speed matters more than more cores. The table below is sizing reasoning from the docs, not a benchmark.

Who uses the node	Plan	Per day (24 h)	Reasoning
You: one phone and one laptop	Quartz Q1 (1 shared vCPU, 1 GB RAM)	$0.24/day	Meets Ubuntu’s 1 GB minimum for 24.04 cloud images; Tailscale adds one daemon
A family or small team on one trip	Quartz Q2 (1 vCPU, 2 GB RAM)	$0.48/day	Memory headroom for updates and more simultaneous connections
Many people streaming or downloading at once	Chrono C8 (2 dedicated vCPU, 8 GB RAM)	$1.68/day	Dedicated cores are not shared with other servers, and Tailscale’s guide favors CPU clock speed over core count

Renting a VPS by the day is hourly billing counted in days, with no daily cycle to prepay. Quartz Q1 costs $0.01/hour, so a 24-hour day comes to $0.24, a one-week trip of 168 hours to $1.68 and two weeks to $3.36. However long the trip, the server never costs more than the plan’s monthly price, $5.00, in a billing period. Tailscale adds no charge for the exit node itself.

Quartz Q1 as a Tailscale exit node for a day out, one day, a long weekend, one week, two weeks and a month, billed by the hour and capped at the monthly price

Duration	Hours on the meter	Cost $0.01/hour · cap $5.00/month	Note
10 hours	10	$0.10
1 day	24	$0.24
3 days	72	$0.72
7 days	168	$1.68
14 days	336	$3.36
30 days	720	$5.00	Capped at the monthly price

The same hourly billing covers a single day out, such as a conference: ten hours on Quartz Q1 cost $0.10, deducted from the server’s balance hour by hour. A permanent exit node, such as a fixed home-country address all year, needs no other plan. Left running, the server is billed by the hour until its charges reach the plan’s monthly price, then nothing more for the rest of that billing period (one month from your order date), which makes it a monthly VPS with no contract and no prepayment. The VPS cost calculator prices any other length, and the hourly billing guide explains the cap and the initial credit.

Which location should the exit node use?

Websites see the server’s city, and every request detours through it. So choose by what you need: close to where you will be, for the least delay, or in the country whose services you want to reach. HourlyVPS servers deploy in Istanbul, Türkiye, today; New York is coming soon, and the locations page shows what you can order. Our guide to choosing a VPS location has the latency math.

Tailscale’s relays matter too, but only when a direct connection fails. Its DERP server list and the live DERP map that clients download held 28 regions on October 3, 2026, none of them in Türkiye. The closest to Istanbul in straight-line distance are Warsaw (about 1,390 km), Nuremberg (about 1,680 km) and Frankfurt (about 1,870 km), though each device picks its home relay by measured latency. So an Istanbul exit node uses a relay in another country whenever its traffic is relayed. Tailscale says that “in most environments” it establishes direct connections, and a server with a public IP address helps; the relay section shows how to check.

Traffic adds up faster on an exit node than on most servers. Each byte you download crosses the server’s network port twice: in from the website, then out to you, encrypted. Istanbul plans include the monthly traffic allowance listed for each plan, prorated for a server that exists for part of a billing period. If you plan long video calls, compare the allowance on the plan card below with the location details.

How to set up a Tailscale exit node on a VPS (Ubuntu 24.04)

You need a Tailscale account, Tailscale 1.20 or later on the server and on every client, and an Ubuntu 24.04 server you can reach over SSH as a sudo user. Run the commands in one SSH session, in order. The examples name the node exit-ist; use any name you like.

Step 1: Deploy Ubuntu 24.04 and harden it

Deploy Ubuntu 24.04 in the city you chose. Connect with an SSH key as our SSH connection guide shows, then work through the VPS security checklist: a sudo user, key-only SSH, updates, and UFW with SSH allowed. Keep the VNC console in the portal in mind as your way back in if a firewall change goes wrong.

Step 2: Install Tailscale

Tailscale’s Linux install guide uses one script, which detects your distribution and installs Tailscale from Tailscale’s own package repository:

curl -fsSL https://tailscale.com/install.sh | sh

If you would rather not pipe a script into a shell, the stable package page lists the same repository steps for Ubuntu 24.04 (Noble Numbat); its stable track was at version 1.102.4 on October 3, 2026:

sudo mkdir -p --mode=0755 /usr/share/keyrings
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt-get update && sudo apt-get install tailscale

Either way, hold off on tailscale up until forwarding is on in step 3. A node you keep beyond one trip updates with the rest of the system through sudo apt upgrade, or you can let Tailscale update itself with sudo tailscale set --auto-update.

Step 3: Turn on IP forwarding

An exit node passes packets from one network interface to another, which Linux does only with IP forwarding on. These are the lines from Tailscale’s subnet router documentation for systems with an /etc/sysctl.d directory, as Ubuntu 24.04 has. They enable IPv4 and IPv6 forwarding and survive a reboot:

echo 'net.ipv4.ip_forward = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
echo 'net.ipv6.conf.all.forwarding = 1' | sudo tee -a /etc/sysctl.d/99-tailscale.conf
sudo sysctl -p /etc/sysctl.d/99-tailscale.conf

Both values should now read 1:

sysctl net.ipv4.ip_forward net.ipv6.conf.all.forwarding

Leave UFW’s forward policy as Ubuntu ships it, DEFAULT_FORWARD_POLICY="DROP" in /etc/default/ufw (the upstream default). The exit node docs ask for exactly that: a firewall that denies forwarding by default, so that only the rules Tailscale adds let traffic through.

Step 4: Start Tailscale and advertise the exit node

Now connect the server to your tailnet and offer it as an exit node in one command. --hostname is optional and sets the name you will pick on your phone:

sudo tailscale up --advertise-exit-node --hostname=exit-ist

The command prints a login URL. Open it in a browser on your laptop and sign in to your Tailscale account; the server then joins the tailnet. If Tailscale is already running on the server, add the flag with tailscale set instead. The exit node docs say to run tailscale up after it:

sudo tailscale set --advertise-exit-node
sudo tailscale up

If forwarding is still off, the command warns IP forwarding is disabled, subnet routing/exit nodes will not work and adds a help link; the text comes from Tailscale’s source code. Go back to step 3. On Linux it can also warn that UDP GRO forwarding is suboptimally configured on the server’s network interface; the optional tweak below covers that.

Step 5: Approve the exit node in the admin console

1. Open the Machines page of the Tailscale admin console.
2. Find the server. It shows an Exit Node badge, and the filter property:exit-node lists every device that advertises one.
3. Open the server’s menu (…) and select Edit route settings.
4. Check Use as exit node and select Save.

This needs the Owner, Admin or Network admin role. If your tailnet policy has autoApprovers that cover the user who signed the server in, Tailscale approves the exit node automatically.

Tailscale’s default access policy lets every member use an approved exit node. If you replaced it with your own grants, exit node use needs a grant whose destination is autogroup:internet; a grant to the exit node’s own address only allows connections to the server itself, such as SSH. This one, from Tailscale’s grant examples, lets every member use exit nodes. Add it beside your existing grants, because a policy that holds only this grant blocks other tailnet traffic, SSH to the server included:

{
  "grants": [
    {
      "src": ["autogroup:member"],
      "dst": ["autogroup:internet"],
      "ip": ["*"]
    }
  ]
}

One more setting matters if you keep the node longer than a trip. Device keys expire after 180 days by default, and an exit node whose key has expired fails closed: clients keep its routes and lose internet rather than leak traffic around it. For a long-lived node, select Disable Key Expiry in the same menu, after reading the trade-off on Tailscale’s key expiry page; a device you tag starts with key expiry disabled. For a one-week trip, leave expiry on.

How do you use the exit node from your phone and laptop?

Each device opts in separately. Install the Tailscale app on it, sign in to the same tailnet, then switch the exit node on:

Device	Turn the exit node on	Keep reaching your local network (printer, NAS)
iPhone and iPad	Exit Node at the top of the app, then the server’s name	Not named in the iOS steps; Tailscale’s general instructions place Allow Local Network Access in each client’s exit node section
Android	Exit Node section, then the server’s name; the section turns blue while active	Allow LAN access toggle
macOS	Tailscale menu bar icon > Exit Nodes > the server’s name	Allow Local Network Access
Windows	Tailscale tray icon > Use exit node > the server’s name	Allow local network access
Linux	sudo tailscale set --exit-node=exit-ist	Add --exit-node-allow-lan-access=true

The Linux client accepts the exit node’s machine name or its Tailscale 100.x.y.z address, and tailscale exit-node list shows the exit nodes in your tailnet. To stop using it, pass an empty value:

sudo tailscale set --exit-node=

Then confirm it works. Open any what-is-my-IP site on the device: it should show your server’s public IP address, not the network you are on, and on a network with IPv6 the server’s IPv6 address too, because the exit node carries both default routes. On the server, tailscale status lists the devices in your tailnet, and direct or relay in the last column tells you how each active one connects.

Where do DNS lookups go?

A device using an exit node also sends its DNS lookups to the exit node by default, whatever global or split DNS nameservers your tailnet has, according to DNS in Tailscale. The exit node runs a small DNS server for its clients for this purpose, so the hotel network does not see your lookups either. To keep a particular nameserver in use while an exit node is on, enable Use with exit node for it on the DNS page of the admin console.

Which firewall ports does a Tailscale exit node need?

Strictly, no inbound ones. Tailscale’s firewall ports FAQ says most setups need no open ports, because NAT traversal finds a path and relays carry the rest. What the server does need is outbound access, which UFW’s default allow-outgoing policy already gives:

Traffic	Port	What it is for	On a VPS with UFW
Outbound TCP	443	Coordination server and DERP relays, over HTTPS	Allowed by the default outgoing policy
Outbound TCP	80	Coordination server (preferred) and captive portal checks	Allowed by default
Outbound UDP	3478	STUN, so the node learns its public address and port	Allowed by default
UDP from the node’s port	41641 (default)	Direct WireGuard tunnels between devices	Allow it inbound to help direct connections

The FAQ gives the UFW command for the default port. Run it, then list the rules:

sudo ufw allow 41641/udp
sudo ufw status verbose

You do not write forwarding or NAT rules by hand, as the WireGuard guide does. In its default netfilter mode, tailscaled inserts its own ts-input and ts-forward chains into the kernel’s INPUT and FORWARD chains and masquerades traffic that arrives from the tailnet, as its firewall code shows. To see them:

sudo iptables -S FORWARD

In tailscaled’s default iptables mode, the output includes -A FORWARD -j ts-forward. If it does not, sudo journalctl -u tailscaled shows which firewall mode the daemon chose at startup.

Optional: once the tailnet works, you can close public SSH and log in over Tailscale only. Tailscale’s UFW lockdown guide allows everything on tailscale0 and deletes the public port 22 rule. Do this only with the VNC console at hand, because a logged-out or expired node would then lock you out of SSH.

Direct or relayed: why is my exit node slow?

Tailscale connects two devices in one of three ways, all encrypted end to end with WireGuard: directly over UDP, through a peer relay (another device in your tailnet), or through Tailscale’s DERP relay servers. Every connection starts relayed through DERP and upgrades to direct when NAT traversal succeeds. The connection types guide calls a relayed connection where a direct one would be possible “one of the most common causes of performance issues”.

Check from a laptop with the Tailscale CLI:

tailscale ping exit-ist

The first replies often arrive through a relay, shown as via DERP(fra) or another city code. Once a reply shows via followed by an IP address and port, the connection is direct. tailscale status reports the same as direct or relay. If it stays relayed:

• Allow UDP 41641 on the server, as in the firewall section above.
• Try another network. Some hotel and office networks block UDP entirely. The exit node then keeps working through DERP over port 443, only more slowly; that fallback is why Tailscale connects where a plain WireGuard server cannot.
• Run tailscale netcheck on the device. UDP: false means the network blocks UDP, and the DERP latency list shows which relay regions the device reaches and how far away they are.

Optional: faster forwarding on Linux 6.2 and later

Tailscale 1.54 and later can use UDP offloads on Linux 6.2 or later. Ubuntu 24.04 LTS shipped with Linux 6.8, per its release notes, and uname -r prints the kernel your server runs. Tailscale’s performance guide recommends this network device setting on exit nodes and subnet routers. Install ethtool with sudo apt install ethtool if it is missing, then run:

NETDEV=$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")
sudo ethtool -K $NETDEV rx-udp-gro-forwarding on rx-gro-list off

The setting does not survive a reboot. On systems that use networkd-dispatcher (check with systemctl is-enabled networkd-dispatcher), the guide’s script reapplies it at every boot:

printf '#!/bin/sh\n\nethtool -K %s rx-udp-gro-forwarding on rx-gro-list off \n' "$(ip -o route get 8.8.8.8 | cut -f 5 -d " ")" | sudo tee /etc/networkd-dispatcher/routable.d/50-tailscale
sudo chmod 755 /etc/networkd-dispatcher/routable.d/50-tailscale

The guide then runs the script once by hand, sudo /etc/networkd-dispatcher/routable.d/50-tailscale, to check that it exits without an error. For a one-week node used by one person this is optional; for a node several people share, it is worth two minutes.

Tailscale exit node not working? Troubleshooting matrix

Symptom	Likely cause	Check	Fix
The exit node does not show up in the phone’s list	Not advertised, or not approved	Machines page: Exit Node badge, and Use as exit node checked under Edit route settings	Repeat step 4, then approve it in step 5
Selected, but no website loads	IP forwarding is off	sysctl net.ipv4.ip_forward prints 0, and tailscale up warned about forwarding	Repeat step 3
Works for you, not for another user	A custom access policy without autogroup:internet	Access controls page of the admin console	Add a grant like the one in step 5
IP addresses work, names do not resolve	DNS fails on the exit node’s side	On the server: resolvectl query example.com	Fix the server’s resolver, or enable Use with exit node for a nameserver
Slow, and tailscale status says relay	No direct path: UDP blocked on the server or on your network	tailscale ping exit-ist stays via DERP	Allow UDP 41641 on the server; on a strict network it stays relayed but works
Exit traffic stopped after a firewall reset	Tailscale’s chains were flushed	sudo iptables -S FORWARD has no ts-forward	sudo systemctl restart tailscaled sets its rules up again
tailscale up complains about missing flags	tailscale up expects every non-default flag each time	The message includes a copyable command with all current flags	Use tailscale set, which changes only the flags you pass
Home printer or NAS unreachable while connected	Local network access is off by default	The client’s exit node menu	Turn on Allow LAN access or Allow local network access
Hotel Wi-Fi sign-in page never appears	A captive portal holds all traffic until you sign in	Tailscale shows a captive portal alert, or http://neverssl.com opens the sign-in page	On a network you trust: disconnect Tailscale, sign in to the Wi-Fi, then reconnect
No internet at all after the trip	The device still has the deleted server selected as its exit node	The app shows an exit node in use	Select None
Node offline after months	The device key expired (180-day default)	Machines page marks the key as expired	Over SSH or the VNC console, run sudo tailscale up --force-reauth --advertise-exit-node --hostname=exit-ist, then disable key expiry

For anything else, sudo journalctl -u tailscaled shows the daemon’s log, and Tailscale’s can’t connect to the internet checklist covers the client side.

After the trip: log out and delete the server

An exit node for a trip should end with the trip. Work through this list in order:

1. Switch every device to None. In each app, set the exit node to None (on Linux, sudo tailscale set --exit-node=). A device that still points at the server has no internet once the server is gone.
2. Log the server out of Tailscale. On the server, run sudo tailscale logout. According to the Tailscale CLI reference, it disconnects and expires the current login, so the machine cannot rejoin without signing in again.
3. Remove the machine from the tailnet. If it still appears on the Machines page, open its menu, select Remove and confirm with Remove machine, as Tailscale’s remove a device page describes. Revoke any auth key you created for it on the Keys page of the admin console settings.
4. Delete snapshots, then the server. A snapshot is a copy of the disk, including Tailscale’s state files. Deleting the server in the portal is immediate, deletes the virtual disk as our security page explains, and ends billing; a last partial hour is rounded to the nearest cent.
5. Check the portal shows no active service for that server.

For the next trip, deploy a fresh server and repeat the five steps. If you set up nodes often, an ephemeral auth key (sudo tailscale up --auth-key=<key> --advertise-exit-node) makes the node leave the tailnet on its own soon after it goes offline; Tailscale’s ephemeral nodes page lists the limits. Our checklist before you delete a VPS covers revoking keys and VPN peers, backups and billing checks in more detail.

Is it legal to route your traffic through your own exit node?

Encrypting your own traffic is legal in many countries, but some restrict or regulate VPNs, and the rules change. Check the law of each country on your route, and the terms of the networks you join, such as a hotel’s or an employer’s. An exit node does not change what is legal where you are, and it is not a way around a country’s rules or a streaming service’s terms.

Our acceptable use policy applies to everything that leaves the server, including traffic from your tailnet:

• Your tailnet, your responsibility. The policy allows authenticated VPN use for your own users, as long as they follow rules at least as strict as the policy. Everyone you invite into the tailnet counts.
• No open proxy. Only devices signed in to your tailnet and allowed by its access policy can use the node, so this setup is not an open proxy. Do not run a public SOCKS or HTTP proxy beside it.
• The server’s country counts. The policy bans anything illegal under US law, Wyoming law or the law of the country where your server is located, whichever route the traffic takes.

When you are ready, a VPS rented by the day is all this setup needs: deploy it before you leave and delete it when you land.