Конфигуриране на libcurl handle за разрешаване на име на хост през SOCKS5

В рамките на съществуващата инициализация на libcurl в приложението и жизнения цикъл на easy-handle:

curl_easy_setopt(handle, CURLOPT_URL, "https://example.com/");
curl_easy_setopt(handle, CURLOPT_PROXY, "127.0.0.1:1080");
curl_easy_setopt(handle, CURLOPT_PROXYTYPE, CURLPROXY_SOCKS5_HOSTNAME);
curl_easy_setopt(handle, CURLOPT_NOPROXY, "");
curl_easy_setopt(handle, CURLOPT_CONNECTTIMEOUT, 5L);
curl_easy_setopt(handle, CURLOPT_TIMEOUT, 15L);

CURLPROXY_SOCKS5_HOSTNAME изпраща името на хоста на дестинацията по пътя на SOCKS. CURLPROXY_SOCKS5 вместо това го разрешава на клиента, който може да използва DNS изгледа на друга мрежа. C++ HTTP клиент, използващ libcurl, не се нуждае от собствен SOCKS handshake само за да избере този маршрут. За разрешена публична крайна точка, списъкът с SOCKS5 прокси сървъри предлага кандидати за хост и порт, които да заменят илюстративния loopback слушател.

Празната CURLOPT_NOPROXY стойност прави теста на проксито умишлен. Запазете предвидените заобикаляния, когато го адаптирате към нормалната политика на приложението. Тези опции засягат този handle; други библиотеки и сокети в процеса не ги наследяват.

Проверявайте върнатите стойности от задаването на опции и трансфера чрез обработката на грешки на приложението. Неуспехът да се достигне или договори SOCKS може да предхожда всеки HTTP отговор, така че не дава код на състояние на уебсайт.

Изискваните прокси идентификационни данни използват поддържаните настройки за удостоверяване на прокси и механизъм за тайни, отделно от влизането в уебсайта. Поддържайте проверката на TLS включена: отварянето на връзка през SOCKS не установява самоличността на HTTPS услугата.