VPN Split Tunneling Explained: When to Route Some Traffic Around Your VPN

Fact-checked by the SnapMessages editorial team

A 2024 study by cybersecurity researchers found that misconfigured VPN split tunneling is one of the top three causes of unintentional data exposure in remote-access environments, not because the technology is flawed in concept, but because most users apply it without a clear model of what actually leaves the encrypted tunnel. VPN split tunneling works by dividing your device’s outbound traffic into two streams: one routed through an encrypted VPN tunnel, the other sent directly to the internet without any VPN protection. That division sounds convenient. In practice, it requires more deliberate configuration than most guides acknowledge, especially for anyone whose device carries health records, telehealth app sessions, or sensitive medical account credentials.

The scale of VPN adoption makes this matter. According to Security.org’s 2025 VPN Consumer Report, 32% of American adults reported currently using a VPN in 2025. Globally, 23% of internet users aged 16 and over reported using a VPN in Q2 2025, according to GWI research published in the We Are Social Digital 2026 Report. That is a substantial population, many of whom use VPNs on devices that also run pharmacy apps, telehealth platforms, fitness trackers, and mental health tools, exactly the environment where the gap between “configured” and “configured correctly” carries real consequences.

By the end of this guide, you will understand how split tunneling works at a functional level, which types exist, where each earns its place and where each creates risk, and how to audit your own setup for the leaks that most consumer-facing VPN guides never mention. The specific focus throughout is on health and wellness data, because that is where the stakes are highest and the guidance has been thinnest.

What VPN Split Tunneling Actually Means

At its core, VPN split tunneling is a traffic-sorting decision. Your VPN client examines outbound connections from your device and applies a routing rule: some traffic enters the encrypted tunnel and exits through the VPN server, while the rest bypasses the tunnel entirely and goes directly from your device to its destination on the open internet. The practical consequence is that the two streams carry different levels of protection simultaneously.

The NIST CSRC glossary defines split tunneling as “the process of allowing a remote user or device to establish a non-remote connection with a system while simultaneously communicating via another connection to an external network”, in other words, your device maintains an encrypted corporate or private channel while also having direct, unprotected access to the open internet at the same time.

The Contrast With Full Tunneling

Full tunneling routes 100% of your device’s traffic through the VPN server, regardless of destination. Every DNS query, every API call, every streaming request passes through the encrypted channel first. The trade-off is that high-bandwidth or latency-sensitive applications, live video consultations, fitness streaming classes, real-time wearable syncing, all compete for the same VPN connection and can suffer quality degradation as a result.

Split tunneling was designed to solve exactly that problem. A telehealth patient using a VPN for privacy might also want to stream a fitness class at the same time without buffering, and routing the streaming app directly seems reasonable. The question is whether the configuration is precise enough to keep the actually sensitive traffic inside the tunnel. Most configurations are not as precise as users assume.

A Concrete Scenario to Anchor the Concept

Picture a user with three apps open: a telehealth appointment platform, a mental health chat app, and a YouTube fitness video. An app-based split tunneling rule could route the telehealth and mental health apps through the VPN while letting YouTube connect directly. In theory, that is a sound arrangement. In practice, the moment a browser window is also open and excluded from the VPN for speed, any health portal tab running in that same browser window is also exposed. The routing rule does not see tabs. It sees applications. That gap is exactly what most mainstream VPN guides omit.

The Three Types of Split Tunneling

Not all split tunneling configurations work the same way. The differences matter considerably when your goal is to protect health data specifically, because each type gives you a different level of precision, and a different surface area for accidental exposure.

App-Based Split Tunneling

App-based split tunneling is the most widely available option in consumer VPN clients on Windows and Android. You select specific applications to include or exclude from the VPN tunnel, and the routing rule applies to all traffic generated by those apps. It is accessible and easy to configure without technical expertise. The limitation is that rules apply at the application level, not at the session or destination level within an app.

For a health user, that means selecting “Telehealth App X goes through the VPN” and “Streaming App Y bypasses the VPN” is straightforward, as long as you understand that the entire Telehealth App X is routed through the VPN for all sessions, not just the ones carrying sensitive data. It also means that a general-purpose browser excluded for speed is excluded entirely, including whatever health-related content happens to be open in it at any given moment.

Inverse Split Tunneling

