TUN mode vs system proxy is a comparison between packet capture and application cooperation. A TUN interface receives IP packets selected by operating-system routes, whereas a system proxy is a preference that applications may honor, override, or ignore; apps bypass the connection when their traffic never enters the selected mechanism.［1］［2］［3］

The complete VPN guide covers the basic tunnel model. This article isolates the entry path so that a browser success, an application bypass, and a route exclusion are not mistaken for the same failure.

Key Takeaways

TUN mode operates on routed IP packets; a system proxy operates through proxy-aware applications.

Direct sockets, custom network stacks, app-specific proxy settings, and unsupported traffic can bypass a system proxy by design.

TUN mode is broader but not absolute: routes, IPv4/IPv6 coverage, per-app exclusions, DNS, and namespaces still define scope.

Public-IP checks should be repeated from multiple applications and address families.

Fix the layer that failed instead of repeatedly switching protocols or proxy types.

TUN mode vs system proxy in the traffic path

A TUN interface is a virtual layer-3 interface. The operating system sends selected IP packets to it according to the active routing policy. Android documents a VPN application reading outgoing packets from the interface, sending them through its protected tunnel socket, and writing decrypted incoming packets back.［1］

A system proxy is configuration consumed by software. A browser or framework can ask which proxy to use for a URL, authenticate to it, and send a supported request. PAC can return a proxy chain or DIRECT for each request. The setting does not physically intercept every socket on the host.［3］

Question	TUN mode	System proxy
Who selects traffic?	Route and VPN policy	Each proxy-aware application or framework
What enters?	Selected IP packets	Supported requests or connections
Direct socket behavior	Usually follows route policy	Can ignore the proxy completely
UDP behavior	Possible if the tunnel implementation carries it	Varies by proxy and client support
IPv6 behavior	Requires matching IPv6 routes and tunnel support	Depends on application resolution and proxy path
DNS behavior	Can be routed or assigned separately	Can be local, proxied, or application-specific
Exclusions	Route, app, destination, or platform policy	PAC `DIRECT`, bypass list, or application override

Why do some apps bypass a system proxy?

The most common reason is simple: the program never consults the system setting. It may create a direct TCP or UDP socket, use a bundled runtime with its own configuration, inherit environment variables instead of desktop settings, or maintain a previously established connection. A successful browser page therefore says nothing about that program's entry path.

An application can also define an explicit proxy that overrides the system one. Enterprise software may receive managed settings; development tools may use their own configuration file; a browser extension can affect only one browser profile. Different locations in a VPN extension and desktop app are expected when two independent traffic paths and exit selections are active.

Bypass rules are another intentional cause. PAC logic can return DIRECT for matching URLs, while desktop proxy settings often exempt local names or address ranges. Cached PAC results, profile precedence, and authentication failures can make the observed behavior differ between applications even when they display the same proxy address.［3］

Which protocols commonly expose the difference?

Voice, games, discovery, and real-time applications often use UDP. A basic HTTP proxy path does not automatically carry that traffic. Some SOCKS implementations support UDP association, but the client and server must both implement it and DNS may still take a separate path.

Non-HTTP TCP protocols can sometimes use CONNECT, but only if the application asks and the proxy permits the target. A program that expects raw sockets will not become proxy-aware because a desktop checkbox is enabled. This is an integration boundary, not evidence that encryption failed.

Why can TUN mode still miss traffic?

TUN capture is controlled by routes. If the profile installs only selected prefixes, destinations outside them remain on the ordinary interface. Microsoft documents that route specificity and metrics influence VPN route selection, and that forced versus split tunneling changes which defaults are installed.［2］

Address-family mismatch is a frequent source of surprise. An IPv4 default route through TUN does not automatically capture IPv6. A destination with both address families can therefore appear to change paths between applications or attempts. Verify the active IPv4 and IPv6 tables and the address actually selected.

Platforms can also support per-app inclusion or exclusion, local-network allowances, and protected sockets used by the VPN implementation itself. Containers, virtual machines, and separate user or network namespaces may have their own routes. TUN mode should be described as route-level capture within its declared context, not “every packet on the machine.”

Can DNS bypass TUN mode?

Yes, if resolver traffic follows an excluded route, an application uses its own encrypted DNS path, or the platform's name-resolution policy selects another interface. Conversely, a DNS query can enter the tunnel while the resulting connection uses a direct route. DNS and destination traffic are related but distinct observations.

Test a controlled hostname whose resolution you can observe, then inspect the connection address and route. Do not treat one resolver setting or a cached answer as complete proof.

How should you diagnose application bypass?

Begin with a reproducible pair: one application that appears protected and one that appears direct. Record the same timestamp, destination, address family, and network. If the destinations differ, the comparison cannot isolate capture behavior.

