curl se SOCKS-na-HTTP-proxyketting
Stel curl se ondersteunde SOCKS-na-HTTP-ketting op, bepaal die eindpuntvolgorde en toets elke sprong voordat jy hulle kombineer.
curl se --preproxy verbind met ’n SOCKS-proxy voordat dit ’n HTTP- of HTTPS-proxy bereik. Dit ondersteun hierdie spesifieke ketting, nie ’n willekeurige lys proxybedieners nie.
Die pad is kliënt → SOCKS-eindpunt → HTTP-proxy → bestemming. Vervang albei dokumentasie-eindpunte in die opdrag:
curl --preproxy socks5h://203.0.113.10:1080 --proxy http://203.0.113.20:8080 --noproxy '' --connect-timeout 5 --max-time 20 --verbose https://example.com/
Die SOCKS-diens moet die HTTP-proxy se adres en poort kan bereik. Die HTTP-proxy moet dan die bestemmingsversoek aanvaar. As die tweede proxy ’n gasheernaam gebruik, bepaal die eerste SOCKS-modus waar dié naam opgelos word; ’n numeriese eindpunt vermy die opsoek.
Vind die sprong wat misluk
Bevestig eers ’n versoek deur elke eindpunt afsonderlik; gebruik vir die HTTP-sprong ’n HTTP-proxytoets met tydsgrense. Al werk albei, kan die saamgestelde roete misluk omdat die eerste proxy die tweede nie kan bereik nie.
Lees die breedvoerige nasporing in verbindingsvolgorde. ’n SOCKS-fout terwyl die tweede proxy bereik word, gebeur voor die HTTP-proxy besluit om CONNECT na die webwerf te aanvaar of te weier. Teken aan watter handdruk misluk het.
Wanneer die ekstra sprong help
Dié opstelling kan nuttig wees wanneer ’n gemagtigde HTTP-proxy via ’n SOCKS-pad bereikbaar is. Dit voeg ook nog ’n diens en netwerkroete by wat kan misluk of vertraag. Om eindpunte van ’n openbare proxylys te ketting waarborg nie betroubaarheid of anonimiteit nie en vereis steeds vertroue in die partye wat die verbinding hanteer.
--preproxy vereis curl 7.52.0 of nuwer; ander toepassings ondersteun moontlik nie dieselfde opstelling nie.