Inverse split tunneling reverses the default logic: all traffic passes through the VPN by default, and you explicitly list which low-sensitivity applications are permitted to bypass the tunnel. This is a meaningfully safer configuration for health-conscious users, because the default state is maximum protection and exceptions are narrow and deliberate.

In practice, inverse tunneling might exclude a local weather widget, a food-delivery app, or a fitness-streaming service from the VPN, while routing everything else, including any app or browser tab touching health credentials or records, through the encrypted channel. This is the least-discussed option in mainstream VPN guides, which tend to frame split tunneling as “choose what to protect” rather than “protect everything and carve out explicit exceptions.”

URL/IP-Based and Dynamic Split Tunneling

URL and IP-based split tunneling offers the most granular control, routing traffic to specific domains or IP ranges through the VPN while leaving all other connections direct. A healthcare worker might configure their VPN to auto-route traffic to their clinic’s EHR domain and billing portal through the tunnel, with no VPN overhead on anything else. Dynamic split tunneling extends this further by allowing routing rules to update in real time based on network conditions or connection type.

These modes are predominantly available in enterprise VPN solutions, not consumer apps. They require meaningful technical setup and ongoing maintenance. For individual health users or small-practice clinical staff working outside a managed IT environment, URL-based and dynamic options are generally out of reach without dedicated support.

When Split Tunneling Makes Sense for Health Users

There are legitimate use cases for split tunneling even in health-adjacent contexts. The key is that the justification should be specific and the resulting exclusions should be genuinely low-sensitivity, not simply whatever would be most convenient to speed up.

Telehealth Video Calls on Trusted Networks

Telehealth video calls are real-time, bandwidth-sensitive, and latency-dependent. VPN encryption adds processing overhead and routes traffic through an additional server hop, both of which increase latency. On a quality home broadband connection with a modern VPN protocol like WireGuard, the impact is often modest. On a slower connection or with older OpenVPN-based clients, it can be enough to degrade video quality meaningfully during a live appointment.

If a telehealth platform uses its own end-to-end TLS encryption for the video session (most regulated platforms do), routing that specific app’s video traffic directly while keeping the login and authentication traffic inside the VPN is a defensible trade-off, provided the VPN’s split tunneling is precise enough to make that distinction. In most consumer apps, it is not. The more practical option on a trusted home network is to run full tunneling and accept a modest quality trade-off rather than to introduce the configuration risk.

Fitness App Syncing and Wearable Data

Fitness apps and wearables collect heart rate, location, sleep duration, body weight, and in some cases reproductive health data. These apps often need to sync with cloud services in the background, and routing that sync traffic through a VPN on a trusted home network adds overhead without much practical benefit, your home ISP already sees your connection to the fitness app’s servers regardless. On public Wi-Fi at a gym or coffee shop, that calculus changes sharply: other devices on the same network can attempt to intercept unencrypted or improperly secured traffic, and fitness data sent outside the VPN on an untrusted network is genuinely exposed.

The sensible approach is network-aware routing rather than blanket exclusion: keep fitness apps inside the VPN when on public networks, and consider excluding them only on a verified home connection. Several VPN clients support trusted-network detection that can automate this distinction.

Location-Dependent Health Services

Some practical scenarios involve apps that actively break when they detect a VPN IP address. Local pharmacy portals, regional health-insurance member sites, and location-based nutrition services often trigger fraud alerts or geographic access restrictions when they see traffic originating from a VPN server in a different city or country. Excluding those specific apps from the VPN tunnel can restore functionality while keeping other sensitive traffic protected, as long as the excluded apps do not themselves carry session credentials or health records in plaintext.

When You Should Not Use Split Tunneling

The cases where split tunneling actively creates risk for health users are more common than the cases where it provides a genuine benefit. Three scenarios in particular deserve direct treatment, because they are either underexplained in general VPN guides or entirely absent from consumer-facing content.

Patient Portals, EHR Access, and Mental Health Platforms

Any application that handles electronic Protected Health Information (ePHI), patient portal logins, EHR systems, telehealth scheduling platforms, mental health chat apps that retain session records, should stay inside the VPN tunnel. Full stop. The encryption provided by the VPN is not redundant even when the app itself uses HTTPS, because VPN encryption protects metadata that HTTPS does not: which servers you are connecting to, how often, and from where.

