Use an Android Phone as a Cellular Exit Node: Step by Step

Two devices, two cities, one requirement: the laptop's web requests should leave through the phone's mobile connection. Most people start by installing a VPN app on the phone, which does the opposite job, because that app makes the phone a client of somebody else's gateway. The working shape is a tunnel from the laptop to the phone, with the phone forwarding onward to the internet. Tailscale supports this on Android as an exit node, and the steps are short once you know which switch belongs to which side.

Name the role before you install anything

A hotspot is proximity. The laptop joins the phone's Wi-Fi or USB tether and the phone carries its traffic, which is exactly the behaviour you want but only while the two devices are next to each other. A VPN client on the phone is the reverse role: the phone sends its own traffic to a remote gateway, and a laptop in another city gains nothing from it.

A remote cellular exit is the third shape. The laptop joins a private network, the phone is on the same private network and is approved to forward internet traffic, and the laptop selects the phone as its exit. Nothing about the arrangement requires the two devices to be near each other, and nothing about it is automatic: a phone that has merely joined the network forwards nothing.

Before you touch the phone

You need an account that administers the private network, because approving an exit node is an administrative action rather than a device setting. You need the laptop's client installed and signed into the same network, and you need the phone charging for anything beyond a short test.

Decide in advance whether the phone's Wi-Fi should stay on, because that choice decides which uplink you are actually testing. If the network uses access rules, add the permission that lets users reach the internet through an exit node before you debug the phone. A phone that is correctly configured and an account that is not allowed to use it produce the same symptom on the laptop, which is a refusal with no useful explanation.

Enable the role on the phone, then approve it

Install the client on the phone, sign in, and open the exit-node setting in the app. Turn on the option that lets this device act as an exit node. The exact wording moves between app versions, but the intent does not: the phone offers itself, it does not select an exit for itself.

Then open the admin console, find the phone in the machine list, and approve the exit-node route. Approval is separate from the app switch on purpose, so that a device cannot quietly become an internet gateway for the whole network.

If your network requires device approval as well, approve the device first; an unapproved machine cannot serve as an exit whatever the app says. Finally, on the laptop, open the client menu, choose the exit node, and select the phone by name. The laptop's default route now points at the tunnel. Confirm the selection stuck: some clients show the exit node in the menu but keep using the local connection until the tunnel re-establishes, and a quick reconnect is faster than diagnosing a stale state.

Check the uplink before you measure anything

On the phone, turn Wi-Fi off if the point of the exercise is the mobile connection, and confirm that mobile data actually works by loading a page in the phone's browser first. If the phone is on Wi-Fi, your exit is that Wi-Fi network, which is a fine arrangement but not the one the ticket describes.

Compare egress addresses from both ends. Open an address-echo page on the phone, then run curl -s https://ifconfig.me on the laptop. Matching addresses mean the laptop left through the phone's connection; a carrier that shares addresses between subscribers can make two unrelated connections look identical, so treat a match as consistent rather than conclusive.

Budget for two legs, not one. The first leg is laptop to phone, over whatever path the tunnel takes; the second is phone to destination, over the mobile radio. A fast download on the phone says nothing about the first leg, and a congested uplink shows up as slow requests in both directions.

Know the limits before you depend on it

Tailscale's exit-node documentation notes that Android exit nodes forward in userspace, which is slower than a kernel path and is not intended to replace a router. It also recommends external power for long sessions. On a phone that is charging, warm, and forwarding traffic, Android's battery management still deserves attention: aggressive power saving can suspend the app, and the tunnel then looks like an intermittent network fault.

The subscription matters as much as the hardware. Tethering and hotspot clauses, fair-use thresholds, and carrier-grade address sharing all apply to traffic that leaves through the phone, and none of them are visible from the laptop. A plan that allows unlimited phone browsing may still meter forwarded traffic. For a permanent installation, a small router with a cellular modem and a supported gateway role gives a cleaner boundary: the subscription, the tunnel, the forwarding policy, and the power supply become one service you can monitor, instead of a phone on a shelf that must stay awake. Use the phone as the exit when the requirement is a limited remote-access or location test, and plan the router when the requirement is availability.