What Is Split Tunneling and When You'd Actually Want It

What is split tunneling, exactly?

When a VPN is switched on in its default mode, every piece of traffic leaving your device — every app, every browser tab, every background sync — gets encrypted and routed through the VPN provider's server before it reaches the open internet. That's the whole point of a VPN in its simplest form: one tunnel, everything goes through it. Split tunneling is a setting, available in many consumer VPN apps, that breaks that all-or-nothing behavior. It lets you specify a subset of apps, websites, or IP ranges that should bypass the VPN tunnel entirely and connect to the internet directly, on your normal network path, while everything else continues to route through the encrypted tunnel as usual.

The name describes the mechanism reasonably well: your device's network traffic, which would otherwise travel as a single combined stream into the VPN, gets split into two paths. One path goes into the tunnel and comes out the other side at the VPN server, picking up that server's IP address and the VPN's encryption along the way. The other path skips the tunnel and goes straight out through your regular internet connection, exactly as if the VPN weren't running at all. Both paths are active at the same time, and which one a given piece of traffic takes depends on rules you set — usually a list of apps, sometimes a list of domains or IP ranges, depending on the app.

It's worth being precise about what "some traffic is protected and some isn't" actually means here, because it's easy to round split tunneling up to something it's not. It doesn't mean the VPN is somehow doing a partial or weaker version of encryption on the traffic that does go through the tunnel — that portion is protected exactly as it would be if split tunneling were off. It means the traffic you've excluded gets zero VPN involvement whatsoever: your real IP address, your real location as seen by that specific app or site, and no VPN encryption layered on top of whatever encryption the app already uses (like HTTPS). Split tunneling routes traffic differently; it doesn't change how protected the traffic is once it's decided which path to take.

How does split tunneling actually work under the hood?

You don't need to understand networking internals to use split tunneling, but a rough mental model helps explain why it behaves the way it does and where it can go wrong. When a VPN app connects, it typically changes your device's routing table — the internal list your operating system consults to decide which network interface a given piece of outgoing traffic should use. Normally, that table has one relevant entry after a VPN connects: send everything to the virtual VPN network adapter. Split tunneling adds more specific rules on top of that default, carving out exceptions for particular apps or address ranges that should use the regular network adapter instead.

There are two broad ways VPN apps implement this, and which one a given app uses affects what you can actually exclude:

App-based (or "app-level") split tunneling works by identifying which running process generated a piece of traffic and routing based on that. You pick specific apps — a browser, a game, a work client — and the VPN software tags traffic from those apps and sends it around the tunnel. This is the more common implementation on desktop and mobile apps because it maps to how people actually think about the problem ("I want Chrome protected but Steam not"), and it doesn't require knowing anything about the destination.

Rule-based (IP or domain) split tunneling instead routes based on where the traffic is going rather than which app sent it — for example, "anything headed to this IP range goes direct, everything else goes through the tunnel." This is more common on routers and business VPN setups, where you might want to exclude an entire local subnet or a specific set of corporate IP addresses regardless of which app on which device is talking to them.

Most consumer VPN apps that offer split tunneling use the app-based approach, often with an inclusion or exclusion list you manage from a settings screen: either "tunnel everything except the apps I list here" or "tunnel nothing except the apps I list here," depending on the app and how you've configured it. Some apps support both modes and let you pick whichever framing fits what you're trying to do.

Is split tunneling available on every VPN and every device?

No, and this is one of the more consistently misunderstood parts of the feature. Split tunneling support varies by both the VPN provider and the operating system you're running the app on, for reasons that are mostly about platform-level networking constraints rather than provider laziness.

Android has the most reliable native support for app-based split tunneling among mobile platforms, because Android's VPN API is built in a way that makes per-app routing straightforward for developers to implement.

Windows apps commonly offer split tunneling too, generally through a driver-level component the VPN installs alongside its main app.

iOS is the platform where split tunneling is most limited. Apple's networking framework historically hasn't exposed the same level of per-app routing control to third-party VPN apps that Android does, so iOS split tunneling support tends to be narrower — sometimes limited to excluding specific domains rather than arbitrary apps, sometimes not offered at all, depending on the provider and the current state of their iOS app. If split tunneling matters to your use case and you're primarily on an iPhone or iPad, check the specific app's current feature list before assuming it works the way it does on desktop.

macOS support sits in between — better than the tightest iOS restrictions, but historically less consistent than Windows or Android, and it varies more by provider.

