Agordi libcurl-tenilon por SOCKS5-gastigantomana solvo
Uzu CURLPROXY_SOCKS5_HOSTNAME sur la transporta tenilo por solvi la celon tra la prokurilo.
Ene de la ekzistanta libcurl-ekigo de aplikaĵo kaj la vivociklo de 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 sendas la gastigantoman nomon de la celo laŭ la SOCKS-vojo. CURLPROXY_SOCKS5 anstataŭe solvas ĝin ĉe la kliento, kiu povas uzi la DNS-vidon de alia reto. C++ HTTP-kliento uzanta libcurl ne bezonas sian propran SOCKS-manpremon nur por elekti ĉi tiun vojon. Por permesita publika finpunkto, la listo de SOCKS5-prokuriloj proponas gastigantajn kaj pordajn kandidatojn por anstataŭigi la ilustran loopback-aŭskultanton.
La malplena CURLOPT_NOPROXY valoro igas la prokurilan teston intenca. Konservu celitajn preterirojn kiam vi adaptas ĝin al normala aplikaĵa politiko. Ĉi tiuj opcioj efikas al ĉi tiu tenilo; aliaj bibliotekoj kaj ingoj en la procezo ne heredas ilin.
Kontrolu la revenajn valorojn de opciagordo kaj transporto per la erartraktado de la aplikaĵo. Malsukceso atingi aŭ intertrakti kun SOCKS povas antaŭi ajnan HTTP-respondon, do ĝi ne donas retejan statkodon.
Bezonataj prokurilaj akreditaĵoj uzas la subtenatajn prokurilajn aŭtentikigajn agordojn kaj sekretan mekanismon, aparte de la reteja ensaluto. Tenu TLS-kontrolon ŝaltita: malfermi konekton tra SOCKS ne establas la identecon de la HTTPS-servo.