The proxy is on in the system tray, yet a site opened inside some other program still sees the real address — a common complaint when a proxy was configured the way it's done in a browser, without accounting for how that program reads network settings. Here are the three levels a proxy works at, which programs bypass a system tunnel, how to spot a leak, and when one shared tunnel isn't enough.
Three levels: browser, application, system
A browser proxy is configured through the browser itself or an extension and only affects traffic the browser sends on its own — tabs, built-in downloads, sometimes extensions with their own network access. It never reaches a neighbouring program.
An app-level proxy is a field for an address and port inside the program itself: an antidetect browser, a torrent client, an account manager. It only affects that one program and needs no system tunnel, but only works if the developer built that field in.
A system-level tunnel changes the OS routing table, or runs as a separate TUN adapter: it intercepts outbound connections from every program at once, regardless of whether the app supports proxy settings. The catch: some programs read the system proxy through one library, some through another, some ignore both.
Which applications ignore system settings
Background auto-update services almost always reach their update server directly, at a hardcoded address, bypassing both the system proxy and the tunnel — same for some game clients, emulators, and programs built on their own networking stack, which simply don't read environment variables or tray settings.
Command-line tools usually need the proxy spelled out explicitly, in a config file or environment variable; a tunnel will still catch them, but a per-app setting will not. Antidetect browsers and multi-accounting tools are built differently: they carry their own proxy field per profile, a strength rather than a gap — the setup is in setting up a proxy for an antidetect browser step by step.
Leaks around the tunnel and how to spot them
A DNS leak is the most common one: the app resolves a domain through the system DNS server, bypassing the tunnel, and that lookup exposes the real provider even though the data itself later travels through the proxy. An IPv6 leak happens when the tunnel only handles IPv4 while the app has a separate IPv6 route — the connection goes out directly, as covered in IPv4 vs IPv6 in practice.
A separate category is background processes and telemetry inside the program: the interface uses the configured proxy while the app's own service connections go out directly. The only reliable way to catch this is a network monitor or firewall log — any address in the outbound list other than the proxy's own means part of the traffic is bypassing it.
How to verify traffic really goes through the proxy
Checking inside a browser tells you nothing about what a separate application sees — an IP-check needs to run inside the program itself, if possible, or via what address the target site actually reports. The second method is the outbound connection list in the task manager or firewall: any connection not going to the proxy's address and port is a bypass.
The most reliable approach is a dedicated port with a unique session: if the address the target service reports doesn't match what that port hands out, the leak is obvious immediately. General quality metrics that apply here too are in how to check proxy quality.
When an app needs its own dedicated port
One shared tunnel with a single address doesn't work when several isolated profiles run at once and each needs its own IP — the same principle as multiple antidetect profiles. A local proxy manager solves this by binding a separate local port to its own upstream address per application, so every program runs in parallel without overlap.
For automation with scheduled or on-demand rotation, the same idea works through an API: every script gets its own port and session, instead of depending on the tunnel as a whole. Setup is in how to set up IP rotation via API.
Frequently Asked Questions
How is a system tunnel different from a browser proxy?
A browser proxy only affects the browser's own traffic. A system tunnel changes OS-level routing and by default intercepts outbound connections from every program, except ones using their own networking stack instead of the system's.
How do I know an application isn't using the configured proxy?
Check a network monitor or firewall log: connections to addresses other than the proxy's own mean part of the traffic is going out directly. Or compare the IP the program or target site reports against the expected proxy address.
Do I need to restart an app after changing the proxy?
Often, yes. Many programs read proxy settings only once at startup and don't pick up changes on the fly. Until the app restarts, it may keep using the old route.
Dedicated addresses and separate ports per application or profile are in the proxy section. The same page lets you pick a channel for the task — from a system-wide tunnel to a single port for one application.