Test NO_PROXY as Routing Logic, Not Just a String

NO_PROXY is executable routing policy. One overbroad entry can silently send traffic direct even when your proxy variables look correct.

Why this matters

A bypass can change source IP, region, egress monitoring, and destination behavior. That makes proxy incidents look inconsistent across local development, CI, containers, and production.

A successful response is not proof that the proxy was used.

Build a route matrix

For every bypass entry, test:

• the exact host;
• a subdomain;
• the parent domain;
• an unrelated lookalike;
• explicit and default ports;
• IPv4 and IPv6;
• redirects to another host;
• development, CI, and a production-like container.

Write the expected route before each test: proxy or direct. Then compare it with the observed route from proxy access logs or another controlled signal.

Do not assume client behavior

Clients differ in how they interpret:

• leading dots and domain suffixes;
• wildcards;
• CIDR notation;
• host-plus-port entries;
• IPv6 brackets;
• uppercase and lowercase variable names.

Test the exact library and version you deploy. curl, Python, Node.js, container tooling, and service meshes may make different decisions from the same value.

Check layered configuration

A shell can define one value, the container another, and the application a third. CI platforms and build tools may also inject proxy settings.

Inspect which variables are present, their precedence, and which process reads them. Do this without printing proxy credentials or confidential internal inventory.

env | grep -iE '^(http|https|all|no)_proxy='

Sanitize the output before sharing it. Credential-bearing proxy URLs must never appear in public logs.

Keep the policy small

Every bypass entry is an exception. Give it an owner, reason, and review date. Prefer exact hosts and ports when possible. Remove expired development rules and add regression tests for critical destinations.

At minimum, keep one test that must use the proxy and one that must bypass it. Fail the test when the actual route differs from policy.

Common failure patterns

• A suffix intended for one host matches many subdomains.
• A client ignores CIDR syntax it does not support.
• Lowercase no_proxy overrides a different uppercase value.
• A redirect reaches a host governed by another rule.
• IPv6 formatting prevents an expected match.
• A container replaces rather than extends the inherited bypass list.

Incident checklist

Capture the client version, variable names, a redacted bypass list, destination host and port, resolved address family, redirect chain, expected route, observed route, and timestamp.

Do not log passwords, authorization headers, tokens, or sensitive internal hostnames.

The safest bypass list is short, explicit, observable, and tested. Prove the route before replacing a provider or rotating credentials.

Use proxy and bypass configurations only for authorized systems and follow destination terms, privacy requirements, and security policy.

Disclosure: I work with 98IP. English service information: https://en.98ip.com/?k=dev