Як перевірити антидетект-браузер на витоки через WebRTC, UDP і QUIC

SOCKS5-UDP витік - це коли браузер надсилає UDP-пакети, найчастіше трафік WebRTC чи QUIC, напряму в інтернет замість тунелю проксі. Причина проста: більшість проксі-налаштувань пересилають лише TCP. З цим стикаються під час відеодзвінків, при завантаженні сайтів через HTTP/3 або в антидетект-профілі, який мав би ховатися за резидентною IP. І ризик тут прямий: справжня IP-адреса, провайдер і країна випливають поруч із тією особистістю, яку ви будували в профілі.

Що насправді означає SOCKS5-UDP витік

SOCKS5-UDP витік це ситуація, коли частина трафіку, зазвичай WebRTC або QUIC, обходить проксі повністю і йде через реальне мережеве з'єднання. Браузер у рядку адреси все ще показує IP проксі. Тим часом скрипт у тій самій вкладці вже отримав вашу справжню IP через окремий канал.

Це найбільше стосується тих, хто веде більше одного браузерного профілю. Чекеру відбитків, рекламній платформі чи антифрод-системі маркетплейсу не потрібно бачити вашу справжню IP напряму, достатньо однієї невідповідності між IP, яку показує TCP-трафік, і IP, яку зливає UDP-трафік. Саме цю невідповідність описує наша стаття про витік WebRTC як один із найстаріших і досі найпоширеніших способів деанонімізації в мережі.

TCP проти UDP: чому більшість проксі покривають лише половину трафіку

Стандартні SOCKS5 і HTTP проксі створювалися навколо TCP, протоколу, на якому працюють звичайні завантаження сторінок, логіни та форми. UDP це другий протокол того самого транспортного рівня, що й TCP, тільки він пропускає хендшейк і не гарантує доставку пакетів. Через це він швидший, але складніший для стабільного релею, і значна частина проксі-софту просто ніколи його не реалізувала.

RFC 1928, специфікація, що визначає SOCKS5, насправді містить окрему команду протоколу під назвою UDP ASSOCIATE саме для такого випадку. Клієнт відкриває TCP-з'єднання керування, проходить автентифікацію і просить проксі відкрити UDP-релей. Проксі у відповідь дає адресу для надсилання датаграм, і з цього моменту кожен UDP-пакет обгортається у невеликий заголовок SOCKS5 перед пересиланням. Важлива деталь: те саме TCP-з'єднання має лишатися відкритим протягом усієї UDP-сесії, бо воно контролює час життя релею, і щойно воно обірветься, проксі закриє асоціацію. Наш детальний розбір UDP через SOCKS5 розкриває цей хендшейк докладніше, якщо цікавить повна механіка.

Підтримка UDP ASSOCIATE у специфікації SOCKS5 це одне. А те, щоб браузер справді пропускав WebRTC і QUIC трафік через цей релей, це вже окрема задача, і саме тут ламається більшість налаштувань. Багато провайдерів проксі рекламують "SOCKS5 з UDP", тоді як браузер поверх нього продовжує надсилати STUN-запити через звичайну мережеву картку. Проксі і браузер мають працювати разом, і саме цей розрив розбирає наш гайд про антидетект-браузери та анонімність.

І головна причина тут зовсім не в проксі. Реалізація SOCKS5 у самому Chromium обмежена операціями TCP CONNECT, команди UDP ASSOCIATE в ній немає взагалі. Ба більше, коли профілю призначено SOCKS5-проксі, Chromium примусово вимикає QUIC і відкочує з'єднання на HTTP/2 поверх TCP. Тож нативна підтримка UDP в антидетект-браузері означає, що вендор пропатчив мережевий стек Chromium, а не додав перемикач у налаштуваннях.

QUIC, HTTP/3 і WebTransport: протоколи, що обходять старі проксі

