SOCKS प्रॉक्सी संदेश लोड करू शकतो पण कॉलवर अयशस्वी होतो

मजकूर संदेश SOCKS प्रॉक्सीद्वारे येतात, पण व्हॉइस कॉल कधीही जोडला जात नाही. प्रॉक्सी पूर्णपणे खराब असणे आवश्यक नाही. अनुप्रयोग कॉलसाठी वेगळे वाहतूक वापरत असू शकतो.

यशस्वी TCP विनंती त्या क्रियेसाठी TCP मार्ग सिद्ध करते. SOCKS5 UDP सहयोग देखील परिभाषित करते, पण क्लायंट, SOCKS सेवा, नेटवर्क नियम आणि अनुप्रयोग सेटिंग्ज सर्वांनी इच्छित UDP मार्गाला आधार दिला पाहिजे.

TCP श्रोत्यापेक्षा अधिक काही आहे

Dante हस्तपुस्तिका प्रोटोकॉल आणि आदेश नियम वेगळे करते, त्यात connect, udpassociate आणि udpreply आहेत. जो नियम फक्त तुम्ही आधीच तपासलेल्या TCP कनेक्शनला परवानगी देतो तो आवश्यक UDP परवानग्या स्थापित करत नाही.

UDP सहयोगात रिले एंडपॉइंट आणि परतीचा रहदारी देखील समाविष्ट आहे. फायरवॉल आणि पत्ता भाषांतराने तो प्रत्यक्ष मार्ग परवानगी दिली पाहिजे. SOCKS चा TCP श्रोता उघडणे त्याच्या UDP रिलेला पोहोचण्यायोग्य करण्यासारखे नाही.

अनुप्रयोगाचे सध्याचे प्रॉक्सी दस्तऐवज आणि सेटिंग्ज तपासा. वेगवेगळ्या आवृत्त्या संदेश, मीडिया आणि कॉल वेगळ्या प्रकारे हाताळू शकतात. जुन्या क्लायंटसाठीची फोरम रेसिपी प्रत्येक सध्याचा क्लायंट कॉल SOCKS द्वारे पाठवतो याचा पुरावा म्हणून सादर करू नये.

पहिल्या निदानासाठी प्रत्येक UDP पोर्ट उघडणे टाळा. रिले वर्तन आणि इच्छित क्लायंट व्याप्ती निश्चित करा, नंतर योग्य प्रतिबंधित नेटवर्क धोरण लागू करा. त्याचप्रमाणे, कॉलसाठी प्रॉक्सी सेटिंग बंद केल्यास कॉल थेट पाठवून काम करू शकतो, जे प्रॉक्सी केलेला मार्ग दुरुस्त करण्याऐवजी बाह्य मार्ग बदलते.

प्रत्येक क्रियेसाठी यश नोंदवा: संदेश, मीडिया हस्तांतरण आणि कॉल. एक कार्यरत विनंती किंवा बदललेला ब्राउझर IP हे सिद्ध करू शकत नाही की दुसर्‍या अनुप्रयोगाचा प्रत्येक भाग समान प्रॉक्सी एक्झिट सामायिक करतो.