Kial http_proxy ne nepre influas Whois
Distingvu tradiciajn Whois TCP-demandojn de HTTP-bazitaj registrajdatumaj klientoj kiam vi elektas proksan vojon.
Tradicia Whois uzas sian propran TCP-protokolon, kutime sur pordo 43. Ĝi ne estas HTTP-peto nur ĉar la respondo priskribas interretan domajnon.
La variablo http_proxy helpas nur programaron, kiu legas ĝin por subtenata HTTP-proksa vojo. Whois-implementaĵo povas ignori tiun variablon dum ĝi establas sian normalan TCP-konekton.
Se certa kliento subtenas SOCKS, agordu tiun dokumentitan funkcion. Kongrua TCP-ĉirkaŭvolvaĵo estas alia eblo, kondiĉe de la interkaptaj limoj de la ĉirkaŭvolvaĵo kaj la celporda politiko de la prokso. Ne supozu, ke ĉiu programo nomata whois havas la samajn funkciojn. Se tiu kliento subtenas SOCKS kaj publikaj perantoj estas permesataj, la SOCKS-proksa listo proponas kandidatojn por kontroli aliron al la realaj Whois-serviloj kaj -pordoj, inkluzive de referencoj.
HTTP-bazitaj registrajdatumaj servoj, inkluzive de RDAP, uzas malsaman aplikaĵprotokolon kaj povas havi la proksan subtenon de HTTP-konscia kliento. Ŝanĝi interfacon estas intenca ŝanĝo de ilo kaj respondformo, ne pruvo ke la origina Whois-demando ĉiam estis HTTP.
Konsideru ankaŭ referencan konduton: unu serĉo povas kontakti pli ol unu servilon. Unu permesita konekto ne pruvas, ke ĉiu posta celo povas uzi la celitan vojon.