Split Tunneling vs. Full Tunneling: Which VPN Setup Is Best?

What is full tunneling?

Full tunneling, also called a full tunnel or sometimes force tunneling, makes the VPN the usual path for internet traffic within the connection’s scope. A device-wide client generally aims to cover the device; a browser extension generally covers supported browser traffic. The words “all traffic” must therefore be read alongside what the software actually controls.

The device still needs a physical network connection to reach the VPN endpoint. It sends protected tunnel packets over that connection, and the gateway forwards the inner traffic onward. Full tunneling does not mean the Wi-Fi adapter stops carrying packets. It means the application traffic is normally carried inside the VPN rather than sent directly to its destination.

What is VPN split tunneling?

Split tunneling assigns different traffic to different paths. A business VPN might send internal company destinations through the corporate gateway while sending public internet traffic directly. A personal VPN app might tunnel most traffic but exclude one selected app. Both are split configurations, even though their defaults are opposite.

An excluded connection does not receive the VPN tunnel’s protection on its direct path. It may still use HTTPS or another encrypted application protocol. “Outside the VPN” and “unencrypted” are therefore different statements. The direct connection also normally uses the ordinary network’s outward IP address rather than the VPN exit’s address.

Read how VPNs work for the tunnel’s basic operation and VPN encryption explained for the separate question of protecting contents.

A VPN client can install routes, use operating-system filtering or apply application-aware policy. The exact mechanism varies. At the route-table level, a destination is matched against available routes. A more specific matching network generally takes precedence over a broader one; preference or metrics help select between otherwise comparable routes. Other policy layers can further constrain the result.

Default routes and specific routes

A default route covers destinations without a more specific match. IPv4 represents that broad route as 0.0.0.0/0; IPv6 uses ::/0. A full-tunnel implementation can install VPN defaults or equivalent routes and filtering. A destination-based split configuration can instead install selected networks through the VPN while retaining a direct internet default.

Microsoft’s VPN routing documentation describes Windows split and force-tunnel routing. It also notes that a more specific physical-interface route can take precedence in its force-tunnel configuration. The practical lesson is to inspect the effective policy rather than treating the mode’s name as proof that every packet follows one path.

Routes are not the entire security policy

A route describes where traffic should go. A firewall or kill switch can block traffic even when a route exists. An application-aware client may classify connections by process rather than simply adding a destination subnet. Conversely, a route can exist without the intended filtering being active. Connection status, route choice and permission to transmit are separate observations.

Local private ranges can overlap with remote company networks. If both use the same subnet, the device may select an unintended interface or be unable to reach one side. Resolve that conflict through the approved network configuration rather than adding a broad bypass that creates a new exposure.

Exclude mode: tunnel by default

In an exclusion-based setup, most covered traffic stays inside the VPN and selected apps or destinations bypass it. This is often easier to reason about for a personal device because newly installed apps normally inherit the VPN path, within the client’s scope. Each exclusion is still a deliberate reduction in VPN coverage.

For example, you might keep your browsers and messaging apps tunneled while excluding a specific game after measuring a connection problem. That rule could also affect the game’s login, chat, telemetry and update connections if they belong to the excluded process. The label “game” does not mean every connection from it is nonsensitive.

Include mode: direct by default

An inclusion-based or inverse split setup tunnels only listed traffic. Other covered apps or destinations use the ordinary connection. It can fit a narrowly scoped corporate resource or a single application, but adding a new browser or tool does not automatically add VPN coverage. Forgetting one relevant process can change the result.

Domain rules are not permanent IP lists

Modern websites use multiple domains, content delivery networks and changing addresses. A hostname may resolve differently over time or by location. A client that supports domain rules can implement them differently from a manually maintained IP list. Do not assume excluding one page’s current address reliably excludes the whole service.

A browser extension may apply domain rules only within that browser. The same site opened in a standalone app can take a different path. Review VPN versus proxy before assuming browser-level routing covers your entire device.