Routers running VPN client software (rather than a phone or laptop) typically only support IP-based or domain-based splitting, not app-based, because a router has no visibility into which application on which connected device generated a given packet — it only sees addresses.

Because support is this uneven, if a specific split tunneling setup is a deciding factor for you, the only reliable way to confirm it is to check the provider's current documentation or support pages for the exact platform you'll be using, rather than assuming a feature you've seen on one platform carries over to another.

How is split tunneling different from a VPN's "trusted networks" or LAN settings?

Split tunneling gets confused with a handful of other, similarly-named VPN settings often enough that it's worth distinguishing them explicitly, because they solve overlapping problems in different ways.

"Trusted networks" or "auto-connect exceptions"

Many VPN apps let you mark a specific Wi-Fi network — your home network, for instance — as "trusted," so the app doesn't automatically connect the VPN while you're on it. That's a different mechanism from split tunneling: it controls whether the VPN turns on at all for the whole device based on which network you've joined, rather than routing some traffic through an active tunnel and some around it. You could be on a trusted network with the VPN fully off, or on an untrusted network with the VPN on and split tunneling active at the same time — the two settings operate independently.

Local network access / LAN discovery toggles

Some VPN apps ship a simpler, single toggle labeled something like "allow LAN traffic" or "local network access," rather than full split tunneling. This is effectively a narrower, pre-built version of the local-network exclusion case described above — it's hard-coded to just your local subnet rather than letting you pick arbitrary apps or IP ranges, but it solves the same "can't see my printer" problem with one click instead of a manual rule.

"Bypass VPN" or per-site browser extensions

A few providers also offer this kind of control at the browser level, through an extension rather than the main app, letting you exclude individual websites from the VPN without touching the whole browser or the operating system's routing table. Functionally it's the same idea as domain-based split tunneling, just implemented at a different layer and scoped to a single browser rather than the whole device.

Multi-hop or "double VPN"

Worth mentioning mainly to rule it out: multi-hop routes your traffic through two VPN servers in sequence for additional obfuscation, and split tunneling routes some traffic through zero VPN servers. They're opposite ends of the same spectrum — more tunnel versus less tunnel — not variations on the same feature, and a given connection profile is generally one or the other, not both.

Is split tunneling a consumer-only feature, or does it come from somewhere else?

The concept predates consumer VPN apps by a considerable margin. Long before "VPN" meant a privacy app on a phone, businesses used VPNs to let remote employees securely reach internal company resources — an intranet, an internal file server, an internal tool — over the public internet. In that original corporate context, split tunneling solved a very practical bandwidth and infrastructure problem: without it, every byte of an employee's internet traffic, including things with nothing to do with work, had to travel all the way to the company's network and back out again, consuming corporate bandwidth and adding latency to traffic that never needed to touch the company network in the first place. Split tunneling let only the traffic actually destined for internal company resources take that route, while general internet use went out directly from the employee's own connection.

That history is worth knowing for two reasons. First, it explains why router-level and business-oriented VPN products tend to have more mature, flexible split tunneling controls — often rule-based, working off IP ranges or subnets rather than app names — than a lot of consumer apps offer, since the feature matured in that setting first. Second, it's a useful reminder that split tunneling's original purpose was efficiency and practicality, not privacy or security. Consumer VPN apps inherited the mechanism and repurposed it for privacy-adjacent conveniences — reaching a home printer, keeping a banking app working, avoiding a laggy game — but the underlying trade-off is the same one it always was: traffic that's excluded from the tunnel gets whatever the tunnel would have provided, minus.

It also shows up today in IT-managed environments in a slightly different form worth knowing about if you use a work-issued device or a company VPN app: some organizations enforce full-tunnel VPN with no split tunneling allowed, specifically so that all of an employee's traffic on that device can be monitored or filtered by the company's security tools, while others deliberately configure split tunneling so that only traffic bound for internal systems uses the company VPN, leaving an employee's general browsing on their own connection and outside the company's visibility. Which approach a given employer takes is a policy decision, not a technical limitation — the same underlying feature supports either choice, and if you're on a managed device, that policy is set by your IT department, not something you'd typically toggle yourself.

Is split tunneling worth using for gaming or streaming specifically?

These two come up often enough as motivations that they're worth walking through separately, because the calculus is a little different for each.

Gaming

