proxy-chain: リスナーごとにアカウントとアップストリームを分ける

proxy-chain は待ち受けポートごとに 1 つの Server インスタンスを実行できます。そのリスナーのポリシーを認証コールバックに保持します:

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 を渡します。各コールバックは独自のルールを保持するため、ポート 8001 でアカウントを受け入れても、ポート 8002 でそのアカウントを受け入れることにはなりません。

requestAuthentication true は Basic プロキシのチャレンジを返します。認証が必要な場合、そのリクエストでは upstreamProxyUrl は無視されます。受信アカウントの認証成功とアップストリームのアカウントは別の ID です。

各アップストリームにはサポートされた URL を使用し、必要に応じて適切にエンコードされた資格情報を含めます。認証不要の公開 HTTP アップストリームでは、HTTP プロキシ一覧から候補を選び、資格情報なしで URL を組み立てます。アップストリームを省略すると、別の自動プロキシではなく直接転送が選ばれます。

この例はローカルクライアント向けに loopback をバインドします。別のマシンが接続する必要がある場合は、対応するアクセスポリシーとともに目的のインターフェースを意図的にバインドしてください。

サーバーはクライアントの負荷のために稼働させ続けます。所有者はシャットダウン時にサポートされた終了方法で各サーバーを閉じるべきです。この例はそのアプリケーションの完全なライフサイクルを定義していません。