SocksClient.createConnection devolve un fluxo conectado ao destino solicitado. Para HTTPS, ese fluxo aínda necesita un handshake TLS antes de transportar a petición HTTP.

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`
  );
});

A lista de proxies SOCKS5 fornece candidatos para o host e o porto do proxy. onTransportError e onResponseBytes pertencen á aplicación existente; o segundo debe analizar o fluxo de resposta HTTP. Os fragmentos de datos TLS non son mensaxes HTTP completas de forma independente.

O servername é o nome DNS do destino. O tls.connect de baixo nivel de Node non activa SNI por defecto, e o nome de host do proxy non é a identidade do certificado do sitio.

Mantén activada a verificación do certificado. Fornecer o socket conectado evita abrir unha conexión directa separada ao sitio e conserva a súa identidade TLS.

O tempo de espera de SOCKS limita esa negociación. O intercambio posterior de TLS e da aplicación segue necesitando o tempo de espera, a cancelación e a política de limpeza previstos por quen chama.

Artigos relacionados