ધારો કે east.proxy.example અને west.proxy.example એક જ સાદા HTTP પ્રોક્સી શ્રોતા પર ઉકેલાય છે. બંનેમાંથી કોઈપણ નામ વાપરતો ક્લાયન્ટ મોકલી શકે છે:

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

વિનંતી વેબસાઇટને ઓળખે છે. TCP ખોલતાં પહેલાં ક્લાયન્ટે ઉકેલેલું પ્રોક્સી ઉપનામ તે વહન કરતી નથી. તેથી Express માં Host પરથી મેળવેલું હોસ્ટનામ તે પ્રોક્સી સબડોમેનના આધારે માર્ગ પસંદ કરી શકતું નથી.

જો તમે ક્લાયન્ટ અને પ્રોક્સી નિયંત્રિત કરો છો, તો સ્પષ્ટ રાઉટિંગ ઇનપુટ આપો. 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 વિનંતી મિડલવેર તે ઘટનાને સંભાળતું નથી. તેનું CONNECT લક્ષ્ય હજી પણ લક્ષ્ય સર્વરને ઓળખે છે, પ્રોક્સી ઉપનામને નહીં.

સંબંધિત લેખો