ब्राउझरची HTTP प्रॉक्सी सेटिंग WebRTCला आपोआप लागू होत नाही. नेहमीचे IP-तपासणी पेज वेब विनंती मोजते; कॉल जोडण्यासाठी आणि पत्ते शोधण्यासाठी वेगळे मार्ग वापरू शकतो.

SOCKS5 हा फरक मिटवत नाही. Chromiumमधील अंगभूत SOCKS5 URL प्रॉक्सी अंमलबजावणी TCPला समर्थन देते, सर्वसाधारण UDP असोसिएशनला नाही. प्रोटोकॉलची क्षमता ब्राउझरच्या या इंटरफेसपेक्षा व्यापक आहे.

ब्राउझर WebRTCसाठी वेगळी नेटवर्क नियंत्रणे देतात. Chrome गोपनीयता एक्स्टेंशन APIमधून disable_non_proxied_udpसह IP हाताळणीचे धोरण उपलब्ध करते; Mozillaही WebRTC नेटवर्क गोपनीयता सेटिंगची कागदपत्रे देते. Chromeचे हे मूल्य API धोरण आहे, सर्वत्र असणारा चेकबॉक्स किंवा प्रत्येक पत्ता लपवण्याची हमी नाही.

आधी नेहमीचा वेब एक्झिट तपासा, मग प्रत्यक्ष वापरल्या जाणाऱ्या कॉन्फरन्सिंग अॅपमध्ये WebRTCचे वर्तन अशा निदान साधनाने पाहा ज्याच्या अहवालातील फील्ड तुम्हाला समजतात. स्थानिक पत्ते, रिले पत्ते आणि बाहेरून दिसणारे सार्वजनिक पत्ते कनेक्शनचे वेगवेगळे भाग दर्शवतात. ब्राउझर आणि तपासणीच्या अटी नोंदवा: धोरणे, एक्स्टेंशन, गोपनीयतेचे वर्तन आणि उपलब्ध मार्ग निकालावर परिणाम करतात. म्हणून «नेहमी गळती होते» किंवा यशस्वी वेब IP तपासणी, यांपैकी कोणतेही एक पुरेसे निष्कर्ष नाही.

WebRTCचा मार्ग मर्यादित केला तर आवश्यक कॉल पुन्हा करून पाहा. पत्ते उघड होणे कमी केल्याने कॉल जोडणेही थांबू शकते. ही तडजोड HTTP प्रॉक्सी एंडपॉइंट ऑनलाइन आहे की नाही यापासून वेगळी आहे.

संबंधित लेख