NO_PROXY Compatibility Across curl, .NET and Containers
Turn a shared direct-routing policy into client-specific configuration using a small set of representative destinations.
A team puts one bypass string into a shared environment file. curl goes direct, another application uses the proxy, and a container behaves differently again. The shared file distributed the same characters. It did not distribute one shared parser.
The durable object is the policy: which destinations should be direct, under which conditions? Keep that separate from the string each program needs.
Write the expected routes first
Use representative addresses, including boundaries rather than only easy successes:
| Destination shape | Question for the policy owner |
|---|---|
| Parent domain | Should it bypass, or only its children? |
| A subdomain | Does it inherit the same route? |
| A literal private IP | Is that address directly reachable from this client? |
| The same service under a hostname | Should name-based and address-based requests agree? |
| Another service port | Does the exception cover the host or one listener? |
Then identify the consumers: the daemon pulling an image, the program inside the container, a language HTTP library, and an interactive browser can all be separate entries. A Docker client proxy configuration can populate container environment values without making every client inside implement the same matching rules.
Translate instead of copying blindly
One documented example of a real difference is the parent-domain boundary. curl's domain exclusion covers the named domain and matching children. .NET's environment policy distinguishes the bare name from the leading-dot subdomain form. A universal rule to “always add a leading dot” cannot express both policies reliably.
IP-range support also depends on the consumer and its version. A machine with a new standalone curl can still run an application linked to an older libcurl, or a client using another library entirely. The operating-system release is not a complete client inventory.
For each consumer, record its supported configuration interface and the smallest expression of the intended routes. A short explicit host list can be better than a clever pattern whose meaning nobody can explain.
Keep configuration evidence separate from connection evidence
A parsed setting or routing-decision API can show what the program selected. A request outcome then shows whether that route was usable. In .NET, HttpClient.DefaultProxy.IsBypassed supplies that configuration-side check when the default proxy is the policy in use. Do not diagnose an unreachable direct service as a bypass-parser failure solely because the request timed out.
Retain the boundary destinations when updating a client or a base image. They make future compatibility changes visible without requiring the whole team to rediscover why the file contains two similar-looking domain entries.