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-ს აკავშირებს ლოკალური კლიენტებისთვის. როცა სხვა მანქანა უნდა დაუკავშირდეს, განზრახ მიაბით სასურველი ინტერფეისი შესაბამისი წვდომის პოლიტიკით.

შეინარჩუნეთ სერვერები ცოცხლად მათი კლიენტების დატვირთვისთვის. მათმა მფლობელმა გამორთვისას უნდა დახუროს თითოეული სერვერი მისი მხარდაჭერილი დახურვის მეთოდით; მაგალითი არ განსაზღვრავს ამ აპლიკაციის სრულ სიცოცხლის ციკლს.

დაკავშირებული სტატიები