The best comparison starts with your objective. Broad routing coverage, access to internal resources and application performance are different requirements. A useful configuration makes those requirements explicit and gives you a way to confirm them.

Encryption strength is not a routing score

The same VPN protocol and cipher can protect a connection in either mode. A full-tunnel setting does not upgrade weak cryptography, and a split rule does not weaken the cipher for traffic that remains tunneled. What changes is which connections receive the tunnel’s protection and which use a separate path.

Convenience needs a defined exception

If one service works poorly through the VPN, identify the actual failure before excluding a whole browser. A smaller supported exception may solve the problem with less change to coverage. If the service does not support a reliable narrow rule, decide whether a separate app, a different endpoint or keeping full tunneling is the better fit.

With full tunneling, the local network normally sees the device exchanging tunnel traffic with its VPN endpoint rather than directly contacting each covered internet destination. It can still observe the endpoint, timing and volume. That does not make the device anonymous or hide every possible identifier from every observer.

What changes for excluded traffic?

An excluded application can expose its direct destination addresses and other available connection metadata to the local network and ISP. Plain HTTP or another unencrypted application protocol can expose its contents as well. HTTPS protects the application exchange against ordinary intermediaries, but it does not give that direct flow the VPN’s exit address or eliminate all metadata.

The website can still recognize accounts, cookies, browser properties and information you submit. If you use the same account through tunneled and direct connections, it may be able to associate both. Splitting paths should not be sold as identity separation.

What can a VPN operator see?

A VPN operator handles tunneled traffic and may observe information available at its network boundary. HTTPS continues to protect application contents against an ordinary forwarding operator. Directly excluded traffic normally bypasses that VPN operator, although DNS and other related connections may still follow a different policy. Review the actual architecture rather than assuming every related byte follows the app’s payload.

Our guides to VPN logging policies and VPN limitations explain provider trust and the threats routing cannot solve.

Intentional exclusions and accidental leaks

A direct connection from an intentionally excluded app is expected behavior. A direct connection from an app that your policy says must be tunneled is a routing or protection failure. That distinction matters when interpreting IP tests. Write down your intended policy before deciding whether a result is acceptable.

DNS does not necessarily follow the application rule

DNS translates names into addresses. The operating system, a browser or an application can perform the lookup. A split rule for application connections does not automatically prove where that lookup goes. Depending on the client, excluded traffic may still use the VPN’s resolver, or different namespaces may use different resolvers.

Microsoft’s VPN name-resolution documentation describes Windows Name Resolution Policy Table rules for choosing how particular namespaces resolve. This illustrates why name resolution deserves its own configuration review alongside routes. The mechanism available in a consumer VPN app may differ.

A company’s internal hostname may require an internal resolver reachable through the corporate tunnel. A public encrypted-DNS setting in a browser might not know that internal name. Conversely, using a corporate resolver for every query can reveal personal domain lookups to that resolver. Choose the supported policy that fits the intended separation.

DNS-over-HTTPS changes the resolver path, not all traffic

Encrypted DNS can protect a supported lookup’s contents on its way to a resolver. Its network connection must still take some route. It does not automatically tunnel subsequent website traffic, replace a VPN or make a split rule correct. Test your application’s actual resolver behavior rather than inferring it from a browser checkbox.

IPv4 and IPv6 need consistent treatment

A destination may be reachable over both address families. An IPv4 route or exclusion does not define what happens to IPv6 traffic. A client can tunnel IPv6, deliberately block it or implement another documented policy. The outcome should match your expectations for both tunneled and excluded connections.

A public IP test that shows only IPv4 leaves part of that question unanswered. See DNS leaks and prevention and IP leaks, WebRTC and IPv6 for the related checks.

Local access is a separate permission

Printers, storage devices and casting receivers may need direct LAN access or multicast discovery. Allowing a local subnet can help with reachability, but it does not automatically enable discovery protocols or override firewall restrictions. Check the client’s supported local-network option before excluding a large application group.

