How to Test NO_PROXY Rules Before Traffic Bypasses Your Proxy

NO_PROXY is an egress policy, not a harmless convenience variable. One broad suffix, a wildcard, an uppercase-versus-lowercase conflict or a runtime-specific parser can send requests directly when operators expect them to pass through a proxy. The result may be an unexpected source IP, missing audit evidence, regional inconsistency or a silent fallback that hides proxy failures.

This guide provides a controlled way to test bypass behavior before deployment. Use only destinations and networks you are authorized to test.

Start with the effective configuration

Record the value actually visible inside the running process, not merely the value in a deployment template. Inventory:

• lowercase and uppercase proxy variables;
• command-line proxy and bypass options;
• application or SDK proxy agents;
• container, serverless and service-manager environment injection;
• operating-system proxy discovery;
• network controls that permit or deny direct egress.

Restart or recycle a canary after changing environment variables. Long-lived workers may retain an old environment or an already-created connection pool.

Do not assume clients interpret the same string

There is no single behavior shared by every HTTP stack. Current Node.js built-in proxy support gives lowercase environment variables precedence over uppercase variants and supports exact hosts, domain suffixes, wildcard entries, IP addresses, IP ranges and host-and-port entries. It must also be enabled through the documented environment, command-line, global configuration or agent mechanism.

curl accepts host and domain rules, a wildcard that disables proxying for all destinations, and CIDR notation. Numerical IPv6 entries are written without brackets. An empty libcurl no-proxy option explicitly restores proxy use for all hosts, which is materially different from a wildcard.

Python urllib can discover proxy settings from the environment and operating system; its documented no_proxy behavior uses comma-separated hostname suffixes with optional ports. A custom ProxyHandler can change or disable that discovery.

Treat these as client-specific contracts. Test every runtime and version that exists in production.

Build a route-decision matrix

Use two synthetic endpoints you control: one expected to use the proxy and one explicitly allowed to connect directly. Add cases that should not match so accidental expansion is visible.

Also test whitespace, trailing dots, internationalized hostnames, punycode, redirects, DNS aliases and a hostname with the same suffix embedded in an unrelated domain. A match should be intentional, narrow and documented.

Prove the route instead of inferring it

An HTTP 200 response proves reachability, not the path. Collect two independent signals:

1. A proxy-side synthetic request identifier that appears only when the request crossed the proxy.
2. The destination’s observation of a known proxy egress or known direct canary egress.

Record aliases rather than credentials or raw customer identifiers:

runtime_version
policy_hash
test_case
destination_alias
expected_route
proxy_observed
egress_class
status_class
latency_bucket

If the two signals disagree, fail the test. Do not let a successful response override a route mismatch.

Test the actual deployment boundary

Run the matrix inside the same container image, host class and startup path used in production. A local shell may have different casing, inherited variables or OS proxy discovery. Validate:

1. a clean process start;
2. a warm process with connection reuse;
3. a configuration update followed by the intended restart;
4. proxy unavailability without direct fallback;
5. a redirect from an allowed host to a non-allowed host;
6. both IPv4 and IPv6 resolution where applicable.

For Node.js, test both the global proxy setup and any custom agent supplied by the application. For curl, compare environment-driven behavior with explicit command-line or libcurl options. For Python, confirm whether a custom opener overrides environment discovery.

Make direct fallback fail closed

A robust design uses a short, reviewed bypass list and blocks unexpected direct egress at the network layer. Recommended controls are:

• default proxy routing for outbound web traffic;
• explicit exact-host or narrowly scoped suffix exceptions;
• no wildcard in persistent production configuration;
• startup validation that rejects ambiguous or malformed entries;
• an allowlist for direct destinations and ports;
• bounded retries that do not switch to direct mode;
• a policy hash in sanitized telemetry;
• staged rollout with a known rollback configuration.

Do not place proxy credentials in URLs, logs or test fixtures. If an application cannot express the required bypass semantics safely, use explicit per-destination routing rather than a growing global variable.

Release checklist

• [ ] Effective lowercase and uppercase variables are captured.
• [ ] Runtime and client versions are recorded.
• [ ] Exact host, suffix, port, IPv4 and IPv6 cases are tested.
• [ ] Unsupported CIDR or range syntax is identified.
• [ ] Wildcard and empty-value behavior are verified.
• [ ] Redirects cannot escape the intended route.
• [ ] Proxy-side and destination-side evidence agree.
• [ ] A proxy outage does not trigger direct fallback.
• [ ] Direct egress is restricted at the network layer.
• [ ] Logs contain no credentials or sensitive identifiers.
• [ ] Canary restart and rollback procedures are tested.

Related 98IP guides cover proxy failover recovery drills, curl proxy authentication 407 troubleshooting, and proxy credential rotation.

FAQ

Does .example.internal match only one host?

Usually it represents a suffix rather than one exact host, but exact behavior varies by client. Include the parent, a subdomain, a sibling and a look-alike domain in the matrix.

Is * a safe temporary default?

No. In common clients it bypasses the proxy for every destination. Use it only in a controlled diagnostic environment and prevent it from entering persistent production configuration.

Can a firewall replace application tests?

No. Network enforcement is an important fail-closed control, but the application still needs route tests so configuration errors are detected before they become outages.

Should a failed proxy request retry directly?

Not unless a separately approved policy explicitly permits that route. Silent direct fallback changes identity, geography and audit coverage. Prefer bounded proxy retries and a visible failure.

Compliance note

Test only infrastructure and endpoints you own or are authorized to assess. Keep bypass lists limited to lawful business needs, respect destination terms and rate limits, minimize collected data, and never use routing controls to evade access restrictions or conceal abusive activity.

Source note: Node.js project, HTTP documentation; curl project, curl manual and CURLOPT_NOPROXY documentation; Python Software Foundation, urllib documentation. Accessed September 5, 2026.