¿Admite NO_PROXY expresiones regulares y patrones wildcard?
Elija una expresión de omisión que admita el cliente real en lugar de suponer que NO_PROXY acepta expresiones regulares o la sintaxis wildcard del navegador.
La excepción parece convincente: *.server.*. También parece un patrón de shell. Ninguno de los dos hechos demuestra que su cliente HTTP la entienda.
NO_PROXY no es un motor compartido de expresiones regulares. El asterisco especial de un cliente no demuestra compatibilidad con wildcards arbitrarios en medio de un nombre. curl documenta un único * como omisión de todos los hosts. Eso es muy distinto de prometer que *.server.* selecciona una familia de dominios.
Empiece por los nombres que realmente solicita. Si el requisito es un dominio conocido y sus subdominios, use la forma de dominio documentada por el consumidor. Si el requisito son varios nombres no relacionados que contienen una palabra, puede hacer falta una API de selección de ruta compatible o una política PAC. Añadir más puntuación a un patrón no compatible no puede aportar esa función.
Mantenga algunos contraejemplos junto a las coincidencias previstas. ¿Deben omitirse server.example, files.server.example y server.other.test? ¿Y un nombre con las mismas letras sin la misma frontera de dominio? Esas respuestas definen el requisito con más claridad que llamar «wildcard» al ajuste.
Cambiar de cliente es motivo para comprobar el patrón de nuevo. Una regla de omisión copiada de una extensión de navegador no es automáticamente válida en una variable de entorno que lee otro programa.