Ланцюжок проксі від SOCKS до HTTP у curl

Параметр --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 або новішого; інші застосунки можуть не підтримувати таку схему.