Параметр --preproxy у curl падключаецца да SOCKS-проксі да дасягнення HTTP- або HTTPS-проксі. Ён падтрымлівае менавіта гэты ланцужок, а не адвольны спіс проксі-сервераў.

Шлях: кліент → канцавы пункт SOCKS → HTTP-проксі → мэта. Замяніце абодва дакументацыйныя пункты ў камандзе:

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-проксі. Потым HTTP-проксі павінен прыняць запыт да мэты. Калі другі проксі зададзены імем хоста, першы рэжым SOCKS вызначае, дзе вырашаецца гэтае імя; лікавы адрас дазваляе пазбегнуць гэтага пошуку.

Пошук няспраўнага звяна

Спачатку пацвердзіце запыт праз кожны пункт асобна; для HTTP-звяна выкарыстоўвайце праверку HTTP-проксі з часовымі межамі. Нават калі абодва працуюць, агульны маршрут можа не спрацаваць, бо першы проксі не дасягае другога.

Чытайце падрабязную трасіроўку ў парадку злучэнняў. Памылка SOCKS пры дасягненні другога проксі адбываецца раней за рашэнне HTTP-проксі прыняць або адхіліць CONNECT да сайта. Запішыце, якое ўзгадненне не ўдалося.

Калі карыснае дадатковае звяно

Гэтая схема можа дапамагчы, калі дазволены HTTP-проксі дасягальны праз SOCKS-шлях. Яна таксама дадае яшчэ адзін сэрвіс і сеткавы маршрут, што могуць адмовіць або павялічыць затрымку. Ланцужок пунктаў з публічнага спіса проксі не гарантуе надзейнасці ці ананімнасці і па-ранейшаму патрабуе даверу да бакоў, што апрацоўваюць злучэнне.

--preproxy патрабуе curl 7.52.0 або навейшага; іншыя праграмы могуць не падтрымліваць такую схему.

Падобныя артыкулы