آنچه CURLOPT_CONNECT_TO هنگام استفاده از پراکسی تغییر می‌دهد
به‌جای فرض اینکه HTTP یا SOCKS را در نشانی جدید پیاده می‌کند، از نگاشت connect-to کتابخانه libcurl برای نقاط پایانی شبکه جایگزین استفاده کنید.
CURLOPT_CONNECT_TO میزبان و پورتی را که libcurl برای مقصد منطبق به آن متصل می‌شود تغییر می‌دهد. این گزینه باعث نمی‌شود نقطه پایانی جایگزین به HTTP CONNECT یا SOCKS سخن بگوید.
نام میزبان اصلی همچنان هویت پروتکل برنامه و TLS را تأمین می‌کند. این هنگام رسیدن عامدانه به نمونه سرور دیگری از همان سرویس سودمند است. در عوض، یک شنونده پراکسی دلبخواه انتظار دست‌دهی پراکسی خودش را دارد، نه بایت‌های خام برنامه.
ترکیب نگاشت با یک پراکسی HTTP
پراکسی HTTP را جداگانه پیکربندی کنید. یک مسیر HTTP بدون اعتبارنامه به سرویس عمومی می‌تواند وقتی آن واسط مجاز است از نقطه پایانی فهرست پراکسی HTTP استفاده کند؛ هیچ حساب پراکسی موجودی نباید به نامزد فرستاده شود. libcurl مستند می‌کند که نگاشت connect-to متفاوت می‌تواند سپس درخواست را به حالت تونل ببرد: پراکسی اتصال مقصد نگاشت‌شده را باز می‌کند. نگاشت تعیین می‌کند چه چیزی از طریق پراکسی به دست می‌آید؛ این نگاشت پیکربندی پراکسی را جایگزین نکرده است.
سه مقدار را جدا نگه دارید: نام سرویس موردنظر، نقطه پایانی اتصال جایگزین و نقطه پایانی پراکسی. هر گزینه را برای نقش واقعی‌اش انتخاب کنید و بررسی عادی نام TLS را برای سرویس حفظ کنید.
اگر خودِ پورت پراکسی اتصال‌ها را رد کند، گزینه دیگری که به همان شنونده غایب اشاره می‌کند نمی‌تواند پرش نخست را درست کند. پیش از تغییر نگاشت مقصد، آن خرابی شنونده یا مسیر را برطرف کنید.