

By default, a VPN sends all of your device's traffic through the encrypted tunnel. Every app, every connection, every background service goes through the VPN's server before reaching the internet.
Split tunneling breaks that assumption. It lets you define rules for which traffic goes through the tunnel and which goes directly over your regular network connection, bypassing the VPN entirely.1
Most implementations let you split by app (send traffic from this app through the VPN, everything else directly) or by destination (send traffic to these IP ranges through the VPN). Some allow both.
The most practical reasons are performance and compatibility.
Banking and financial apps: Some banks flag logins from VPN IP addresses and may lock accounts or require extra verification. Routing your banking app outside the tunnel avoids this while keeping everything else protected.
Local network access: When all traffic goes through the VPN, your device loses visibility to local devices like printers, NAS drives, and smart home hubs. Split tunneling can exempt local network ranges so these keep working.
Speed-sensitive applications: VPN tunnels add latency and reduce throughput. For applications where speed matters more than privacy, such as large file transfers to a known destination or video calls that are already encrypted end-to-end, sending that traffic directly can help.
Work alongside personal use: If you use a VPN for work purposes and also want personal browsing protected by a separate VPN, split tunneling can keep them separated so each app uses the right connection.
Split tunneling is useful, but it weakens the privacy model in ways that are easy to miss.
Your real IP is still visible: Any traffic sent outside the tunnel comes from your actual IP address. If one of those apps or destinations is logging IPs, that log contains your real identity. The VPN protects nothing for that traffic.
Correlation between tunneled and non-tunneled activity: If a third party can observe both your real-IP traffic and your VPN-IP traffic simultaneously, they may be able to correlate them. Your tunneled traffic is no longer truly separate if your real IP is active at the same time.
Browser fingerprinting still applies: Even if you route your browser through the VPN, your non-VPN traffic can contain fingerprinting data that ties back to the same device. Split tunneling does not protect against device-level identification.
The non-tunneled traffic is fully unprotected: On untrusted networks like public WiFi, the traffic you chose to route outside the VPN is exposed to anyone monitoring that network. Split tunneling should be configured more conservatively on networks you do not control.
Split tunneling is a tool for balancing usability against protection, not a way to improve privacy. If your goal is to prevent as much IP exposure as possible, keeping everything in the tunnel is the stronger approach.
DNS is where split tunneling gets complicated. When you exempt an app from the VPN tunnel, you might expect only that app's connections to go outside. But DNS queries are often handled centrally by the operating system, not individually by each app.
A poorly implemented split tunneling configuration can route the excluded app's traffic outside the tunnel while still sending its DNS queries through the VPN, or the reverse: route excluded app traffic outside and also leak all DNS outside, revealing your browsing destinations even for the apps that are supposed to be protected.3
This is one of the most common sources of DNS leaks. If you are using split tunneling, it is worth running a DNS leak test to confirm that only the traffic you intended is leaving the tunnel.
BuycatVPN supports split tunneling on Windows and Android. You can choose specific apps to route outside the VPN tunnel, or use inverse mode to only send selected apps through the tunnel and everything else directly.
DNS leak protection remains active regardless of split tunneling configuration, so DNS queries stay inside the tunnel even for traffic that is excluded from it.
B. Gleeson et al., IETF, February 2000. Describes VPN routing models, including the concept of selective traffic routing through tunnels.
R. Draves, IETF, February 2003. Relevant to understanding how the OS routing table determines which interface handles which traffic in split-tunnel configurations.
Overview of how split tunneling configurations commonly produce DNS leaks and what to check for.