R-Proxy-Diagnose: libcurl-Version, TLS-Backend und Protokolle

Das in einer Conda-Umgebung installierte R kann einen anderen libcurl-Build verwenden als die curl-Binärdatei im Terminal. Fragen Sie die fehlschlagende R-Sitzung, welche Bibliothek sie tatsächlich hat:

info <- libcurlVersion()
info
attr(info, 'ssl_version')
attr(info, 'protocols')

Der Zeichenwert meldet die Version der verlinkten libcurl. Sein Attribut ssl_version kennzeichnet die TLS-Implementierung, während protocols die von dieser Bibliothek unterstützten Zielprotokolle auflistet. Sie beschreiben den eingebauten libcurl-Pfad von R, nicht einen Shell-Befehl namens curl.

Bericht und Downloadmethode abgleichen

download.file mit method='libcurl' nutzt diese Bibliothek. method='curl' startet die externe Binärdatei. Die aktuelle automatische HTTP(S)-Auswahl verwendet libcurl, und eine download.file.method-Option mit dem Wert NULL kann diese Voreinstellung bestehen lassen.

Führen Sie die Prüfung in der tatsächlichen Umgebung aus, die der Job oder die IDE auswählt. Eine andere R-Installation kann eine andere Version oder ein anderes TLS-Backend melden, selbst wenn ihre Skripte identisch aussehen.

Ein aufgeführtes https-Protokoll bedeutet, dass HTTPS-Ziele unterstützt werden. Es beweist nicht, dass ein bestimmter Proxy-Listener TLS akzeptiert. Ein gewöhnlicher HTTP-Proxy für einen HTTPS-Download hat weiterhin eine Proxy-URL mit http://.

Bewahren Sie den Bibliotheksbericht zusammen mit der gewählten Methode und dem Verbindungsfehler auf. Ein Zertifikatsfehler, ein nicht unterstütztes Proxy-Schema und ein abgelehnter Listener bleiben unterschiedliche Befunde; eine Versionsnummer allein ist nicht ihre Diagnose.