NO_PROXY prend-il en charge les regex et les motifs wildcard ?
Choisissez une expression de contournement que le client réel prend en charge au lieu de supposer que NO_PROXY accepte les expressions régulières ou la syntaxe wildcard du navigateur.
L'exception semble convaincante : *.server.*. Elle ressemble aussi à un motif shell. Aucun de ces deux faits ne prouve que votre client HTTP la comprend.
NO_PROXY n'est pas un moteur d'expressions régulières partagé. L'astérisque particulier d'un client ne prouve pas la prise en charge de wildcards arbitraires au milieu d'un nom. curl documente un seul * comme contournement de tous les hôtes. C'est très différent de promettre que *.server.* sélectionne une famille de domaines.
Partez des noms que vous demandez réellement. Si l'exigence est un domaine connu et ses sous-domaines, utilisez la forme de domaine documentée par le consommateur. Si l'exigence est plusieurs noms sans rapport contenant un mot, une API de sélection de route prise en charge ou une stratégie PAC peut être nécessaire. Ajouter de la ponctuation à un motif non pris en charge ne peut pas fournir cette fonction.
Gardez quelques contre-exemples à côté des correspondances prévues. server.example, files.server.example et server.other.test doivent-ils tous être contournés ? Et un nom contenant les mêmes lettres sans la même frontière de domaine ? Ces réponses définissent l'exigence plus clairement que d'appeler le réglage un « wildcard ».
Changer de client est une raison de vérifier à nouveau le motif. Une règle de contournement copiée d'une extension de navigateur n'est pas automatiquement valide dans une variable d'environnement lue par un autre programme.