Does NO_PROXY Support Regex and Wildcard Patterns?
Choose a bypass expression the actual client supports instead of assuming NO_PROXY accepts regular expressions or browser wildcard syntax.
The exception looks convincing: *.server.*. It also looks like a shell pattern. Neither fact proves that your HTTP client understands it.
NO_PROXY is not a shared regular-expression engine. One client's special asterisk does not establish support for arbitrary wildcards in the middle of a name. curl documents a single * as an all-hosts bypass. That is very different from promising that *.server.* selects a family of domains.
Start with the names you actually request. If the requirement is one known domain and its subdomains, use the consumer's documented domain form. If the requirement is several unrelated names containing a word, a supported route-selection API or PAC policy may be needed. Adding more punctuation to an unsupported pattern cannot supply that feature.
Keep a few counterexamples beside the intended matches. Should server.example, files.server.example, and server.other.test all bypass? What about a name containing the same letters without the same domain boundary? Those answers define the requirement more clearly than calling the setting a “wildcard.”
Changing clients is a reason to check the pattern again. A bypass rule copied from a browser extension is not automatically valid in an environment variable consumed by a different program.