فرض کنید east.proxy.example و west.proxy.example به یک شنوندهٔ معمولی HTTP پراکسی تفکیک می‌شوند. کارخواهی که هر یک از این نام‌ها را به کار ببرد می‌تواند بفرستد:

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

درخواست وبگاه را مشخص می‌کند. اما نام مستعار پراکسی را که کارخواه پیش از گشودن TCP تفکیک کرده بود، حمل نمی‌کند. از این رو نام میزبان برگرفته از Host در Express نمی‌تواند بر پایهٔ آن زیردامنه‌های پراکسی مسیری را برگزیند.

اگر کارخواه و پراکسی را کنترل می‌کنید، ورودی مسیریابی صریحی فراهم کنید. برای پراکسی‌ای که برچسب 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 آن هنوز سرور مقصد را مشخص می‌کند، نه نام مستعار پراکسی را.

مقالات مرتبط