WinHTTP vs. WinINET: Why The Proxy Bypass for your S3 Repo Works in the GUI but Not in Production

What is this about?

Recently I ran into a subtle but classic Windows networking trap while wiring up an Ootbi appliance with two nodes and a common IP behind a corporate proxy. The symptom was familiar: everything looked correct in the Windows proxy dialog, yet the backup traffic originating from the Windows based gateway server still tried to crawl partly through the proxy instead of talking to the appliance directly. If you have ever set a proxy bypass in the GUI and wondered why a service ignores it completely, this one is for you.

One note up front: I hit this with an Ootbi, but nothing here is Ootbi specific. This will bite you the same way with any S3 based / object storage target that you reach through an HTTP(S) endpoint behind a proxy, whether that is another on prem object appliance, a MinIO cluster, or a public S3 compatible service. The mechanism is Windows proxy handling, not the storage brand.

The misleading symptom: it "connected", then the backup died

Here is the part that cost me the most time, and the reason I am writing this down. Before I touched the WinHTTP configuration, adding the Ootbi to Veeam actually worked. The appliance was discovered, the repository got added, everything in the console looked green. So naturally I assumed the connection was fine.

Then the backups failed with a certificate error.

That is exactly the kind of message that sends you down the wrong rabbit hole. A certificate error screams "trust problem, TLS problem, appliance problem" and says nothing about proxies. I spent time staring at certificates and thumbprints when the real issue was that the data traffic was being pushed through the corporate proxy, which terminated or interfered with the TLS session. The proxy was effectively sitting in the middle of a connection that should never have gone near it, and the resulting handshake looked to Veeam like a certificate failure.

So the trap is twofold: the add/connect step succeeded (misleading you into thinking networking is healthy), while the actual backup data path failed (with an error that points you in the wrong direction).

The root cause: Windows has two separate proxy stacks

This is what was really going on. Windows does not have one proxy configuration. It has two independent HTTP stacks, each with its own proxy settings, its own bypass list, and its own storage location.

The GUI writes into WinINET. Your services read from WinHTTP. Those are two different worlds, and they can happily hold contradictory settings at the same time.

Why this bites you with Ootbi (and any S3 target)

An Ootbi connection is never a browser session. The traffic is driven by Veeam services (data mover, gateway, transport), and those typically run in the SYSTEM or a service context. That means they consult the WinHTTP configuration, not whatever you typed into the GUI proxy dialog.

The same is true for every S3 based repository. Object storage is spoken over HTTP(S), so the Veeam service issues those S3 calls through the WinHTTP stack. If that stack routes your storage endpoint through the corporate proxy, it does not matter whether the target is an Ootbi, some other object appliance, or an S3 compatible cloud bucket. The proxy gets in the way of traffic that should be direct.

That also explains my misleading symptom above. The lightweight discovery and add step behaved one way, but the heavy lifting of the actual backup, done by a service in the SYSTEM context, followed the WinHTTP path straight through the proxy. Add the proxy and bypass entries only in the GUI and:

• The interactive test from a browser looks fine.
• Adding the appliance in the console can even succeed.
• The Veeam service, running as SYSTEM, never sees your bypass entries. It routes the storage traffic through the proxy, and you end up with slow transfers, blocked sessions, or a certificate error that has nothing to do with the certificate.

Internal storage traffic through a corporate proxy is a recipe for pain. The proxy has no business sitting between your backup host and your immutable appliance.

The fix: set it where the service actually looks

This is why the command below is the reliable path. It writes into WinHTTP, so the services honor it:

netsh winhttp set proxy proxy-server="10.10.10.100:8080" bypass-list="localhost;127.0.0.1;*.corp.local;10.20.22.64;10.20.22.65;10.20.22.66;<local>"

(FQDN and addresses obfuscated. Substitute your real domain suffix and the appliance addresses, including the common IP, in my case here ending in .66. For a cloud S3 target, add its endpoint hostname to the bypass list instead of the internal IPs.)

A few things worth understanding in that bypass list:

• <local> tells WinHTTP to send any short host name without a dot (anything that is not an FQDN) directly, bypassing the proxy.
• The explicit target IPs (...64, ...65, ...66) and the wildcard *.corp.local are only honored in the stack that the connecting process actually reads. If the Ootbi common IP, or your S3 endpoint, is not in the WinHTTP bypass list, the service will try to reach it via 10.10.10.100:8080 and stall, or throw that misleading TLS/certificate error.
• A GUI bypass list is a WinINET construct and does nothing for your services. The two lists do not talk to each other.

Once the appliance IPs sat in the WinHTTP bypass list, the certificate error disappeared, because the traffic finally went directly to the appliance instead of through a proxy that was breaking the TLS session.

Verify what the service really sees

Never trust the dialog. Check the stack that matters:

netsh winhttp show proxy

If you would rather inherit the browser settings than type them twice, you can import them into WinHTTP once:

netsh winhttp import proxy source=ie

Just remember that import is a snapshot, not a live sync. Change the GUI later and WinHTTP stays on the old values until you import again.

The one question you must answer first

Before you blame the proxy, or the certificate, confirm the security context of the connecting process. Is your Veeam component running as SYSTEM, or under a dedicated service account with its own user profile? If it is a real user account, that account's WinINET profile can enter the picture as well, and you may have to align both stacks. For SYSTEM, WinHTTP is the single source of truth.

Takeaway

• This is not Ootbi specific. It applies to any S3 based / object storage target reached through a proxy. I just happened to hit it with an Ootbi.
• A successful "add appliance" step does not prove the data path is clean.
• A certificate error can be a proxy interception in disguise. Check the proxy path before you tear apart your certificates.
• Two stacks: WinHTTP for services, WinINET for the interactive user.
• Object storage traffic runs through services, so WinHTTP wins.
• Put your appliance IPs or S3 endpoint and internal domain in the WinHTTP bypass list and verify with netsh winhttp show proxy.

Set it in the right place, verify it, and let your backup host talk to the storage the way it should: directly.