Split Tunneling Not Working? Troubleshoot It

Split tunneling is supposed to be simple: you pick which apps or addresses go through the VPN and which use your normal connection. When it works, your banking app stays on the ordinary route while the rest of the phone is protected. When it does not, you get the opposite of what you asked for. An app you excluded still shows the VPN address, an app you wanted protected leaks onto the ordinary network, or a local device such as a printer disappears.

This guide is for people whose rules exist but do not behave. It is not an introduction to the idea; for that, read what split tunneling is. Here we start from symptoms, show how to test one app at a time, and work through the usual causes, then the differences between Windows, Android, iPhone and Mac.

First, check which kind of split tunneling you have

"Split tunneling" is a label covering several different mechanisms, and most failures come from expecting one behaviour while the app implements another.

Type	How it decides	Typical wording
App-based, exclude	Chosen apps skip the VPN, everything else uses it	"Bypass VPN for selected apps"
App-based, include	Only chosen apps use the VPN, everything else skips it	"Use VPN only for selected apps"
Route-based	Chosen networks or addresses use the tunnel	"Allowed IPs", "routes"
Domain-based	Chosen website names follow a rule	"Domain rules"
Local network exception	Home addresses stay outside the tunnel	"Allow LAN", "local network access"

Before changing anything, find out what your own app offers. Settings screens differ between apps and platforms, and some do not offer split tunneling at all. If you cannot find an option, that is the answer, and you should not try to force it with extra tools.

The most common misunderstanding is mixing up the two app-based modes. If your list is in "include" mode, adding your banking app to it routes the banking app through the VPN, which is the reverse of what you wanted. Read the heading above the list again and confirm what it means.

A simple test: prove what each app is doing

Never trust the settings screen alone. Test the real behaviour.

1. Disconnect the VPN and open an IP-checking page in the app or browser in question. Write down the address shown. This is your normal address.
2. Connect the VPN with no split rules and check again. The address should now be different. Write it down. This is the tunnel address.
3. Add your rule, then fully close and reopen the app you are testing, and check again.
4. If an excluded app shows the tunnel address, or an included app shows the normal one, the rule is not being applied.

Use at least two different apps for the check, such as two browsers, because one app may follow the rule while the other ignores it. Remember that a browser reports the address of the connection it is using, while a game or a chat app might use a separate channel. For simple apps without a page to open, the next best test is whether a site that rejects the tunnel address now works.

This test also teaches you about timing. Many VPN apps apply new rules only when the next connection is opened. Existing connections inside the app can stay in the old path until restarted.

Five common causes and their fixes

Cause 1: The app starts through a helper or another file

Modern apps rarely use one single program. A chat app may start a helper for calls. A browser opens many processes. A game launcher starts the game as a second program with a different file name. If your VPN picks apps by file, the rule applies to the file you chose and not to the helper that actually sends the data.

What to do:

• Add the main program and any visible helper or launcher to the list.
• Restart the app and then the VPN after every list change. A restart makes the VPN re-read the rules.
• If an app is a packaged or store app, look for how your VPN app lists those; some choose them differently from classic programs.
• For a launcher plus game case, test with the launcher closed and the game started alone, then the other way round.

Do not hunt for obscure files in system folders. If an app has helpers you cannot identify, try the exclude route at the network level instead, or turn the VPN off briefly for that session.

Cause 2: DNS lookups still use the other path

Even when app traffic follows your rule, the name lookup that comes before it may not. If an excluded app asks the VPN's DNS to resolve a name, the app might receive an address that is meant for the tunnel, or it might be slower or fail to find a local service. In the other direction, an included app may send DNS questions to your internet provider and show them to the local network.

Symptoms are a site that works in one browser and not the other, a work server name that cannot be found, and pages that load slowly at first. VPN split DNS explains why name resolution follows its own rules. For the basics see how DNS works.

What to do:

1. Restart the app after you change the rule so cached lookups are cleared.
2. Try opening the site by its address instead of its name, if you know it. If that works, it is a DNS issue.
3. Check whether your VPN app has a DNS option. Keep defaults unless support suggests otherwise.
4. Clear the browser's DNS cache or restart the device.

Cause 3: IPv6 slips past the rules

Some networks use IPv6 alongside IPv4. If the rules or the tunnel cover only IPv4, an app can reach a site over IPv6 on the normal connection and appear to ignore the VPN. The address shown on an IP-checking page might be an IPv6 one that does not match what you expected. The IPv6 specification describes why both address families exist side by side.

