Apple TV VPN: Per-App Selection vs a Router Device Rule

Both requests open with the same sentence: put the Apple TV behind the VPN. One person means the whole box, another means a single streaming app running on it. Those are different scopes, and on tvOS only one of them is usually available today. The distinction is not about the protocol or the provider, it is about who can see which application created a connection. A router sees packets and addresses, while an app on the TV sees process identity only when its own client implements that selection.

The difference is who can see the app identity

A router forwards by source address, destination address and port. It never receives the name of the tvOS process that opened a socket, so it has no way to express "this app and nothing else".

A VPN app running on the TV sits inside the process boundary and can, in principle, apply per-app rules. Whether the shipped client exposes that is a product question rather than a protocol one.

What a tvOS VPN app can and cannot select

Apple added third-party VPN app support in tvOS 17, as its platform announcement records. That corrected the older assumption that a router must be the endpoint. It did not promise that every client offers an include or exclude list, and that gap is where most of these comparisons go wrong. Read the provider's tvOS page, not its Windows or Android page.

Split tunnelling described for a desktop build is not evidence for the TV build. Providers ship different codebases per platform, and the TV client is often the smallest of them.

Apple's managed per-app VPN documentation describes a deployment model for supervised devices, not a consumer toggle. Check the supported platform list before importing instructions written for a managed iPhone or Mac.

What a router rule actually selects

With the router as endpoint, a device rule selects the Apple TV's address or segment. That is whole-device selection inside the policy's scope, and it does not become "one app only" because you tested with one app. If a second app on the same television uses the tunnel, the rule is working exactly as designed.

This is usually the right answer when the goal is "this television, all of it". It also survives app updates, new streaming services and profile changes, which is more than most per-app lists can say.

Domain and destination rules are not app identities

A destination rule selects addresses or maintained domain sets. One app contacts login, media, telemetry and advertising endpoints, and several apps can share the same delivery infrastructure. A domain rule can therefore miss part of the app you meant and capture traffic from one you did not.

DNS forwarding and independent resolvers complicate it further. If the TV resolves names through a different path than the rule assumes, the destination set is wrong even when the rule itself is written correctly.

A public address check run from your laptop tells you nothing about the television's path. Test from the TV, or from the app you actually care about.

Choosing between the two

Pick the router rule when the requirement is device-wide, when you control the network, and when you can accept that a failed tunnel affects everything on that television. Pick the tvOS app when the provider's own client documents per-app selection for tvOS and you can confirm it on the device. In between those two, the honest answer is that you have whole-device scope and should write that down before anyone relies on it.

Either way, keep the service's access rules intact. Routing capability does not expand an account's regional entitlement, and a scope decision does not change what the provider will serve you.

Two questions settle most of these tickets: who needs to be able to name the app, and what should happen when the tunnel drops? Answer both before you buy hardware or a subscription.