SocksClient.createConnection returnerar en ström som är ansluten till den begärda destinationen. För HTTPS behöver den strömmen fortfarande en TLS-handskakning innan den bär HTTP-begäran.

import { SocksClient } from 'socks';
import tls from 'node:tls';

const targetHost = 'service.example';
const info = await SocksClient.createConnection({
  proxy: { host: 'proxy.example', port: 1080, type: 5 },
  command: 'connect',
  destination: { host: targetHost, port: 443 },
  timeout: 10000,
});
const secure = tls.connect({
  socket: info.socket,
  servername: targetHost,
});
secure.on('error', onTransportError);
secure.on('data', onResponseBytes);
secure.once('secureConnect', () => {
  secure.write(
    `GET /data HTTP/1.1\r\nHost: ${targetHost}\r\nConnection: close\r\n\r\n`
  );
});

SOCKS5-proxylistan tillhandahåller kandidater för proxyvärd och port. onTransportError och onResponseBytes tillhör den befintliga applikationen; den senare måste tolka HTTP-svarsströmmen. TLS-databitar är inte i sig kompletta HTTP-meddelanden.

servername är destinationens DNS-namn. Nodes tls.connect på låg nivå aktiverar inte SNI som standard, och proxyns värdnamn är inte webbplatsens certifikatidentitet.

Låt certifikatverifieringen vara på. Genom att skicka den anslutna socketen undviks en separat direkt anslutning till webbplatsen samtidigt som dess TLS-identitet bevaras.

SOCKS-timeouten begränsar den förhandlingen. Det senare TLS- och applikationsutbytet behöver fortfarande anroparens avsedda timeout, avbrytning och städpolitik.

Relaterade artiklar