SocksClient.createConnection returnerer ein straum som er kopla til målet du bad om. For HTTPS treng den straumen framleis eit TLS-handtrykk før han ber HTTP-førespurnaden.

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-proxylista gjev kandidatar for vert og port til proxyen. onTransportError og onResponseBytes høyrer til den eksisterande applikasjonen; den siste må parse HTTP-svarstraumen. TLS-databitar er ikkje sjølvstendig komplette HTTP-meldingar.

servername er DNS-namnet til målet. Nodes tls.connect på lågt nivå slår ikkje på SNI som standard, og vertsnamnet til proxyen er ikkje sertifikatidentiteten til nettstaden.

Lat sertifikatvalideringa stå på. Å gje den tilkopla socketen unngår ei eiga direkte tilkopling til nettstaden og bevarer TLS-identiteten.

SOCKS-tidsavbrotet avgrensar den forhandlinga. Den seinare TLS- og applikasjonsutvekslinga treng framleis det tiltenkte tidsavbrotet, avbrytinga og oppryddingspolicyen til den som kallar.

Relaterte artiklar