NO_PROXY not respected (internal host goes through proxy) in CI

A request to an internal or localhost address is being sent through the proxy even though you set NO_PROXY. The entry does not match the host as the tool compares it, or the tool honors a differently spelled variable, so the bypass never applies.

What this error means

Calls to internal services or localhost fail with proxy errors (407, tunnel failures) even though NO_PROXY lists them; removing the proxy env vars makes the same calls succeed.

Terminal

# NO_PROXY=internal.example.com set, yet:
curl: (56) Received HTTP code 407 from proxy after CONNECT
# request to internal.example.com still went via the proxy

Common causes

The no_proxy pattern does not match the host

no_proxy matching is literal per tool: an entry like example.com may not cover sub.example.com, and IPs, ports, or CIDR ranges are handled inconsistently.

The tool reads a different case or name

Some tools honor no_proxy, others NO_PROXY; setting only one can leave the other client still proxying.

How to fix it

List every host and set both cases

Enumerate the exact hosts and IPs that must bypass the proxy, including subdomains.
Set both NO_PROXY and no_proxy to the same value.
Re-run and confirm internal calls no longer hit the proxy.

.github/workflows/ci.yml

env:
  NO_PROXY: localhost,127.0.0.1,internal.example.com,.internal.example.com
  no_proxy: localhost,127.0.0.1,internal.example.com,.internal.example.com

Use leading-dot suffixes for subdomains

A leading dot (.internal.example.com) matches all subdomains in most clients, closing the gap where a bare domain only matched the apex.

How to prevent it

Always set NO_PROXY and no_proxy together with identical values.
Include localhost and 127.0.0.1 so local services never route through the proxy.
Use leading-dot patterns to cover subdomains explicitly.