Split tunneling sounds useful in the abstract. The problem is that most guides selling you on it list ten or twelve scenarios that mostly do not apply to anyone, then leave you to figure out whether the configuration is worth your time. It usually is not, unless you fall into one of a small number of specific situations.
Here are six of those situations on Windows, where setting up split tunneling actually pays for the effort. After that, a section on when not to bother, because that part matters too.
What Split Tunneling Actually Does (Briefly)
Split tunneling lets you choose which apps or destinations route through your VPN connection and which connect directly to the internet. Two configurations exist. Inclusive mode sends only the apps you specify through the VPN; everything else goes direct. Exclusive mode is the inverse: everything routes through the VPN by default except the apps you explicitly exempt.
On Windows, split tunneling is configured at the VPN client level, not the operating system level. Windows itself does not provide this feature in its built-in VPN client. The implementation, the modes available, and the granularity of control all depend on which third-party VPN application you use.
With that out of the way, here are the situations where setting it up is worth the effort.
1. Banking and Financial Apps That Block VPN Traffic
You connect to your VPN, then your banking app refuses to load. Or it accepts your password, then sends you through three rounds of two-factor authentication. Or it locks the account entirely and asks you to call a fraud line.
This happens because banks and brokerages run IP reputation checks before accepting a session. Commercial VPN servers are shared by thousands of users, and inevitably some of those users will have triggered fraud rules from another bank, another country, or another time of day. The IP gets flagged. Your perfectly legitimate session gets penalized for sharing an address with someone who, hours earlier, looked suspicious to a different bank’s risk model.
Most of the time, this is not a deliberate “block VPNs” policy. It is a side effect of how IP-based fraud detection scores requests. The bank does not know you are on a VPN. It only knows the IP has a reputation problem.
The fix is straightforward. Configure your VPN in exclusive mode and add your banking app, brokerage app, and payment apps (Venmo, Cash App, similar) to the exclusion list. Those apps now connect directly using your home IP, while the rest of your traffic stays encrypted. Your bank session is not VPN-protected, but the bank’s own TLS encryption handles transport security. The trade-off is reasonable: you give up VPN protection for a session that did not really benefit from it, in exchange for a session that actually works.
Banking apps are the most common version of this problem, but they are not the only one. Some of the apps that misbehave under VPN are sitting in your living room.
2. Accessing Local Network Devices While the VPN Is On
You turn the VPN on, and suddenly your printer is gone. Your laptop cannot find the Chromecast. The smart home dashboard times out. The NAS on the desk five feet from you is unreachable.
The mechanic is simple. The VPN sends all traffic to a remote server, including traffic destined for devices on the same Wi-Fi network. Without an exception, your laptop tries to reach your printer through a server in another country, which obviously does not work.
Two fixes exist, and the right one depends on the device. The first is the “allow LAN access” toggle that most VPN clients offer in their settings. This handles the simple cases: printers reachable by IP, NAS shares over standard ports, anything that just needs traffic on your local subnet to bypass the tunnel.
The toggle is not always enough. Casting from your laptop to your TV uses multicast discovery (mDNS or Bonjour), and that discovery often does not survive the basic LAN bypass. Some smart home hubs use proprietary protocols that get blocked by the VPN’s interception. In those cases, you need route-based split tunneling: explicitly exclude your local subnet (typically 192.168.x.x or 10.x.x.x) from the VPN tunnel at the routing level. This is more powerful than app-based exclusion because it covers any traffic destined for those addresses, regardless of which app initiated it.
Some users have a more bandwidth-sensitive reason to keep specific apps off the VPN.
3. Competitive Online Gaming Without Sacrificing Privacy Elsewhere
A VPN adds latency. How much depends on the protocol and the distance to the server, but ten to fifty milliseconds is the typical range. In a competitive shooter, MOBA, or fighting game, that is the difference between a click that lands and one that gets traded out.
The instinct is to turn the VPN off when you play. The problem with that instinct is that you also turn it off for your browser, your Discord client, your torrent app, and anything else running in the background that benefits from the encryption. Every gaming session becomes a privacy gap.
Split tunneling resolves the trade-off. Add the game’s executable to the exclusion list and route everything else through the VPN. The game gets a direct connection at native latency, the rest of your traffic stays protected.
A few practical points. Exclude the game executable, not just the launcher. Steam, Epic, Battle.net, and Riot’s launcher all run as separate processes from the games they manage; excluding only the launcher leaves the actual game routed through the VPN. Check the running process in Task Manager during a match to confirm what to add.
A secondary reason to do this involves anti-cheat. Some kernel-level anti-cheat systems flag VPN IP ranges as suspicious, leading to false-positive bans, queue blocks, or extended verification flows. Routing the game directly avoids the friction.
The myth that all VPN protocols add the same overhead is dated. WireGuard, in particular, sits within five to ten percent of native throughput on most hardware. But for matchmaking-sensitive games, that single-digit gap still matters.
4. Running a Personal VPN Alongside a Corporate One
Remote work introduced a problem that consumer VPN guides rarely address. Your employer requires you to connect to a corporate VPN (Cisco AnyConnect, Palo Alto GlobalProtect, Zscaler) for the workday. You also run a personal VPN for your own browsing. Both clients want to manage the routing table on your machine. They fight.
The symptoms vary. Sometimes the personal VPN refuses to connect once the corporate one is active. Sometimes both connect, but DNS resolution breaks for one or the other. Sometimes the connection drops every few minutes as the two clients overwrite each other’s routes.
The clean solution is asymmetric. Treat the corporate VPN as the default tunnel, the one your machine assumes is in charge. Configure your personal VPN in exclusive mode, and exclude the corporate VPN client’s process and any apps tied to it: Outlook, Microsoft Teams, the corporate browser session, internal-only tools. Those apps flow through the corporate VPN as your employer expects. Everything else (personal browsing, personal email, anything outside work) routes through your personal VPN.
A caveat. Some corporate VPN deployments use full-tunnel enforcement and explicitly block any other VPN client from running on the same machine. If your IT setup is one of those, you have two options: disconnect the personal VPN during work hours, or run personal apps in a separate Windows user profile that the corporate VPN does not control.
Some apps also need accurate location, but for legitimate reasons rather than fraud rules.
5. Region-Locked Services That Require Your Home IP
Region-locking is usually framed as a streaming barrier: foreign Netflix catalogs, BBC iPlayer outside the UK, regional sports blackouts. Reverse the framing. Your own country also has services geofenced to verify residency, and your VPN can break them just as easily as it can unlock the others.
Tax filing software wants confirmation that you are in the country whose taxes you are filing. Government benefits portals check IP location as a soft fraud signal. Telehealth apps in regulated jurisdictions verify residency before issuing prescriptions. Some banking and brokerage features (wire transfers, account changes) require a domestic IP even when login does not. Online voter registration, where it exists, may include location checks.
If your VPN is permanently set to a server in another country, all of these can fail. The error messages range from polite (“we are unable to verify your location”) to silent (the page just hangs) to suspicious (the service flags your account for review).
The fix is the same shape as the banking case but for different reasons. Add the affected apps or browser sessions to your VPN’s exclusion list so they connect using your home IP. For services accessed through a browser, a cleaner approach is to use a separate browser profile, or even a dedicated browser, for these services and exclude that browser’s executable. That way your everyday browsing stays tunneled, while the residency-verifying services see what they need to see.
The opposite trade-off involves apps where the VPN works fine, but is not earning its overhead.
6. High-Volume Downloads That Don’t Need VPN Overhead
You start a 60 GB Steam library transfer or a multi-hour OneDrive backup, and within minutes everything else slows down. The VPN is the bottleneck. Sustained encrypted throughput is more demanding than bursty browsing, and not every protocol or every machine handles it equally well.
Modern VPN protocols are not the throughput killers they used to be. WireGuard delivers within five to ten percent of native speed on most consumer hardware, and OpenVPN is no longer the default in serious clients. The “VPN destroys speed” reflex is outdated.
What still holds up: high-volume sustained traffic competes with everything else for VPN bandwidth, especially on shared servers. CPU usage matters on lower-spec laptops where the encryption load is noticeable. Some ISPs throttle sustained encrypted streams in ways they do not throttle direct downloads. For traffic that gains nothing from being tunneled, the overhead is not worth the cost.
The deciding question is whether the tunnel is doing useful work for the traffic in question. Steam, Epic, and Battle.net downloads are signed and checksummed by the client; the tunnel adds no integrity benefit. Windows Update and software patch traffic is signed at the source. Cloud backup over TLS already encrypts the payload end-to-end. For these, exclude the relevant client and let the connection breathe.
Do not split tunnel browsing or torrenting for speed reasons. That defeats the actual purpose of running a VPN.
Six use cases is a useful number, but it is not a full picture. The honest part is what these scenarios do not justify.
When Split Tunneling Isn’t Worth Setting Up
The configuration is not free. Every excluded app is an attack-surface decision, every routing rule is something to maintain, and every VPN client update can silently reset your exclusions. For most users who do not hit any of the scenarios above, full-tunnel mode is simpler, safer, and removes a class of problems you do not want to think about.
A few specific situations where split tunneling is the wrong tool:
If your privacy needs are critical, full-tunnel is non-negotiable. Threat models that include law enforcement, stalkers, or targeted surveillance cannot tolerate a single non-VPN connection, no matter how innocuous it looks. Split tunneling adds attack surface and configuration risk that those threat models cannot absorb.
If you are on an untrusted or metered network (public Wi-Fi, hotel networks, cellular hotspots), every direct connection is a potential interception point. Keep everything tunneled.
If your goal is “general speed,” the answer is to upgrade your protocol or your server, not to split your traffic. Modern WireGuard implementations make this concern largely moot.
Split tunneling is a configuration tool for specific problems, not a default best practice. If none of the use cases above describe you, leaving it off is the right call.
How to Set It Up on Windows
The structural fact most guides bury: split tunneling on Windows is a feature of the VPN client, not the operating system. Windows ships with a basic VPN client supporting L2TP, IKEv2, and SSTP, but it does not include split tunneling controls in the consumer interface. PowerShell can configure some routing-level split tunneling for IKEv2 connections, but the syntax is unfriendly and the result is brittle.
For any of the use cases in this article, you need a third-party VPN client that supports split tunneling natively. A few things to look for:
- App-based exclusion at minimum, ideally with route-based exclusion as well for cases like local subnet bypass.
- Explicit kill switch behavior for excluded apps, so the kill switch does not fight with your exclusions when the VPN drops.
- A clear interface for adding and reviewing exceptions, since you will need to revisit it.
Several reputable consumer VPN clients on Windows include split tunneling, with implementations that vary in flexibility. Mullvad supports app-based exclusion. Proton VPN offers both inclusive and exclusive modes. Windscribe’s VPN for Windows includes both inclusive and exclusive split tunneling and exposes route-based exclusion for advanced cases. The right choice depends on which mode and which level of granularity you need.
Two practical tips after configuration. First, test it. Open an excluded app, visit a what-is-my-IP service, and confirm you see your home IP. Open a tunneled app and confirm you see the VPN’s IP. Second, review the configuration after every VPN client update; some updates silently reset exclusions or change defaults.
FAQ
Does split tunneling weaken my VPN’s security?
It changes what the VPN protects, not how strongly it protects it. Apps you exclude do not get VPN encryption or IP masking, by design. The encryption on tunneled apps is unchanged. The risk in split tunneling is misconfiguration (excluding an app you actually wanted protected), not weaker cryptography.
Can split tunneling be configured per app, per website, or both?
On Windows, almost all clients implement app-based or process-based exclusion. URL or destination-based exclusion exists in some advanced clients, but it is the exception. App-based is the baseline to expect.
Does split tunneling work with the VPN’s kill switch?
It depends on the client. A well-designed implementation treats excluded apps as exempt from the kill switch, so they keep working when the VPN drops. A poorly designed one either disables exclusions when the kill switch fires or leaves leak paths. Test both states explicitly after configuring: drop the VPN deliberately and verify the excluded apps still work and the tunneled apps stop.
Is split tunneling available in the Windows built-in VPN client?
No. The native client supports L2TP, IKEv2, and SSTP, but it does not expose split tunneling in the consumer interface. PowerShell can configure routing-level exclusions for IKEv2, but it is not user-friendly and most users will be better served by a third-party client.
Will excluded apps leak my real IP?
Yes, by design. Excluded apps connect directly using your home IP. That is the point. If that is not what you want for a given app, do not exclude it. This is why the exclusion list deserves explicit review whenever your routine changes.
Can I split tunnel a single browser tab?
Not at the operating system level. The browser is one process, so split tunneling routes the entire browser one way or the other. Workarounds: run two different browsers (one tunneled, one direct), or use distinct browser profiles in clients that support per-profile network controls. At the system level, the smallest unit of split tunneling is the executable, not the tab.
