What is split tunneling

Split tunneling is a VPN feature that lets you decide which traffic goes through the VPN and which goes through your normal connection. By default, a VPN sends everything through the tunnel. Split tunneling carves out exceptions.

The setup is rule-based: typically per-app (this browser uses the VPN, that game client doesn't) or per-domain (corporate intranet bypasses the VPN, everything else uses it).

When split tunneling makes sense

A few real use cases:

• Local network services. Your printer, NAS, or smart home hub on the LAN. If everything goes through the VPN, your laptop talks to those devices via a route through Frankfurt and back. Not what you want for a printer ten feet away.
• Banks and apps that block VPNs. Some apps refuse to work over commercial VPN IPs (banking apps especially). Split tunneling lets those apps go direct while the rest of the system stays tunneled.
• Gaming. A VPN adds latency. Latency-sensitive multiplayer games run better direct. Browsing and downloads can still go through the VPN. Read more in VPN for gaming.
• Development. Local dev servers, container networks, VPN for developers workflows that need direct access to specific cloud resources.

What split tunneling costs

Anything outside the tunnel sees your real IP, leaks DNS to your ISP, and is subject to whatever filtering your local network does. So:

• A leak by design. If you put your browser outside the tunnel, your ISP sees every site you visit. That's the trade-off you're making.
• Kill switch interaction. Real kill switches block all non-tunnel traffic when the VPN drops. Split-tunneled apps are non-tunnel traffic. The kill switch has to know which is which, or split tunneling cancels kill switch protection.
• DNS leakage. Split-tunneled apps use the system resolver. If you wanted DNS-only privacy via the VPN, split tunneling defeats it for those apps.

How to think about it

Split tunneling is useful for narrow, deliberate exceptions. It's a bad default. The mental model: "the tunnel is on for everything, except these specific apps where I have a specific reason to bypass."

If you find yourself routing most of your apps outside the tunnel, you've inverted the model — better to disconnect the VPN and use it only when needed than to maintain a leaky exception list.

Status on Fexyn

Split tunneling is on the roadmap for the Windows app. It isn't shipping yet — the helper service architecture supports per-app routing, but the UI and the rule engine to expose it cleanly are in progress. The current model is all-or-nothing: connected means everything tunneled, disconnected means nothing.

For users who need per-app routing today, the workaround is connecting and disconnecting around specific tasks. Not elegant, but it's honest about what the product currently does.

When split tunneling lands, it'll be wired through the helper service so the kill switch keeps working — split-tunneled apps continue working when the VPN drops, while still-tunneled apps are blocked rather than leaked.

Try Fexyn free for 7 days — the rotation engine and kernel-level kill switch are the priorities; split tunneling joins them when it's ready.