UDP прокси

В PapaProxy UDP-прокси — это SOCKS5-прокси с полностью реализованной командой UDP ASSOCIATE: SOCKS5 (RFC 1928) — единственный массовый стандарт прокси с нативной поддержкой UDP, и мы реализовали и протестировали эту поддержку от начала до конца. Когда ваше приложение подключается к нашему прокси, оно открывает управляющее TCP-соединение и отправляет запрос UDP ASSOCIATE; наш сервер возвращает выделенный адрес и порт для ретрансляции; затем ваш клиент шлёт UDP-датаграммы (каждая обёрнута в небольшой заголовок SOCKS5) на этот адрес, а мы пересылаем их получателю и возвращаем ответы обратно. Управляющее TCP-соединение остаётся открытым на всю сессию, так как именно оно определяет время жизни ассоциации. Мы провели множество внутренних тестов этого механизма, поэтому игры, голосовые клиенты и стриминг работают через наши UDP-прокси без скрытого отката на TCP.

Нет. HTTP- и HTTPS-прокси работают только с TCP (через метод CONNECT), поэтому они не могут передавать настоящий UDP-трафик — именно поэтому наши UDP-прокси работают на SOCKS5 с UDP ASSOCIATE, а не на HTTP. На практике это важно: многие провайдеры помечают свои прокси как «UDP-совместимые», но на деле всегда пересылают только TCP. У нас же UDP ASSOCIATE реализован по-настоящему и проверен в тестах, поэтому ваши UDP-датаграммы действительно ретранслируются. (Передача UDP поверх HTTP через MASQUE / CONNECT-UDP в HTTP/3 существует, но в 2026 году это всё ещё экспериментальная технология, доступная лишь у нескольких крупных CDN, поэтому мы используем проверенный путь через SOCKS5.)

Если прогонять UDP через туннель, поддерживающий только TCP, каждая датаграмма оборачивается в TCP-соединение с состоянием, и одна потерянная пачка данных останавливает весь поток, пока TCP ждёт повторной пересылки (head-of-line blocking) — отсюда рывки в играх, рост пинга и заикания в звонках. Именно поэтому мы реализовали полноценный UDP ASSOCIATE, а не оборачиваем ваш трафик в TCP: с нашими прокси UDP остаётся UDP.

UDP — основа интернета реального времени, и вот задачи, для которых наши клиенты чаще всего используют наши UDP-прокси:

• Онлайн-игры — гонки, MMO и шутеры используют UDP для связи клиент—сервер с низким пингом, где важны даже несколько миллисекунд.
• Голосовые и видеозвонки — Discord, Zoom, Microsoft Teams и другие VoIP-приложения передают аудио и видео в реальном времени по UDP (RTP).
• Стриминг и IPTV — UDP избавляет от заиканий, которые в real-time видео вызывают повторные пересылки.
• DNS-запросы — DNS работает по UDP, порт 53.
• WebRTC — связь в реальном времени прямо в браузере работает по UDP и часто становится причиной утечки IP.
• Торренты — протокол uTP в BitTorrent работает поверх UDP.
• NTP — синхронизация времени использует UDP, порт 123.
• Туннелирование UDP-VPN — например, маскировка WireGuard под обычный трафик для обхода строгих фаерволов.

Нет, и мы говорим об этом честно. Наши прокси подменяют ваш реальный IP на IP прокси, но SOCKS5 — как и сам UDP — не шифрует содержимое пакетов. Если вам нужно шифрование, используйте приложение со встроенным шифрованием (HTTPS или DTLS для WebRTC) либо поднимите шифрованный туннель, например WireGuard, поверх нашего прокси. Прокси даёт вам чистый IP и настоящий UDP-транспорт, а шифрование — задача приложения уровнем выше.

Нас выделяют три вещи:

• Настоящий UDP, а не пометка. Полноценный UDP ASSOCIATE на SOCKS5, подтверждённый множеством внутренних тестов — UDP-приложения работают без скрытого отката на TCP.
• Скорость. До 500 Мбит/с на собственной управляемой сети — этого хватает для HD-стриминга, передачи больших объёмов данных и игр с низкой задержкой.
• Чистые статические IP. Ваш реальный IP заменяется на IP прокси, что помогает снизить риск обнаружения при работе с несколькими аккаунтами, смене региона или проверке задержки из разных локаций.

