CIDR-omseiling in curl misluk, maar --noproxy '*' werk
Gebruik die werklike kliënt en die gekoppelde biblioteekweergawe om verskille in die omseilingfunksie te verduidelik, eerder as om 'n hele bedryfstelselvrystelling te blameer.
'n Versoek na 'n letterlike private IP gebruik die instaanbediener met 'n subnet-uitsondering, maar gaan direk met --noproxy '*'. Dit bewys nie dat die bedryfstelsel elke instaanbediener-uitsondering ignoreer nie.
Die kliënt het een verstaanbare vorm van omseiling gedemonstreer. Die volgende vraag is of dit die reeksvorm wat jy verskaf het implementeer.
curl het CIDR-passing vir hierdie uitsonderings in 7.86.0 bygevoeg. 'n Masjien met 'n nuwer lykende bedryfstelselvrystelling kan steeds 'n kliënt of gekoppelde biblioteek uit 'n ander weergawe-lyn hê. Kontroleer die uitvoerbare lêer wat werklik opgeroep word en sy gekoppelde libcurl, nie net die OS-naam in die kwessietitel nie.
'n Toepassing wat libcurl gebruik, kan ook van die selfstandige curl-opdrag verskil. Verspreidingspleisters kan saak maak, so gebruik die geïnstalleerde pakket se funksiedokumentasie wanneer die basisweergawe alleen nie beslissend is nie.
Hou die versoekinvoer presies. 'n Gasheernaam wat na die subnet oplos, is 'n ander geval as 'n URL met die letterlike adres. 'n Ondersteunde CIDR-ontleder doen nie outomaties 'n DNS-soektog om elke naam in 'n adresgebaseerde omseilingsbesluit te verander nie.
Versamel die kliëntidentiteit, presiese URL, uitsonderingswaarde en beheerde resultaat voordat jy pakette vervang of 'n enorme lys individuele adresse genereer. 'n Globale omseiling vir alle gashere is nuttige bewyse oor die vergelyking; dit is nie outomaties die beoogde permanente roeteringsbeleid nie.