Introduction

Bazel can fail behind a corporate proxy even when ordinary command-line tools work. The usual problems are that external repository fetches do not inherit the right proxy settings, TLS interception breaks certificate validation, or the Java runtime used by Bazel is not configured consistently with the shell. The fix is to treat Bazel downloads, the host environment, and repository rules as one connected network path.

Where Proxy Problems Usually Appear

Bazel itself may start fine and still fail later during dependency resolution. Common failure points include:

• 'http_archive or git_repository fetches'
• remote module downloads
• registry access for external dependencies
• Java-based HTTPS requests made by Bazel internals

That is why a plain shell curl success does not always prove Bazel is configured correctly.

Start With Standard Proxy Environment Variables

The first step is to export proxy variables in the shell that launches Bazel.

export HTTP_PROXY=http://proxy.example.com:8080
export HTTPS_PROXY=http://proxy.example.com:8080
export NO_PROXY=localhost,127.0.0.1,.internal.example.com

Many tools also read lowercase variants, so in restrictive environments it is reasonable to set both forms.

export http_proxy=$HTTP_PROXY
export https_proxy=$HTTPS_PROXY
export no_proxy=$NO_PROXY

Then run Bazel from that same shell:

bazel build //app:server

Persist Environment Through Bazel Configuration

If developers repeatedly forget shell setup, add environment forwarding in .bazelrc.

1build --action_env=HTTP_PROXY
2build --action_env=HTTPS_PROXY
3build --action_env=NO_PROXY
4build --repo_env=HTTP_PROXY
5build --repo_env=HTTPS_PROXY
6build --repo_env=NO_PROXY

repo_env is especially important because repository fetch logic can run in a different environment context from ordinary actions.

Java Trust Store Problems Behind TLS-Intercepting Proxies

Some corporate proxies inspect HTTPS traffic and re-sign certificates with an internal certificate authority. In that case Bazel may fail with SSL or PKIX validation errors even though the proxy address is correct.

Typical symptom:

• certificate path building failure
• unable to find valid certification path
• handshake failure during repository download

If your organization provides a corporate root certificate, the Java runtime used by Bazel may need to trust it.

1keytool -importcert \
2  -alias corp-proxy-root \
3  -keystore "$JAVA_HOME/lib/security/cacerts" \
4  -file corp-root-ca.pem

Use the correct trust-store path for the JDK Bazel is actually using, and coordinate this with your security team rather than modifying random JDK installations.

Verify Which JDK Bazel Uses

Bazel network behavior depends partly on the JVM it runs with. Confirm the Java setup before debugging proxy errors forever.

bazel info java-home
java -version

If Bazel and your shell use different JDKs, one may trust the proxy CA and the other may not.

Repository Rules Need Reachable URLs

Even with proxy configuration, WORKSPACE or module URLs still need to be valid and allowed by policy.

Example external repository rule:

1http_archive(
2    name = "rules_pkg",
3    urls = ["https://github.com/bazelbuild/rules_pkg/releases/download/0.10.0/rules_pkg-0.10.0.tar.gz"],
4    sha256 = "example_sha256_value",
5)

If GitHub or the public registry is blocked, proxy configuration alone will not solve the problem. You may need an internal artifact mirror.

Internal Mirror Strategy

For tightly controlled enterprise networks, the most reliable setup is often to mirror external archives internally and point Bazel there instead.

Benefits:

• fewer internet dependencies during builds
• better compliance and auditability
• faster repeated fetches inside the network

In practice, teams mirror release tarballs and update urls to internal endpoints first, leaving public URLs only as a fallback if policy allows it.

Debugging Checklist

When Bazel still fails behind a proxy, check these in order:

1. verify proxy variables in the current shell
2. verify .bazelrc forwards needed variables
3. verify Bazel can resolve and reach dependency hosts
4. verify TLS trust-store setup if certificates are intercepted
5. verify repository URLs are permitted by company policy

That sequence separates network, certificate, and repository-rule problems cleanly.

Common Pitfalls

• Setting proxy variables in a shell but launching Bazel from an IDE that does not inherit them. Fix: confirm the actual process environment or use .bazelrc.
• Forwarding action_env but not repo_env. Fix: configure both when repository fetching is affected.
• Assuming proxy configuration fixes certificate interception automatically. Fix: validate the JDK trust store used by Bazel.
• Leaving public URLs in repository rules when corporate policy blocks them. Fix: use an approved internal mirror.
• Debugging Bazel before verifying which JDK it is using. Fix: check bazel info java-home early.

Summary

• Bazel proxy failures usually involve environment forwarding, certificate trust, or blocked repository URLs.
• Set proxy variables in the launching environment and forward them through .bazelrc.
• Verify the JDK used by Bazel, not just the system Java.
• Handle TLS-intercepting proxies with the correct trust-store configuration.
• For strict enterprise networks, internal mirrors are often more reliable than direct internet fetches.