Online games are sensitive to latency in a way that most other traffic isn't — an extra 40 or 50 milliseconds that's invisible while loading a webpage can be the difference between landing a shot and not. Routing a game through a distant VPN server adds exactly that kind of delay. If you're running a VPN for other reasons — protecting a home network, keeping general browsing private on public Wi-Fi — but the extra latency makes a specific game unplayable, excluding that game's executable from the tunnel while leaving everything else protected is a reasonable, narrow fix. The trade-off is that your real IP address becomes visible to that game's servers and to other players in some game types, which matters if part of your reason for using a VPN was to avoid exactly that.

Streaming

Streaming is a slightly different case because the direction of the trade-off often flips: people use a VPN specifically to make a streaming service think they're in a different location, which is the opposite of what split tunneling's exclusion does. Where split tunneling helps with streaming is the reverse scenario described earlier — keeping a domestic streaming app working normally, unaffected by the VPN, while other traffic on the same device stays tunneled. If your goal is instead to reach a streaming catalog only available in another country, that traffic needs to go through the tunnel, not around it, so there's nothing to exclude for that use case.

One caveat that applies to both: a streaming service or, less commonly, a game that actively detects and blocks VPN traffic will typically keep blocking you while that specific app is routed through the tunnel, regardless of what else on the device is or isn't excluded — split tunneling doesn't make VPN traffic harder for a destination to detect, since it doesn't change anything about the traffic that does go through the tunnel.

How do you actually turn split tunneling on? General steps

Exact menus vary by provider and update over time, so treat this as a rough map of the process rather than instructions for a specific app — always check the provider's current support documentation for the precise steps and current terminology in your version of the app.

1. Open the VPN app's settings, not the main connect screen. Split tunneling is almost always tucked into an advanced or connection-related settings menu rather than surfaced on the primary screen you see when opening the app.
2. Find the setting, which may be labeled split tunneling, app exclusions, bypass rules, or similar. If you don't see it under any of those names, check whether it's only available on certain platforms — as covered above, it's commonly missing or limited on iOS specifically.
3. Choose the mode, if the app offers more than one. Some apps ask you to pick between "only these apps use the VPN, everything else goes direct" and "only these apps go direct, everything else uses the VPN" — read this carefully, since picking the wrong mode inverts your intended result entirely.
4. Add the specific apps, domains, or IP ranges you want to route differently. On mobile and desktop this is usually a searchable list of installed apps you check or uncheck; on router-based setups it's typically an IP address or subnet you type in manually.
5. Reconnect the VPN if the app doesn't apply the change automatically. Some apps require a fresh connection for split tunneling rule changes to take effect, rather than applying them live to an existing session.
6. Verify the result rather than assuming it worked. For an app you've excluded, check that it now shows your real IP address and location; for an app you've kept in the tunnel, confirm it still shows the VPN server's. A quick check now is cheaper than discovering a misconfiguration later.

When would you actually want to use split tunneling?

The feature exists because "encrypt everything, all the time" is sometimes the wrong trade-off for a specific task, even when a VPN is genuinely useful for other traffic on the same device at the same time. A few situations come up repeatedly:

Reaching local network devices while connected to a VPN

This is probably the single most common practical reason people reach for split tunneling. When a VPN is on in its default full-tunnel mode, your device's traffic is routed out to the VPN server and back, which typically breaks its ability to see other devices on your local network — a printer, a network-attached storage drive, a smart TV you're trying to cast to, a router's admin page. Excluding local network traffic (or the specific app you use to reach that device) from the tunnel lets you keep the VPN active for general browsing while still being able to print a document or open your NAS.

Keeping bandwidth-heavy or latency-sensitive traffic off the VPN

Routing traffic through a VPN server adds a hop, and depending on the server's location relative to you and its current load, that can mean noticeably reduced speed or added latency compared to your direct connection. For something like a large file download, a video call, or an online game where every extra millisecond of lag is noticeable, some people choose to exclude that specific app from the tunnel while keeping the VPN running for everything else, rather than disconnecting the VPN entirely and forgetting to turn it back on.

Using region-locked domestic services while the VPN masks your location for other traffic

Some banking apps, government portals, and domestic streaming services check your IP address and refuse to work — or throw up extra verification steps — if it looks like you're connecting from somewhere other than your home country. If you're using a VPN for other traffic but need one specific app to see your real, local IP address, excluding just that app from the tunnel avoids having to disconnect the whole VPN every time you need to check your bank balance.

Managing traffic across a home network via a router-level VPN

