CIDR notation in NO_PROXY is not evaluated

[abx-its-e2emon]

Describe the bug
I am forced to use a company proxy for extranet connections, but not for intranet connections.
HC vault CLI disrespects CIDR subnet notation in NO_PROXY and tries to use the proxy to connect to an internal Vault instance running at vault.mycompany.tld. At least under Windows in PowerShell.

To Reproduce
Steps to reproduce the behavior:

1. In PowerShell 7.6 set the environment variables $env:VAULT_ADDR="https://vault.mycompany.tld/", $env:HTTP_PROXY, $env:HTTPS_PROXY and $env:NO_PROXY. Set $env:NO_PROXY="localhost,127.0.0.1,10.66.0.0/16"
2. Run either vault status or vault login
3. See error HTML from Proxy

Expected behavior
I would expect the HC Vault CLI's HTTP framework to:

• go through comma-separated NO_PROXY entries
• if the entry contains a subnet in CIDR notation expand the "10.66.0.0/16" to an address range
• do the nslookup of vault.mycompany.tld
• match the returned IP of 10.66.0.88
• realize that it is on the subnet of 10.66.0.0/16
• do NOT use a proxy when connecting to vault.mycompany.tld

Environment:

• Vault Server Version: 1.17.2
• Vault CLI Version: Vault v2.0.0 (cf1ce4d), built 2026-04-13T18:49:01Z, installed using WinGet
• Server Operating System/Architecture: Windows AMD64 PowerShell 7.6.1

Additional context
Setting $env:NO_PROXY="localhost,127.0.0.1,10.66.0.0/16,.mycompany.tld" including the domain works just fine with Vault CLI. Then it matches and does not use the proxy.

Seems like the HTTP framework within HC Vault CLI is not calculating CIDR subnets and matching them to the IP returned by the hostname lookup.

[dosubot]

This is a known behavioral limitation in how Go's standard library handles CIDR notation in NO_PROXY — specifically, Go's httpproxy package does support CIDR notation, but it only matches against the literal IP address of the destination, not by performing a DNS lookup of the hostname first. In other words, if you connect to vault.mycompany.tld, Go checks NO_PROXY against that hostname string — it does not resolve the hostname to an IP and then check if that IP falls within a CIDR range.

This is documented behavior in Go's httpproxy package: CIDR entries in NO_PROXY only match when the request URL contains an IP address directly (e.g., https://10.66.0.88/), not when it contains a hostname that happens to resolve to an IP in that range.

Workaround (which you've already found): Add the domain suffix to NO_PROXY:

$env:NO_PROXY="localhost,127.0.0.1,10.66.0.0/16,.mycompany.tld"

This is the correct and intended approach — domain suffixes (.mycompany.tld) match hostnames directly without requiring DNS resolution.

Additionally, if you're using VAULT_PROXY_ADDR or VAULT_HTTP_PROXY, note that these use http.ProxyURL() internally [1], which bypasses NO_PROXY entirely. Make sure you're relying on the standard HTTP_PROXY/HTTPS_PROXY/NO_PROXY environment variables instead for proper proxy bypass behavior.

This isn't unique to Vault — it's how Go's HTTP client works for any Go-based tool. The rationale is that performing DNS lookups during proxy decisions would add latency and create potential circular dependencies (the DNS server itself might require a proxy).

Tagging @heatherezell to flag this for product and engineering review — Vault could potentially improve this by documenting the limitation more clearly or implementing custom proxy logic that resolves hostnames before CIDR matching.

Written by @dosu, approved by heatherezell

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.