Proxy Environment Variables with curl: HTTP_PROXY, HTTPS_PROXY, ALL_PROXY, and NO_PROXY

curl can select a proxy from environment variables even when the command line contains no --proxy option. That is useful for developer shells, CI runners, containers, and service processes—but it also means two machines can run the same curl command and take different network paths.

This guide shows how curl evaluates http_proxy, HTTPS_PROXY, ALL_PROXY, and NO_PROXY, how command-line options interact with them, and how to prove which route was actually used without exposing proxy credentials.

Direct answer

For curl:

• use lowercase http_proxy for HTTP target URLs;
• use https_proxy or HTTPS_PROXY for HTTPS target URLs;
• use ALL_PROXY or all_proxy only as a fallback when no protocol-specific proxy variable applies;
• use NO_PROXY or no_proxy to bypass the proxy for selected destinations;
• use --proxy when you want to select a proxy explicitly for one command;
• remember that NO_PROXY can still bypass an explicitly supplied --proxy unless you override the no-proxy list;
• do not depend on uppercase HTTP_PROXY: curl intentionally accepts http_proxy only in lowercase.

These are curl/libcurl rules, not a universal standard. Other clients can differ in case handling, precedence, wildcard matching, and CIDR support.

How curl chooses the route

The target URL scheme decides which protocol-specific proxy variable curl checks. An https:// target therefore uses the HTTPS proxy setting, even when the selected proxy itself is an ordinary http:// proxy.

That distinction matters during debugging. If --proxy appears to be ignored, inspect NO_PROXY before assuming the proxy option failed.

Why http_proxy is lowercase-only

CGI environments historically translate incoming HTTP request headers into environment variables prefixed with HTTP_. An incoming Proxy header can therefore become HTTP_PROXY inside a CGI process.

If an HTTP client trusted that uppercase variable, request-controlled input could influence an outbound proxy setting. curl avoids that class of problem by recognizing http_proxy only in lowercase. curl's current proxy documentation describes this exception, and RFC 3875 documents CGI's HTTP_ meta-variable convention.

Operational rule: do not “fix” curl proxy routing by exporting uppercase HTTP_PROXY. Set lowercase http_proxy, or use an explicit --proxy option for a controlled test.

Safe baseline: inspect configuration without dumping secrets

Do not start with env, set, or a complete CI environment dump. Proxy variables frequently contain credentials.

First check only whether relevant variables exist:

for name in http_proxy https_proxy HTTPS_PROXY all_proxy ALL_PROXY no_proxy NO_PROXY; do
  if printenv "$name" >/dev/null 2>&1; then
    printf '%s=<set>\n' "$name"
  else
    printf '%s=<unset>\n' "$name"
  fi
done

Then record the curl build you are actually debugging:

curl --version

This matters because behavior such as CIDR matching in no-proxy lists is version-dependent.

Test proxy selection with one controlled request

Use documentation placeholders and an authorized target:

export PROXY_HOST='proxy.example.net'
export PROXY_PORT='8000'
export PROXY_USER='example-user'
export PROXY_PASS='example-password'

curl --silent --show-error --fail-with-body \
  --proxy "http://${PROXY_HOST}:${PROXY_PORT}" \
  --proxy-user "${PROXY_USER}:${PROXY_PASS}" \
  --connect-timeout 10 \
  --max-time 30 \
  --write-out '\nhttp=%{http_code} remote_ip=%{remote_ip} proxy_used=%{proxy_used}\n' \
  'https://example.com/'

proxy.example.net and the credentials above are placeholders. Use the timeout values as starting guardrails, then tune them from behavior you observe in your own environment rather than treating them as BytesFlows performance targets.

For account-specific BytesFlows hostnames, ports, usernames, GEO selectors, and session controls, copy the current values from the Dashboard rather than reconstructing them from an article or screenshot.

Prove the effect of NO_PROXY

Suppose the environment contains:

export HTTPS_PROXY='http://proxy.example.net:8000'
export NO_PROXY='example.com'

This request is expected to bypass the proxy because the destination matches NO_PROXY:

curl --verbose 'https://example.com/'

Adding --proxy alone does not necessarily cancel that bypass:

curl --proxy 'http://proxy.example.net:8000' 'https://example.com/'

To perform a controlled test that explicitly clears the no-proxy exclusion for that command, curl documents an empty --noproxy value:

curl \
  --proxy 'http://proxy.example.net:8000' \
  --noproxy '' \
  'https://example.com/'

Conversely, to suppress an environment-selected proxy for one request, use an empty proxy value:

curl --proxy '' 'https://example.com/'

These are diagnostic boundaries. Do not leave temporary overrides in production configuration after the cause is understood.

NO_PROXY matching rules worth testing explicitly

curl supports comma-separated exclusions including hostnames, domain entries, numerical IP addresses, a single * that matches all hosts, and CIDR notation in curl 7.86.0 and later.

Example:

export NO_PROXY='localhost,127.0.0.1,.internal.example,192.168.0.0/16'

Before deploying a list like this, record:

• the exact curl version;
• the target hostname exactly as curl receives it;
• whether the target is a hostname, IPv4 address, or IPv6 address;
• whether a domain entry is intentionally broad;
• whether a CIDR rule is supported by every deployed curl version;
• whether the direct route is intended in every environment.

Avoid assuming shell glob syntax such as *.internal.example is portable proxy-exclusion syntax. A broad NO_PROXY=* disables proxy use for all matching requests and should be treated as a high-impact configuration change.

Use a route matrix instead of guessing

When development works but CI or production does not, compare one variable at a time.

Change only one routing input between runs. Otherwise a successful retry does not tell you whether the cause was proxy selection, DNS, authentication, target behavior, or an unrelated network change.

Failure classification

A returned HTTP status is not the same thing as a curl process exit code. Preserve both when debugging.

Keep proxy credentials out of evidence bundles

Proxy URLs can contain usernames and passwords. Environment variables can leak through CI logs, crash reports, shell history, support bundles, process inspection, screenshots, or accidental debug output.

Prefer secret injection for credentials and keep non-secret endpoint configuration separate where practical. Do not commit real proxy URLs to repositories or copy complete environment dumps into tickets.

A useful sanitized evidence record is:

Timestamp and timezone:
curl version:
OS/container image:
Target URL scheme: http | https
Proxy source: environment | explicit --proxy | none
Selected variable name: http_proxy | HTTPS_PROXY | ALL_PROXY | other
Proxy scheme: http | https | socks5 | socks5h
Proxy hostname: redacted or approved test hostname
Proxy port:
NO_PROXY present: yes | no
NO_PROXY rule relevant to target: yes | no | unknown
Expected route: proxy | direct
Observed route evidence:
HTTP status, if any:
curl exit code:
Exact sanitized error:

Never include a proxy password, Proxy-Authorization value, session token, full account username, or raw environment dump.

Common mistakes

Setting only HTTP_PROXY

curl intentionally does not treat uppercase HTTP_PROXY as the HTTP proxy environment variable. Use lowercase http_proxy.

Expecting http_proxy to proxy an HTTPS target

Proxy-variable selection follows the target URL scheme. For an HTTPS target, inspect https_proxy / HTTPS_PROXY rather than assuming http_proxy applies.

Assuming HTTPS_PROXY means “HTTPS proxy”

It means “the proxy selected for HTTPS target URLs.” The proxy URL itself determines whether the client-to-proxy connection uses HTTP, HTTPS, SOCKS, or another supported proxy scheme.

Assuming --proxy always defeats NO_PROXY

Current curl documentation states that NO_PROXY can disable proxy use even when --proxy is supplied. Use --noproxy '' when you intentionally need to clear the inherited exclusion for a diagnostic run.

Treating NO_PROXY=* as harmless

A single * matches all hosts and can silently convert a proxied workload into direct traffic.

Printing the whole environment

That can leak credentials and account identifiers. Record presence and sanitized configuration instead.

Production checklist

FAQ

Does --proxy override HTTPS_PROXY or ALL_PROXY?

Yes for proxy selection: an explicit --proxy takes precedence over proxy-selection environment variables. However, a matching NO_PROXY can still result in a direct connection unless the no-proxy list is explicitly overridden.

How do I temporarily ignore NO_PROXY?

For a controlled curl command, use --noproxy ''. Do not permanently remove organization-wide exclusions without understanding why they exist.

How do I temporarily ignore all proxy environment variables?

Use --proxy '' for that request. This is useful as a direct-route control during troubleshooting.

Does HTTPS_PROXY=http://proxy.example.net:8000 make the proxy connection HTTPS?

No. HTTPS_PROXY is chosen because the target URL uses HTTPS. The proxy URL's own scheme determines how curl connects to the proxy.

Can I copy NO_PROXY rules from another language runtime?

Do not assume identical behavior. NO_PROXY is widely used but matching semantics vary between clients and runtimes. Test the exact curl version deployed in your environment.

Does a successful curl request prove the requested proxy geography or session behavior?

No. It proves only what the captured evidence demonstrates. Verify exit IP, requested versus observed GEO, and session behavior separately when those properties matter.

Related BytesFlows guides

For account-specific endpoint, port, GEO, authentication, and session settings, use the BytesFlows proxy setup guide. For credential lifecycle work, see Rotate Proxy Credentials Safely. Avoid using a generic proxy-route result as proof of target permission or compatibility.

References

• curl official proxy environment-variable documentation↗: scheme-specific variables, ALL_PROXY, NO_PROXY, CIDR support, and the lowercase-only http_proxy rule.
• curl official manual↗: --proxy, --noproxy, environment-variable precedence, explicit empty overrides, proxy schemes, and no-proxy matching.
• RFC 3875, CGI/1.1↗: CGI request meta-variable conventions that explain the security background for uppercase HTTP_PROXY.

Treat the commands as diagnostic examples rather than performance evidence. Validate them with your own authorized endpoint and target before drawing conclusions about availability, compatibility, latency, geography, or production behavior.