If a VPN is configured at the router level so every device on a home network is covered by default, split tunneling by IP or device lets you carve out exceptions — a smart TV that needs to reach a domestic streaming service, a games console that performs poorly over the tunnel — without pulling the whole household off the VPN.

Working with two network contexts at once

Someone who needs to stay connected to a work VPN or a specific internal tool through a personal VPN's tunnel, while browsing normally for everything else on the same device, is another common case. Split tunneling lets the work-related app keep whatever routing or IP requirements it needs while the rest of the device's traffic isn't forced through the same path unnecessarily.

What these cases have in common is that they're all about convenience, compatibility, or performance for a specific piece of traffic — not about wanting "extra" privacy or security for that traffic. Nothing about excluding traffic from the tunnel adds protection; it removes it for that traffic specifically, in exchange for the local device, the speed, or the domestic service working normally.

What are the real downsides and risks of using split tunneling?

The core trade-off is simple to state and easy to lose track of in practice: anything you route outside the VPN tunnel gets none of the VPN's benefits for that traffic. No IP masking, no added encryption layer, no location spoofing. That's the intended behavior, not a bug — but it creates a few specific risks worth being deliberate about.

It's easy to exclude more than you meant to

If you're excluding an app rather than a specific narrow task within that app, you're excluding everything that app does. Excluding a browser so one domestic site works correctly also means every other site you visit in that same browser window is now unprotected too, unless the VPN app supports finer-grained, domain-level rules rather than whole-app rules. Check exactly what unit of traffic you're excluding before assuming the scope matches what you intended.

Your real IP address is exposed to whatever you've excluded

Anything on the excluded path sees your actual IP address and your actual approximate location, and connects on your actual ISP's network, exactly as if the VPN weren't running. If the whole reason you're using a VPN in a given session is to hide your IP address from a specific service, and you accidentally exclude that service (or the app you're using to reach it), the VPN isn't doing the job you turned it on for — even though the VPN icon still shows "connected."

It can undermine the reason you're using a VPN in high-stakes situations

For most everyday uses, that gap is a minor inconvenience at worst. But if you're using a VPN because you specifically need every piece of your traffic routed through it — for instance, in a context where your network activity being traceable back to your real IP address carries real personal risk — split tunneling is not the feature to reach for casually. In that kind of situation, a single misconfigured exclusion rule, or an app you forgot was on the excluded list, can quietly defeat the entire point of running the VPN, without any warning that anything is wrong. Full-tunnel mode, without exceptions, is the safer default when the stakes are that high.

It doesn't combine cleanly with a kill switch, on some apps

A kill switch is a separate VPN feature that blocks all internet traffic if the VPN connection drops unexpectedly, so you're never silently exposed while thinking you're still protected. Depending on the app, a kill switch and split tunneling can interact in ways that aren't obvious — some apps exempt split-tunneled traffic from the kill switch by design (since it wasn't going through the tunnel anyway), while others handle it differently. If you rely on both features together, it's worth confirming in the specific app's documentation how they're meant to interact, rather than assuming.

DNS requests don't always follow the same path as the traffic you'd expect

DNS — the lookup that turns a domain name into an IP address — is handled separately from the traffic that follows once the lookup resolves, and depending on the app and platform, DNS requests for excluded traffic may or may not be routed the way you'd assume. This is a fairly technical edge case, but it's part of why split tunneling configurations are worth testing rather than just setting and trusting blindly, especially if the exclusion is protecting something sensitive.

What are the most common split tunneling mistakes?

Most problems with split tunneling aren't dramatic failures — they're quiet mismatches between what someone intended to exclude and what they actually excluded, which is exactly the kind of thing that's easy not to notice until it matters.

Excluding the wrong app by name

Some apps present multiple processes under similar-looking names, or a single app with several components (a browser and its update service, for instance). Excluding the wrong one, or excluding only part of a multi-process app, can leave you thinking traffic is protected when part of it isn't, or thinking a local device still won't connect when the actual traffic-generating process was never excluded in the first place.

Confusing inclusion mode with exclusion mode

As mentioned above, apps that offer both "only these apps skip the VPN" and "only these apps use the VPN" modes make it possible to build a list of the apps you want protected, then leave the app set to the mode that treats that list as the apps that should bypass the VPN instead — the exact opposite of what was intended, with no error message to flag the mistake.

Forgetting an exclusion exists