Allowing a LAN path also lets selected traffic reach that LAN. A setting appropriate for your home printer may be inappropriate on a shared guest network. Reassess local exceptions when the network changes instead of assuming “local” always means trusted.

A kill switch controls what may transmit when the intended VPN path is unavailable. Split tunneling controls which traffic uses that path while it is available. These policies must agree. A device-wide block on all non-VPN traffic can intentionally prevent excluded apps from connecting, while another implementation may allow direct exclusions and block only traffic meant to be protected.

Read the exact feature combination

Do not assume a provider has the same behavior on every operating system. Proton VPN’s current split tunneling instructions distinguish its Windows support for combining split tunneling with standard or advanced kill switch from compatibility limitations on most other platforms. That is a product-specific example, not a universal rule for VPNs.

Android’s VPN documentation describes per-app allowed or disallowed lists and its option to block connections without a VPN. It warns that apps outside the allowed VPN path lose network access when non-VPN connections are blocked. An excluded app that stops working under this policy is not necessarily malfunctioning.

Manual disconnect and unexpected failure differ

Some switches protect only an unexpected interruption; stricter modes may also block traffic after a deliberate disconnect. Startup, sleep, network switching and app crashes are additional transitions. Test those that matter to your use, and document which apps should be blocked and which should remain direct.

Full tunneling without effective failure blocking can also fall back to an ordinary connection. The full-tunnel label alone is not a kill switch. Read how VPN kill switches work before relying on either routing mode for continuity of protection.

In a business environment, full tunneling can provide a common gateway for internet traffic from remote devices. That can support centralized monitoring, access controls or filtering when those systems are actually deployed. Routing through a company gateway does not automatically mean every connection is inspected or every threat is blocked.

Why organizations choose split tunneling

A company may tunnel only internal resources to reduce gateway load or avoid sending public cloud traffic through a distant office. That design should account for endpoint protection, identity controls, data handling, resolver policy and the organization’s visibility requirements. Direct access is a planned architecture choice, not simply a speed setting for an employee to enable.

Simultaneous access creates a boundary to manage

A device connected to both a local network and corporate resources can be exposed to multiple environments at once. Split tunneling does not automatically turn it into a packet-forwarding bridge, but a compromised endpoint can still abuse the access available to it. Host firewalls, application controls, patching, least privilege and segmentation remain relevant.

Full tunneling also does not repair an infected endpoint or guarantee isolation from its local network. The security assessment should consider what the device can access and transmit, rather than using routing mode as a complete endpoint defense.

Work privacy and personal browsing

A corporate exit or resolver can create visibility into traffic that traverses it, subject to encryption and actual monitoring. A split configuration may keep some internet flows off that gateway, but it does not remove management software, browser policy or device telemetry. Use the organization’s approved tools and account boundaries instead of treating split tunneling as a way to make a managed device private.

Choose the mode by the traffic that needs coverage and the exception you need to solve. The following scenarios are decision examples, not promises about a particular service’s compatibility or speed.

Gaming and calls

Direct routing can avoid an unnecessary detour, but an ISP path can also be congested or less favorable than the VPN route. Compare latency, jitter, loss and application behavior instead of judging only download speed. If you exclude a voice client, its signaling and other connections may also use the direct path.

Streaming, banking and region-sensitive services

Some services react to VPN exit reputation, account location or anti-fraud rules. A direct exception can change the outward IP used by a supported app, but it does not guarantee access, remove account checks or make every region-dependent feature work. Follow the service’s requirements and keep account security controls enabled.

Public Wi-Fi and captive portals

A captive portal may require limited local onboarding before a VPN can connect. Use the client’s supported workflow, then reestablish the intended protected policy. A temporary onboarding step should not become a permanent broad bypass. HTTPS, software updates and phishing awareness remain important in either mode.

For the broader decision, see whether you need a VPN and VPN server types. Your routing rules and selected exit serve different purposes.

