تنظیم پروکسی HTTP مرورگر به‌طور خودکار WebRTC را پوشش نمی‌دهد. صفحه معمول بررسی IP یک درخواست وب را می‌سنجد؛ تماس ممکن است برای اتصال و کشف آدرس از مسیرهای جداگانه استفاده کند.

SOCKS5 این تفاوت را از بین نمی‌برد. پیاده‌سازی داخلی پروکسی URL از نوع SOCKS5 در Chromium از TCP پشتیبانی می‌کند، نه یک ارتباط عمومی UDP. توانایی‌های پروتکل گسترده‌تر از این رابط مرورگر است.

مرورگرها کنترل‌های شبکه جداگانه‌ای برای WebRTC دارند. Chrome از طریق API افزونه‌های حریم خصوصی، سیاست رسیدگی به IP از جمله disable_non_proxied_udp را ارائه می‌کند؛ Mozilla هم تنظیمات حریم خصوصی شبکه WebRTC را مستند کرده است. این مقدار Chrome یک سیاست API است، نه گزینه‌ای همگانی یا تضمینی برای پنهان کردن همه آدرس‌ها.

ابتدا خروجی معمول وب را بررسی کنید، سپس رفتار WebRTC را در برنامه کنفرانس واقعی با ابزار عیب‌یابی‌ای بسنجید که معنای فیلدهای گزارش آن را می‌دانید. آدرس‌های محلی، آدرس‌های رله و آدرس‌های عمومی مشاهده‌شده بخش‌های متفاوت اتصال را توصیف می‌کنند. مرورگر و شرایط آزمایش را ثبت کنید: سیاست‌ها، افزونه‌ها، رفتار حریم خصوصی و مسیرهای در دسترس بر نتیجه اثر دارند؛ بنابراین نه «همیشه نشت می‌کند» و نه موفقیت بررسی IP وب، به‌تنهایی نتیجه کافی نیست.

اگر مسیر WebRTC را محدود می‌کنید، تماس‌های موردنیاز را دوباره امتحان کنید. کاهش افشای آدرس ممکن است مانع برقراری تماس هم بشود. این بده‌بستان جدا از آنلاین بودن نقطه پایانی پروکسی HTTP است.

مقالات مرتبط