Why Split Tunneling Does Not Cover Your App's Updates

You add the application to the split-tunnel exclusion list, the app reaches the internet directly, and the updates still fail or still crawl through the tunnel. The exclusion worked. It just covered a different process than the one doing the download, because a modern updater is rarely the same executable as the application window.

The myth: excluding the app excludes its traffic

Per-app split tunneling matches a process, a package or an application path, depending on the platform. It does not match a brand, a feature or a user intention. When the application hands the download to a helper, a shared platform service or a browser component, that helper has its own identity and its own path through the tunnel. The exclusion list has no idea that the two processes belong to the same product. It only knows which one you named.

So the rule is doing exactly what it was told. The assumption about who owns the transfer was wrong, and the fix starts with identifying that owner rather than adding more exclusions.

Find the transfer owner

On Android, the update may be fetched by a shared service package rather than the app package you excluded, and a per-app VPN rule applies to the package that opens the socket. On Windows, an updater service can run under a different executable path than the application, so a rule that matches the app path misses it. On macOS, a privileged helper or a system update daemon can perform the transfer while the app only requests it.

Identify the owner from evidence: the platform network activity view, a packet capture filtered by process, or the vendor documentation that names the updater component. Guessing from the process name is how two similar-looking binaries get confused and the wrong one gets excluded.

Update systems often split the work as well. A small metadata request checks for a version, and a much larger package download goes to a content delivery host or a different domain. The metadata check can succeed through the tunnel while the package transfer stalls on a host the tunnel routes differently. That split explains the confusing report where updates are detected but never installed. Test the package download itself, from the same device and the same network, rather than testing whether the application opens.

Verification survives a route change

Changing a route does not replace TLS, publisher identity or package signature verification. Do not switch those checks off because a download succeeds only after you click past an unexplained certificate warning. A warning that appears only on the excluded path is a finding, not an obstacle. Investigate it before you widen the bypass.

On a managed device, ask for a supported exception instead of adding a broad rule for every system service. A rule that excludes all shared services to fix one updater widens the bypass far beyond the original request.

Test the update, then document the owner

Reconnect after the change and verify the applied rule again, because some clients rebuild their routing when the tunnel reconnects. Run one full update cycle: check, download, verify and install. A successful check proves the smallest part of the path.

Record the transfer owner, the destination hosts and the intended route in the same place as the split-tunnel rule. The next update mechanism change will silently invalidate the exception otherwise, and the person who inherits it will have no way to know which process the rule was written for.