প্রক্সি ব্যবহার করলে CURLOPT_CONNECT_TO কী পরিবর্তন করে

CURLOPT_CONNECT_TO মিলে যাওয়া গন্তব্যের জন্য libcurl যে হোস্ট ও পোর্টে সংযোগ করে তা পরিবর্তন করে। এটি বিকল্প এন্ডপয়েন্টকে HTTP CONNECT বা SOCKS বলতে বাধ্য করে না।

মূল হোস্টনামই এখনও অ্যাপ্লিকেশন-প্রোটোকল ও TLS পরিচয় যোগায়। একই সেবার অন্য কোনো সার্ভার ইনস্ট্যান্সে সচেতনভাবে পৌঁছাতে এটি কাজে লাগে। কিন্তু একটি নির্বিচার প্রক্সি লিসেনার বরং তার প্রক্সি হ্যান্ডশেক আশা করে, অ্যাপ্লিকেশনের কাঁচা বাইট নয়।

ম্যাপিংটি HTTP প্রক্সির সঙ্গে মেলানো

HTTP প্রক্সিটি আলাদাভাবে কনফিগার করুন। পাবলিক সেবায় শংসাপত্রহীন HTTP পথ সেই মধ্যস্থতাকারী অনুমোদিত হলে HTTP প্রক্সি তালিকা থেকে একটি এন্ডপয়েন্ট ব্যবহার করতে পারে; প্রার্থীর কাছে কোনো বিদ্যমান প্রক্সি অ্যাকাউন্ট পাঠানো উচিত নয়। libcurl নথিভুক্ত করে যে ভিন্ন connect-to ম্যাপিং তখন অনুরোধটিকে টানেল মোডে বদলে দিতে পারে: প্রক্সি ম্যাপকৃত গন্তব্য সংযোগটি খোলে। ম্যাপিং ঠিক করে প্রক্সির মাধ্যমে কী পৌঁছানো হবে; এটি প্রক্সি কনফিগারেশনকে প্রতিস্থাপন করেনি।

তিনটি মান আলাদা রাখুন: অভিপ্রেত সেবার নাম, বিকল্প সংযোগ এন্ডপয়েন্ট এবং প্রক্সি এন্ডপয়েন্ট। প্রতিটি অপশন তার প্রকৃত ভূমিকার জন্য বেছে নিন এবং সেবার জন্য স্বাভাবিক TLS নাম যাচাই বজায় রাখুন।

যদি প্রক্সি পোর্ট নিজেই সংযোগ প্রত্যাখ্যান করে, তবে সেই একই অনুপস্থিত লিসেনারের দিকে দেখানো অন্য কোনো অপশন প্রথম ধাপটি ঠিক করতে পারে না। গন্তব্য ম্যাপিং পরিবর্তনের আগে সেই লিসেনার বা পথের ব্যর্থতা সমাধান করুন।