If your split tunneling configuration excludes a browser for speed and you then open your patient portal in that browser, that session is completely outside the VPN tunnel. The hospital’s HTTPS encryption protects the content of the page, but your ISP can see that you connected to the patient portal’s domain, when, and for how long. On an untrusted network, more is visible still. This is not a theoretical risk, it is the predictable consequence of how browser-level routing exclusions work.

The Hidden Browser-Tab Trap

This is the most concrete and underexplained risk in consumer split tunneling guides. App-based routing rules apply to the application as a whole. If Chrome, Firefox, or Safari is excluded from the VPN to improve general browsing speed, every tab open in that browser simultaneously bypasses the VPN, regardless of what that tab contains. A user who has excluded their browser for speed and then opens their pharmacy login, mental health scheduling page, and health insurance account in separate tabs has exposed all three sessions outside the VPN protection, while believing the VPN is providing coverage because it is turned on.

The solution is not to exclude browsers from split tunneling rules at all, or to use a dedicated secondary browser exclusively for non-sensitive browsing and keep the primary browser inside the VPN tunnel. That is an unconventional setup that requires deliberate commitment, which is itself evidence that the more practical default is full tunneling rather than trying to fine-tune browser-level exclusions.

Public Wi-Fi: The Threat Model Changes Completely

On an untrusted network, an airport, hotel, café, or conference center, the threat model for split tunneling is fundamentally different from a home broadband connection. Other devices on the same network segment can attempt man-in-the-middle attacks, network scanning, and traffic analysis against unencrypted or metadata-exposed connections. Any traffic running outside the VPN tunnel on that network is exposed to the full range of attacks that VPNs are specifically designed to block.

For anyone managing health data on a shared public network, split tunneling should be disabled and full tunneling enforced. This is not a fringe recommendation. The UK National Cyber Security Centre explicitly warns that “enabling split tunnelling increases the risk that sensitive data will be exposed to an unprotected network, and could enable external attackers to access internal resources by pivoting through the device.” If you are traveling and your digital security habits matter to you, the guide on securing messaging apps before international travel covers related considerations for protecting sensitive communications on the road.

The DNS Leak Problem Nobody Warns Health Users About

DNS leaks are the technical gap most frequently overlooked in consumer split tunneling guides, and the consequences for health-data privacy are more specific than most people realize.

How the Leak Happens

When a VPN is active, DNS queries (the requests your device sends to translate a domain name like “mentalhealth-portal.com” into an IP address) should pass through the VPN’s encrypted DNS resolver. When split tunneling is misconfigured, DNS queries for apps running outside the tunnel can bypass the VPN’s DNS resolver and go instead to your ISP’s default DNS servers. The actual content of the page may be protected by HTTPS, but your ISP now has a timestamped record of the domain you visited.

A properly configured split tunneling setup routes all DNS queries through the VPN regardless of which traffic stream the associated app belongs to. Many consumer VPN apps do not enforce this by default. The “DNS leak protection” setting, where it exists, is often disabled out of the box and must be manually enabled. Users should verify this setting is active in their VPN client and confirm it with a DNS leak test from a tool like dnsleaktest.com after any configuration change.

Why This Specifically Matters for Health Data

ISP-visible DNS queries carry a form of exposure that HTTPS encryption does not prevent. Your ISP cannot read the content of an encrypted health portal session, but it can see, and potentially log, that your device queried the domain for a mental health clinic, an addiction treatment service, a reproductive health provider, or an HIV testing facility. Those domain-level visits constitute sensitive health information even in the absence of any readable content.

This is not a hypothetical sensitivity. State insurance regulations, employment contexts, and social situations all create circumstances where the mere fact of visiting certain health-related domains carries real consequences for individuals. A split tunneling configuration that leaks DNS queries while encrypting page content provides a false sense of protection precisely where health users are most vulnerable. If you are building a broader security routine and want to think about this systematically, the guide on building a personal digital security routine offers a practical framework for layering protections.

Split Tunneling and HIPAA Compliance

The intersection of VPN configuration and healthcare regulation is almost entirely absent from general split tunneling guides, yet it is directly relevant to a substantial population: healthcare workers connecting to clinical systems remotely, telehealth practitioners operating from home offices, and administrative staff handling billing and scheduling for medical practices.

The Transmission Security Requirement

