I-configure ang isang libcurl handle para sa SOCKS5 hostname resolution

Sa loob ng umiiral na libcurl initialization ng application at lifecycle ng 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 ipinapadala ang hostname ng destinasyon sa landas ng SOCKS. CURLPROXY_SOCKS5 sa halip ay nire-resolve ito sa client, na maaaring gumamit ng DNS view ng ibang network. Ang isang C++ HTTP client na gumagamit ng libcurl ay hindi kailangan ng sarili nitong SOCKS handshake para lamang piliin ang rutang ito. Para sa isang pinapayagang pampublikong endpoint, ang listahan ng SOCKS5 proxy ay nag-aalok ng mga kandidatong host at port upang palitan ang ilustratibong loopback listener.

Ang CURLOPT_NOPROXY walang laman na halaga ay ginagawang sinadya ang pagsubok ng proxy. Panatilihin ang mga inilaan na bypass kapag iniaangkop ito sa normal na patakaran ng application. Ang mga opsyong ito ay nakakaapekto sa handle na ito; ang iba pang library at socket sa proseso ay hindi nagmamana ng mga ito.

Suriin ang mga return value ng pagtatakda ng opsyon at paglilipat sa pamamagitan ng error handling ng application. Ang pagkabigo na maabot o makipagnegosasyon sa SOCKS ay maaaring mangyari bago ang anumang HTTP response, kaya hindi ito nagbibigay ng status code ng website.

Ang mga kinakailangang proxy credential ay gumagamit ng mga sinusuportahang setting ng proxy authentication at mekanismo ng lihim, hiwalay sa login ng website. Panatilihing naka-enable ang TLS verification: ang pagbukas ng koneksyon sa pamamagitan ng SOCKS ay hindi nagpapatunay ng pagkakakilanlan ng serbisyong HTTPS.