VPN split tunnelling: choose an exception and check its limits

Split tunnelling lets you use a VPN for some traffic while allowing other traffic to take a different route. A consumer VPN app may let you exclude a particular application, or offer a different selection method. The exact options depend on the provider, app and operating system.

An exception can help when a service does not work through your VPN. It also changes which traffic uses the VPN connection. Start with the smallest exception that solves a defined problem, and check the provider’s current instructions for your device before enabling it.

This article explains a verification method based on published documentation. It is not a report of hands-on speed, leak or reliability testing.

Decide what you are willing to send outside the VPN

Suppose a fictional home user can reach a service only through their ordinary connection. They consider excluding a browser from the VPN. If the setting excludes the whole browser, every site opened in that browser may use the exception, including a tab opened later for another purpose.

That is a broader decision than excluding one website. A browser extension, another user profile and a desktop VPN app may also affect different traffic. Do not assume the same setting applies to all of them.

Traffic outside the VPN does not use the VPN’s exit address for that route. However, HTTPS still encrypts the connection between the browser and the website when properly established; Mozilla’s HTTPS explanation describes that separate protection. Neither HTTPS nor a VPN makes a misleading website trustworthy, and signing into an account can identify you regardless of the IP address shown.

For a work device, ask the responsible IT team before changing routing. An organisation’s requirements and managed settings may differ from a personal VPN configuration.

Read the platform section, not just the feature name

“Supports split tunnelling” is not enough detail to choose a subscription. Find the documentation for your operating system, application type and installation method. Record the app version so you know what the instructions refer to.

As a concrete example, Mullvad’s split-tunnelling documentation, checked on 9 November 2026, describes support on Windows, Linux, macOS and Android, with platform-specific restrictions. It identifies Safari and other WebKit-based apps as unsupported for exclusion on macOS. It also explains that Android’s “Block connections without VPN” setting prevents excluded apps from connecting.

These are documented limitations of that product, not rules for every provider. Use your own provider’s current platform page rather than copying a setting from an unrelated guide. An app update or operating-system change is a reason to check again.

Check DNS separately from the public IP address

DNS translates a name such as a website address into connection information. Its route need not follow the same simple included/excluded distinction as application traffic.

For example, Mullvad documents that excluded apps normally still use its DNS while connected, unless the app handles DNS in a different way. A browser’s secure-DNS settings may therefore matter to the result. Do not describe every excluded app as automatically sending all DNS outside the tunnel, or assume that seeing the expected public IP proves the DNS arrangement.

If your reason for using a VPN depends on a particular DNS or routing guarantee, ask the provider how that guarantee interacts with exclusions on your device. A generic feature label cannot answer it.

Run a narrow comparison with harmless traffic

Here is a proposed check for the fictional user, where their provider supports excluding one browser. It is not a claim that we performed the test:

1. Record the VPN app, operating system, browser and chosen exclusion.
2. Connect the VPN and open the provider’s connection-check page in a browser that should remain inside the tunnel.
3. Open the same check in the excluded browser, following any restart or launch instructions in the provider’s guide.
4. Compare the reported connection with the intended routes. Then try the specific service that prompted the exception.
5. Close unnecessary tabs and remove the exception if it does not solve the problem.

A different public IP is evidence about the tested request. It does not prove the behaviour of every app, background process, DNS request or future connection. Likewise, a service loading successfully does not demonstrate anonymity or a speed improvement.

Record what should happen when the VPN stops

Look up how the provider’s kill switch or lockdown mode interacts with excluded apps. Do not assume a protection intended for tunnelled traffic also blocks deliberate exceptions. Where the provider documents a safe disconnection check, use non-sensitive traffic and record the expected and observed behaviour.

Keep a short note: why the exception exists, what it covers, what remains uncertain and when to review it. Review after changing devices, updating the VPN or switching provider. If the original compatibility problem has disappeared, remove the exception and confirm that the ordinary VPN route works again.