curl socks5h بمقابلہ socks5: میزبان نام کون حل کرتا ہے

لوگ socks5h کو socks5 کی آسان ہجے سمجھتے ہیں، اور توقع کرتے ہیں کہ دونوں وہی درخواست اسی جگہ بھیجیں گے۔ اضافی حرف اس کے بجائے DNS استفسار کو منتقل کرتا ہے۔ جس مشین میں حل کنندہ اور پراکسی مختلف نیٹ ورکس میں ہوں، وہاں یہی کامیاب اور ناکام درخواست کے درمیان فرق ہے۔

ایک حرف، دو حل کنندہ

اسکیم طے کرتی ہے کہ منزل کا نام کہاں پتہ بنتا ہے۔ مقامی حل آپ کی مشین پر ترتیب دیا گیا حل کنندہ استعمال کرتا ہے۔ دور دراز حل میزبان نام کو SOCKS درخواست کے اندر رکھتا ہے، اور پراکسی اسے اپنے حل کنندہ اور نیٹ ورک کے بارے میں اپنے نظریے سے تلاش کرتی ہے۔ دونوں شکلیں اب بھی اسی پورٹ پر اسی پراکسی پتے سے جڑتی ہیں، اس لیے فرق راستے میں نہیں، درخواست کے جسم میں ہے۔

اسکیم میں کوئی چیز خفیہ کاری یا توثیق نہیں بدلتی؛ صرف DNS راستہ سرکتا ہے۔ اسی لیے حرف کو نظر انداز کرنا آسان اور غلطی کرنا مہنگا ہے۔

وہی پراکسی، مختلف درخواست

دونوں کالز صرف ایک حرف سے مختلف ہیں۔ باقی سب کچھ یکساں ہے:

curl --proxy socks5://proxy.example:1080 https://service.example/
curl --proxy socks5h://proxy.example:1080 https://service.example/

The curl پراکسی حوالہ ان اسکیموں کو الگ الگ دستاویز کرتا ہے، اور یہی انہیں متبادل نام نہ سمجھنے کی مستند وجہ ہے۔ دونوں کو کسی بے ضرر اینڈ پوائنٹ کے خلاف چلائیں جس کے استعمال کی آپ کو اجازت ہے اور فرق پڑھیں۔ کامیاب دور دراز تلاش دیگر ایپلیکیشنز کے بارے میں کچھ نہیں کہتی، کیونکہ براؤزر، پیکیج مینیجر اور زبانوں کے رن ٹائم ہر ایک خود چنتا ہے۔

پراکسی کا اپنا نام مقامی طور پر حل ہوتا ہے

اس کمانڈ میں، کچھ اور ہونے سے پہلے proxy.example کو پتہ بننا ہوتا ہے، اور وہ تلاش ہمیشہ مقامی ہوتی ہے۔ service.example کے حل کو پراکسی پر منتقل کرنے سے پراکسی کے اپنے نام کے لیے کچھ نہیں ہوتا، جسے اب بھی ایسا حل کنندہ درکار ہے جس تک آپ کی مشین پہنچ سکے۔ یہیں VPN تصویر بدلتا ہے۔

اگر پراکسی کا نام صرف سرنگ کے اندر حل ہوتا ہے، تو curl شروع ہونے سے پہلے سرنگ کے قائم ہونے پر رابطہ منحصر ہے۔ پھر کون سی اسکیم جیتے گی اس پر منحصر ہے کہ کون سا فریق جواب دے سکتا ہے۔ جب آپ کی مشین منزل حل نہیں کر سکتی مگر پراکسی کر سکتی ہے، تو socks5 ناکام ہوتا ہے اور socks5h کامیاب ہوتا ہے۔ جب آپ کی مشین اسے سرنگ کے ذریعے حل کرتی ہے اور پراکسی نہیں کر سکتی، تو socks5 کام کرتا ہے اور socks5h ناکام ہوتا ہے۔

اسکیم پراکسی سے رابطے کو VPN کے اندر یا باہر نہیں رکھتی؛ یہ روٹنگ جدول کرتا ہے، اور اسکیم اسے کبھی نہیں دیکھتی۔ اسی لیے ایک سرنگ ایک اسکیم درست کر سکتی ہے اور دوسری کو اسی مشین پر توڑ سکتی ہے۔ حرف صرف یہ طے کرتا ہے کہ سوال کون پوچھتا ہے۔

ہر فریق کیا حل کر سکتا ہے

عوامی پراکسی صرف کمپنی میں موجود نام حل نہیں کر سکتی، اس لیے اسے میزبان نام بھیجنا پراکسی پر ناکام ہوتا ہے اور مقامی DNS خرابی کے بجائے پراکسی خرابی کے طور پر ظاہر ہوتا ہے۔ اسی نجی نیٹ ورک کے اندر کی پراکسی ایسے نام عام طور پر حل کر سکتی ہے، اور وہیں socks5h اپنی قدر ثابت کرتا ہے۔ حل کنندہ کی جگہ اس پالیسی کے مطابق چنیں جس کی آپ کو واقعی ضرورت ہے، کیونکہ دور دراز DNS خود بخود زیادہ قابل نہیں ہوتا اور یہ نام تیسرے فریق کے حوالے کرتا ہے۔ عوامی منزل کے لیے دونوں شکلیں کام کرتی ہیں، اس لیے وہی چنیں جو آپ کے دیگر اوزار پہلے ہی استعمال کرتے ہیں۔

وہ انتخاب تبصرے میں نہیں، رن بک میں لکھیں، اور اسناد کو مشترکہ تاریخ اور تشخیصی آؤٹ پٹ سے باہر رکھیں۔ پھر ایک وقت میں ایک متغیر بدلیں: وہی منزل، وہی بائنری، وہی حل کنندہ، ایک حرف۔

کون سی بائنری نے جواب دیا

ایک ہی مشین پر دو curl بائنریز ورژن اور بلڈ خصوصیات میں مختلف ہو سکتی ہیں۔ Unix جیسے شیل میں type -a curl راستے پر ہر مماثلت کی فہرست دیتا ہے اور curl --version چلنے والی بائنری کی خصوصیات دکھاتا ہے۔ راستے میں پہلے آنے والی ریپر اسکرپٹ یا عرف عام وجہ ہے کہ نتائج اس بائنری سے میل نہیں کھاتے جسے آپ جانچ رہے ہیں۔

غیر معاون اسکیم، نام حل نہ کر سکنے والی پراکسی اور ناقابل رسائی منزل تین مختلف خرابیاں ہیں، اس لیے حرف بدلنے سے پہلے پیغام پڑھیں۔ socks5h نحو کے بغیر بلڈ پراکسی اسٹرنگ کو غیر معاون بتاتا ہے، جو حل نہ ہونے والے نام کے برابر نہیں۔ نظام curl کے بارے میں ایک پرانی رپورٹ کو ہر پلیٹ فارم کے لیے مستقل اصول نہ بنائیں۔