დავუშვათ, east.proxy.example და west.proxy.example ერთსა და იმავე ჩვეულებრივ HTTP პროქსის მსმენელზე წყდება. კლიენტს, რომელიც რომელიმე სახელს იყენებს, შეუძლია გაგზავნოს:

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

მოთხოვნა განსაზღვრავს ვებსაიტს. ის არ შეიცავს იმ პროქსის ფსევდონიმს, რომელიც კლიენტმა TCP-ის გახსნამდე გადაწყვიტა. ამიტომ Express-ის Host-იდან მიღებული hostname ვერ აირჩევს მარშრუტს ამ პროქსის ქვედომენების მიხედვით.

თუ აკონტროლებთ კლიენტსა და პროქსის, მიაწოდეთ მარშრუტიზაციის მკაფიო შეყვანა. პროქსისთვის, რომელიც ახორციელებს X-Route ჭდეს:

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

--proxy-header მიმართულია პროქსისთან კომუნიკაციაზე, CONNECT-ის ჩათვლით. HTTPS მოთხოვნაზე ჩვეულებრივი -H სათაური დანიშნულების დაშიფრულ HTTP გაცვლაშია.

სერვერმა უნდა განახორციელოს და უფლება მისცეს მარშრუტიზაციის პოლიტიკას, შემდეგ კი გამოიყენოს ჭდე ვებსაიტზე გადაუგზავნლად. ალტერნატივის სახით, გამოიყენეთ ცალკე კონფიგურირებული მოსმენის ბოლო წერტილები ან პროქსის ანგარიშები მარშრუტიზაციის შეყვანად.

HTTPS დანიშნულებებისთვის Node საწყის გვირაბის მოთხოვნას იღებს თავისი HTTP სერვერის connect მოვლენის მეშვეობით. ჩვეულებრივი Express მოთხოვნის middleware ამ მოვლენას არ ამუშავებს. მისი CONNECT სამიზნე კვლავ დანიშნულების სერვერს განსაზღვრავს, არა პროქსის ფსევდონიმს.

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