Check by looking at both addresses on the test page, if it shows two. If the IPv6 one is your ordinary address while the IPv4 one is the tunnel's, the rule is working only partly. See VPN IPv6 leaks for details, and consider turning IPv6 off on the network adapter as a test. Do this only if you are comfortable changing network settings, and write down the original value so you can restore it.

Cause 4: Local network devices unreachable

A common complaint is "my printer, TV or NAS vanished when the VPN is on". Devices at home use private addresses such as those in the ranges described in RFC 1918. When all traffic goes into the tunnel, a request for a private address may travel to the VPN server, which has never heard of your living-room printer.

Options, from simplest to most involved:

1. Look for an Allow local network or LAN access option in the VPN app and turn it on.
2. Use split tunneling to exclude the one app that talks to the device, such as a printer utility or a casting app.
3. Turn the VPN off while you print or cast, then turn it on again.
4. On a phone, check that the app has the local network permission, because the operating system may block it separately.

Be careful with the reverse risk. Allowing local access means that nearby devices on the same network can still reach yours. On public Wi-Fi, keep this option off unless you must use it, since shared networks are the setting where isolation matters most.

Cause 5: Rules saved but not applied

Sometimes the list looks right and nothing changes. Common reasons:

• The VPN was connected when you edited the list, and it only reads rules at connection time. Disconnect, then reconnect.
• The device went to sleep or switched network, which silently restarted the tunnel with a default state.
• Battery saver or an aggressive background-limit setting stopped the VPN's helper from running.
• Another app on the device, such as a second VPN, a security suite or a work profile, has taken control of routing. Only one can own the default route.
• An update changed or reset the saved list. Open the list again and compare.

A neat method: after you change the rule, disconnect the VPN completely, wait ten seconds, reconnect, and repeat the earlier IP test. If that fixes it, you have found a timing issue and not a broken rule.

What differs by device

Behaviour varies by platform, so match the advice to what you use.

Windows. Rules often depend on the program file path. Different installed copies, or an app updated into a new folder, can break a rule that used to work. Read split tunneling on Windows for details. Security suites and the Windows firewall may also interfere, so check those if the rule looks right but nothing changes.

Android. The app list is usually by installed app, which is cleaner than files. Problems arise from work profiles, from apps that open links in a different browser, and from battery restrictions. See Android VPN split tunneling.

iPhone and iPad. iOS limits how VPN apps can pick apps. Some VPN apps offer domain or network rules rather than a per-app list, and some offer none. Do not assume an Android-style list exists. If you cannot find one, treat the lack as a platform limit.

Mac. The Mac has system extensions and permission prompts that must be approved before a VPN can steer traffic by app. If a prompt was dismissed, rules do nothing. See Mac VPN split tunneling.

Everyday scenarios

A banking app that refuses the VPN. Lena excluded her banking app but still sees a warning. She finds that the bank's app opens its login in the system browser, which is not on the exclude list. She briefly turns the VPN off for banking on her phone's mobile data, then turns it on again. Excluding the browser would defeat the purpose, so she does not.

A remote worker with a work portal. Karim needs his company portal to see the company network and everything else to use the VPN on cafe Wi-Fi. His list was in "include" mode and held only the browser, so the portal opened through the tunnel and was refused. After he moved to route-based rules supplied by his employer's IT team, the portal worked.

A family with a streaming stick. The family cast videos from phone to TV. With the VPN on, the TV vanished from the casting menu. Enabling local network access in the VPN app fixed it, and they left it off on trips.

Limits and good habits

• An excluded app has no tunnel protection. Do not exclude apps just because it is convenient.
• Split tunneling does not guarantee that a site's access rules or checks will behave differently.
• Keep your list short. Long lists are hard to audit, and mistakes hide in them.
• Re-test after each operating system or app update.
• Keep a written note of the original settings before you change network options.
• If a setting is unclear, leave defaults alone and ask support rather than experimenting on a shared device.

Summary

When split tunneling does not work, first confirm which type your app offers, then prove what each app is doing with a simple address test. The usual culprits are helper processes, DNS lookups, IPv6, local-network access, and rules that are saved but only read when the VPN reconnects. Platform differences matter, and some devices simply do not offer a per-app list. Fix one cause at a time, re-test after each change, and remember that an excluded app is not protected by the VPN.

If you want a simple prepaid setup to test these steps on your own devices, the download page has the official apps and the pricing page shows the passes.