Материал системно сравнивает Proxy и VPN на уровне стеков: прокси работает на L4 и проксирует трафик отдельных приложений, тогда как VPN инкапсулирует весь трафик на L2/L3. Подробно разобраны два основных подхода к проксированию HTTP-трафика: CONNECT (сквозное шифрование между клиентом и ресурсом, RFC 7231) и менее распространённый RELAY (замена отправителя/получателя, без сквозного шифрования и без UDP). SOCKS5 описан как бинарный протокол L5 без собственного шифрования, с поддержкой аутентификации и команды UDP ASSOCIATE для переключения на UDP (RFC 1928/1929).

Показаны практические способы «поднять» прокси: SSH с динамическим порт-форвардингом (ssh -D) для локального SOCKS5; chisel, переводящий HTTP-соединение в WebSockets для производительности; rpc2socks по SMB/445 при наличии админ-прав. Для проксирования трафика выделены три модели: клиентская (например, FoxyProxy), проксификация библиотечных вызовов (proxychains, graftcp) и прозрачный прокси (redsocks + iptables).

• Ротация IP: mubeng распределяет запросы по списку прокси для избежания блокировок при массовых обращениях.
• «Проблемные зоны»: чистый UDP (обход через socat TCP↔UDP), проксирование DNS облегчает DNS-over-TCP (RFC 7766); сырые сокеты (AF_PACKET) обходят стек TCP/IP, что ломает классические схемы прокси — нужен промежуточный узел/маршрутизатор.
• Практические артефакты: порты 22/80/443/135/445; методология прозрачного перенаправления через iptables; учет ограничений LD_PRELOAD для статически скомпилированных бинарей.

Вывод: в прикладных задачах предпочтителен SOCKS5 из-за универсальности L5 и поддержки UDP; выбор режима (клиентский/прозрачный) определяется целями, сетевыми ограничениями и требованиями к наблюдаемости.