System proxy or TUN? Six real situations, one answer each

The previous article covered how TUN works. This one answers a single question: in your situation, which do you turn on?

The table first.

Now the reasoning.

1. Everyday browsing

The system proxy on its own is enough.

Chrome, Edge and Firefox follow the system proxy by default, so one switch covers everything. TUN adds nothing here and costs you extra CPU plus a layer of DNS handling.

2. Steam, Battle.net or Epic downloading slowly

TUN is required.

Game platform downloaders talk to sockets directly and ignore the system proxy entirely. You get a characteristic symptom: the Steam store page loads fine (that part went through the proxy) but downloads crawl along at tens of KB (the downloader did not, and is still fighting for the original international route).

3. Command-line tools hanging

git clone stuck at 0%, npm install spinning, docker pull timing out — none of these read the system proxy.

Two routes.

Route A: enable TUN. Done once, every CLI tool works.

Route B: set environment variables. Lighter, no virtual adapter needed:

# PowerShell (current session)
$env:HTTP_PROXY="http://127.0.0.1:7897"
$env:HTTPS_PROXY="http://127.0.0.1:7897"

# Git specifically (permanent)
git config --global http.proxy http://127.0.0.1:7897
git config --global https.proxy http://127.0.0.1:7897

# npm
npm config set proxy http://127.0.0.1:7897
npm config set https-proxy http://127.0.0.1:7897

Docker is a special case: 127.0.0.1 inside a container means the container itself, not the host. Use host.docker.internal or just enable TUN — the latter is far less work.

4. Streaming (Netflix, Disney+, HBO)

System proxy is enough; TUN is unnecessary.

Both the web players and the desktop apps follow the system proxy. What actually determines whether content unlocks is something else:

5. Multiplayer games

Enable TUN, but keep expectations realistic.

Games need UDP, the system proxy does not handle UDP, so TUN is the only option. But:

• The node must actually forward UDP — plenty of cheap nodes do not, or restrict it
• An extra hop adds latency by definition, unless your node is on a dedicated IPLC/IEPL line
• Some anti-cheat systems react to virtual adapters

6. A laptop your employer manages

Be careful with TUN.

Corporate machines usually run endpoint security (EDR), a VPN client, or domain policy. TUN creates a virtual adapter and rewrites routes, which tends to cause three kinds of trouble:

1. Fighting the corporate VPN over routes, breaking internal access
2. Being flagged and reported by the EDR as suspicious network behaviour
3. Conflicting with a proxy setting enforced by domain policy

If you do need it:

• Use the system proxy only, no TUN
• Explicitly mark internal domains and IP ranges as DIRECT in your rules
• Check with IT first whether this is permitted

What the three combinations actually cost

The gap is small — modern machines will not notice. The real difference is in behavioural complexity: with TUN running, any network problem has one more layer to rule out.

A middle option: TUN only, system proxy off

If you want both games and a browser, try:

• TUN on
• System proxy off

Everything then takes one path, behaviour is uniform, and diagnosis is simpler. The trade-off is that software explicitly written to "use the system proxy" may behave differently, and browser extensions that set their own proxy (SwitchyOmega and friends) can bypass TUN.

In short

When in doubt, start from the system proxy and add what is missing — far easier to debug than switching everything on at once.

Further reading: how TUN mode works and sharing the proxy over your LAN.