Во постоечката иницијализација на 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 ракување само за да ја избере оваа рута. За дозволена јавна крајна точка, списокот на SOCKS5 прокси сервери нуди кандидати за домаќин и порта за да го заменат илустративниот loopback слушател.

Празната CURLOPT_NOPROXY вредност го прави тестот на прокси намерен. Зачувајте ги предвидените заобиколувања кога го приспособувате кон нормалната политика на апликацијата. Овие опции влијаат на оваа рачка; другите библиотеки и сокети во процесот не ги наследуваат.

Проверете ги повратните вредности од поставувањето на опциите и преносот преку ракувањето со грешки на апликацијата. Неуспехот да се стигне или преговара со SOCKS може да претходи на секој HTTP одговор, па затоа не дава статусен код на веб-страница.

Потребните акредитиви за прокси ги користат поддржаните поставки за автентикација на прокси и механизмот за тајни, одделно од најавувањето на веб-страницата. Држете ја проверката на TLS вклучена: отворањето врска преку SOCKS не го утврдува идентитетот на HTTPS услугата.

Поврзани статии