SOCKS5 ホスト名解決のための libcurl ハンドルの設定

アプリケーションの既存の 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 ビューを使う可能性があります。libcurl を使う C++ HTTP クライアントは、この経路を選ぶためだけに独自の SOCKS ハンドシェイクを必要としません。許可された公開エンドポイントには、SOCKS5 プロキシリストが、例示的な loopback リスナーの代わりになるホストとポートの候補を提供します。

空の CURLOPT_NOPROXY 値はプロキシのテストを意図的なものにします。通常のアプリケーションポリシーに合わせるときは、意図したバイパスを残してください。これらのオプションはこのハンドルにのみ影響し、プロセス内の他のライブラリやソケットには継承されません。

オプション設定と転送の戻り値は、アプリケーションのエラー処理を通じて確認してください。SOCKS への到達や折衝の失敗は HTTP 応答より前に起こりうるため、Web サイトのステータスコードは得られません。

必要なプロキシ認証情報は、Web サイトのログインとは別に、サポートされているプロキシ認証設定とシークレット機構を使います。TLS 検証は有効のままにしてください。SOCKS 経由で接続を開いても、HTTPS サービスの身元は確立されません。