QUIC це транспортний протокол поверх UDP: спочатку його розробили в Google як gQUIC, згодом IETF стандартизував його як RFC 9000, і сьогодні він є основою HTTP/3. Він знімає проблему head-of-line blocking, коли в TCP один загублений пакет блокує всю чергу і решта даних чекає на його повторне надсилання, навіть якщо давно дійшла. QUIC мультиплексує потоки так, що втрачений пакет затримує лише ті дані, які в ньому й були. Chrome, Firefox, Safari і більшість CDN (Cloudflare, Google, Fastly) вже за замовчуванням надають перевагу HTTP/3, коли він доступний.

WebTransport будується прямо поверх такої QUIC-сесії. Він відкривається запитом CONNECT через HTTP/3 і далі тримає постійний зашифрований канал для даних із низькою затримкою, за духом схожий на WebSockets, але працює через UDP замість TCP. Проксі, який перехоплює лише TCP, взагалі не знає про існування сесії WebTransport. Він просто бачить, як UDP-пакети пролітають повз через реальний мережевий інтерфейс, і ніхто їх не зупиняє.

Найнаочніше цю різницю показує wtcheck.top: сторінка паралельно визначає вашу адресу через звичайне TCP-з'єднання і через WebTransport поверх QUIC, а потім виводить обидва значення поруч. Якщо профіль тунелює UDP коректно, обидва рядки однакові. Якщо ні, друге значення миттєво видає реальну адресу.

Тут же підключаються STUN-запити WebRTC. WebRTC використовує процес ICE, щоб знайти найшвидший шлях для peer-to-peer з'єднання: браузер збирає список ICE-кандидатів, тобто всіх адрес, за якими до нього можна достукатися, з локальних мережевих інтерфейсів і від зовнішніх серверів. Частина цього процесу це запит до STUN-сервера (Session Traversal Utilities for NAT) з питанням "як виглядає моя IP ззовні". Якщо цей запит іде через реальний інтерфейс замість проксі, STUN-сервер віддає вашу справжню публічну IP прямо в JavaScript сторінки, без жодного спеціального дозволу. Технічний розбір є в нашій статті про WebRTC STUN.

STUN не варто плутати з TURN. STUN лише повідомляє браузеру, як його адреса виглядає ззовні, а TURN ретранслює весь трафік через власний сервер і тому реальну IP співрозмовнику не показує. Витік стається саме через STUN, бо ICE пробує його першим як найдешевший варіант.

Покроково: перевірка браузера на витік IP через WebRTC

Тест на витік WebRTC відповідає на одне пряме питання: чи збігається IP-адреса, яку показує WebRTC, з тією IP, яку має показувати ваш проксі. Ось як перевірити це правильно, а не гадати.

1. відкрий антидетект-профіль з уже призначеним і активним проксі
2. занотуй IP і країну проксі з дашборду провайдера ще до будь-яких дій
3. перейди на browserleaks.com/webrtc у тому самому профілі
4. порівняй рядок "Public IP Address" у блоці "Your WebRTC IP" з IP проксі, яку записав
5. розгорни "SDP Log" і перевір список ICE-кандидатів, бо витік інтерфейсу часто видно саме там, навіть коли підсумкове поле виглядає чистим
6. повтори тест в іншому профілі з іншим проксі, щоб виключити випадковість

Якщо "Public IP Address" точно збігається з проксі, цей канал виглядає чистим. Якщо там стоїть IP вашого провайдера, щось на машині зливає реальні мережеві дані прямо в сторінку.

А от рядок "Local IP Address" сучасні браузери маскують навмисно. Замість приватної адреси на кшталт 192.168.1.5 ви побачите випадковий хостнейм виду 1f4712db-ea17-4bcf-a596-105139dfd8bf.local: це mDNS, протокол виявлення пристроїв у локальній мережі, який WebRTC застосовує саме для того, щоб не віддавати приватну IP в JavaScript. Chrome, Firefox, Edge і Safari роблять так за замовчуванням, тож .local у цьому рядку це нормальна поведінка, а не витік. Порожній прочерк замість адреси теж нормальний: він означає, що локальних кандидатів браузер не зібрав узагалі, і саме так виглядає результат на скріншоті нижче.

