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

Приложение передаёт значения учётных записей и URL-адреса upstream через свою обычную конфигурацию. Каждый callback сохраняет собственное правило, поэтому принятие учётной записи на порту 8001 не принимает эту запись на порту 8002.

requestAuthentication true возвращает запрос прокси-аутентификации Basic. Когда требуется аутентификация, upstreamProxyUrl для этого запроса игнорируется. Успешная входящая учётная запись и учётная запись upstream — разные субъекты.

Используйте поддерживаемый URL для каждого upstream, включая правильно закодированные учётные данные, когда это необходимо. Для публичного HTTP-upstream без аутентификации выберите кандидата из списка HTTP-прокси и постройте его URL без учётных данных. Пропущенный upstream выбирает прямую передачу, а не другой автоматический прокси.

В примере привязка идёт к loopback для локальных клиентов. Привязывайте нужный интерфейс осознанно, когда должно подключаться другое устройство, с соответствующей политикой доступа.

Поддерживайте серверы работающими для нагрузки их клиентов. Владелец должен закрывать каждый сервер поддерживаемым методом закрытия при остановке; пример не определяет полный жизненный цикл этого приложения.

Похожие статьи