ALL_PROXY en die “Onbekende skema: http”-fout
’n Program kan ’n http://-waarde in ALL_PROXY verwerp selfs al aanvaar HTTP_PROXY dit. Die verbruiker van die veranderlike bepaal die ondersteunde skemas.
proxy: unknown scheme: http kan absurd lyk wanneer dieselfde eindpunt in curl werk. Die eindpunt is dalk heeltemal reg. ’n Ander program interpreteer die veranderlike.
Omgewingsname is konvensies, nie ’n universele netwerk-API nie. Go se golang.org/x/net/proxy-pakket het SOCKS-georiënteerde URL-hantering. ’n Verbruiker wat daardie ontleder gebruik, kan ’n HTTP-skema verwerp wat ’n volledige HTTP-kliënt elders ondersteun.
Vind die komponent wat die fout lewer en die veranderlike wat dit lees. Kyk na sy weergawe en gedokumenteerde skemas. Moenie http:// na socks5:// verander nie, tensy die diens aan die ander kant werklik SOCKS5 praat. As hierdie verbruiker SOCKS5 vereis en ’n openbare roete toegelaat word, bied die SOCKS5-proksilys werklike eindpunte vir daardie protokol; hou die HTTP-roetes wat ander kliënte vereis, apart.
’n Ou Docker Toolbox-verslag het ’n bepaalde historiese implementering betref. Dit is nie ’n rede om ’n moderne Docker-installasie af te gradeer nie. Huidige HTTP-proksi-instellings van die Docker-daemon het hul eie gedokumenteerde koppelvlak.
As ’n onverwante oorgeërfde ALL_PROXY-waarde die oorsaak is, verwyder of oorheers dit by die beoogde prosesomvang. Behou die HTTP-proksi-instelling wat ander kliënte vereis. ’n Enkele omgewing wat albei waardes bevat, kan verskille openbaar wat die individuele toepassings nooit in isolasie sou wys nie.