An exclusion added for a one-time reason — reaching a printer at a location you're no longer at, testing whether an app performs better outside the tunnel — that's never removed afterward becomes a standing, forgotten gap. Reviewing the exclusion list occasionally is the main defense against this, since the app itself has no way of knowing which exclusions are still intentional.

Assuming split tunneling and a kill switch are protecting the same thing

A kill switch protects against the VPN connection dropping unexpectedly; it says nothing about traffic you've deliberately routed outside the tunnel via split tunneling, which was never covered by the kill switch's guarantee in the first place. Treating "kill switch is on" as a blanket assurance that nothing is leaking, without accounting for what split tunneling is separately excluding, is a common source of surprise.

Not accounting for DNS separately

As noted earlier, DNS lookups for excluded traffic don't always follow the path you'd intuitively expect, and this varies by app and platform. For most everyday exclusions this is a non-issue, but for anything where you're relying on an exclusion to keep a specific piece of traffic looking local, it's worth confirming DNS resolution is happening the way you assume rather than taking it on faith.

Split tunneling vs. just turning the VPN off — what's the actual difference?

It's a fair question, because on the surface both options result in some traffic going out unprotected. The difference is what happens to everything else at the same time. Turning the VPN off drops protection for all of your device's traffic, until you remember to turn it back on. Split tunneling drops protection only for the specific apps or destinations you've deliberately excluded, while everything else keeps running through the tunnel exactly as before, with no need to remember to reconnect afterward.

In practice, that difference is largely about reducing the chance of forgetting to re-enable the VPN. Someone who turns their VPN off to print a document, then gets pulled into email, then closes the laptop for the day, has spent the rest of that session unprotected without meaning to. The same person with a local-network exclusion configured never has to make that trade-off in the first place — the printer traffic goes direct, everything else stays tunneled, automatically, every time.

How do you decide whether to use it?

A reasonable way to think about it: split tunneling is worth setting up when you have a specific, recurring, well-defined reason to exclude a specific, narrow piece of traffic — a local device, one app that performs badly over the tunnel, one domestic service that needs your real IP address — and you're comfortable that excluding it doesn't undercut the reason you're using the VPN in the first place. It's worth being more cautious, or skipping it entirely, when your reason for using the VPN applies to everything you do on that device without exception, or when you're not fully sure what "excluding this app" actually covers.

A few habits make split tunneling safer to rely on once you've decided it fits your situation:

• Exclude the narrowest thing that solves the problem — a single domain rather than a whole browser, a single app rather than a whole device, where the app gives you that choice.
• Periodically review what's on your exclusion list. Apps you added an exclusion for months ago, for a reason you no longer remember, are an easy way to end up with traffic silently bypassing the VPN.
• Check, rather than assume, how the exclusion interacts with any kill switch setting in the same app.
• If the traffic in question is genuinely sensitive, verify the exclusion is doing what you expect — checking the IP address an excluded app reports, for instance — rather than trusting the settings screen alone.

Quick reference: good reasons to use split tunneling vs. reasons to avoid it

As a fast summary of everything above, these are the patterns that consistently separate a sensible use of split tunneling from a risky one.

Generally reasonable to exclude from the tunnel: a local printer or NAS you need to reach while the VPN handles everything else; a single domestic banking or government app that needs your real, local IP address to function correctly; one specific game or video-call app where added latency is a genuine, measured problem; an internal work tool that requires a separate company VPN connection running alongside your personal one.

Generally not a good fit for split tunneling: anything you're using the VPN specifically to protect — if the entire reason you turned the VPN on was to keep a particular app or activity from being traceable back to your real IP address, excluding that exact app defeats the purpose; broad categories like "my whole browser" when only one site within it actually needs the exclusion, since that's wider than necessary; any exclusion in a context where the consequence of a mistake is serious rather than a mild inconvenience, where a simpler always-on, no-exceptions VPN connection is the safer default.

The through-line in both lists is the same question: does excluding this specific traffic undercut the actual reason I'm running a VPN right now? When the answer is clearly no — the excluded traffic was never traffic I needed protected in the first place — split tunneling is doing exactly what it's designed to do. When the answer is unclear, or is yes, that's the signal to leave the tunnel alone rather than carve an exception into it.

Split tunneling is a convenience feature layered on top of a privacy and security tool, not a privacy or security feature in its own right. Used deliberately, for a clearly scoped reason, it removes a real everyday friction point without meaningfully changing your overall exposure. Used carelessly, or left configured and forgotten, it's a quiet way for a VPN that appears to be protecting everything to actually be protecting less than you think.