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 बारे एउटा पुरानो प्रतिवेदनलाई हरेक प्लेटफर्मका लागि स्थायी नियम नबनाउनुहोस्।