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 बद्दलचा एक जुना अहवाल प्रत्येक प्लॅटफॉर्मसाठी कायमचा नियम करू नका.