UDP через SOCKS5: как это работает (игры, VoIP, QUIC)

Привычное представление о прокси — это TCP-ретранслятор: открыл соединение, прогнал байты, закрыл. Так работают HTTP, HTTPS и SSH. Но огромная доля трафика реального времени — онлайн-игры, голосовые и видеозвонки, а всё чаще и сам веб через QUIC — идёт поверх UDP, у которого нет соединений и который работает пакетами. SOCKS5 — один из немногих прокси-протоколов, способных его нести, через отдельную команду UDP ASSOCIATE. SOCKS4 и обычные HTTP-прокси так не умеют вовсе.

Если разобраться в механизме, становится понятно и почему это мощная вещь, и почему она так часто не работает через случайный прокси.

Ретрансляция UDP в SOCKS5 состоит из управляющего канала и отдельного пути для данных. Сначала клиент открывает обычное TCP-соединение к прокси и посылает запрос UDP ASSOCIATE. Прокси отвечает IP-адресом и портом — это UDP-точка ретрансляции, которую он только что открыл для этой сессии. Дальше клиент шлёт свои UDP-датаграммы на эту точку, заворачивая каждую в небольшой заголовок SOCKS с конечным назначением, а прокси пересылает их дальше и возвращает ответы обратно.

Ключевое: управляющее TCP-соединение должно оставаться открытым всю сессию — как только оно закрывается, прокси разбирает UDP-ретрансляцию. То есть UDP-сессия в SOCKS5 — это на самом деле два связанных соединения: TCP, держащий сессию живой, и поток данных по UDP. Именно поэтому наивные клиенты, открывающие только UDP-сторону, падают. Это и есть механика, на которой через SOCKS5-прокси гоняют QUIC, VoIP (RTP), DNS-запросы и игровые протоколы.

Два честных предостережения. Первое: UDP должны поддерживать обе стороны — ваша клиентская библиотека должна реализовывать UDP ASSOCIATE (многие этого не делают: обычные стеки для HTTP-скрапинга его не касаются вовсе), а сервер прокси должен разрешать ретрансляцию UDP. Второе: UDP через прокси добавляет задержку, а NAT или файрволы между вами и точкой ретрансляции могут его резать, так что производительность в реальном времени никто не гарантирует. Для игр, чувствительных к задержке, обычно лучше подходит VPN с полным туннелем на WireGuard, чем UDP поверх SOCKS.

Прокси s4m — это SOCKS5 с аутентификацией на proxy.s4m.online:1080: для TCP-нагрузок они подходят напрямую, а там, где вашему клиенту и задаче действительно нужна ретрансляция UDP, именно SOCKS5 делает её возможной. Но если настоящая цель — пустить игру или звонок целиком, вместе с UDP, через один выход, берите VPN. Поведение протоколов проверяйте через API и инструменты.