SocksClient.createConnection връща поток, свързан с поисковата дестинация. За HTTPS този поток все още се нуждае от TLS ръкостискане, преди да пренесе 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`
  );
});

Списъкът със SOCKS5 проксита предоставя кандидати за хоста и порта на проксито. onTransportError и onResponseBytes принадлежат на съществуващото приложение; второто трябва да анализира потока на HTTP отговора. TLS парчетата данни не са самостоятелно пълни HTTP съобщения.

servername е DNS името на дестинацията. Нискоравневият tls.connect на Node не включва SNI по подразбиране, а името на хоста на проксито не е идентичността на сертификата на сайта.

Оставете проверката на сертификата включена. Подаването на свързания сокет избягва отварянето на отделна директна връзка към сайта, като същевременно запазва TLS идентичността му.

Таймаутът на SOCKS ограничава тази договорка. Следващият обмен по TLS и приложението все още се нуждаят от предвидените от извикващия таймаут, отмяна и политика за почистване.

Подобни статии