proxy-chain: cyfrifon ac upstreams ar wahân ar gyfer pob listener

Gall proxy-chain redeg un enghraifft Server fesul porth gwrando. Cadwch bolisi'r listener hwnnw yn ei alwad ôl dilysu:

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()));

Mae'r cymhwysiad yn darparu gwerthoedd y cyfrifon a'r URLau upstream drwy ei ffurfweddiad arferol. Mae pob galwad ôl yn cadw ei rheol ei hun, felly nid yw derbyn y cyfrif ar borth 8001 yn derbyn y cyfrif hwnnw ar borth 8002.

Mae requestAuthentication true yn dychwelyd her proxy Basic. Pan fo dilysu'n ofynnol, anwybyddir upstreamProxyUrl ar gyfer y cais hwnnw. Mae cyfrif mynediad llwyddiannus a'r cyfrif upstream yn unfathiantau ar wahân.

Defnyddiwch URL a gefnogir ar gyfer pob upstream, gan gynnwys glodau wedi'u hamgodio'n gywir pan fo angen. Ar gyfer upstream HTTP cyhoeddus heb ddilysu, dewiswch ymgeisydd o'r rhestr proxïau HTTP a chodwch ei URL heb glodau. Mae upstream a hepgorir yn dewis anfon uniongyrchol yn hytrach na phroxy awtomatig arall.

Mae'r enghraifft yn rhwymo loopback ar gyfer cleientiaid lleol. Rhwymwch y rhyngwyneb a fwriedir yn fwriadol pan fo rhaid i beiriant arall gysylltu, gyda'r polisi mynediad cyfatebol.

Cadwch y gweinyddwyr yn fyw ar gyfer llwyth eu cleientiaid. Dylai eu perchennog gau pob gweinydd drwy ei ddull cau a gefnogir wrth gau i lawr; nid yw'r enghraifft yn diffinio cylch bywyd llawn y cymhwysiad hwnnw.