HIPAA’s Security Rule, under the Transmission Security standard at 45 CFR § 164.312(e)(1), requires covered entities to implement technical security measures that guard against unauthorized access to ePHI being transmitted over an electronic communications network. VPN encryption is one mechanism for meeting this requirement. A split tunneling configuration that allows EHR traffic, clinical messaging, or patient billing data to pass outside the encrypted tunnel, even briefly, even accidentally, creates a direct gap in that transmission security standard.

Healthcare security professionals generally recommend one of two approaches: disable split tunneling entirely for any device used in clinical workflows, or use administrator-enforced policy-based split tunneling that explicitly routes EHR, billing, and clinical-messaging app traffic through the VPN and nothing else, with the configuration locked by IT policy rather than left to individual user discretion. Consumer VPN apps do not offer administrator-enforced policy controls. The setting is user-configurable, which means it can be changed, misconfigured, or simply forgotten.

The Business Associate Agreement Gap

There is a less-discussed compliance issue that applies specifically to consumer VPN products. Under HIPAA, any vendor that handles ePHI on behalf of a covered entity must sign a Business Associate Agreement (BAA) before that relationship can legally proceed. Consumer VPN providers, including major paid services, generally do not offer BAAs. Their terms of service are not structured around healthcare compliance frameworks.

A healthcare worker using a consumer VPN with permissive split tunneling settings to access their clinic’s EHR remotely is creating two overlapping compliance problems: the transmission security gap created by misconfigured routing, and the absence of a BAA with the VPN provider through whose infrastructure patient data may be passing. This is not a technicality. It is a structural compliance gap with real enforcement exposure for covered entities and their staff.

The Practical Middle Ground for Small Practices

A small practice or solo telehealth provider who cannot deploy enterprise VPN infrastructure still has options. The most defensible configuration in a consumer VPN context is inverse split tunneling: route everything through the VPN by default, then explicitly exclude only apps with no conceivable connection to patient data, a music streaming service, a weather app, or a game. All clinical apps, all browsers used for clinical access, and all email clients remain inside the tunnel. This does not solve the BAA gap, but it meaningfully reduces the transmission security exposure compared to permissive app-exclusion configurations.

How to Set Up Split Tunneling Safely

A structured approach to configuring split tunneling starts with inventory, not with the VPN app itself. The routing decision should follow an honest assessment of what apps are on the device and what data they carry, not be driven by what the VPN client makes easy to configure by default.

Classifying Your Apps

List every app on the device you plan to use with split tunneling. Assign each one to one of two categories. Sensitive apps include anything that handles login credentials for health accounts, displays or transmits health records or clinical notes, carries pharmacy or prescription data, manages mental health sessions or therapy scheduling, or passes health insurance account information. Low-sensitivity apps include fitness streaming services with no account credential exposure on untrusted networks, weather apps, podcast players, and similar tools with no health-adjacent data.

If you are uncertain which category an app belongs in, it goes in the sensitive category. The asymmetry of consequences makes that the right default: an over-protected streaming app costs you some bandwidth efficiency; an under-protected health portal costs you potentially irreversible privacy exposure.

Platform Caveats That Most Guides Skip

App-based split tunneling is broadly available on Windows and Android. iOS is a different environment. Apple’s network extension architecture is significantly more restrictive, and most major consumer VPN providers either do not offer split tunneling on iOS at all or offer a limited “bypass” version with fewer configuration options than the desktop or Android equivalent. Healthcare workers and telehealth patients who use iPhones as their primary device should check their specific VPN provider’s iOS feature documentation before assuming split tunneling is available in the form they need. In the absence of reliable iOS split tunneling, full tunneling is both simpler and more airtight. The guide on automating tasks on iPhone with Shortcuts touches on iOS-specific app behavior that is similarly worth understanding in this context.

Verification Steps After Configuration

After any split tunneling configuration change, two verification steps are non-negotiable. First, run a DNS leak test with the VPN active and split tunneling configured. The test should show only DNS servers associated with your VPN provider, if it shows your ISP’s DNS servers, DNS leak protection is not working correctly. Second, run an IP address check from inside one of the apps you have placed inside the VPN tunnel, using a tool like ipleak.net. The displayed IP should match your VPN server’s IP, not your home ISP’s IP. If it does not, the app is not routing through the tunnel as configured.

Split Tunneling vs. Full Tunneling: The Honest Trade-Off