Split tunneling can reduce the amount of traffic passing through a VPN gateway. That is an arithmetic consequence of moving selected traffic to another path. It does not guarantee faster applications: bandwidth, server capacity, geography, protocol, loss and competing traffic all matter.

In this example the VPN gateway carries 60 fewer application units, a 60% reduction from the chosen baseline. The underlying internet connection still carries both paths. This does not claim that total internet use falls by 60% or that the device becomes 60% faster.

Use matched conditions for a real comparison

Keep the destination, physical network and test window comparable. Record the VPN endpoint and protocol. Repeat measurements and include loss or jitter for real-time applications. A speed test in a different browser may use a different rule from the app you are trying to evaluate.

See VPN speed and latency and common VPN protocols explained for the other variables that affect performance.

A feature available on one app is not automatically available on another. Check the exact operating system, app distribution, protocol and feature combination you plan to use. Settings can change as clients evolve, so use the current instructions rather than a screenshot from a different platform.

Desktop clients

Desktop apps may offer process-based rules, address-based rules or both. A program can use helper processes, background services or shared networking components. Selecting the visible executable is therefore a configuration step to verify, not proof that every related connection has been classified.

On Linux, packaging and sandboxing can affect feature availability. On macOS, networking frameworks and app architecture can affect process attribution. Avoid assuming all desktop clients expose identical include, exclude or domain modes.

Mobile clients

Mobile operating systems provide different VPN APIs and management options. A consumer app’s interface can differ from a managed per-app corporate deployment. Check the exact supported model rather than expecting a phone to reproduce a desktop route table or app picker.

Browser extensions and routers

An extension’s exceptions usually apply within its supported browser scope. A router rule can instead affect an entire device or network segment, potentially including apps the user did not intend to split. Verify DNS and failure behavior at the layer that owns the rule.

NordVPN’s split tunneling setup guide provides platform-specific instructions, including Windows, Android and Android TV. Use the matching instructions and check your app’s current feature set before choosing it for a particular rule. Its presence on one platform does not establish support on every device.

Begin with the desired behavior in plain language. Decide which apps must use the VPN, which may connect directly and what should happen when the VPN is unavailable. This is more reliable than enabling a toggle first and trying to infer the policy afterward.

1. Confirm the scope. Identify whether the VPN is device-wide, browser-based, router-based or a managed work profile. List the apps and resources you actually need to control.
2. Choose the default path. Select full tunneling, tunnel-by-default exclusions or direct-by-default inclusions. Write the default down so new applications are not a surprise.
3. Define the smallest useful rule. Prefer a supported narrow exception over excluding an entire browser or network range without a reason. Include dependent processes where the client requires them.
4. Review DNS, IPv6 and LAN access. Record the intended resolver behavior, address-family treatment and any permitted local destinations.
5. Check kill switch compatibility. Confirm whether protected apps remain blocked during failure and whether excluded apps may stay direct. If the combination is unsupported, choose a supported policy.
6. Apply the configuration as documented. Reconnect the VPN and restart affected applications when required. Existing connections may not move paths just because a setting changed.
7. Test both sides. Check an included app and an excluded app, not only the browser you normally use for IP checks. Verify failure and recovery as well as steady-state behavior.
8. Record and review. Keep the reason for each rule and retest after app updates, network changes or VPN upgrades.

An adaptable personal policy worksheet

VPN ROUTING POLICY — EXAMPLE WORKSHEET
Scope: personal device-wide VPN client
Default: VPN for covered internet traffic
Direct exception: [specific app and reason]
Local access: [required subnet/resources, if permitted]
DNS: [documented resolver policy]
IPv6: [tunneled or blocked as documented]
Tunnel failure: protected apps must not fall back directly
Excluded-app failure behavior: [supported direct or blocked policy]
Verification: app paths, DNS, address families, drop and recovery
Review: after client updates, app changes and network changes

Use our split tunneling configuration helper to organize the decision. A worksheet describes intent; the VPN client still needs to implement and verify the actual rules.

