Proxy Configured, Traffic Direct: 1,080 Tests of Four Common HTTP Clients

We configured a small proxy and two destination servers on one Debian PC. One destination served HTTP; the other served HTTPS. A third path redirected from the HTTP destination to the HTTPS destination.

The destination recorded whether each synthetic request arrived from the proxy’s outgoing connection or directly from the client. For HTTPS, the proxy forwarded an encrypted CONNECT tunnel. It did not decrypt TLS. A temporary certificate was trusted only by the test processes, and a negative control confirmed that an unrelated certificate authority was rejected.

Each trial launched a fresh client process with a controlled environment. We removed inherited proxy settings, disabled curl’s user configuration file, and used a temporary home directory. This prevented an existing shell setting or user configuration from silently changing the experiment.

The installed versions were curl 8.14.1, Python 3.13.5, Requests 2.32.3, and Node 25.2.1. Our evidence records curl’s Debian patch version and complete runtime details.

We tested four configurations:

• Lowercase http_proxy and https_proxy together.
• Uppercase HTTP_PROXY and HTTPS_PROXY together.
• Lowercase http_proxy alone.
• Both lowercase settings plus a deliberate NO_PROXY exception for the destination.

Each configuration faced a healthy proxy and five failure conditions: connection refusal, HTTP 407 authentication required, HTTP 503 unavailable, a TCP reset, and a connection that accepted the request but stalled.

With both lowercase proxy variables present, default Node fetch connected directly for HTTP, HTTPS, and the redirect path. Enabling NODE_USE_ENV_PROXY=1 changed all three paths to use the proxy.

We reproduced that distinction against a public HTTPS destination. Default fetch returned a valid response without contacting our researcher-operated proxy. The enabled mode established a CONNECT tunnel through it.

This behavior follows the tested runtime’s configuration model. Node documents the environment proxy option; the result should not be described as a Node security vulnerability. It demonstrates why checking that an environment variable exists is insufficient evidence that a particular application uses it. Node 25.2.1 documentation

In the local HTTP tests, curl connected directly when given uppercase HTTP_PROXY, while urllib, Requests, and proxy-enabled Node used the proxy. For HTTPS, curl used uppercase HTTPS_PROXY.

curl deliberately treats http_proxy differently: it accepts the HTTP variable in lowercase to avoid a CGI-related security problem. The measured behavior is documented and intentional. curl’s proxy environment documentation

That produced a distinctive local redirect route. With uppercase settings, curl sent the initial HTTP request directly and the redirected HTTPS request through the proxy. A test that checked only the final HTTPS response would miss the first leg.

We did not repeat this HTTP redirect scenario against a public destination, so its measured scope remains the controlled local fixture.

When only lowercase http_proxy was supplied, curl, urllib, and Requests used the proxy for the initial local HTTP request, then connected directly for the redirected HTTPS request.

Proxy-enabled Node behaved differently: it used the HTTP proxy setting for both HTTP and HTTPS in this configuration. Default Node fetch connected directly throughout.

All three repetitions agreed for each local combination. Public HTTPS checks reproduced the HTTPS column: curl, urllib, Requests, and default Node fetched directly; enabled Node used the test proxy.

The practical implication is specific: validating one HTTP request does not establish how the same configuration routes HTTPS. Requests and urllib each document their proxy configuration mechanisms; users need to apply the configuration supported by the client they actually run. Requests documentation, Python urllib documentation

We first identified the client/configuration/path combinations that used the proxy for every leg in all three healthy baselines. There were 28 such combinations.

Across their five failure conditions and three repetitions, we observed 420 matched failure trials. None reached the controlled destination by any route.

A proxy-generated HTTP 407 or 503 response did not count as destination receipt. Some clients can return such a response to an application without a transport-level error, so an exit code alone would be an inadequate routing test.

This result is bounded. It applies to these versions, settings, fixtures, and failure conditions. Our HTTP versus SOCKS proxy guide explains why a different protocol requires its own testing. We did not test PAC fallback rules, browser extensions, SOCKS, mid-transfer failures, connection reuse, or every possible retry policy.

Local addresses can receive special treatment from proxy implementations. We therefore repeated the HTTPS configuration comparisons using api.ipify.org, a public IP-echo endpoint.

The public phase covered five client modes, four configurations, two proxy states, and two repetitions: 80 attempts. There were 62 valid responses—44 direct and 18 through the researcher proxy. The remaining 18 attempts returned no valid response in refused-proxy configurations whose healthy counterparts had used the proxy.

These totals describe deliberately selected configurations. They are not a population estimate that a percentage of proxy users leaks traffic. Both repetitions agreed on the observed route or failed-response outcome for each public configuration.

Our temporary forwarding proxy ran on the same PC as the clients. It therefore shared their Internet egress. Its CONNECT records establish that a request used the configured proxy path; they do not demonstrate that a remote paid proxy concealed the PC’s public IP. Raw public IP responses were handled in memory and saved only as opaque, salted comparison labels.

For the application and version you use, establish a working baseline first. Confirm the proxy receives the request. Test each relevant URL scheme and redirect leg. Then make the proxy unavailable and check whether the destination still receives a request.

Separate three outcomes: a client that never engaged the proxy, an intentional bypass rule, and a client that changes from a proven proxy route to a direct route after failure. Combining those outcomes into one “leak rate” would hide the cause.

Our study’s central finding is a configuration gap: a proxy setting can look complete while leaving a particular client or request scheme on a direct route. The reproducible route evidence makes that gap visible.

Route verification is only one layer. Our proxy-password transport experiment separates destination HTTPS from the connection to the proxy, while our reporting-service access study distinguishes proxy tunnel refusals from destination responses. For practical configuration steps, use the Windows and Mac proxy setup guide.

The accompanying package contains the scripts, exact main-run source snapshots, individual trial records, server events, aggregates, controls, and SHA-256 manifests. The 360-trial exploratory fixture pilot is excluded from the main totals.

An earlier Honeygain supplier setup attempt is a separate experiment. It authenticated but received “Network Overused”; it did not establish customer relay traffic or consent-withdrawal behavior, and it contributes no observations to this routing matrix.

Our research is about application routing, rather than the separate browser and network mechanisms described in our WebRTC and IPv6 leak guide. No proxy vendor supplied a paid endpoint or sponsored this measurement session. No café customer traffic was captured. All services were temporary, no recurring task was created, and neither the router nor the PC’s VPN configuration was changed.