VPN split tunnelling lets you choose which applications or destinations use an encrypted VPN connection and which connect directly to the internet or your local network. This guide explains how to make those decisions safely, compare common use cases, estimate the practical trade-offs, and troubleshoot routing exceptions across Windows, macOS, Android, iOS, and router-based setups.
Overview
When a VPN is active, a device normally sends its traffic through the VPN provider’s server. This can help protect traffic on untrusted networks, hide the device’s public IP address from websites, and provide access to private business resources. The drawback is that every connection follows the same route, even when that is unnecessary.
Split tunnelling creates two paths. Selected traffic uses the VPN tunnel, while excluded traffic uses the ordinary connection supplied by the home router, mobile network, or public Wi-Fi. Depending on the client, you may be able to define rules by application, website, IP address, port, or destination network.
The right choice is not simply VPN on or VPN off. It is a risk and compatibility decision:
- Use the VPN for traffic that needs privacy from the local network, a protected route to a private service, or a consistent source IP.
- Bypass the VPN for traffic that must reach local devices, depends on the normal network location, or performs poorly through the VPN.
- Use caution when an application handles sensitive information but also needs local-network access. A bypass may improve compatibility while removing some VPN protection.
Split tunnelling is different from a kill switch. A kill switch is designed to stop selected traffic if the VPN disconnects. Split tunnelling decides which traffic should use the VPN in the first place. Check both settings together, because a rule that bypasses the tunnel may continue using the ordinary connection during a VPN outage.
How to estimate
You can assess a split-tunnel rule with a simple four-step method. The goal is to avoid adding exceptions merely because an application is inconvenient through the VPN.
- Identify the application or destination. Record the app name, browser profile, website, server, or device involved. Some applications use separate background services, launchers, or helper processes, so the visible app may not be the only traffic that needs a rule.
- Classify the data and access requirement. Ask whether the traffic contains personal, business, financial, authentication, or otherwise sensitive information. Then ask whether it needs a private corporate route, a local printer, a smart-home device, or a service on the public internet.
- Choose the route. Select the VPN when confidentiality, a private route, or a stable VPN egress is more important than latency and local access. Select bypass when local discovery, normal regional access, or application compatibility is the primary requirement.
- Test the result. Confirm the public IP, DNS behaviour, application connectivity, local-network access, and behaviour after reconnecting the VPN. Test both the intended path and the failure case.
A practical scoring method is to give each traffic type a priority from one to three for privacy, private-resource access, local-network access, and performance. A high privacy or private-resource score favours the VPN. A high local-access or performance score favours a bypass, provided the data is suitable for a direct connection. These scores are decision aids, not a security guarantee.
| Use case | Starting decision | Reason and caution |
|---|---|---|
| Online banking | Usually use the VPN, or use a trusted direct connection | Avoid frequent location changes if the bank challenges unfamiliar sessions. Do not assume a VPN makes banking activity risk-free. |
| Streaming | Test a VPN route and a direct route | A VPN may be useful for privacy, but services can apply location or account rules. Availability and performance can change. |
| Gaming | Often test direct routing first | Direct traffic may reduce latency, while a VPN can help in specific network conditions. Protect other device traffic separately. |
| Work tools | Use the organisation’s approved route | Corporate VPNs, device management, and access policies may require full tunnelling. Do not bypass business controls without approval. |
| Printers and file shares | Usually bypass to the local network | Local discovery often fails when the device is isolated behind a VPN tunnel. Confirm that the local network is trusted. |
| Smart-home devices | Usually bypass, with care | Many devices require local discovery. Segmenting smart-home devices from work systems is preferable where the network supports it. |
Inputs and assumptions
Before configuring a VPN app bypass or routing exception, document the assumptions behind the rule. This makes the setup easier to review when an application changes or the device moves to another network.
- Device and operating system: Windows and macOS clients commonly offer application-based or destination-based controls, but the exact options vary by provider and client version.
- Mobile platform: Android VPN applications may expose per-app allow or deny lists. iOS support can be more constrained because of platform and provider implementation differences. Verify the current client documentation rather than assuming desktop features exist on mobile.
- Router capability: Router-level split tunnelling may apply rules to individual devices, IP ranges, domains, or VLANs. It can cover devices that cannot run a VPN app, but one mistake can affect the whole household or network segment.
- Protocol and client behaviour: WireGuard, OpenVPN, IKEv2, and proprietary implementations can handle routes differently. A protocol comparison can help when behaviour changes after switching clients or devices; see our guide to VPN protocols.
- DNS handling: Routing web traffic outside the tunnel does not automatically explain how DNS requests are handled. Test for DNS leaks and unexpected resolvers after applying a rule.
- Kill-switch scope: Establish whether the kill switch covers all traffic or only traffic assigned to the VPN. Read the client’s wording carefully and test with the connection interrupted.
For business use, treat split tunnelling as a policy decision rather than an individual preference. A direct path may expose traffic to local networks and may not satisfy an organisation’s access or monitoring requirements. If the objective is access to specific applications rather than broad network access, compare the design with a zero-trust network access model using this ZTNA versus VPN guide.
Worked examples
Working from home with a local printer
Suppose a laptop needs a company document system and a home printer. Route the company application through the approved business VPN, then test whether the printer remains discoverable. If it does not, create the narrowest local-network exception supported by the client, or use a separate trusted device for printing. Do not bypass the entire business VPN simply to make a printer work.
Streaming and general browsing
A user may want streaming traffic to use the VPN while allowing software updates or local services to connect directly. Start with an application rule rather than a broad domain rule, because streaming applications may use multiple domains and delivery services. Check the service’s terms, confirm playback, and test the public IP from a browser assigned to each route. A direct browser session should not be mistaken for proof that every background process follows the same path.
Gaming with a privacy-sensitive browser
Gaming can be latency-sensitive, so a direct route may provide the better experience on a particular network. The same device can keep a separate browser or work application inside the VPN. Test the game’s login, matchmaking, voice functions, and updates independently; launchers and anti-cheat components may not follow the same rule as the game executable.
Mobile use on public Wi-Fi
On public Wi-Fi, avoid broad bypass rules for email, work tools, password managers, and other sensitive applications unless there is a clear reason. A local printer or casting device may need a temporary exception, but remove it when leaving the trusted network. Mobile operating systems may apply VPN rules at the app or profile level, so verify the actual route rather than relying on the setting’s label.
When to recalculate
Review split-tunnel rules whenever the underlying conditions change. Revisit them after a VPN client or operating-system update, a change of VPN protocol, a new router, a new internet provider, or a move between home, office, hotel, and public networks. Also review them when an application adds a launcher, changes its executable, moves to a new domain, or stops working.
Use this short troubleshooting workflow:
- Disable the suspect exception temporarily and confirm whether the problem is routing-related.
- Check the device’s public IP and DNS results while using the VPN and while using the bypass.
- Inspect local routes or the VPN client’s connection log if available. Look for overlapping private address ranges, incorrect gateways, or a rule matching too broadly.
- Test the application after a fresh VPN connection and again after the tunnel drops and reconnects.
- Narrow the rule to one app, destination, device, or network segment. Avoid solving a single failure with a whole-device bypass.
- Remove temporary exceptions and record the final rule, its purpose, date, and owner.
Finally, run a privacy check after meaningful changes. Confirm the expected IP address, DNS path, local-resource access, and kill-switch behaviour. Our VPN privacy audit checklist provides a broader review. Split tunnelling is most useful when its exceptions remain few, documented, and tied to a clear use case—not when it becomes an unexamined collection of bypasses.
