proxy-chain․ առանձին հաշիվներ և upstream յուրաքանչյուր listener-ի համար

proxy-chain-ը կարող է մեկ Server օրինակ աշխատեցնել յուրաքանչյուր լսող պորտի համար։ Գրանցեք այդ listener-ի քաղաքականությունը նրա նույնականացման callback-ում․

import { Server } from 'proxy-chain';

const listeners = [
  { port: 8001, user: userA, password: passwordA, upstream: upstreamA },
  { port: 8002, user: userB, password: passwordB, upstream: upstreamB },
];
const servers = listeners.map(rule => new Server({
  host: '127.0.0.1',
  port: rule.port,
  prepareRequestFunction: ({ username, password }) => ({
    requestAuthentication:
      username !== rule.user || password !== rule.password,
    upstreamProxyUrl: rule.upstream,
  }),
}));
await Promise.all(servers.map(server => server.listen()));

Ծրագիրը տրամադրում է հաշիվների արժեքները և upstream URL-ները իր սովորական կազմաձևով։ Յուրաքանչյուր callback պահպանում է իր կանոնը, ուստի 8001 պորտում հաշիվը ընդունելը չի ընդունում այդ հաշիվը 8002 պորտում։

requestAuthentication true-ն վերադարձնում է Basic proxy մարտահրավեր։ Երբ նույնականացում է պահանջվում, այդ հարցման համար upstreamProxyUrl-ը անտեսվում է։ Հաջող ներգնա հաշիվը և upstream հաշիվը տարբեր ինքնություններ են։

Օգտագործեք աջակցվող URL յուրաքանչյուր upstream-ի համար, ներառյալ ճիշտ կոդավորված հավատարմագրերը, երբ անհրաժեշտ է։ Առանց նույնականացման հանրային HTTP upstream-ի համար ընտրեք թեկնածու HTTP proxy ցանկից և կառուցեք նրա URL-ը առանց հավատարմագրերի։ Բաց թողնված upstream-ը ընտրում է ուղիղ փոխանցում այլ ավտոմատ proxy-ի փոխարեն։

Օրինակը loopback-ը կապում է տեղական հաճախորդների համար։ Երբ այլ մեքենա պետք է միանա, գիտակցաբար կապեք նախատեսված ինտերֆեյսը համապատասխան մուտքի քաղաքականությամբ։

Պահեք սերվերները կենդանի իրենց հաճախորդների ծանրաբեռնվածության համար։ Դրանց սեփականատերը պետք է անջատման ժամանակ փակի յուրաքանչյուր սերվեր իր աջակցվող փակման մեթոդով․ օրինակը չի սահմանում այդ ծրագրի ամբողջ կենսացիկլը։