The honest answer about which configuration is better for health users is not the balanced “it depends on your use case” conclusion that most VPN guides arrive at. Full tunneling is the safer default for anyone who regularly accesses health portals, conducts telehealth appointments, or syncs sensitive medical records on their device. Split tunneling earns its place in specific, clearly justified situations, not as a general convenience setting.

The Performance Case Is Weaker Than VPN Marketing Implies

VPN providers market split tunneling partly as a solution to speed degradation, and that framing overstates how severe the speed impact of full tunneling actually is with modern protocols. WireGuard-based VPN implementations are substantially faster than the older OpenVPN protocol, and on a quality home broadband connection, the latency overhead of a full-tunnel WireGuard VPN is often imperceptible for most tasks, including HD video streaming. The performance case for split tunneling is most defensible on genuinely slow connections, on high-latency networks, or with older VPN clients still running OpenVPN by default.

The speed trade-off that does deserve acknowledgment is real-time video call quality. A live telehealth appointment is more latency-sensitive than video streaming, because buffering is not available, any packet delay is immediately perceptible as a lag in the conversation. On a slow connection or with a geographically distant VPN server, full tunneling can introduce enough added latency to affect call quality noticeably. That is the most legitimate use case for excluding a telehealth video app from the tunnel, and even then, it applies only when the platform’s own encryption provides adequate protection for the session content.

The Misconfiguration Risk Is Concrete and Documented

The security gaps introduced by misconfigured split tunneling are not hypothetical. They include unencrypted traffic exposure on hostile networks, DNS query leakage revealing sensitive health-related domain visits, and the browser-tab trap that exposes health credentials through what appears to be a performance-only decision. NIST SP 800-46 Rev. 2 advises organizations to model threats carefully before deploying split-access architectures, specifically because tunneling solutions protect communications between the client and VPN gateway but do not protect communications beyond the gateway. For individual users without IT support, threat modeling before configuration is rarely done.

Split tunneling is not a flawed technology. It is a technology that requires more deliberate configuration than most users apply to it, and the consequences of under-configuration fall disproportionately on the data categories that health users care most about protecting. The recommendation here is not to avoid split tunneling categorically, but to start with full tunneling as the default and add narrow, justified exceptions only after you have understood what you are actually doing with each exclusion.

Emerging State Laws and Consumer Health Data

The regulatory context for consumer health data has expanded substantially beyond HIPAA in recent years. Fitness apps, wearable devices, mental health platforms, and nutrition trackers, the exact category of apps that split tunneling decisions typically affect, operate largely outside HIPAA’s coverage because they are not provided by covered healthcare entities. That gap has increasingly attracted state-level legislative attention.

Washington, Nevada, California, and the FTC

Washington State’s My Health My Data Act, Nevada SB 370, and California AB 352 all impose requirements on companies collecting consumer health data outside of HIPAA’s scope, covering categories including heart rate, sleep data, reproductive health information, and location data when associated with health services. These laws give consumers new rights around data collection consent and deletion, but they place the compliance burden on the companies, not the individual user.

The updated FTC Health Breach Notification Rule similarly expanded its scope to cover health apps and connected devices, requiring notification when health data is breached or shared without authorization. These regulatory developments are relevant to split tunneling decisions because they confirm that the health data collected by fitness apps and wearables is legally recognized as sensitive, even though HIPAA has never covered it. If that data is transmitted outside a VPN tunnel on an untrusted network where it could be intercepted, any resulting breach falls within these laws’ scope.

What This Means for Your VPN Configuration Decisions

The practical implication is that the category of health-adjacent apps worth routing through the VPN is broader than most users initially assume. A fitness tracker syncing heart-rate data, a period-tracking app transmitting cycle information, or a sleep-monitoring service sending biometric data all carry information that multiple legal frameworks now classify as requiring protection. Excluding these apps from the VPN tunnel for convenience makes a legal and privacy trade-off that users increasingly should make consciously, not by default. Understanding how spyware operates on mobile devices is a related concern for anyone handling sensitive health data on their phone, since VPN protection is meaningless if the device itself is compromised.

Your Action Plan

1. Audit every app on your device before touching the VPN settings

   List all apps on the device you will configure. Assign each one a category: sensitive (any app that touches health credentials, health records, mental health sessions, pharmacy data, or insurance accounts) or low-sensitivity (streaming, weather, games, food delivery). Do this before opening the VPN client, not after. The routing decisions should follow the inventory, not the other way around.

