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