L’objet agent de Got est indexé par le protocole de destination. Une connexion SOCKS pour une URL HTTPS relève donc de https, et non d’une nouvelle clé nommée socks.

Pour une application ESM existante qui utilise Got et socks-proxy-agent sur le chemin HTTP/1 :

import got from 'got';
import {SocksProxyAgent} from 'socks-proxy-agent';

const agent = new SocksProxyAgent('socks5h://proxy.example:1080');
const body = await got('https://www.example.org/', {
  http2: false,
  agent: {
    http: agent,
    https: agent,
  },
  timeout: {request: 20000},
}).text();

La liste de proxys SOCKS5 fournit des candidats pour l’URL de proxy sans compte de l’exemple. Le même agent peut prendre en charge les entrées HTTP et HTTPS montrées. Il établit la connexion SOCKS, puis le chemin HTTPS effectue sa poignée de main TLS avec la destination.

Dans cet agent, socks5h laisse la résolution du nom d’hôte de destination au proxy SOCKS. socks5 choisit la résolution locale. Le nom d’hôte du proxy lui-même doit rester joignable depuis le processus Node.

L’emplacement d’agent HTTP/2 de Got attend une autre interface. Ne copiez pas cet agent dans agent.http2 en supposant qu’il apporte la prise en charge du proxy HTTP/2.

Réutilisez l’agent configuré pour la charge de travail et détruisez-le à l’arrêt de son propriétaire. Alignez les versions des paquets sur l’environnement Node de l’application ; cet exemple utilise l’export nommé SocksProxyAgent.

Articles similaires