Є ще одна пастка, про яку майже ніхто не пише. Збіг IP у цьому тесті сам по собі не доводить, що UDP справді йде через тунель. Частина антидетект-браузерів просто підміняє відповідь WebRTC на рівні JavaScript API: сторінка отримує IP проксі, тоді як самі UDP-пакети летять повз тунель через реальну мережеву картку. Тому WebRTC-тест не можна вважати самодостатнім. Реальне тунелювання дає збіг одразу в трьох каналах, а підміна ламається щойно ви виходите за межі WebRTC, і наступний розділ це якраз перевіряє.

Наша стаття про обхід чекерів відбитків розповідає, що робити після підтвердження витоку саме на цьому каналі, включно з тим, які прапорці браузера справді його закривають.

Покроково: перевірка витоків QUIC, HTTP/3 і WebTransport

Перевірка QUIC і WebTransport вимагає трохи більше терпіння, ніж перевірка WebRTC, здебільшого тому, що ці з'єднання узгоджують версію протоколу і не завжди спрацьовують з першого завантаження. Одразу застереження щодо http3.is: сервіс перевіряє чернеткові версії h3-29 і h3-27 зразка 2020 року, тоді як фінальний HTTP/3 стандартизовано як RFC 9114 з ідентифікатором h3. Його вердикт "HTTP/3 не використано" сам по собі ще не означає проблеми, тож основним інструментом краще тримати browserleaks.com/quic.

1. відкрий http3.is в активному профілі й прочитай повідомлення на банері
2. онови сторінку два-три рази, бо браузеру іноді потрібен попередній візит, перш ніж він спробує HTTP/3
3. відкрий quic.tanatos.org:444 у другій вкладці й запиши IP, порт і версію протоколу
4. звір цю IP з IP проксі з дашборду провайдера
5. відкрий browserleaks.com/quic і звір IP-адресу з'єднання, набір шифрів, JA4-відбиток та статус Encrypted Client Hello
6. заверши перевіркою на wtcheck.top, яка окремо показує вашу IP через TCP і через WebTransport поверх QUIC

Кілька приміток до кроків. Без порту 444 домен quic.tanatos.org віддає загальний список інструментів, а не сам тест. У звіті browserleaks JA4 це хеш параметрів TLS-рукостискання, за яким сайт упізнає ваш клієнт, а Encrypted Client Hello показує, чи шифрується ім'я домену в запиті; обидва поля тут другорядні, головне це IP-адреса з'єднання. Сервіс wtcheck.top зручний, але його веде команда одного з антидетект-браузерів із таблиці нижче, тож поради на його сторінці читайте як рекламу.

Чистий результат виглядає навмисно нудно: та сама IP всюди, у WebRTC, HTTP/3 і WebTransport. Витік виглядає як IP проксі в першому інструменті і IP провайдера в третьому. Саме ця невідповідність і є сигналом.

Третій можливий результат збиває з пантелику найчастіше: HTTP/3 не встановлюється взагалі. Це не поломка. Пам'ятаєте про Chromium, який вимикає QUIC при налаштованому SOCKS5? Трафік просто відкотився на TCP і пішов через проксі, тобто витоку немає. Небезпечний сценарій виглядає інакше: HTTP/3 працює, а IP у звіті ваша власна.

Які антидетект-браузери справді тунелюють UDP через SOCKS5

Маркетингові сторінки обожнюють фразу "підтримує UDP", але відрізнити реальну функцію на рівні ядра від рядка, скопійованого зі специфікації партнера-проксі, не так просто. Тому ми звірились з офіційною документацією для кожного браузера, а не з тим, що пишуть сайти-порівнювачі. Рядки відсортовані за силою підтвердження: згори ті, у кого підтримка задокументована, знизу ті, у кого її в документації немає.

Два рядки варті окремого коментаря. У Multilogin теза "SOCKS5 підтримує UDP" описує можливості самого протоколу, а не те, що клієнт браузера ці можливості використовує, і це різні речі. У GeeLark аргумент "це реальний Android у хмарі" теж нічого не доводить: хмарний пристрій так само підключений до проксі, і той проксі так само має вміти UDP ASSOCIATE.

