No Proxy: What NO_PROXY Skips in Proxy Setup

No proxy means certain requests bypass your proxy instead of using it. In setup, NO_PROXY is the skip list that keeps local or internal hosts direct.

That small bypass list can decide whether a scraper, API client, or health check uses the paid proxy route or quietly talks straight to the destination. The problem is that tools do not all read the list in the same way.

Key takeaways

• NO_PROXY is a bypass list: hosts on the list go direct even when a proxy is configured.
• Start with local targets: include loopback entries and private domains you control.
• Do not bypass your test endpoint: when testing a ColdProxy route, keep the IP-check endpoint out of NO_PROXY or the check can show your direct IP.
• Check each client: curl, Wget, Go, browsers, and language SDKs can treat patterns, case, wildcards, and CIDR differently.

No proxy: when does traffic skip the proxy?

Traffic skips the proxy when the destination matches a bypass rule. In a shell, that rule is often NO_PROXY or no_proxy. In a browser or desktop app, it may appear as a field called no proxy, bypass list, exclusions, or proxy exceptions.

GitLab's 2025 engineering post describes the core problem well: "no standard exists for how clients should handle these variables." That is the reason a setting that works in one CLI can fail in another.

The safest mental model is simple. Proxy variables decide the default route. The no-proxy list names exceptions. If a request matches an exception, it goes direct. If it does not, the client can use the configured proxy.

NO_PROXY: what should you put in the bypass list?

Put only destinations that should never leave through the proxy. For most teams, the first entries are local services, private admin domains, and health-check addresses that must stay on the private network.

• Loopback names: localhost, 127.0.0.1, and ::1 keep local dev servers direct.
• Internal domains: a suffix such as .internal.example can keep company-only hosts out of the proxy, if your client supports suffix matching.
• Exact hosts: use exact names for APIs, admin panels, or metadata services that must not use the proxy.
• Ports when supported: some clients allow host-plus-port entries such as example.com:443. Check the client documentation before relying on this.
• CIDR only when documented: curl documents CIDR support for no-proxy matching starting in curl 7.86.0, but that does not mean every client supports 10.0.0.0/8.

curl's CURLOPT_NOPROXY reference says the value is a comma-separated hostname list, supports a single * wildcard, and expects IPv6 numeric addresses without square brackets. Treat those as curl rules, not universal rules.

NO_PROXY example: what does a safe starting config look like?

This example keeps local and private targets direct while sending normal external requests through a ColdProxy gateway. Replace the username, password, service ID, and port with the values from your account.

1export http_proxy="http://USERNAME:PASSWORD@gw-2312.coldproxy.com:30000"
2export https_proxy="$http_proxy"
3export NO_PROXY="localhost,127.0.0.1,::1,.internal.example"
4
5# This should go through the proxy because api.vipv6proxy.com is not in NO_PROXY.
6curl https://api.vipv6proxy.com/api/checker/my-ip

Do not add api.vipv6proxy.com or api6.vipv6proxy.com to NO_PROXY during this check. If you do, your test can bypass the proxy and return the direct network IP, which makes a working proxy look wrong.

For a browser check, use the ColdProxy proxy checker when you want to test a proxy string, and use My IP when you want to compare the public IP your browser sees before and after a proxy or VPN change.

Proxy environment variables: why do clients disagree?

Proxy environment variables grew from tool behavior, not from one shared internet standard. That history matters when you move the same proxy settings between a shell, a container, a Go service, and a browser profile.

• curl: curl accepts proxy environment variables, but everything curl notes that the HTTP proxy variable is accepted only as lowercase http_proxy because uppercase HTTP_PROXY has a CGI-related security history.
• Go: Go net/http documentation says ProxyFromEnvironment reads HTTP_PROXY, HTTPS_PROXY, and NO_PROXY, plus lowercase versions, unless the request is excluded.
• HashiCorp Vault: HashiCorp support guidance lists common NO_PROXY entry types: IP prefixes, CIDR notation, domain names, the * label, optional literal ports, and comma-separated combinations.

The practical rule: do not copy a bypass list between tools without testing it in the tool that will run the job. The spelling and pattern support are part of the client contract.

ColdProxy check: how do you prove NO_PROXY did not hide the proxy?

Run one positive check and one bypass check. The positive check should hit a public endpoint through the proxy. The bypass check should hit a local or internal target that you expect to stay direct.

1# Positive check: should show the proxy exit IP.
2export http_proxy="http://USERNAME:PASSWORD@gw-2312.coldproxy.com:30000"
3export https_proxy="$http_proxy"
4export NO_PROXY="localhost,127.0.0.1,::1,.internal.example"
5curl https://api.vipv6proxy.com/api/checker/my-ip
6
7# Bypass check: should stay direct to your local service.
8curl http://localhost:8080/health

If the public check shows your real ISP, inspect NO_PROXY first. Then inspect credentials, protocol, and port. The proxy host and port guide covers the host and port side; the HTTP proxy guide covers HTTP proxy behavior and status code 407.

If you prefer explicit flags while debugging, the ColdProxy cURL guide shows -x, --proxy, --proxy-user, HTTP, HTTPS, and SOCKS5 examples against the same IP-check endpoint. Explicit flags remove one layer of environment-variable confusion.

No proxy mistakes: what usually breaks?

• The bypass list is too broad: a wildcard or domain suffix can send more traffic direct than intended. Use the narrowest entry that works.
• The test endpoint is bypassed: if the exit-IP test host is in NO_PROXY, the result proves the direct route, not the proxy route.
• The client ignores the spelling: one client may read NO_PROXY; another may expect no_proxy or a UI-level exception list.
• CIDR is assumed everywhere: CIDR works in modern curl, but other clients may treat 10.0.0.0/8 as plain text.
• IPv6 syntax is copied from URLs: a proxy URL may use brackets around an IPv6 literal, while a no-proxy list may require the bare address. Check the client rule before shipping.
• The proxy plan is blamed too early: first prove whether the request used the proxy at all, then compare plans on pricing if the workflow needs a different proxy type or billing model.

Frequently Asked Questions

What does no proxy mean?

No proxy means the client sends a request directly instead of through the configured proxy. In setup screens, it usually means a bypass list or an option that disables proxy use for selected destinations.

Is NO_PROXY a standard?

No. Many tools support NO_PROXY or no_proxy, but behavior is not fully standardized. Pattern matching, case handling, wildcards, CIDR, ports, and IPv6 literals can differ by client.

Should localhost be in NO_PROXY?

Usually yes. Keep localhost and other loopback entries in the bypass list so local dev servers and health checks do not leave through the proxy by accident.

Does NO_PROXY work with curl?

Yes. curl supports no-proxy behavior through environment variables and options such as --noproxy and libcurl CURLOPT_NOPROXY. Confirm the exact syntax in the current curl documentation before relying on wildcards or CIDR.

Why does my proxy test show my real IP?

A real-IP result often means the request bypassed the proxy, used the wrong environment variable, or hit a target listed in NO_PROXY. Remove the IP-check host from the bypass list, run one explicit curl -x test, then test again through your app.