Octo Browser
Пользователь
- Регистрация
- 14.11.24
- Сообщения
- 40
- Реакции
- 0
Octo Browser поддерживает UDP через SOCKS5. Это значит, что WebRTC, QUIC, HTTP/3 и WebTransport идут через прокси, а не мимо него. Ниже показываем, так ли это на деле.
Что именно проверяем
Утверждения «UDP работает» недостаточно. Главный вопрос: выходит ли UDP-трафик с того же адреса, что и TCP. Провалиться тут можно двумя способами, и оба заканчиваются деанонимизацией:
Стенд
Все шесть кадров — один непрерывный сеанс, а не шесть отдельных прогонов. Это видно по трём вещам:
Тест 1. Звонок через прокси: Twilio Network Test
12:04, одна вкладка, сеанс только начался
Официальный диагностический инструмент Twilio, крупного провайдера телефонии и видеосвязи. Разработчики используют его, чтобы проверить, потянет ли сеть клиента браузерные звонки. Он не ищет утечки и ничего не знает про антидетект-браузеры: он просто делает настоящий звонок.
Все проверки прошли, включая TURN UDP Connectivity. Это буквально означает, что UDP-пакеты от браузера дошли до серверов Twilio и вернулись обратно. Затем тест провёл два реальных звонка на разных кодеках, PCMU и Opus. В логе справа видны их идентификаторы, нулевые потери пакетов и итоговые оценки качества: Great и Good.
Отдельно обратите внимание на примечания к пунктам про TCP и TLS. Twilio пишет, что Twilio Voice по TCP не работает вообще. То есть оба состоявшихся звонка шли по UDP, другого варианта у них не было.
Вывод: через SOCKS5-прокси прошли два живых голосовых звонка с нулевой потерей пакетов.
Тест 2. QUIC работает, и адрес прокси: BrowserLeaks
Публичная проверка 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
Первые два теста показали, что UDP проходит и что по QUIC адрес правильный. Этот тест сверяет адреса по всем каналам сразу и отдельно проверяет, не имитирует ли браузер работу WebRTC вместо настоящей.
В блоке IP Sources четыре строки, то есть четыре разных способа узнать наш адрес: обычный HTTP-запрос (TCP), STUN-сервер (UDP), TURN-ретранслятор по UDP и тот же TURN по TCP. Все четыре показывают 68.59.118.110, адрес прокси. Адрес по UDP совпадает с адресом по TCP.
Ниже блок Detection Flags: семь отдельных проверок на то, что браузер жульничает. У всех семи результат NO:
Вывод: четыре независимых канала (HTTP, STUN, TURN UDP и TURN TCP) дают один и тот же адрес. Ни одна из семи проверок на блокировку и подмену не сработала.
Тест 4. 3000 запросов по HTTP/3: NGINX QUIC Sandbox
Тестовый стенд самих разработчиков 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
Это уже третий способ гонять UDP: в тесте 1 был WebRTC, в тестах 2 и 4 QUIC и HTTP/3, здесь WebTransport. Каждый следующий тест сужает пространство для возражения «ну этот конкретный протокол у вас работает, а остальные?».
Оба поля показывают 68.59.118.110. Сравнивать между скриншотами ничего не нужно, оба значения на одной странице.
Вывод: соединение по WebTransport пришло с того же адреса, что и обычный TCP-запрос той же страницы.
Тест 6. DNS резолвится на стороне прокси: BrowserLeaks
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.
Для новых пользователей действует промокод CPAMAFIA30 (скидка 30% на первую покупку подписки).
Что именно проверяем
Утверждения «UDP работает» недостаточно. Главный вопрос: выходит ли UDP-трафик с того же адреса, что и TCP. Провалиться тут можно двумя способами, и оба заканчиваются деанонимизацией:
- UDP идёт в обход прокси, напрямую с машины. Сайт видит и адрес прокси (по TCP), и настоящий адрес пользователя (по STUN или QUIC). Это худший вариант: человек считает себя защищённым, а на деле раскрыт сильнее, чем вообще без прокси.
- UDP заблокирован целиком. Утечки нет, но браузер без WebRTC и без QUIC сам по себе аномалия, и антифрод её замечает.
Стенд
- Браузер — 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.
Все шесть кадров — один непрерывный сеанс, а не шесть отдельных прогонов. Это видно по трём вещам:
- В верхней части каждого кадра одна и та же строка профиля: имя, ID, прокси и рядом бейдж UDP с адресом 68.59.118.110. Octo показывает выходной адрес для UDP отдельной строкой, и именно он должен появляться во всех тестах.
- Вкладки не закрывались. На первом скрине она одна, на последнем шесть, а предыдущие тесты видны в панели по названиям.
- Часы в трее идут подряд: 12:04 → 12:04 → 12:05 → 12:07 → 12:10 → 12:11.
Тест 1. Звонок через прокси: Twilio Network Test
12:04, одна вкладка, сеанс только начался
Официальный диагностический инструмент Twilio, крупного провайдера телефонии и видеосвязи. Разработчики используют его, чтобы проверить, потянет ли сеть клиента браузерные звонки. Он не ищет утечки и ничего не знает про антидетект-браузеры: он просто делает настоящий звонок.
Все проверки прошли, включая TURN UDP Connectivity. Это буквально означает, что UDP-пакеты от браузера дошли до серверов Twilio и вернулись обратно. Затем тест провёл два реальных звонка на разных кодеках, PCMU и Opus. В логе справа видны их идентификаторы, нулевые потери пакетов и итоговые оценки качества: Great и Good.
Отдельно обратите внимание на примечания к пунктам про TCP и TLS. Twilio пишет, что Twilio Voice по TCP не работает вообще. То есть оба состоявшихся звонка шли по UDP, другого варианта у них не было.
Вывод: через SOCKS5-прокси прошли два живых голосовых звонка с нулевой потерей пакетов.
Тест 2. QUIC работает, и адрес прокси: BrowserLeaks
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
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: ретранслятор настоящий
Вывод: четыре независимых канала (HTTP, STUN, TURN UDP и TURN TCP) дают один и тот же адрес. Ни одна из семи проверок на блокировку и подмену не сработала.
Тест 4. 3000 запросов по HTTP/3: NGINX QUIC Sandbox
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
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
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.
- networktest.twilio.com: звонок по WebRTC, проходит ли UDP до серверов телефонии
- browserleaks.com/quic: работает ли QUIC и с какого адреса он приходит
- ipbinding.notsosmart.dev: сверка адреса по HTTP, STUN, TURN UDP и TURN TCP плюс флаги подмены
- quic.nginx.org/quic.html: держит ли канал нагрузку, 3000 запросов по HTTP/3
- wtcheck.top: совпадает ли адрес по WebTransport с адресом по TCP
- browserleaks.com/dns: кому принадлежат резолверы, участвовавшие в определении адресов
Для новых пользователей действует промокод CPAMAFIA30 (скидка 30% на первую покупку подписки).
