WebRTC leak в Multilogin: что проверить, чтобы IP не утекал через браузерный канал

WebRTC leak в Multilogin: что проверить, чтобы IP не утекал через браузерный канал

WebRTC течёт не потому, что «антидетект плохой», а потому что браузер отдаёт сетевые кандидаты: локальный IP, публичный IP, иногда связку между ними. Для антидетекта это критично: профиль может выглядеть чисто по фингерпринту, но спалиться на сетевом слое.

В Multilogin обычно смотрят на три вещи:
— отключён ли прямой WebRTC-доступ к локальной сети;
— подменяется ли наружный адрес на тот же, что у прокси;
— не включён ли режим, где браузер всё равно отдаёт реальные кандидаты через SDP.

На практике безопаснее не «ломать» WebRTC полностью, а приводить его к модели прокси: внешний IP должен совпадать с прокси, а локальные адреса не должны светиться в тестах. Если профиль работает через резидентский или мобильный прокси, проверь, чтобы WebRTC не выбирал прямой маршрут мимо него 🔍

Минимальный чек:
— открыть тест WebRTC в профиле;
— сравнить IP в браузере и IP прокси;
— проверить, не виден ли localhost, 192.168.x.x или другой private range;
— прогнать профиль после перезапуска, а не только сразу после создания.

Если WebRTC закрыт правильно, профиль выглядит не просто «маскированным», а сетево согласованным. А это как раз тот случай, когда банов меньше не из-за магии, а из-за отсутствия лишних несостыковок.