Le contournement CIDR de curl échoue alors que --noproxy '*' fonctionne
Utilisez la version réelle du client et de la bibliothèque liée pour expliquer les différences de la fonction de contournement, au lieu d'accuser toute une version du système d'exploitation.
Une requête vers une adresse IP privée littérale utilise le proxy avec une exception de sous-réseau, mais passe en direct avec --noproxy '*'. Cela ne prouve pas que le système d'exploitation ignore toutes les exceptions de proxy.
Le client a démontré une forme de contournement comprise. La question suivante est de savoir s'il implémente la forme par plage que vous avez fournie.
curl a ajouté la correspondance CIDR pour ces exceptions dans la version 7.86.0. Une machine dont la version du système d'exploitation semble plus récente peut encore disposer d'un client ou d'une bibliothèque liée issus d'une autre ligne de versions. Vérifiez l'exécutable réellement appelé et sa libcurl liée, pas seulement le nom du système d'exploitation dans le titre du problème.
Une application utilisant libcurl peut aussi différer de la commande curl autonome. Les correctifs de distribution peuvent compter, utilisez donc la documentation des fonctionnalités du paquet installé lorsque la seule version de base ne permet pas de conclure.
Gardez l'entrée de la requête exacte. Un nom d'hôte qui se résout dans le sous-réseau est un autre cas qu'une URL contenant l'adresse littérale. Un analyseur CIDR pris en charge n'effectue pas automatiquement une requête DNS pour transformer chaque nom en décision de contournement fondée sur l'adresse.
Rassemblez l'identité du client, l'URL exacte, la valeur de l'exception et le résultat contrôlé avant de remplacer des paquets ou de générer une liste énorme d'adresses individuelles. Un contournement global pour tous les hôtes est une preuve utile pour la comparaison ; ce n'est pas automatiquement la politique de routage permanente voulue.