Next, inspect entry configuration. For a system proxy, check the active proxy source, application-specific overrides, PAC result, bypass list, authentication, and whether the application must restart. For TUN, check interface state, route prefixes, metrics, app exclusions, address families, and whether the VPN tunnel socket is correctly protected from recursion.

Then classify the flow. Identify TCP or UDP, destination IP and port, resolver path, local or remote scope, and whether the application reused an existing connection. Browser-only VPN success is easier to interpret once these facts are known.

Finally, change one variable. Force the same address family, restart only the target application, remove one authorized bypass rule, or compare one direct and one proxied request. Avoid changing the protocol, endpoint, DNS service, and application settings together; that destroys the evidence needed to locate the boundary.

What does a reliable test matrix include?

Use a matrix with rows for browser, command-line client, background service, and a controlled UDP-capable tool. Use columns for system proxy, TUN, disconnected state, IPv4, IPv6, DNS result, egress address, and expected local access. Mark unsupported combinations rather than calling them failures.

Capture local evidence before and after every test: route output, interface identity, proxy source, PAC decision where available, and sanitized application logs. Server-side logs can confirm that a request reached the intended endpoint, but absence may also mean name resolution or routing failed earlier.

Define the pass condition in policy language. “All managed applications use the tunnel except the approved update service” is testable. “The VPN works” is not. Also define failure behavior: whether direct fallback is allowed, whether local services remain reachable, and whether reconnection must terminate old sockets.

When should you use each approach?

Use TUN when the requirement applies to multiple applications, software without proxy support, UDP traffic, or a device-level network policy. Accept the added need to manage routes, DNS, interface lifecycle, MTU, and safe failure behavior.

Use a system proxy when the scope is explicitly limited to compatible applications, direct access for other software is acceptable, and per-request proxy decisions are useful. Document every bypass and prohibit silent DIRECT fallback if the threat model requires fail closed.

A combined design is possible: a TUN component can translate captured flows into a proxy stack. In that case, keep the layers separate in diagnosis. The TUN decides what enters; the proxy stack decides how those flows are represented and transported.

Does the TUN/system-proxy model describe AethoVPN?

For a controlled test with AethoVPN, connect with global mode on and check three things separately: a browser leak test, the resolver reported by a DNS leak test, and a command-line tool or app that ignores system proxy settings. If all three leave through the chosen location, you have observed system-wide coverage, but AethoVPN's documentation does not say whether that is achieved with a TUN interface, a proxy or both, so record the result rather than the mechanism. Start the 3-day free trial to run the three checks.

Summary

TUN mode captures routed IP packets, while a system proxy depends on participating software.
Direct sockets, custom settings, UDP limitations, and DIRECT rules commonly explain proxy bypass.
TUN scope still depends on routes, address families, exclusions, namespaces, and DNS behavior.
Compare identical destinations from several applications and change one variable at a time.
Write explicit coverage and failure rules before treating a result as pass or bypass.

FAQ

Does TUN mode guarantee that no app can bypass the VPN?

No. Platform exclusions, route gaps, another namespace, IPv6, local routes, or privileged behavior can create a different path. The guarantee must be evaluated against the actual platform policy and route state.

Why does my browser use the proxy but a game does not?

The browser is proxy-aware, while the game may use direct TCP or UDP sockets. Check the game's supported proxy settings and the required traffic types rather than assuming it inherits browser configuration.

Is a system proxy the same as split tunneling?

No. A system proxy is one traffic-entry mechanism. It can produce a split outcome because some applications use it and others connect directly, but split tunneling can also be based on apps, routes, destinations, or domains.

Can TUN mode and a proxy be used together?

Yes. A client can capture IP packets with TUN and translate eligible flows into a proxy stack. Capture, proxy protocol, transport, routing, and DNS remain separate configuration layers.

Why does IPv6 show a different public address?

The profile may capture only IPv4, or the proxy application may resolve and connect differently over IPv6. Inspect both route tables and test the same dual-stack destination with recorded addresses.

Do I need to restart an app after changing the system proxy?

Sometimes. An application may cache settings, PAC results, DNS answers, or existing connections. Restarting the target app is a controlled diagnostic step, but it does not prove that all future flows will honor the proxy.

Is direct fallback always a security leak?

It is a leak only when it violates the declared policy. Direct access may be an intentional availability choice for excluded applications or local services. A fail-closed requirement must explicitly prohibit and test fallback.

Disclaimer: This article provides general networking information. Follow the rules of the networks, devices, and services you administer.

Sources:

Android Developers, “VpnService”: https://developer.android.com/reference/android/net/VpnService
Microsoft Learn, “VPN routing decisions”: https://learn.microsoft.com/en-us/windows/security/operating-system-security/network-security/vpn/vpn-routing
MDN Web Docs, “Proxy Auto-Configuration file”: https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Proxy_servers_and_tunneling/Proxy_Auto-Configuration_PAC_file

Sources checked 12 September 2026.

Related Articles:

TUN Mode vs System Proxy: Why Apps Bypass the VPN