A full-tunnel connection makes one very simple promise: flip the switch, and every packet leaving your computer goes through the same remote server. Nothing is left behind, nothing is a special case, and there is exactly one thing to remember — is it on, or is it off?
That simplicity was enough for a long stretch of the desktop era. But what a typical machine does on a network has changed. A laptop today is simultaneously talking to a printer down the hall, a NAS in the next room, a bank that watches where you log in from, and a video call that cares about jitter more than throughput. Pushing all of that through one hop in another country has a cost, and it shows up in places nobody connects back to the switch they flipped.
The alternative is not “no protection”. It is a rule engine that inspects each connection and sends it somewhere appropriate. What follows compares the two models: what a full tunnel quietly charges you, what splitting buys back, and when the blunt instrument is still the right choice.
What “Full Tunnel” Actually Means
In a full-tunnel setup, your operating system’s default route is replaced. The tunnel interface becomes the path of last resort for essentially every destination, so traffic to a public DNS resolver, to your office intranet, and to the smart speaker on your shelf all get handed to the same encrypted pipe.
Most consumer clients hardcode a few exceptions, but the model stays binary: there is one exit, and the only decision available is whether to use it.
Split routing inverts that. A default still exists, but it sits at the bottom of a list evaluated first. Each connection is matched against domains, IP ranges, geographic databases, rule sets, and sometimes the process that opened it. The first match decides, and the available destinations include “straight out the normal interface, untouched”.
The Bills a Full Tunnel Quietly Charges You
Latency on things that were already close
Distance is not free. If a CDN node is 12 milliseconds away and your tunnel endpoint is 140 milliseconds away, the tunnel does not cost you 140 milliseconds once — it costs the trip to the endpoint plus the endpoint’s own path back, on every request. Modern pages open dozens of connections, so the delay compounds in a way a single ping test never reveals.
The effect is worst on chatty workloads: web apps that poll, package managers pulling hundreds of small files, Git against a nearby mirror, database clients issuing many small queries.
Geolocation checks that break
Plenty of legitimate services check where a connection originates. Banks flag logins from unexpected regions and may lock the session. Payment processors decline. Government and utility portals sometimes refuse foreign addresses. Streaming catalogues change contents or stop playing.
None of these are edge cases. They are ordinary Tuesday-afternoon tasks that a full tunnel turns into a chore of switching off, doing the thing, and switching back on — and every toggle is a chance to forget.
LAN and NAS access that stops working
This one generates the most confused support threads. Your NAS sits at 192.168.1.20, your printer at 192.168.1.35, your router’s admin page at 192.168.1.1. If the tunnel takes the default route without carving out private address space, those requests go to a server in another country that has no idea what 192.168.1.20 means, and get dropped.
The symptoms look like broken hardware rather than a routing problem: the NAS disappears from the file browser, cast targets vanish, local development servers stop resolving, and SSH to a machine on the same desk hangs.
Bandwidth paid for twice
Every byte through a tunnel crosses the endpoint’s link in both directions. Back up 200 GB to cloud storage, sync a media library, or pull container images all day, and that volume becomes the endpoint’s problem too. On metered or fair-use plans, this is where throttling starts — and it is simply wasted capacity when the traffic never needed tunnelling.
Real-time media quality
Video and voice calls are unusually sensitive to jitter and packet loss, and comparatively indifferent to raw bandwidth. Each extra hop adds another place where queuing delay can appear. A tunnel that benchmarks well on a speed test can still produce worse calls, because a speed test measures throughput while a call cares about consistency of arrival.
What a Rule Engine Does Instead
A rule-based client keeps the tunnel but demotes it from “the only option” to “one of several targets”. The configuration is an ordered list, walked top to bottom, first match wins:
rules: - IP-CIDR,127.0.0.0/8,DIRECT,no-resolve - IP-CIDR,192.168.0.0/16,DIRECT,no-resolve - IP-CIDR,10.0.0.0/8,DIRECT,no-resolve - IP-CIDR,172.16.0.0/12,DIRECT,no-resolve - DOMAIN-SUFFIX,local,DIRECT - DOMAIN-SUFFIX,mybank.example,DIRECT - GEOIP,CN,DIRECT - RULE-SET,work-tools,Proxy - MATCH,Proxy
Read it as a sequence of sentences. Loopback, direct. Anything on a private network, direct. Anything ending in .local, direct. The bank, direct, so its fraud engine keeps seeing the address it always has. Domestic destinations, direct. A curated set of work tools, tunnelled. Everything unmatched, tunnelled. That ordered evaluation is what makes a clash configuration different from a VPN profile — you are writing policy, not toggling a state.
The no-resolve flag matters. Without it the engine may run a DNS lookup just to test an IP rule against a hostname-based request, which wastes time and can leak queries. On pure address-range rules it should almost always be present.
Side by Side
BehaviourFull tunnelRule-based splitDecision granularityOne switch for the whole machinePer connection, domain or processLocal network devicesOften unreachable unless carved outReachable via private-range DIRECT rulesBank and payment portalsMay flag or block the sessionPinned DIRECT, origin stays consistentNearby CDNsExtra round trip on every objectServed at native latencyLarge uploads and backupsConsume endpoint bandwidthSent direct unless you say otherwiseVideo callsExtra hop adds jitterExcluded by process or domainSetup effortMinimalAn afternoon, then stableFailure modeObvious — everything stopsSubtle — one rule can be wrongAuditabilityLittle per-app visibilityLog shows the matched rule
The last row deserves emphasis. With a split configuration you can open a live connections view, see that a request matched GEOIP,CN and went DIRECT, and adjust accordingly. Cross-platform desktop clients like Clash Verge Rev put that view next to a rules page, which turns rule debugging into reading a log rather than guessing; the Clash Verge Rev site shows how a Mihomo-based GUI lays that information out.
Bypassing Private Address Space Properly
If you take one thing from this comparison, make it this: private ranges belong at the very top of the list, and they should be excluded by address, not by hostname.
10.0.0.0/8— the large private block, common in corporate networks and container bridges172.16.0.0/12— the middle block, heavily used by Docker’s default networks192.168.0.0/16— home routers, NAS boxes, printers, IoT devices127.0.0.0/8— loopback, including local development servers169.254.0.0/16— link-local, used by mDNS device discoveryfc00::/7andfe80::/10— the IPv6 equivalents, easy to forget
Devices found by mDNS and SSDP are the usual casualty when link-local is missed. If cast targets, scanners or smart-home hubs vanish after enabling a virtual adapter, look there first.
Per-App Routing
Domain rules answer “where is this going”. Process rules answer “who is asking”, which is sometimes the only question with a clean answer — a backup agent talking to dozens of rotating storage hostnames is far easier to describe by its binary name.
rules: - PROCESS-NAME,Steam.exe,DIRECT - PROCESS-NAME,zoom.exe,DIRECT - PROCESS-NAME,Docker Desktop.exe,DIRECT - PROCESS-NAME,code.exe,Proxy
Typical DIRECT candidates are game clients pulling multi-gigabyte updates, backup and sync agents, conferencing apps, and anything moving large volumes on the local network. Typical tunnel candidates are developer tooling, package managers with poor local routing, and terminal sessions.
One caveat: process matching requires the client to see which program owns a socket, which generally means running with the necessary system integration. On some platforms that needs elevated privileges, and in plain system-proxy mode the process name may be unavailable.
When a Full Tunnel Is the Right Answer
Split routing is not universally better, and pretending otherwise would be dishonest. There are clear cases for sending everything one way:
- Untrusted local networks. On a hotel or conference network, the local segment is exactly what you do not want to talk to directly. Reaching a nearby printer is irrelevant when the printer is someone else’s.
- Threat models where partial exposure is unacceptable. If a single direct request would be a problem, flexibility becomes a liability and the correct configuration has no DIRECT branch at all.
- Compliance-driven corporate access. Some environments require all traffic to cross an inspection point. That is policy, and splitting is out of scope by design.
- Machines nobody maintains. A shared family device is better off with a switch that has two positions.
The practical middle ground is a rule engine holding a full-tunnel profile as one of several, so you can switch to an all-through configuration when circumstances call for it without installing a second application.
Building a Split Configuration Step by Step
- Start from a working baseline. Import your node subscription and confirm connectivity before adding rules.
- Add private ranges first. All four IPv4 blocks plus the IPv6 equivalents, each with
no-resolve, at the very top. - Verify local devices. Ping the router, open the NAS, print a test page. Everything after this depends on this layer.
- Pin the sensitive services. Bank, tax portal, employer SSO —
DOMAIN-SUFFIXrouted DIRECT. - Add a domestic geographic rule. One
GEOIPentry for your own country catches most local services. - Add process exclusions. Watch the connections log for a day and exclude whatever is producing volume you never meant to tunnel.
- Set the final policy.
MATCHdecides everything unmatched, so choose it deliberately — it runs most often. - Re-read the log a week later. Real usage surfaces cases no planning predicts.
Common Questions
Does split routing weaken encryption?
No. Traffic that goes through the tunnel is encrypted exactly as before. What changes is which traffic goes through it — a smaller set, chosen by you, not weaker protection on the set that does.
How do I know which rule a connection matched?
Use the connections view. A capable client lists active connections with destination, process, applied policy and usually the specific rule responsible. If something goes somewhere unexpected, that view names the line to fix.
Why do my rules seem to be ignored?
Almost always ordering. Evaluation stops at the first match, so a broad rule above a narrow one swallows it. A GEOIP line near the top will absorb domain rules below it that resolve into the same region. Move specific rules up.
Should DNS be handled separately?
Yes, and it is the most commonly missed piece. If every lookup goes to one resolver through the tunnel, domestic services get handed distant CDN addresses and perform badly despite a correct DIRECT rule. Point local domains at a local resolver.
Where This Leaves You
The full-tunnel model is not wrong, just coarse. It answers one question — on or off — and charges for that simplicity in latency, broken geographic checks, unreachable local devices, wasted bandwidth and degraded calls. Most of those costs go unnoticed, because the symptoms rarely look like routing problems.
A rule engine asks a better question: what is this connection, and where should it go? Start narrow — exclude private ranges, pin the services that break, set a sensible default — and let real usage tell you what to adjust. A configuration built that way tends to outlive the switch it replaced.