2. Choose inverse split tunneling as your starting point if your VPN supports it

   Configure your VPN to route all traffic through the tunnel by default, then explicitly add only low-sensitivity apps to the bypass list. This is the safer default for health-conscious users, it means accidental omissions leave apps protected rather than exposed. If your VPN does not support inverse tunneling, start with full tunneling and add specific exclusions only after the steps below are complete.

3. Never exclude a general-purpose browser from the VPN tunnel

   If you want a faster non-VPN browsing experience for genuinely non-sensitive tasks, install a dedicated secondary browser and use it exclusively for that purpose. Keep your primary browser, the one you use for any health portal, pharmacy login, or insurance account, inside the VPN tunnel at all times. App-level routing rules see the browser application, not individual tabs. There is no configuration that selectively protects some tabs within the same browser instance.

4. Enable DNS leak protection in your VPN client and verify it is working

   Find the DNS leak protection setting in your VPN app and confirm it is active. It is often disabled by default. After enabling it, run a DNS leak test at a tool like dnsleaktest.com with your VPN connected and split tunneling configured. The results should show only DNS servers associated with your VPN provider. If your ISP’s DNS servers appear, DNS leak protection is not functioning correctly, and sensitive domain queries are visible to your ISP regardless of which traffic stream those apps are assigned to.

5. Switch to a modern VPN protocol before concluding that full tunneling is too slow

   Many consumer VPN clients default to OpenVPN for compatibility reasons. WireGuard is significantly faster and introduces substantially less latency overhead. Before deciding that full tunneling degrades performance enough to justify split tunneling, switch your VPN client to WireGuard (or your provider’s equivalent, such as NordLynx or Lightway) and re-test your connection speed and video call quality. The performance gap that prompted the split tunneling decision often disappears with the protocol change.

6. Disable split tunneling entirely on any untrusted network

   Configure your device or VPN client to enforce full tunneling whenever you are connected to a network you do not control: airports, hotels, gyms, cafés, conference centers. Some VPN clients support a “trusted networks” feature that can automate this. If yours does not, make a habit of manually disabling split tunneling before connecting to any public Wi-Fi. The threat model on an untrusted network is categorically different from a home connection, and any traffic outside the tunnel is exposed to the full range of attacks that shared networks enable.

7. Run an IP leak test from inside your sensitive apps after configuration

   After completing your split tunneling setup, use an IP address checker (such as ipleak.net) from within the apps you have designated as VPN-routed. The displayed IP address should match your VPN server, not your home ISP. If it matches your ISP, the app is not routing through the tunnel as configured. Do this test after any VPN client update or device OS update, because updates can reset VPN settings to defaults without notification.

8. If you handle ePHI professionally, address the BAA gap separately

   The steps above substantially reduce transmission security exposure for individual health users. They do not solve the compliance issue created by using a consumer VPN without a Business Associate Agreement for workflows that touch ePHI. If you are a healthcare worker, telehealth provider, or clinical administrator, consult with your practice’s compliance officer or IT team about enterprise or healthcare-specific VPN solutions that offer BAA coverage. This is a structural compliance requirement that configuration changes to a consumer VPN product cannot resolve.

Frequently Asked Questions

What exactly does VPN split tunneling do to my internet traffic?

Split tunneling divides your outbound traffic into two streams based on rules you configure. One stream travels through your VPN’s encrypted tunnel and exits through the VPN server, so websites and services see the VPN server’s IP address rather than yours. The other stream goes directly from your device to the internet without any VPN encryption, routing, or IP masking. Both streams run simultaneously while your VPN is active, which is why split tunneling does not mean “VPN is off for some apps”, it means “VPN is selectively active, and the selection is determined by your configuration, whether or not that configuration reflects your actual risk model.”

Is split tunneling safe for everyday use?

It depends on the precision of the configuration and the network you are on. On a trusted home network, with inverse split tunneling configured (all traffic through VPN by default, narrow low-sensitivity exceptions), DNS leak protection enabled, and no browsers excluded from the tunnel, split tunneling is generally safe for everyday use. On a public Wi-Fi network, or with a permissive configuration that excludes entire browsers or entire categories of apps, split tunneling creates concrete exposure that most users underestimate.

Can split tunneling make my VPN faster?

