Split tunneling lets you route only some of your device’s traffic through a VPN while the rest travels over your regular internet connection directly. It is one of the most misunderstood VPN settings — used correctly, it solves real performance problems; used carelessly, it can quietly undo the protection a VPN is supposed to provide. This guide explains how it actually works, when it makes sense for a small team, and how to configure it without creating a security gap.
This builds on our VPN provider guide and protocol comparison — read those first if you have not yet chosen a provider or protocol.
How split tunneling works
Without split tunneling, every byte of traffic leaving your device — browsing, video calls, background app syncing, everything — routes through the VPN’s encrypted tunnel before reaching the internet. This is the default and most secure configuration, but it also means every application on your device pays the performance cost of that extra routing hop, even applications that do not need VPN protection at all.
Split tunneling lets you specify which apps, websites, or IP ranges go through the VPN and which bypass it entirely, traveling over your normal internet connection instead. Most business VPN apps implement this either by application (route Slack and your browser through the VPN, but not your video streaming app) or by destination (route traffic to your company’s internal network through the VPN, but let everything else go direct).
Legitimate reasons to use split tunneling
Bandwidth-heavy local tasks that do not need protection. Video calls, large file downloads, and streaming can consume significant bandwidth, and routing them through a VPN adds latency and reduces available throughput for the traffic that actually needs protection, like access to internal company systems.
Accessing local network devices. If someone needs to print to a local network printer or access a smart home device while connected to a company VPN, a full-tunnel VPN configuration can block that local network access entirely, since all traffic — including traffic meant for devices on the same local network — gets routed to the VPN server instead.
Reducing load on limited VPN server capacity. For teams running a self-hosted VPN with limited server bandwidth, split tunneling ensures the server capacity is reserved for traffic that actually needs the secure tunnel, rather than being consumed by employees streaming video in the background.
Where split tunneling creates real risk
The core risk is straightforward: any traffic excluded from the VPN tunnel travels over whatever network the device is actually connected to, unencrypted by the VPN and visible to anyone else on that same network — a coffee shop Wi-Fi network, a hotel network, or any other untrusted public connection. If an employee configures split tunneling incorrectly, or a provider’s default split-tunnel rules are broader than intended, sensitive traffic that should be protected can end up traveling directly over an insecure connection without anyone realizing it.
This is particularly risky for any application handling credentials, client data, or company systems — these should virtually always be included in the VPN tunnel, never excluded, regardless of any performance benefit from excluding them.
A safe approach for small teams
Rather than letting each employee configure split tunneling individually with no oversight, define an explicit policy at the team level:
Always tunnel: Browsers used for work, email clients, internal company tools, code repositories, and any application that touches client data or credentials.
Safe to exclude: Video conferencing apps that already use their own end-to-end encryption (verify this claim for your specific tool before assuming it), streaming services, and general consumer apps with no connection to company systems.
Document this policy clearly and, where your VPN provider’s admin tooling supports it, enforce these rules centrally rather than relying on each team member configuring their own device correctly. Centrally managed split-tunnel rules remove the risk of an individual misconfiguration exposing sensitive traffic.
Application-based vs destination-based split tunneling
Application-based split tunneling (choosing specific apps to include or exclude) is generally easier to reason about for a small team, since you can directly map the policy above to a list of apps in your VPN client’s settings. The downside is that it requires updating the configuration whenever your team adopts a new tool.
Destination-based split tunneling (routing traffic to specific IP ranges or domains through the VPN, everything else direct) is more common for accessing specific internal company infrastructure — for example, always tunneling traffic to your company’s internal server IP range regardless of which application is generating that traffic. This approach tends to be more stable over time since it does not need updating every time a new app is installed, but requires more upfront technical setup to define the correct IP ranges.
Common misconfiguration mistakes we see
Excluding an entire browser instead of specific sites. Some VPN clients only support application-level exclusion, meaning excluding “the browser” excludes all traffic from that browser, including tabs open to internal company tools. If your VPN client only supports whole-application rules, consider using a separate browser profile or a dedicated browser exclusively for tunneled work traffic, keeping a second browser for excluded, non-sensitive browsing.
Forgetting split-tunnel rules exist after switching VPN providers. Split-tunnel configurations are typically app-specific and do not automatically carry over when switching to a new VPN provider. Teams that migrate providers sometimes assume their previous exclusion rules are still in effect when they are not, leading to either unnecessary full-tunnel slowdowns or, more concerning, assuming something is excluded when it is actually now being tunneled (or vice versa).
Not accounting for DNS leaks. Even with correctly configured split tunneling, DNS requests (which translate website names into IP addresses) can sometimes leak outside the tunnel due to how an operating system handles DNS resolution, potentially revealing which sites you are visiting even for traffic you intended to protect. Test for DNS leaks specifically using any of the several free online DNS leak test tools, rather than assuming correct split-tunnel configuration automatically means DNS is handled correctly too.
Split tunneling on mobile devices
Mobile operating systems handle split tunneling with more restrictions than desktop platforms, generally for security and battery-management reasons built into the OS itself. iOS in particular offers less granular control over per-app VPN routing compared to Android, which has historically offered VPN apps more flexibility in this area. If your team relies heavily on split tunneling for mobile devices specifically, verify your chosen VPN provider’s mobile app actually supports the level of control you need before assuming feature parity with its desktop app.
Testing your split tunnel configuration
After configuring split tunneling, verify it actually works as intended rather than assuming the settings took effect correctly:
1. Connect to the VPN with split tunneling enabled.
2. Check your public IP address from within an application that should be tunneled — it should show the VPN server’s IP, not your actual network IP.
3. Check your public IP address from within an application that should be excluded — it should show your actual network IP, confirming it correctly bypassed the tunnel.
4. Repeat this check periodically, especially after any VPN app update, since settings occasionally reset or behave differently after an update.
Split tunneling vs full tunneling: a quick decision guide
If you are still unsure which approach fits your team, these questions can help decide:
Does your team regularly work from untrusted networks — coffee shops, co-working spaces, airports? If so, lean toward full tunneling as the safer default, since split-tunnel exclusions on an untrusted network carry more risk than the same exclusions on a trusted home network.
Is your team experiencing genuine performance problems with full tunneling — slow video calls, poor file transfer speeds — rather than a theoretical concern? Split tunneling is worth implementing when there is a specific, measurable problem it solves, rather than as a default optimization applied preemptively.
Does your team have the administrative capacity to maintain a split-tunnel policy over time, including reviewing it as tools change? If your team is very small and does not have anyone tracking this kind of configuration over time, the operational simplicity of full tunneling — one rule, always applied, nothing to maintain — may outweigh the performance benefits of split tunneling.
There is no universally correct answer here — the right choice depends on your team’s specific risk tolerance, the sensitivity of the data your team handles, and how much ongoing attention you can realistically give to maintaining the configuration correctly.
Frequently asked questions
Does split tunneling reduce our overall security compared to full tunneling?
Only for the specific traffic you choose to exclude. As long as the exclusion policy is deliberate and limited to traffic that genuinely does not need protection, split tunneling does not meaningfully weaken security for the traffic that remains tunneled.
Should we ever use split tunneling for a device handling client financial or health data?
We would recommend full tunneling for any device regularly handling this category of data, since the consequences of a misconfiguration are more severe. If specific bandwidth-heavy applications genuinely need exclusion, document the reasoning carefully and review it periodically.
Can our VPN provider see which traffic we have excluded from the tunnel?
No — excluded traffic bypasses the VPN entirely and never reaches the provider’s servers, so the provider has no visibility into it at all. This is exactly why the security consideration is about the network the excluded traffic travels over instead, not about the VPN provider itself.
Is split tunneling available on all VPN providers and protocols?
Most modern business VPN providers support it on both WireGuard and OpenVPN, though the exact configuration interface varies. Check your specific provider’s documentation, since some offer it only on certain platforms (desktop but not mobile, for example).
How do we audit whether our team’s split tunnel rules are still appropriate over time?
Review the policy alongside your regular VPN provider re-evaluation — a reasonable cadence is every six to twelve months, or any time your team adopts a significant new tool that touches client data. Treat the exclusion list as something that needs active maintenance rather than a one-time setup that stays correct indefinitely.
For more on building a complete VPN setup for your team, see our tool reviews and full hardening guides section.