Nagbabalik ang SocksClient.createConnection ng stream na konektado sa hiniling na destination. Para sa HTTPS, kailangan pa rin ng TLS handshake ang stream na iyon bago nito dalhin ang HTTP request.

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

Ang listahan ng SOCKS5 proxy ay nagbibigay ng mga kandidato para sa host at port ng proxy. Ang onTransportError at onResponseBytes ay pag-aari ng umiiral na aplikasyon; kailangang i-parse ng pangalawa ang HTTP response stream. Ang mga tipak ng TLS data ay ay hindi nakapag-iisang kumpletong HTTP message.

Ang servername ay ang DNS name ng destination. Ang low-level na tls.connect ng Node ay hindi nagpapagana ng SNI bilang default, at ang hostname ng proxy ay hindi ang identity ng certificate ng website.

Panatilihing naka-on ang pagpapatunay ng certificate. Ang pagbibigay ng konektadong socket ay umiiwas sa pagbubukas ng hiwalay na direktang koneksyon sa website habang pinapanatili ang identity nitong TLS.

Nililimitahan ng timeout ng SOCKS ang negosasyong iyon. Ang susunod na palitan ng TLS at aplikasyon ay nangangailangan pa rin ng inilaan na timeout, pagkansela at patakaran sa paglilinis ng tumatawag.

Kaugnay na mga artikulo