A full VPN tunnel treats a printer ten feet away exactly the way it treats a server on the other side of the planet — both disappear behind the same encrypted wall. That's the whole tension behind split tunneling on a home network: you want your outbound traffic locked down, but you still need your laptop to find the NAS, the printer, and whatever smart-home gadget got plugged in last week.
Short answer, since this comes up constantly: split tunneling does solve that problem, but only when the client lets you exclude by IP range instead of just by named app, and only when excluding that range doesn't quietly break the local device discovery your printer and NAS depend on. That second failure mode trips up more setups than people expect, mine included.
What Split Tunneling Actually Solves at Home
Two years of running a dozen-plus VPN clients side by side taught me that split tunneling means slightly different things depending on which settings menu you're standing in. At its core it's routing logic: you tell the app that a specific program, or a specific block of addresses, skips the encrypted tunnel and talks to the local network directly, while everything else — browser traffic, background sync, the usual noise — still goes out encrypted through the VPN server. Nothing about that is exotic. It's the same idea as a HOV lane, minus the guilt of driving solo in it.
Home networks make this necessary in a way that office networks mostly don't, because home networks are full of devices that only work through local discovery — not through a server address you can type in manually. My neighbor homebrews IPAs and runs a kegerator in the garage, with a temperature probe that phones into an app over the LAN; my own setup has a NAS, a printer, and a couple of smart plugs that behave the same way. A fully tunneled VPN doesn't just protect that traffic, it erases the devices from view entirely, which is fine for twenty minutes and unlivable by day three.
None of this requires deep networking expertise, which is the whole point — you shouldn't need to be an IT admin just to keep a printer visible. Running the VPN at the router level instead of on individual devices sidesteps a lot of this splitting question entirely, but that's a bigger weekend project than most people want to take on just to keep a Chromecast working.
App-Based Splitting vs. IP-Range Splitting
Every client I've tested offers app-based exclusion, and it's the version most people reach for first because the settings screen makes it look simple — check a box next to the app, done. The problem shows up with anything that isn't a single, well-behaved application: a NAS discovered over multiple protocols, a smart plug that talks through a hub app, a printer your OS finds through its own service rather than a dedicated client. App-based rules only catch traffic the VPN can actually attribute to that one process, and a lot of local hardware doesn't cooperate with that assumption.
IP-range exclusion is blunter, and for home use it's usually the more reliable option — you tell the VPN to leave the whole 192.168.0.0/16 block, the same local network range your router hands out by default, outside the tunnel entirely. Every device sitting on that range becomes reachable regardless of which protocol it happens to be using, which is the real advantage over picking apps one at a time.
That bluntness has a cost, and it's worth separating split tunneling from a couple of adjacent problems it gets confused with. What protocol a given app negotiates once it's inside the tunnel is a separate question — I get into that across five VPNs over 30 days of speed testing, and it's not something the split itself controls. It's also not the same issue as needing a dedicated IP for remote access into your own network — that's a different piece of infrastructure entirely. And it's not a substitute for setting up port forwarding if you're moving large files in and out — conflating the two is a good way to leave both half-configured.
Incognito Mode Never Hid Your IP Address
For longer than I'd like to admit, I assumed Chrome's incognito mode was doing something to protect my IP address from the sites I visited — some quiet routing trick running underneath the private-browsing label. It wasn't. Incognito just means your own browser stops keeping a local record of where you went; every site you hit still sees the exact same IP address, private window or not.
That mix-up is common enough to be worth naming directly: incognito mode, a full VPN tunnel, and a browser-only proxy extension are three different tools solving three different problems — a proxy extension only touches traffic inside that one tab, not the rest of your machine, which is a distinction split tunneling doesn't need you to worry about at all.
Watching a Reader's NAS Stay Exposed
A reader named Darby Kuang emailed in after an earlier piece on this exact setup, describing a NAS that stayed reachable from its public IP even though the app was supposedly excluded from the tunnel. The message came with three paragraphs of structured log output and a repro step anyone could follow, which is rarer in a cold email than you'd hope. The cause turned out to be exactly the app-versus-range distinction above: the client only excluded the process it recognized as "the NAS app," and the NAS was also being reached through a protocol that process didn't own. Switching the exclusion to the IP range fixed it in minutes.
Darby pushed back on the fix, reasonably — pointed out that telling an individual client to exclude a range doesn't map cleanly onto an office network, where routing policy sits with IT rather than with whoever's laptop is asking. Fair point, and it's really a threat-model-scoping question more than a VPN settings one — a home network with three devices and a single admin is a different environment than a managed corporate one. Somewhere in the middle of untangling that email thread, a drive spun up out of idle with a soft thud, dumping out another batch of log data it had been queuing — the least dramatic confirmation I've ever gotten that a fix actually worked, and also the most convincing kind. It's the same instinct that made me start logging the kill switch separately: watching that log run three straight days without a single dropped packet told me more than any settings screen did.
When the Split Goes Wrong
Split tunneling creates a bridge, and bridges go both directions. If you exclude a range of local traffic from the tunnel and one of those local devices is already compromised — a cheap smart bulb, some off-brand plug nobody's updated in a year — that device now has a path to your machine that never touches your VPN's encryption at all. That's a real trade-off, not a hypothetical one, and it's separate from whether a provider's no-logs claims actually hold up under an independent audit, which is its own investigation entirely.
It's also worth running its own DNS leak check once you've set up any exclusions, since a misconfigured split can nudge DNS queries onto a resolver you didn't intend — a different failure mode from the local-access bridge, but one that shows up in the same settings menu. And how your ISP classifies that split traffic in the first place is yet another question, one that has more to do with your provider's network than with anything the VPN client controls.
Which Setup to Use
If the only friction you're solving is a printer or a Chromecast going dark, exclude by IP range and leave it there — it's the more forgiving option for anyone who doesn't want to manage a growing list of apps. If you're routing a work laptop that touches anything sensitive, go the other way: exclude specific tools by app and leave the rest of the machine fully tunneled by default, because the convenience of a blanket range exclusion isn't worth it on a device you'd hate to have compromised. And if you're managing this across more than just your own laptop, the math changes again — that's genuinely a separate topic, and I've gone into it on its own in Best VPN for Multiple Devices to Protect Your Entire Family Household.
All of this stops being complicated once the exclusions are set correctly. My partner still thinks the network has too many flags planted in it, and she's probably right, but at least the printer works now without anyone opening a terminal first.