VPN split tunneling: choose which traffic uses the VPN

What split tunneling changes

Split tunneling lets selected traffic use a different route from the rest. In one configuration, most traffic uses the VPN and chosen apps bypass it. In another, only selected traffic uses the VPN while everything else stays direct. Providers may call the second design reverse split tunneling or an inverse routing mode.

The rule’s scope matters. A complete desktop application, a website, an IP address and a local subnet are different things. A website exclusion does not establish full app exclusion, and a Linux subnet exception does not identify a particular program.

Direct traffic does not receive the VPN tunnel’s protection. That does not mean all direct traffic is unencrypted: HTTPS can still encrypt the browser’s connection to a website. Routing and application encryption are separate layers.

Useful reasons for an exception

An exception can help when an application or local resource does not work through the selected route, or when you want only a particular program inside the tunnel. For example, a local device on your own network may need a route that the current VPN settings interfere with.

Treat the exception as a limited configuration change rather than a universal fix for blocked sites. It changes exposure and may interact with DNS, kill-switch settings or organizational policy. If a service requires a particular account location or prohibits certain access, routing alone does not establish that the service will work or that its terms permit the use.

Documented platform differences

This table summarizes current provider documentation, not hands-on testing. Operating-system versions, app releases and network-extension requirements can change. Use the provider’s specific current instructions when setting up a rule.

NordVPN’s app rules and Linux Allowlist

NordVPN documents app exclusions on Windows and Android. Its Linux Allowlist instead exempts ports and subnets, with matching traffic bypassing both the VPN and kill switch. That is useful to understand before assuming a Linux exception has the same security behavior as a Windows app rule.

Its support also warns that excluded Windows apps may retain Nord DNS and that Internet Kill Switch can take priority over split-tunnel exclusions. A direct data route therefore does not guarantee a program sees the same DNS behavior or connectivity it had before the VPN was installed.

Surfshark Bypasser and reverse mode

Surfshark’s Bypasser lists app and site routing on Windows, Android and supported Macs. Current Mac guidance requires macOS 12 or later and approval of a system extension. The feature does not support Big Sur.

On iOS, exclusions apply to websites rather than full apps. Reverse Bypasser documentation distinguishes Android apps/websites from Windows apps. Linux is absent from the Bypasser platform list, so do not buy it expecting a documented Linux per-app workflow.

PIA desktop rules and documentation conflicts

PIA’s current desktop guide covers app rules on Windows, macOS and Linux. Apps can bypass the tunnel or require VPN connectivity; IP and subnet rules are bypass rules. Default behavior for the remaining apps can also be selected.

Windows and Linux have documented choices for DNS to follow app rules or use the app’s configured resolver. The same DNS setting is not established for macOS. Current Mac setup requires approval of a network extension, despite an older marketing FAQ that states a conflicting compatibility restriction.

PIA’s official blog and detailed iOS settings guide conflict about iPhone app splitting. We have not tested the app to resolve that, so it remains unverified here. Confirm the current capability with support if it is the reason you would purchase.

Why DNS can make results confusing

An application’s connection route and the resolver used for its name lookups are related but distinct. A browser may also use its own encrypted DNS provider. A site can therefore behave differently from what a simple public-IP check suggests.

If an excluded app still fails, review DNS behavior and the provider’s known limitations before widening the exception. Avoid changing several settings at once: record the original configuration, make one supported change, and check the result with ordinary non-sensitive activity.

The DNS leak guide explains why an unexpected resolver name is a prompt to investigate rather than automatic proof of a leak. The kill-switch guide explains which blocking behavior to confirm alongside exclusions.

A practical setup checklist

1. Define the requirement: app, website, destination address or local subnet.
2. Confirm the installed app and OS support that exact rule type.
3. Decide whether most traffic should use the VPN or remain direct.
4. Review DNS and kill-switch interactions in the platform guide.
5. Add the narrowest supported exception and test ordinary activity.
6. Remove the rule when it is no longer needed, if your intended configuration is full-tunnel access.

Use our provider comparisons to choose by established controls rather than a generic split-tunneling check mark.