Dans l'initialisation libcurl existante d'une application et le cycle de vie d'un 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 envoie le nom d'hôte de la destination le long du chemin SOCKS. CURLPROXY_SOCKS5 le résout plutôt sur le client, qui peut utiliser la vue DNS d'un autre réseau. Un client HTTP en C++ utilisant libcurl n'a pas besoin de son propre handshake SOCKS uniquement pour choisir cette route. Pour un point de terminaison public autorisé, la liste de proxies SOCKS5 propose des candidats d'hôte et de port pour remplacer l'écouteur loopback illustratif.

La valeur CURLOPT_NOPROXY vide rend le test du proxy délibéré. Conservez les contournements prévus lors de son adaptation à la politique normale de l'application. Ces options affectent ce handle ; les autres bibliothèques et sockets du processus ne les héritent pas.

Vérifiez les valeurs de retour de la définition des options et du transfert via la gestion des erreurs de l'application. Un échec pour atteindre SOCKS ou négocier avec lui peut précéder toute réponse HTTP, il ne fournit donc pas de code d'état de site web.

Les identifiants de proxy requis utilisent les paramètres d'authentification de proxy pris en charge et le mécanisme de secrets, séparément de la connexion au site web. Laissez la vérification TLS activée : ouvrir une connexion via SOCKS n'établit pas l'identité du service HTTPS.

Articles similaires