બ્રાઉઝરની HTTP પ્રોક્સી ગોઠવણી WebRTCને આપમેળે આવરી લેતી નથી. સામાન્ય IP-તપાસ પેજ વેબ વિનંતી માપે છે; કૉલ જોડાવા અને સરનામાં શોધવા માટે અલગ માર્ગ વાપરી શકે છે.

SOCKS5 આ ભેદ દૂર કરતું નથી. Chromiumનું અંદરથી આપેલું SOCKS5 URL પ્રોક્સી અમલીકરણ TCPને ટેકો આપે છે, સામાન્ય UDP એસોસિએશનને નહીં. પ્રોટોકોલની ક્ષમતા બ્રાઉઝરના આ ઇન્ટરફેસ કરતાં વિશાળ છે.

બ્રાઉઝર WebRTC માટે અલગ નેટવર્ક નિયંત્રણ આપે છે. Chrome તેની ગોપનીયતા એક્સ્ટેન્શન API દ્વારા IP સંભાળવાની નીતિ આપે છે, જેમાં disable_non_proxied_udp છે; Mozilla પણ WebRTC નેટવર્ક ગોપનીયતા ગોઠવણીનું દસ્તાવેજીકરણ આપે છે. Chromeનું આ મૂલ્ય API નીતિ છે, સર્વત્ર લાગુ ચેકબોક્સ કે દરેક સરનામું છુપાવવાની ખાતરી નથી.

પહેલાં સામાન્ય વેબ એક્ઝિટ તપાસો, પછી ખરેખર વપરાતી મીટિંગ એપમાં WebRTCનું વર્તન એવા નિદાન સાધનથી તપાસો જેના રિપોર્ટના ક્ષેત્રો તમે સમજો છો. સ્થાનિક સરનામાં, રિલે સરનામાં અને બહારથી દેખાતા જાહેર સરનામાં કનેક્શનના અલગ ભાગ દર્શાવે છે. બ્રાઉઝર અને તપાસની પરિસ્થિતિ નોંધો: નીતિ, એક્સ્ટેન્શન, ગોપનીયતા વર્તન અને ઉપલબ્ધ માર્ગ પરિણામને અસર કરે છે. એટલે «હંમેશાં લીક થાય છે» કે સફળ વેબ IP તપાસ, બંનેમાંથી કોઈ એક પૂરતું તારણ નથી.

WebRTCનો માર્ગ મર્યાદિત કરો તો જરૂરી કૉલ ફરી અજમાવો. સરનામાંનું પ્રગટીકરણ ઘટાડવાથી કૉલ જોડાવું પણ અટકી શકે છે. આ સમાધાન HTTP પ્રોક્સી એન્ડપોઇન્ટ ઑનલાઇન છે કે નહીં તેનાથી અલગ છે.

સંબંધિત લેખો