UDP через SOCKS5: шесть тестов, один профиль, один IP

Хотите попробовать Octo Browser со скидкой?
По промокоду OCTOBLOG получите 30% скидку на любую подписку. Предложение действительно только для новых пользователей.

Стенд

• Браузер — Octo Browser 3.1.3 (Chromium 152).

• Профиль — Quick honorable-bar · ID 8dd7332…

• Прокси (Elusive) — SOCKS5 · 91.132.161.222:35225.

• Выходной адрес — 68.59.118.110 · США · Comcast · резидентный.

• Дата и время — 10 сентября 2026, 12:04–12:11.

Как читать скриншоты

Все шесть кадров — один непрерывный сеанс, а не шесть отдельных прогонов. Это видно по трем вещам, и на них стоит обратить внимание, прежде чем смотреть сами тесты: 

1. В верхней части каждого кадра одна и та же строка профиля: Quick honorable-bar, ID 8dd7332…, прокси 91.132.161.222:35225 и рядом бейдж UDP 68.59.118.110. Octo показывает выходной адрес для UDP отдельной строкой — именно он и должен появляться во всех тестах ниже.

2. Вкладки не закрывались. На первом скрине она одна, на последнем — шесть, и предыдущие тесты видны в панели по названиям.

3. Часы в трее идут подряд: 12:04 → 12:04 → 12:05 → 12:07 → 12:10 → 12:11.

Перенастроить профиль между тестами было негде.

Шаг 1. Звонок через прокси — Twilio Network Test

10 сентября, 12:04. Одна вкладка — сеанс только начался

Официальный диагностический инструмент Twilio — крупного провайдера телефонии и видеосвязи. Разработчики используют его, чтобы проверить, потянет ли сеть клиента браузерные звонки. Он не ищет утечки и ничего не знает про антидетект-браузеры — он просто берет и делает настоящий звонок.

Все проверки прошли, включая TURN UDP Connectivity, — а это буквально означает, что UDP-пакеты от браузера дошли до серверов Twilio и вернулись обратно. Дальше тест провел два настоящих звонка на разных кодеках, PCMU и Opus: в логе справа видны их идентификаторы, нулевые потери пакетов и итоговые оценки качества — Great и Good.

Отдельно стоит прочитать примечания к пунктам про TCP и TLS. Twilio там пишет, что Twilio Voice по TCP не работает вообще. То есть оба состоявшихся звонка шли по UDP — другого варианта у них не было.

Вывод: через SOCKS5-прокси прошли два живых голосовых звонка с нулевой потерей пакетов.

Шаг 2: QUIC работает, и адрес — прокси. BrowserLeaks

10 сентября, 12:04. Вкладок стало две — Twilio слева никуда не делся

Публичная проверка QUIC от BrowserLeaks. Она отвечает на два разных вопроса сразу, и оба нам нужны: поддерживает ли браузер QUIC — то есть проходит ли UDP, и с какого адреса сервер увидел нас по QUIC — то есть куда этот UDP идет.

Шаг 1 уже показал работающий UDP, но это был другой UDP. Twilio проверял WebRTC — UDP для звонков. QUIC — это UDP для обычного веба, на нем работает HTTP/3, по нему с браузером общаются Google и YouTube. Технологии разные, и поддержка одной не означает поддержку другой.

На скриншоте два ответа. QUIC Connection: True — соединение поверх UDP установлено. IP Address: 68.59.118.110 — тот самый адрес, который Octo показывает в строке профиля как UDP-выход.

Вывод: QUIC-соединение установлено, и сервер увидел его с адреса прокси.

Шаг 3: Четыре канала — один адрес. WebRTC Detection Check

10 сентября, 12:05. Третья вкладка, два предыдущих теста открыты слева

Первые два шага показали, что UDP проходит и что по QUIC адрес правильный. Этот тест сверяет адреса по всем каналам сразу и отдельно проверяет, не имитирует ли браузер работу WebRTC вместо настоящей.

В блоке IP Sources четыре строки, и это четыре разных способа узнать наш адрес: по обычному HTTP-запросу (TCP), через STUN-сервер (UDP), через TURN-ретранслятор по UDP и через тот же TURN по TCP. Все четыре строки показывают 68.59.118.110 — адрес прокси. То есть адрес по UDP совпадает с адресом по TCP.

Ниже — блок Detection Flags, семь отдельных проверок на то, что браузер жульничает. У всех семи результат NO:

• WebRTC Blocked — WebRTC не отключен, он работает.

• UDP/TCP Mismatch — расхождения между адресом по UDP и по TCP нет.

• Candidates Spoofed — ICE-кандидаты, которыми браузер представляется собеседнику, не подменены.

