Why Plex Calls Tailscale Streams Remote and How to Mark Them Local

When you connect to a Plex server from another device over Tailscale, Plex may label the stream “remote” even if you own both devices and the connection stays encrypted. Plex classifies connections using network addresses. By default, it treats the server’s own local network, or subnet, as local. Tailscale gives its devices virtual IP addresses outside that subnet, so Plex may not recognize a Tailscale connection as local.

Add the relevant Tailscale address or address range to the server’s LAN Networks setting to change Plex’s classification. That setting requires Plex Pass, and it does not guarantee that every Plex app will apply local playback rules or find the server. A subnet router offers another option, with extra network setup.

Why Plex sees a Tailscale address as remote

Plex’s LAN Networks setting identifies the IP addresses the server should treat as local. By default, Plex uses the subnet where the server sits. Plex also identifies VPNs and advanced network configurations as reasons a connection might be treated as remote. The classification can affect local and remote bandwidth settings and other playback behavior; it does not say where the user is physically located. See Plex’s network settings for the default behavior and LAN Networks options.

Tailscale assigns each device a virtual IP address in 100.64.0.0/10, a range reserved for Carrier-Grade NAT (CGNAT). A Tailscale device uses a separate address from the one it would use on the home Wi-Fi or wired network. If Plex receives the connection from the Tailscale address, it may not match the server’s automatically recognized home subnet. Tailscale documents the reserved address range.

That classification does not tell you whether the connection travels over the public internet. Tailscale connections can be direct or relayed, and Tailscale says both use end-to-end WireGuard encryption. Plex can therefore call a stream remote while Tailscale still encrypts the connection between devices. See Tailscale’s explanation of connection types.

Add Tailscale addresses to Plex’s local networks

If the Plex server administrator’s account has an active Plex Pass, add the Tailscale addresses to LAN Networks:

1. In Plex Web App, open Settings, select the Plex server, and choose Network.
2. Select Show Advanced and find LAN Networks.
3. Enter 100.64.0.0/10 to include the full Tailscale IPv4 range. Keep any networks already in the field, separating entries with commas. Do not add spaces or tabs.
4. Save the setting and test playback from a device connected to Tailscale.

Plex documents LAN Networks as accepting individual IP addresses or ranges, and says the setting requires an active Plex Pass for the server administrator’s account. The /10 range covers Tailscale’s full CGNAT address block, not just your devices. If you want a narrower entry, add the individual Tailscale IP addresses for the devices that need access instead.

Treat the setting as a way to expand Plex’s local-network classification, not as a guaranteed fix for every remote-playback rule. Plex’s remote playback requirements describe remote video playback in affected apps in terms of whether the app connects to the server on the same local subnet. Plex’s documentation does not guarantee that adding a Tailscale range will make every app treat every stream as local for playback eligibility.

Route Tailscale traffic through the home LAN

A Tailscale subnet router gives remote Tailscale devices a route to devices on your home LAN. Instead of connecting to Plex through its Tailscale IP, a client reaches the server through the home network. Tailscale’s subnet router documentation explains how to advertise and enable a subnet route.

Tailscale applies source NAT (SNAT) by default for subnet-router traffic. SNAT changes the source address that the destination sees, so Plex sees the router’s home-network address rather than the remote client’s original Tailscale address. That can make Plex classify the connection as local. The trade-off is that Plex loses the original client address in the connection details. Disabling SNAT requires additional routing so replies can reach the remote client; it is not a simple Plex setting.

Check discovery and playback separately

Plex’s local-versus-remote classification and a client’s ability to find the server are separate issues. Plex’s Network settings include Custom server access URLs, which Plex identifies as useful when using a VPN to connect back home. If a client cannot find the server, check that it has a usable Tailscale address or route; changing LAN Networks alone does not fix every discovery problem.

Also distinguish a connection label from playback results. Plex’s bandwidth settings separate local and remote limits, while remote-playback eligibility depends on the applicable Plex app and account conditions. A stream labeled remote does not necessarily mean Plex will throttle or block it in every setup.

Do not change Plex’s List of IP addresses and networks that are allowed without authentication to solve a local-versus-remote classification issue. That setting controls authentication, not LAN classification, and Plex warns that unauthenticated access has security consequences. The two settings serve different purposes, as Plex explains in its guidance on local network authentication.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com