Kumokonekta ang --preproxy option ng curl sa SOCKS proxy bago marating ang HTTP o HTTPS proxy. Ang partikular na chain na ito ang suportado nito, hindi basta anumang listahan ng proxy server.

Ang ruta ay client → SOCKS endpoint → HTTP proxy → destination. Palitan ang parehong endpoint na halimbawa sa dokumentasyon sa command:

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/

Kailangang maabot ng SOCKS service ang address at port ng HTTP proxy. Pagkatapos, kailangang tanggapin ng HTTP proxy ang request sa destination. Kung hostname ang ikalawang proxy, tinutukoy ng unang SOCKS mode kung saan nire-resolve ang pangalang iyon; naiiwasan ng numerikong endpoint ang lookup na iyon.

Paghanap sa pumalyang hop

Tiyakin muna ang request sa bawat endpoint nang hiwalay; para sa HTTP hop, gamitin ang HTTP-proxy test na may takdang oras. Kahit gumana ang dalawa, maaaring pumalya ang pinagsamang ruta dahil hindi maabot ng unang proxy ang ikalawa.

Basahin ang detalyadong trace ayon sa ayos ng koneksyon. Nauuna ang SOCKS failure habang inaabot ang ikalawang proxy sa desisyon ng HTTP proxy na tanggapin o tanggihan ang CONNECT sa website. Itala kung aling handshake ang pumalya.

Kailan nakatutulong ang dagdag na hop

Maaaring makatulong ito kapag naaabot ang awtorisadong HTTP proxy sa rutang SOCKS. Nagdaragdag din ito ng isa pang serbisyo at network route na maaaring pumalya o magdagdag ng pagkaantala. Walang garantiya sa pagiging maaasahan o anonymity ang pag-chain ng mga endpoint mula sa pampublikong proxy list at kailangan pa ring pagkatiwalaan ang mga partidong humahawak sa koneksyon.

Kailangan ng --preproxy ang curl 7.52.0 o mas bago; maaaring hindi suportahan ng ibang application ang parehong ayos.

Kaugnay na mga artikulo