• TURN UDP Blocked и TURN TCP Blocked — ретрансляция работает в обе стороны.

• Relay Spoofed — ретранслятор настоящий.

Важна именно комбинация. Первый флаг говорит, что WebRTC работает, остальные шесть — что при этом ничего не подменено. Скрыть проблему, отключив WebRTC, здесь не получится: это сразу видно в первой же строке.

Вывод: четыре независимых канала — HTTP, STUN, TURN UDP и TURN TCP — дают один и тот же адрес. Ни одна из семи проверок на блокировку и подмену не сработала.

Шаг 4: 3000 запросов по HTTP/3 — NGINX QUIC Sandbox

10 сентября, 12:07. Четвертая вкладка

Тестовый стенд самих разработчиков nginx. Он отправляет пачку запросов и раскладывает результат по трем счетчикам: сколько ушло по QUIC, сколько по обычному HTTP и сколько не дошло вовсе.

Шаг 2 показал одно QUIC-соединение. Здесь их три тысячи подряд — это уже проверка не на поддержку, а на то, держит ли канал нагрузку.

Результат: Total requests 3000, Success with QUIC 3000, Success with HTTP 0, Failed requests 0. Прогресс 3000/3000, и поле визуализации под ним целиком зеленое — по легенде зеленый — это QUIC, ячеек другого цвета на нем нет.

Внимания заслуживает счетчик Success with HTTP. Он существует в этом тесте именно для запросов, которые не смогли уйти по QUIC и ушли по обычному HTTP. В нем ноль.

Вывод: 3000 из 3000 запросов ушли по QUIC. Ни одного отката на обычный HTTP, ни одной неудачи.

Шаг 5: WebTransport — тот же адрес. wtcheck.top

10 сентября, 12:10. Пятая вкладка

WebTransport — еще один браузерный способ обмениваться данными поверх QUIC, то есть поверх UDP. Страница делает два запроса и показывает результат рядом: с какого адреса пришел обычный запрос по TCP и с какого — соединение по WebTransport.

Это третий по счету иной способ гонять UDP: в шаге 1 был WebRTC, в шагах 2 и 4 — QUIC и HTTP/3, здесь — WebTransport. Каждый следующий сужает пространство для возражения «ну этот конкретный протокол у вас работает, а остальные?».

Оба поля показывают 68.59.118.110. Сравнивать между скриншотами ничего не нужно — оба значения на одной странице.

Вывод: соединение по WebTransport пришло с того же адреса, что и обычный TCP-запрос той же страницы.

Шаг 6: DNS резолвится на стороне прокси — BrowserLeaks

10 сентября, 12:11. Шестая вкладка, все предыдущие тесты открыты слева.

DNS — отдельный канал, не тот же, что весь трафик выше. Прокси может быть настроен идеально, а браузер при этом будет спрашивать «какой адрес у сайта X» у резолвера локального провайдера. Последствий два: этот провайдер видит историю посещений, а сайт может сопоставить географию резолвера с географией адреса и заметить нестыковку.

Тест смотрит, какие DNS-серверы участвовали в резолве. На скриншоте: адрес 68.59.118.110, провайдер Comcast и результат Found 77 Servers, 1 ISP. В видимой части списка — резолверы из диапазона 69.241.83.x, и у каждого в графе ISP стоит тот же Comcast.

Ключевая цифра — 1 ISP. Все резолверы до единого принадлежат тому же провайдеру, что и выходной адрес прокси. Ни один запрос не ушел к чужому резолверу.

Вывод: все 77 DNS-серверов принадлежат провайдеру выходной ноды. Резолв происходит на стороне прокси, локальный резолвер не участвует.

Как повторить тест самостоятельно 

Создайте профиль и укажите в нем свой SOCKS5-прокси с поддержкой UDP. Запустите профиль и пройдите по шести ссылкам ниже. Сверяйте адрес. Во всех тестах он должен совпадать с тем, что Octo показывает в строке профиля в бейдже UDP.

1. networktest.twilio.com — звонок по WebRTC — проходит ли UDP до серверов телефонии;

2. browserleaks.com/quic — работает ли QUIC и с какого адреса он приходит;

3. ipbinding.notsosmart.dev — сверка адреса по HTTP, STUN, TURN UDP и TURN TCP плюс флаги подмены;

4. quic.nginx.org/quic.html — держит ли канал нагрузку: 3000 запросов по HTTP/3;

5. wtcheck.top — совпадает ли адрес по WebTransport с адресом по TCP;

6. browserleaks.com/dns — кому принадлежат резолверы, участвовавшие в определении адресов.