curl का --preproxy विकल्प HTTP या HTTPS proxy तक पहुँचने से पहले SOCKS proxy से जुड़ता है। यह इसी खास शृंखला का समर्थन करता है, proxy सर्वर की मनमानी सूची का नहीं।

रास्ता है क्लाइंट → SOCKS endpoint → HTTP proxy → गंतव्य। कमांड में दोनों दस्तावेज़ी endpoint बदलें:

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/

SOCKS सेवा को HTTP proxy के पते और पोर्ट तक पहुँच सकना चाहिए। उसके बाद HTTP proxy को गंतव्य अनुरोध स्वीकार करना चाहिए। दूसरा proxy hostname इस्तेमाल करे तो पहला SOCKS mode तय करता है कि उस नाम का समाधान कहाँ होगा; संख्यात्मक endpoint इस खोज को टालता है।

विफल चरण खोजना

पहले हर endpoint से अनुरोध अलग जाँचें; HTTP चरण के लिए समय सीमा वाली HTTP proxy जाँच इस्तेमाल करें। दोनों चलें तब भी पहला proxy दूसरे तक न पहुँच सके तो संयुक्त रास्ता विफल हो सकता है।

विस्तृत trace कनेक्शन के क्रम में पढ़ें। दूसरे proxy तक पहुँचते समय SOCKS की विफलता HTTP proxy के वेबसाइट तक CONNECT स्वीकार या अस्वीकार करने के निर्णय से पहले होती है। लिखें कि कौन सा handshake विफल हुआ।

अतिरिक्त चरण कब मदद करता है

अधिकृत HTTP proxy तक SOCKS रास्ते से पहुँचने पर यह व्यवस्था उपयोगी हो सकती है। लेकिन इससे एक और सेवा तथा नेटवर्क रास्ता भी जुड़ता है जो विफल हो सकता या देरी बढ़ा सकता है। सार्वजनिक proxy सूची के endpoint जोड़ने से विश्वसनीयता या गुमनामी की गारंटी नहीं मिलती और कनेक्शन संभालने वाले पक्षों पर भरोसा अब भी चाहिए।

--preproxy को curl 7.52.0 या नया चाहिए; अन्य ऐप्लिकेशन शायद इसी व्यवस्था का समर्थन न करें।

संबंधित लेख