It can, in specific circumstances. Routing bandwidth-heavy apps like video streaming directly rather than through the VPN server removes those apps from the VPN’s processing overhead and reduces latency for them. The practical speed benefit depends heavily on which VPN protocol you are using. WireGuard-based protocols are fast enough that the difference is often negligible on modern hardware and a quality broadband connection. OpenVPN-based clients are slower, and split tunneling can produce a more noticeable improvement there. Before using split tunneling primarily for speed reasons, switch to WireGuard and re-test, it frequently eliminates the performance gap that prompted the split tunneling decision in the first place.

Does split tunneling protect my health app data?

Only if those health apps are explicitly routed through the VPN tunnel in your configuration. If they are excluded from the tunnel, either directly, or indirectly because they run inside a browser that is excluded, they are not protected by the VPN at all. Health app data that bypasses the tunnel on a public network is exposed to the same risks as any unprotected connection on that network. HTTPS encryption on the app or website protects the content, but does not protect metadata (which server you connected to, when, and for how long), and does not protect against all forms of network-level attack.

What is a DNS leak and why does it matter for health privacy?

A DNS leak occurs when your device sends DNS queries, the lookups that translate domain names into IP addresses, to your ISP’s DNS servers instead of your VPN provider’s encrypted DNS resolver, even while the VPN is active. The content of a health portal session may be protected by HTTPS, but a DNS leak reveals to your ISP that you looked up the domain for a mental health clinic, a reproductive health provider, or an addiction treatment service. That domain-level information is sensitive regardless of what page content was encrypted. DNS leaks in split tunneling configurations are common when DNS leak protection is disabled in the VPN client, which is the default in several major consumer VPN apps.

Does VPN split tunneling work on iPhone?

It works on some VPN providers’ iOS apps, but with meaningful limitations compared to Windows and Android. Apple’s network extension architecture restricts how VPN clients can implement app-level routing on iOS, and many major providers either do not offer split tunneling on iOS or offer a reduced version with fewer options. If you rely on an iPhone for health-related work or telehealth, verify your specific VPN provider’s iOS documentation before building a security configuration that depends on split tunneling being available there. Full tunneling on iOS is both more reliable and simpler to audit.

Should a healthcare worker use split tunneling to access an EHR system?

Only with administrator-enforced policy controls that lock the EHR and all clinical app traffic inside the VPN and prevent user modification of those rules, not with a consumer VPN where the split tunneling configuration is user-adjustable. Consumer VPNs do not offer the policy-enforcement controls that HIPAA-compliant remote access requires. Consumer VPN providers do not sign Business Associate Agreements, which are legally required before a vendor can handle ePHI on behalf of a covered entity. A healthcare worker accessing EHR systems remotely should use an enterprise or healthcare-grade VPN solution that their organization’s IT department has configured and approved, not a personal subscription-based consumer VPN.

What is inverse split tunneling and how is it different from regular split tunneling?

Standard (or “forward”) split tunneling routes selected apps through the VPN and sends all other traffic directly. Inverse split tunneling reverses that logic: all traffic goes through the VPN by default, and you explicitly list the specific apps or domains that are permitted to bypass the tunnel. Inverse tunneling is the safer default for health-conscious users because accidental omissions, apps you forgot to classify, remain protected rather than exposed. It is available in several major VPN clients but is often not the default mode; users must look for a “bypass” or “inverse” mode setting rather than the standard “include/exclude” interface.

How do I know if my split tunneling is configured correctly?

Two verification tests are the minimum acceptable check after any configuration change. First, a DNS leak test (from a service like dnsleaktest.com) while the VPN is active and split tunneling configured, the results should show only your VPN provider’s DNS servers, not your ISP’s. Second, an IP address check from within one of the apps you have placed inside the VPN tunnel, the IP should match your VPN server’s address, not your home connection’s address. Run both tests again after any VPN client update, device OS update, or configuration change, since updates can silently reset settings to defaults.

Do state health privacy laws affect what I should route through my VPN?

Indirectly, yes. Laws like Washington’s My Health My Data Act, Nevada SB 370, and the updated FTC Health Breach Notification Rule classify data from fitness apps, wearables, and consumer health tools as legally sensitive, even though HIPAA does not cover them. That legal recognition reflects the genuine sensitivity of heart-rate data, location data associated with health facilities, sleep information, and reproductive health tracking. It is a reasonable signal that the apps collecting this data deserve to be inside your VPN tunnel rather than excluded for convenience, particularly on untrusted networks where that data could be intercepted.