Да претпоставиме дека east.proxy.example и west.proxy.example водат кон истиот обичен HTTP-прокси слушач. Клиент што користи кое било од двете имиња може да испрати:

GET http://www.example.org/report HTTP/1.1
Host: www.example.org

Барањето ја идентификува веб-страницата. Тоа не го носи псевдонимот на проксито што клиентот го решил пред да отвори TCP. Затоа hostname во Express изведен од Host не може да избере рута врз основа на тие прокси поддомени.

Ако ги контролирате клиентот и проксито, обезбедете експлицитен влез за рутирање. За прокси што имплементира ознака X-Route:

curl --proxy http://east.proxy.example:8080 \
  --proxy-header 'X-Route: east' \
  https://www.example.org/

--proxy-header е насочен кон комуникацијата со проксито, вклучително CONNECT. Обично заглавје -H на HTTPS-барањето припаѓа внатре во шифрираната HTTP-размена со дестинацијата.

Серверот мора да ја имплементира и авторизира политиката за рутирање, потоа да ја искористи ознаката без да ја препрати до веб-страницата. Алтернативно, користете одделно конфигурирани слушачки крајни точки или прокси-сметки како влезови за рутирање.

За HTTPS-дестинации Node го прима почетното барање за тунел преку настанот connect на својот HTTP-сервер. Обичниот Express посреднички софтвер за барања не го обработува тој настан. Целта CONNECT сè уште го идентификува серверот на дестинацијата, а не псевдонимот на проксито.

Поврзани статии