HTTP_PROXY/HTTPS_PROXY environment variables leak into test suites causing false failures

[Mossaka]

Problem

AWF sets HTTP_PROXY, HTTPS_PROXY, and https_proxy environment variables in the agent container to route traffic through Squid (see src/docker-manager.ts lines 401-410). These variables are visible to all processes inside the container, including test suites. Tests that make HTTP/HTTPS requests detect the proxy variables and route traffic through Squid, causing false failures that do not occur outside the sandbox.

Affected Repos (v6 Experiment, 2026-03-17)

Repo	Failures	Root Cause
python/requests	28 test failures	Tests detect HTTPS_PROXY and route through Squid; SSL cert mismatch / connection handling differences
python/httpx	24 test failures	Same — httpx honors proxy env vars for test HTTP calls
go/echo	Minor test artifacts	Go's http.ProxyFromEnvironment picks up HTTP_PROXY/HTTPS_PROXY
go/websocket	Minor test artifacts	WebSocket upgrade through proxy behaves differently
node/got	SSL/TLS test failures	got detects proxy vars, tunnels HTTPS through Squid, cert validation fails

All of these tests pass on GitHub Actions ubuntu-latest without AWF. The failures are caused entirely by the proxy environment variables.

Technical Analysis

Current proxy mechanism (dual-layer)

AWF uses two independent mechanisms to route traffic through Squid:

1. iptables NAT DNAT (containers/agent/setup-iptables.sh lines 252-253): Transparently redirects all TCP traffic on ports 80/443 to Squid at the kernel level. This is invisible to applications.

2. Environment variables (src/docker-manager.ts lines 401-410): Sets HTTP_PROXY, HTTPS_PROXY, https_proxy so that HTTP client libraries explicitly use Squid as a forward proxy.

// src/docker-manager.ts lines 401-410
const environment: Record<string, string> = {
  HTTP_PROXY: `http://${networkConfig.squidIp}:${SQUID_PORT}`,
  HTTPS_PROXY: `http://${networkConfig.squidIp}:${SQUID_PORT}`,
  https_proxy: `http://${networkConfig.squidIp}:${SQUID_PORT}`,
  SQUID_PROXY_HOST: 'squid-proxy',
  SQUID_PROXY_PORT: SQUID_PORT.toString(),
  // ...
};

Why env vars cause test failures

When HTTP_PROXY/HTTPS_PROXY are set:

• HTTP clients send a CONNECT request to Squid instead of connecting directly
• Squid performs TLS interception, presenting its own certificate
• Tests that validate SSL certificates, connection behavior, or HTTP semantics see different behavior than expected
• Tests that intentionally make requests to non-existent or localhost servers get unexpected proxy errors instead of expected connection errors

Are the env vars even needed?

The iptables DNAT rules (mechanism 1) already force all HTTP/HTTPS traffic through Squid transparently. The env vars provide a secondary layer but are the sole cause of these test failures.

The env vars are currently needed for:

• Yarn 4 / Corepack / undici: These tools require https_proxy (lowercase) because they don't go through standard system HTTP and wouldn't be caught by iptables DNAT in all cases
• JVM build tools: Maven, Gradle, sbt are configured via entrypoint.sh (lines 192-282) using the proxy host/port extracted from HTTP_PROXY

Proposed Solutions

Option A: Unset proxy vars before running the agent command (recommended)

The entrypoint.sh could unset HTTP_PROXY, HTTPS_PROXY, and https_proxy after the build tool configuration phase but before executing the user's command. The iptables DNAT rules would continue to enforce traffic routing transparently.

# In entrypoint.sh, after JVM/build tool proxy config is written:
unset HTTP_PROXY HTTPS_PROXY https_proxy http_proxy

Risk: Tools that rely on env vars (Yarn 4/undici, Corepack) would stop routing through Squid at the application layer. However, iptables DNAT should still catch this traffic at ports 80/443.

Option B: Scope proxy vars to a wrapper script

Instead of setting proxy vars globally, provide a wrapper script (e.g., awf-install) that sets proxy vars only for package install commands:

#!/bin/bash
export HTTP_PROXY=http://172.30.0.10:3128
export HTTPS_PROXY=http://172.30.0.10:3128
exec "$@"

Agents could use awf-install pip install ... for installs, while test commands run without proxy vars.

Option C: Add common test-related entries to NO_PROXY

Expand NO_PROXY to include common test targets (httpbin.org, localhost, etc.). This is fragile and incomplete but would reduce some failures.

Option D: Document the behavior and let agents unset vars

Add guidance to workflow compilation so that agents know to run unset HTTP_PROXY HTTPS_PROXY https_proxy before running tests. This is the least invasive but relies on agent behavior.

Evidence

From the v6 experiment report, section 4.5:

AWF sets HTTP_PROXY/HTTPS_PROXY environment variables for the Squid proxy. These leak into test environments, causing test failures in:

• Python: requests (28 fails), httpx (24 fails)
• Go: echo, websocket (minor)
• Node.js: got (SSL/TLS tests)

These are not real code bugs — the tests pass outside the sandbox. This is a systematic AWF issue that should be addressed.

Recommendation

Option A (unset before agent command) is likely the best balance of safety and simplicity. The iptables DNAT rules provide transparent proxying without application awareness, which is the whole point of the transparent proxy architecture. The env vars were likely added as belt-and-suspenders but have become the primary source of false test failures.

Testing needed: verify that Yarn 4, Corepack, and undici still work correctly when proxy env vars are unset but iptables DNAT is active.