הגדרת פרוקסי HTTP בדפדפן אינה מכסה אוטומטית את WebRTC. עמוד רגיל לבדיקת IP מודד בקשת רשת; שיחה עשויה להשתמש במסלולים נפרדים להתחברות ולגילוי כתובות.

SOCKS5 אינו מבטל את ההבחנה הזו. המימוש המובנה של פרוקסי URL מסוג SOCKS5 ב-Chromium תומך ב-TCP ולא בשיוך UDP כללי. יכולות הפרוטוקול רחבות יותר מהממשק הזה של הדפדפן.

דפדפנים מספקים בקרות רשת נפרדות ל-WebRTC. Chrome חושף מדיניות לטיפול ב-IP דרך API של הרחבות פרטיות, כולל disable_non_proxied_udp; גם Mozilla מתעדת הגדרות פרטיות רשת של WebRTC. הערך הזה ב-Chrome הוא מדיניות API, לא תיבת סימון אוניברסלית או הבטחה להסתיר כל כתובת.

בדקו את יציאת הרשת הרגילה, ואחר כך את התנהגות WebRTC ביישום הוועידות שבו אתם משתמשים בפועל, באמצעות כלי אבחון שאתם מבינים את השדות שהוא מדווח. כתובות מקומיות, כתובות ממסר וכתובות ציבוריות שנצפו מתארות חלקים שונים של החיבור. תעדו את הדפדפן ותנאי הבדיקה: מדיניות, הרחבות, התנהגות פרטיות ומסלולים זמינים משפיעים על התוצאה. לכן לא ״תמיד דולף״ ולא בדיקת IP מוצלחת ברשת מספיקים כמסקנה.

אם אתם מגבילים מסלול WebRTC, נסו שוב את השיחות הנחוצות. צמצום חשיפת הכתובות עלול גם למנוע את התחברות השיחה. הפשרה הזו נפרדת מהשאלה אם נקודת קצה של פרוקסי HTTP זמינה.

מאמרים קשורים