Օգտագործեք SOCKS գործակալ Node-ի HTTPS հաճախորդի հետ

SOCKS ընդունակ գործակալը կարող է հաստատել նպատակակետի կապը Node-ի հիմնական HTTPS հաճախորդի համար։ Երբ socks-proxy-agent-ը հասանելի է հավելվածում՝

const https = require('node:https');
const { SocksProxyAgent } = require('socks-proxy-agent');

const agent = new SocksProxyAgent('socks5h://proxy.example:1080');
const request = https.get('https://www.example.com/', {
  agent,
  signal: AbortSignal.timeout(15000),
}, (response) => {
  console.log(response.statusCode);
  response.on('error', console.error);
  response.resume();
});
request.on('error', console.error);

Փոխարինեք օրինակի վերջնակետը չհաստատված թեկնածուով SOCKS5 վստահված սերվերների ցանկից այս հանրային HTTPS հարցման համար։ Հետկանչը թափում է պատասխանը՝ տպելով կարգավիճակը. սպառեք մարմինը այնտեղ, եթե հավելվածին անհրաժեշտ է։ Կրկին օգտագործեք գործակալը իր հանձնված գործողությունների համար, ապա ոչնչացրեք այն, երբ այդ հաճախորդի քաղաքականությունը դադարեցվի և նրա աշխատանքը ավարտված լինի։

Ընտրեք, թե որտեղ է լուծվում նպատակակետի անունը

socks-proxy-agent-ի URL մշակման ժամանակ socks5h-ը նպատակակետի հոսթանվան լուծումը թողնում է վստահված սերվերի ուղուն. socks5-ը լուծում է այն տեղական։ Սա կարևոր է, երբ անունը հասանելի է միայն վստահված սերվերի ցանցում։

HTTPS URL-ը պահպանում է կայքի ինքնությունը։ Գործակալը կատարում է SOCKS բանակցություն, նախքան Node-ը կսկսի TLS դեպի այդ կայք։

Օգտանուն/գաղտնաբառ ծառայության համար տեղադրեք հավատարմագրերը վստահված սերվերի URL-ում՝ օգտագործելով URI բաղադրիչի կոդավորումը վերապահված նիշերի համար։ Պահեք ամբողջական URL-ը մատյաններից դուրս։ Նպատակակետի Authorization վերնագրերը պատկանում են կայքի հաշվին։

Այս գործակալը աշխատում է Node-ի հիմնական HTTP/HTTPS հարցումների API-ների հետ։ Node-ի fetch-ը օգտագործում է dispatcher ինտերֆեյս, ուստի այդ հաճախորդի աջակցվող SOCKS ինտեգրումը կարգավորեք առանձին։