ব্রাউজারের প্রক্সি কি WebRTC-ও কভার করে?
সাধারণ ওয়েব IP পরীক্ষা ও WebRTC সংযোগ ভিন্ন পথ নিতে পারে। ব্রাউজারের রিয়েল-টাইম যোগাযোগ আলাদাভাবে পরীক্ষা করুন।
ব্রাউজারের 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 প্রক্সি এন্ডপয়েন্ট অনলাইনে আছে কি না, তার থেকে আলাদা।