SOCKS प्रोक्सीले सन्देश लोड गर्न सक्छ तर कलमा असफल हुन्छ
Dante निर्देशिका र SOCKS5 का UDP आवश्यकताहरू प्रयोग गरेर काम गर्ने TCP मार्गले किन एप्लिकेसनको कल ट्राफिकको समर्थन प्रमाणित गर्दैन भन्ने व्याख्या गरिएको छ।
पाठ सन्देशहरू SOCKS प्रोक्सीबाट आउँछन्, तर भ्वाइस कल कहिल्यै जोडिँदैन। प्रोक्सी पूर्ण रूपमा बिग्रेको हुनु आवश्यक छैन। एप्लिकेसनले कलका लागि अर्को ढुवानी प्रयोग गरिरहेको हुन सक्छ।
सफल TCP अनुरोधले त्यो कार्यका लागि TCP मार्ग प्रमाणित गर्छ। SOCKS5 ले UDP सम्बन्ध पनि परिभाषित गर्छ, तर क्लाइन्ट, SOCKS सेवा, नेटवर्क नियम र एप्लिकेसन सेटिङ सबैले इच्छित UDP मार्गलाई समर्थन गर्नुपर्छ।
TCP श्रोताभन्दा बढी केही छ
Dante निर्देशिकाले प्रोटोकल र आदेश नियमहरू अलग गर्छ, जसमा connect, udpassociate र udpreply पर्छन्। तपाईंले पहिले नै परीक्षण गरिसकेको TCP जडानलाई मात्र अनुमति दिने नियमले आवश्यक UDP अनुमति स्थापित गर्दैन।
UDP सम्बन्धमा रिले अन्त्य बिन्दु र फर्किने ट्राफिक पनि समावेश हुन्छ। फायरवाल र ठेगाना अनुवादले त्यही वास्तविक मार्गलाई अनुमति दिनुपर्छ। SOCKS को TCP श्रोता खोल्नु यसको UDP रिले पहुँचयोग्य बनाउनुसरह होइन।
एप्लिकेसनको हालको प्रोक्सी कागजात र सेटिङ जाँच्नुहोस्। विभिन्न संस्करणले सन्देश, मिडिया र कल फरक तरिकाले ह्यान्डल गर्न सक्छन्। पुरानो क्लाइन्टका लागि फोरमको विधिलाई हरेक हालको क्लाइन्टले कल SOCKS मार्फत पठाउँछ भन्ने प्रमाणका रूपमा प्रस्तुत गर्नु हुँदैन।
पहिलो निदानका रूपमा हरेक UDP पोर्ट खोल्नबाट बच्नुहोस्। रिले व्यवहार र इच्छित क्लाइन्ट दायरा निर्धारण गर्नुहोस्, त्यसपछि उपयुक्त प्रतिबन्धित नेटवर्क नीति लागू गर्नुहोस्। त्यस्तै, कलका लागि प्रोक्सी सेटिङ अक्षम गर्दा कल सिधै पठाएर काम गर्न सक्छ, जसले प्रोक्सी गरिएको मार्ग सुधार्नुको सट्टा बाहिरी मार्ग बदल्छ।
प्रत्येक कार्यका लागि सफलता अभिलेख गर्नुहोस्: सन्देश, मिडिया स्थानान्तरण र कल। एउटा काम गर्ने अनुरोध वा बदलिएको ब्राउजर IP ले अर्को एप्लिकेसनको हरेक भाग एउटै प्रोक्सी निकास साझा गर्छ भनी प्रमाणित गर्न सक्दैन।