proxy-chain: ບັນຊີ ແລະ upstream ແຍກຕ່າງຫາກສຳລັບ listener ແຕ່ລະອັນ

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 ສົ່ງຄືນຄຳທ້າທາຍ proxy Basic. ເມື່ອຕ້ອງການການຢືນຢັນຕົວຕົນ, upstreamProxyUrl ຈະຖືກລະເລີຍສຳລັບຄຳຂໍນັ້ນ. ບັນຊີຂາເຂົ້າທີ່ສຳເລັດ ແລະ ບັນຊີ upstream ເປັນຕົວຕົນທີ່ແຍກກັນ.

ໃຊ້ URL ທີ່ຮອງຮັບສຳລັບແຕ່ລະ upstream, ລວມທັງຂໍ້ມູນປະຈຳຕົວທີ່ເຂົ້າລະຫັດຢ່າງຖືກຕ້ອງ ເມື່ອຈຳເປັນ. ສຳລັບ upstream HTTP ສາທາລະນະທີ່ບໍ່ມີການຢືນຢັນ, ເລືອກຜູ້ສະໝັກຈາກລາຍຊື່ proxy HTTP ແລະສ້າງ URL ຂອງມັນໂດຍບໍ່ມີຂໍ້ມູນປະຈຳຕົວ. upstream ທີ່ຖືກລະເວັ້ນຈະເລືອກການສົ່ງຕໍ່ໂດຍກົງແທນ proxy ອັດຕະໂນມັດອື່ນ.

ຕົວຢ່າງຜູກ loopback ສຳລັບລູກຄ້າທ້ອງຖິ່ນ. ຈົ່ງຜູກອິນເຕີເຟດທີ່ຕັ້ງໃຈຢ່າງຕັ້ງໃຈ ເມື່ອເຄື່ອງອື່ນຕ້ອງເຊື່ອມຕໍ່, ພ້ອມນະໂຍບາຍການເຂົ້າເຖິງທີ່ສອດຄ່ອງ.

ຮັກສາເຊີບເວີໃຫ້ຢູ່ລອດສຳລັບພາລະວຽກຂອງລູກຄ້າ. ເຈົ້າຂອງຄວນປິດແຕ່ລະເຊີບເວີຜ່ານວິທີປິດທີ່ຮອງຮັບເມື່ອປິດເຄື່ອງ; ຕົວຢ່າງບໍ່ໄດ້ກຳນົດວົງຈອນຊີວິດເຕັມຂອງແອັບພລິເຄຊັນນັ້ນ.