А если с каким-то UDP-приложением возникнут сложности, наша поддержка настраивала это много раз и поможет вам всё корректно подключить.

Discord для этого не нужен. Самый быстрый способ проверки на реальной задаче:

• Тест на утечку WebRTC (самый простой). Пропустите трафик через прокси инструментом, поддерживающим UDP (см. следующий вопрос), и откройте тест вроде browserleaks.com/webrtc — если он показывает IP прокси, а не ваш, значит UDP ретранслируется.
• DNS через прокси. Отправьте DNS-запрос через прокси: dig @8.8.8.8 example.com (DNS работает по UDP) — обычный ответ означает, что UDP проходит.
• Любое UDP-приложение. Запустите онлайн-игру или зайдите в голосовой чат через прокси — если соединение устанавливается и держится стабильно, UDP работает.

Если всё отваливается по таймауту или незаметно переключается на TCP — прокси на самом деле не пропускает UDP. С нашими прокси эти проверки проходят, а если что-то выглядит не так — наша поддержка проведёт их вместе с вами.

Именно здесь у большинства возникают сложности. WebRTC отправляет STUN-запросы по UDP (порт 3478), а большинство браузеров — включая Chrome — вообще не направляют UDP (а также QUIC/HTTP/3) через SOCKS5-прокси: проксируется только TCP. Поэтому если просто вписать прокси в настройки браузера, ваш UDP не пойдёт через нас, а реальный IP всё равно может утечь. Что действительно работает:

• Направить весь системный трафик через прокси инструментом, умеющим UDP. Proxifier (с графическим интерфейсом для Windows/macOS) или tun2socks-клиенты — sing-box, Clash/Clash Verge, hev-socks5-tunnel — пропускают весь трафик, включая UDP, через наш SOCKS5-прокси. Это самый надёжный вариант.
• Флаг Chrome/Chromium. Запустите браузер с ключом --force-webrtc-ip-handling-policy=disable_non_proxied_udp, чтобы UDP в WebRTC шёл только через прокси.
• Нужно просто убрать утечку? Используйте расширение, блокирующее WebRTC, например WebRTC Control или WebRTC Leak Prevent, либо антидетект-браузер, где WebRTC можно отключить или проксировать для каждого профиля — у нас есть готовые инструкции для Dolphin{anty}, AdsPower, GoLogin и других.

Нужна пошаговая инструкция? Загляните в наши инструкции по настройке для браузеров, операционных систем и более 14 антидетект-браузеров — или просто напишите в поддержку, какие у вас ОС, браузер или антидетект, и мы подскажем точную настройку.

По задержке и накладным расходам — да: нет рукопожатия, подтверждений и повторных пересылок. Но UDP не гарантирует доставку, поэтому он «быстрее» только там, где допустимы редкие потери пакетов (игры, голос, стриминг). Для передач, которые должны прийти целыми и по порядку, правильный инструмент — TCP, поэтому наши тарифы поддерживают и HTTP/SOCKS5 поверх TCP, а UDP вы добавляете сверху, когда это нужно вашей задаче.

QUIC работает поверх UDP. Чистый UDP отправляет датаграммы без рукопожатия, без гарантий доставки и без шифрования — минимальная задержка, но за надёжность и безопасность отвечает само приложение. QUIC (разработан Google, позже стандартизирован IETF как RFC 9000) надстраивается над UDP и добавляет привычные для TCP возможности, сохраняя низкую задержку: встроенное шифрование TLS 1.3 с первого пакета, надёжную доставку по порядку с быстрым восстановлением при потерях, мультиплексирование потоков без head-of-line blocking и быстрое (0-RTT / 1-RTT) установление соединения. На нём работает HTTP/3. Поскольку QUIC использует UDP, тот же механизм UDP ASSOCIATE, на котором работают наши прокси, может переносить и трафик QUIC / HTTP/3 — при условии, что ваш клиент действительно отправляет UDP через прокси.