Problem: proxy env vars set but not taking effect — some commands use the proxy, some don't (HTTP_PROXY case-sensitivity trap) —— Trove problem library

What you will run into

You put export HTTP_PROXY=http://127.0.0.1:7890 in .bashrc, yet curl still times out direct, git is still slow, pip install still errors — the proxy is set but some commands just don't listen.

Even worse, the same variable works for pip but not curl, or vice versa.

Why this happens

Tools differ in case-sensitivity for proxy env vars — that is the root of all confusion (measured 2026-09-01 on this machine, curl 8.18 / pip 25.1):

• curl only honors lowercase http_proxy / https_proxy: it deliberately ignores uppercase HTTP_PROXY (security design — uppercase vars can be injected via CGI environments). HTTPS_PROXY uppercase is the only exception that works (explicitly allowed by curl).
• pip honors uppercase HTTP_PROXY / HTTPS_PROXY (lowercase also works).
• git honors uppercase (also the http.proxy config key).
• npm honors both, but npm config get proxy takes precedence.

So when you only export uppercase HTTP_PROXY: pip uses the proxy, curl ignores it and goes direct — that is exactly why "some work, some don't".

Second trap is NO_PROXY: once a proxy is set, local/intranet requests (localhost, company intranet, 127.0.0.1) may also be forced through the proxy and fail.

Explicitly bypass with NO_PROXY=localhost,127.0.0.1,intranet.host (measured: http_proxy=dead-port + NO_PROXY=127.0.0.1 → curl connects directly; removing NO_PROXY fails immediately).

Step by step

1. First confirm the proxy port is actually listening: ss -ltn | grep 7890 (or your proxy tool's port). No proxy daemon, no variable will help.
2. Verify per tool:

   http_proxy=http://127.0.0.1:1 curl -s --max-time 3 http://example.com; echo "curl: $?"
   HTTP_PROXY=http://127.0.0.1:1 pip3 download --no-deps -d /tmp/t six; echo "pip: $?"

curl non-zero = lowercase honored; pip failure = uppercase honored.

1. git separately: git config --global --get http.proxy — git accepts the http.proxy config key in addition to env vars; config wins when both exist.
2. Proxy only for some domains (campus/company proxies often have allowlists): exclude intranet via NO_PROXY, fall back to ALL_PROXY for SOCKS5 setups.
3. Containers don't inherit: Docker containers do not inherit host proxy env vars by default — pass them with docker run -e http_proxy=... or compose environment:.

How to confirm it works

# 1. All four env vars + NO_PROXY present
env | grep -i proxy
# 2. Real request succeeds fast (proxy vs direct latency is obvious)
curl -o /dev/null -s -w 'time=%{time_total}s
' --max-time 8 https://example.com
# 3. Negative check (proxy truly read): pointing at a dead port must fail immediately
http_proxy=http://127.0.0.1:1 curl -s -o /dev/null --max-time 3 http://example.com && echo "BAD: proxy not used" || echo "OK: proxy var honored"

Other environments

• Windows (PowerShell): case-insensitive — $env:HTTP_PROXY and $env:http_proxy are equivalent, but curl.exe / git behave the same as WSL (curl.exe also ignores uppercase HTTP_PROXY).
• macOS: identical to Linux (same curl security design).
• Proxy tools with "system proxy" mode: Clash/V2Ray system-proxy mode changes OS-level settings (Windows proxy switch / /etc/environment), not shell env vars — env | grep proxy being empty is normal then; commands go through the system proxy without vars.

Verification evidence

• 2026-09-01 measured on this machine (WSL Ubuntu 26.04, curl 8.18 / pip 25.1): local repro log 2026-09-01
• Baseline direct to 127.0.0.1:8089 → 200; uppercase HTTP_PROXY=dead-port → curl still 200 (uppercase ignored, proven);
• lowercase http_proxy=dead-port → curl 000 (lowercase honored, proven);
• HTTPS_PROXY=dead-port + https target → 000 (uppercase HTTPS_PROXY honored, proven);
• http_proxy=dead-port + NO_PROXY=127.0.0.1 → 200 (NO_PROXY bypass, proven);
• pip under uppercase HTTP_PROXY=dead-port → Could not find a version (pip honors uppercase, proven); adding NO_PROXY=pypi.org → download succeeds.