У схожих добірках часто трапляються ще Vision Browser і WADE X із позначкою "UDP через SOCKS5". Обидві згадки ведуть у партнерський контент одного продавця проксі, а публічної технічної документації, яка б це підтверджувала, ми не знайшли, тому в таблицю вони не потрапили. Повну картину щодо цін, доступу до API та глибини фінгерпринтингу на ринку дивись у нашому порівнянні 13 антидетект-браузерів, яке йде далеко за межі лише колонки UDP.

Ніщо з цього не працює без співпраці з боку проксі. Браузер з ідеальною підтримкою UDP ASSOCIATE все одно зливатиме дані, якщо резидентний проксі за ним пересилає лише TCP.

Поширені причини UDP-витоку і як виправити кожну

Більшість витоків зводяться до кількох типових причин. І для кожної є конкретне рішення, а не розпливчасте "будьте обережні".

• провайдер проксі пересилає лише TCP: перейди на тариф, де прямо задокументована підтримка UDP ASSOCIATE, а не просто "SOCKS5"
• браузер за задумом ігнорує проксі для WebRTC: використовуй браузер із нативною маршрутизацією UDP або вимкни WebRTC у налаштуваннях профілю, якщо відео чи голос не потрібні (у звичайному Chrome окремого перемикача вже немає, потрібне розширення або корпоративна політика)
• IPv6 витікає в обхід тунелю: вимкни IPv6 на рівні мережевого адаптера в ОС, бо більшість проксі тунелюють лише IPv4
• розширення браузера відкриває власні мережеві запити поза проксі-налаштуваннями профілю: видали або вимкни розширення, які не перевіряв, особливо гаманці та VPN-розширення, що працюють паралельно
• застарілий DNS чи системні налаштування проксі перебивають налаштування профілю: очисти DNS-кеш ОС, переконайся, що профіль не переходить на системний проксі, і прожени профіль через DNS Leak Test на quic.tanatos.org

Перш ніж міняти проксі чи браузер, варто відсікти найпростіше пояснення: можливо, UDP не працює у вашій мережі взагалі. Корпоративні фаєрволи, готельний Wi-Fi і частина мобільних операторів ріжуть UDP на порті 443 цілком свідомо. Для такої діагностики зручний networktest.twilio.com: він послідовно пробує з'єднання через UDP, TCP і TLS, перевіряє доступність STUN і TURN-серверів і показує, який саме транспорт до вас доходить. Якщо UDP не проходить навіть без проксі, справа не в антидетект-браузері.

Повторюй цей тест двічі на місяць, якщо ведеш кілька профілів одночасно, бо провайдери проксі змінюють інфраструктуру без особливих попереджень, і IP, що підтримує UDP сьогодні, може тихо втратити цю підтримку наступного тижня.

SOCKS5-UDP проти стандартного SOCKS5 чи HTTP проксі

Стандартний SOCKS5 чи HTTP проксі пересилає лише TCP, і крапка. SOCKS5-UDP це та сама родина протоколу, але з командою UDP ASSOCIATE, яка справді реалізована і використовується як на сервері проксі, так і на клієнті, що з нею працює.

Якщо робота обмежується статичним скрейпінгом сторінок без відео, без розширень крипто-гаманців і без сайтів, що активно використовують HTTP/3, стандартного проксі може реально вистачити. Але щойно в картину входять WebRTC, ігри чи сучасні CDN, розрив між цими двома колонками перетворюється на вашу справжню IP у звіті про витік.

Як зібрати налаштування, що справді проходить ці тести

Купівля проксі з підтримкою UDP вирішує лише половину задачі. Друга половина це ядро браузера, яке справді маршрутизує WebRTC, QUIC і WebTransport через цей тунель замість того, щоб тихо відкочуватися на реальну мережеву картку. Саме на цій другій половині провалюється більшість антидетект-налаштувань у всіх тестах вище.

Afina вирішує це всередині самого ядра браузера, а не костилем зверху. Кожен профіль маршрутизує SOCKS5-UDP трафік, включно з QUIC і HTTP/3, через призначений проксі - тому WebRTC-відбиток у тесті збігається з IP проксі, а не з реальним з'єднанням. Матеріал статті для тестування й освітніх цілей: результат все одно залежить від конкретного проксі, з яким працює браузер.

Скачати