proxy-chain: प्रत्येक listener साठी वेगळी खाती आणि upstream

proxy-chain प्रत्येक ऐकण्याच्या पोर्टसाठी एक Server प्रतिकृती चालवू शकते. त्या listener चे धोरण त्याच्या प्रमाणीकरण कॉलबॅकमध्ये नोंदवा:

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 पुरवतो. प्रत्येक कॉलबॅक स्वतःचा नियम ठेवतो, म्हणून पोर्ट 8001 वर खाते स्वीकारणे म्हणजे पोर्ट 8002 वर ते खाते स्वीकारणे नाही.

requestAuthentication true एक Basic प्रॉक्सी आव्हान परत करतो. प्रमाणीकरण आवश्यक असल्यास त्या विनंतीसाठी upstreamProxyUrl दुर्लक्षित केले जाते. यशस्वी येणारे खाते आणि upstream खाते वेगवेगळ्या ओळखी आहेत.

प्रत्येक upstream साठी समर्थित URL वापरा, गरज असल्यास योग्यरित्या एन्कोड केलेली ओळखपत्रे सह. प्रमाणीकरण नसलेल्या सार्वजनिक HTTP upstream साठी HTTP प्रॉक्सी यादीमधून उमेदवार निवडा आणि ओळखपत्रांशिवाय त्याचा URL तयार करा. वगळलेला upstream दुसऱ्या स्वयंचलित प्रॉक्सीऐवजी थेट फॉरवर्डिंग निवडतो.

उदाहरण स्थानिक क्लायंटसाठी loopback बांधते. दुसऱ्या मशीनला जोडायचे असल्यास संबंधित प्रवेश धोरणासह इच्छित इंटरफेस जाणीवपूर्वक बांधा.

सर्व्हर त्यांच्या क्लायंटच्या कामाच्या भारासाठी जिवंत ठेवा. त्यांच्या मालकाने शटडाउनच्या वेळी प्रत्येक सर्व्हर त्याच्या समर्थित बंद पद्धतीने बंद करावा; उदाहरण त्या अनुप्रयोगाचे संपूर्ण जीवनचक्र परिभाषित करत नाही.