Change one variable at a time

If you change the endpoint, protocol, DNS setting and split mode simultaneously, a successful or failed connection will be hard to explain. Save the working configuration, add one rule, test it and expand only if necessary. Keep a clear way to return to the simpler supported setup.

The VPN app’s connected indicator is useful but insufficient. It shows a tunnel state, not the route taken by every application. A browser IP check shows that browser’s observed path at that moment. It does not verify a separate excluded app, a helper process, DNS or later reconnect behavior.

Test the application that owns the traffic

When available, use the application’s own diagnostics or a controlled destination’s connection records. An excluded browser can show the ordinary exit while another browser shows the VPN exit, but that does not prove what a standalone game does. Route-table inspection is helpful for destination rules; process-based filtering may require the client’s diagnostics or more detailed observation.

Account for cached and existing sessions

DNS caches and long-lived connections can make an immediate test misleading. Follow the provider’s reconnect and restart instructions, then start fresh test sessions. A service may also retain location information from your account or cookies, so its displayed region is not a precise network-path test.

Test failure deliberately and safely

Use non-sensitive test traffic and a documented way to interrupt the connection. Check protected and excluded apps separately. Record whether a manual disconnect, an unexpected loss and a network switch produce the expected result. Do not perform a test that disrupts an active work session or remote administration connection you depend on.

For a broader checklist, see how to test your VPN. A passing observation supports the tested conditions, not a permanent guarantee across every app, network and update.

Diagnose the layer that is failing. An app that cannot connect may have a routing problem, resolver problem, blocked direct path or application restriction. Changing to a broad exclusion before identifying the cause can conceal the original issue and change coverage unnecessarily.

Return to a known working configuration

If a new rule fails, remove that rule and confirm the baseline still works. Keep the VPN endpoint and protocol unchanged while comparing. Gather the client version, operating system, rule mode, affected app and non-sensitive diagnostics before contacting support.

Do not solve a DNS or certificate error by disabling certificate validation. Do not remove a work-mandated filter to test personal preferences. Our VPN troubleshooting guide expands on separating connectivity, DNS and routing failures.

A split setup is not an anonymity system

Different exit addresses do not erase shared logins, identifiers or application data. Neither full nor split tunneling protects a compromised device from reading information before it enters the tunnel. Keep the routing decision separate from claims about identity, malware resistance or complete privacy.

Full tunneling is usually the clearer choice if you want broad personal VPN coverage and have no specific bypass requirement. Split tunneling is useful when the exception has a defined purpose, the client can implement it reliably and you accept the direct path’s visibility. Neither choice removes the need to test the surrounding protections.

• Purpose: Is the goal broad coverage, a company resource, one VPN-bound app or a particular direct exception?
• Authority: Is this a personal choice, or does a managed-device policy determine the route?
• Default: Should a newly installed app automatically use the VPN or the direct connection?
• Rule precision: Can the client express the exact app, address or domain scope you need?
• Dependencies: Have you considered helpers, shared processes, DNS and both address families?
• Failure: Which traffic should stop if the VPN is unavailable, and is that combination supported?
• Evidence: Have you tested the affected app rather than merely a separate browser?
• Maintenance: Will you review the rules after updates, app changes and network changes?

If you cannot answer those questions, start with the simpler supported configuration and avoid adding broad exceptions. If full tunneling causes a concrete problem, diagnose it and introduce the smallest verified split rule that meets your need.

Full tunneling and split tunneling are routing strategies. Full tunneling offers a broad default that is usually easier to understand when you want VPN coverage across a personal device. Split tunneling gives you controlled direct paths or selective VPN paths, which can improve compatibility or reduce gateway demand when carefully configured.

The best VPN setup is the one that matches your purpose and behaves as expected. Choose the default explicitly, keep exceptions narrow, check DNS and IPv6, and verify the kill switch combination. Measure performance rather than assuming direct routing is faster. For work connections, follow the approved profile and let the administrator resolve conflicts.