3proxy 1.0.1 и 0.9.9.1 LTS — исправлены сбои при перезагрузке и ошибки SOCKS5

10 октября 2026 года разработчики 3proxy выпустили версии 1.0.1 и 0.9.9.1 LTS. Обе устраняют аварийное завершение сервера при перезагрузке конфигурации под нагрузкой, исправляют работу SOCKS5 UDP с IPv6 и сетевыми интерфейсами, а также ошибки в обработке правил и запросов. Ветка 1.0 получила дополнительные функции, включая встроенный HTTP-сервер.

3proxy — исправлены сбои при перезагрузке и ошибки SOCKS5 — 3proxy — исправлены сбои при перезагрузке и ошибки SOCKS5

Перезагрузка конфигурации 3proxy могла обрывать активные соединения

На загруженном прокси-сервере сигнал SIGUSR1, используемый для перезагрузки конфигурации, иногда приводил к segmentation fault — аварийному завершению процесса из-за обращения к недопустимой области памяти. Вместе с процессом прерывались обслуживаемые им соединения.

Проблему описали в GitHub issue #1278 после серии сбоев при большом количестве активных подключений. Причиной оказалась гонка состояний: во время обновления конфигурации 3proxy освобождал объект службы, с которым ещё работала завершающаяся сессия. Когда сессия обращалась к уже освобождённой памяти, сервер мог падать.

По данным разработчиков, ошибка существовала начиная с версии 0.9.7. В 0.9.9 появился пятиисекундный период ожидания (LINGER), позволяющий завершить передачу оставшихся данных после закрытия одной из сторон соединения. Он увеличил вероятность столкновения с ошибкой, поскольку завершающиеся сессии дольше оставались активными.

Исправление вошло одновременно в 3proxy 1.0.1 и 0.9.9.1 LTS. Оно затрагивает конкретный сценарий: перезагрузку конфигурации при наличии большого числа обслуживаемых подключений. При этом разработчики не публиковали измерений производительности этих выпусков.

SOCKS5 UDP — устранены ошибки выбора интерфейса, IPv6 и правил доступа

В системах с несколькими сетевыми интерфейсами 3proxy мог направлять TCP-трафик через заданное подключение, а UDP-пакеты SOCKS5 — через маршрут по умолчанию. Это проявлялось, например, на сервере с двумя интернет-каналами: опция -De выбирала нужный интерфейс для TCP, но UDP ASSOCIATE игнорировал ограничение. Проблему зафиксировали в issue #1277.

В обоих релизах параметры -Di и -De теперь применяются к сокетам SOCKS5 UDP ASSOCIATE и BIND, а также к соединениям передачи данных FTP-прокси и обратным подключениям. Для конфигураций с несколькими внешними адресами это устраняет расхождение между ожидаемым и фактическим сетевым маршрутом, описанное автором ошибки.

Отдельная проблема затрагивала SOCKS5 UDP через IPv6. В процессе чтения входящей дейтаграммы информация об адресе отправителя могла обрезаться. В результате прокси отправлял ответ на неверный адрес. Исправление #1279 изменило обработку размера структуры адреса и было перенесено в обе ветки.

Изменились и проверки доступа ACL (Access Control List, список правил, определяющих разрешённые направления трафика). Раньше правило с именем хоста могло ошибочно совпасть с любым UDP-пакетом, адресованным напрямую по IP. Теперь при проверке такого запроса числовой адрес используется в качестве имени назначения, как это уже происходило с TCP-запросами. Это устраняет один из способов некорректного применения ограничений на UDP-трафик.

Обработка PCRE и TLS — исправлены переполнения буфера и ошибки сертификатов

Обе версии закрывают ошибку переполнения буфера в pcre_rewrite — механизме изменения запросов по регулярным выражениям. Если подстановка $N обращалась к группе, которая не совпала с исходным текстом, расчёт размера результата мог оказаться неверным. В официальном списке изменений ошибка прямо названа heap buffer overflow, то есть записью за пределами выделенной области памяти в куче.

Разработчики исправили и другую ситуацию, когда после расширения запроса через pcre_rewrite буфера не хватало для дополнительных HTTP-заголовков. Команда pcre_extend раньше добавляла правила, которые затем фактически не учитывались при обработке. Теперь эти правила применяются. В 3proxy 1.0.1 отдельно устранён случай, когда переписанный путь и параметры запроса появлялись только в журнале: при прямом подключении к целевому серверу отправлялся прежний запрос.

Ещё одно общее исправление касается сертификатов, которые прокси создаёт при перехвате TLS-соединений с помощью OpenSSL. В них отсутствовали идентификаторы ключа субъекта и удостоверяющего центра. Строгие проверки сертификатов, в том числе на macOS, в OpenSSL с x509_strict и в Python 3.13, могли отклонять такие соединения. Формирование сертификатов скорректировано.

Помимо этого, устранены ошибки обращения к нулевому указателю в FTP- и SMTP-прокси при некорректной последовательности команд, проблема запуска служб в сборках с wolfSSL на glibc и неполадка DNS-прокси dnspr в Windows. Опубликованный changelog подтверждает исправление переполнения буфера, но не содержит отдельного идентификатора CVE или сведений об эксплуатации этой ошибки.

3proxy 1.0.1 получил HTTP-сервер и новые возможности маршрутизации

Помимо исправлений, актуальная ветка 1.0.1 расширяет функции 3proxy. Появилась служба httpsrv со встроенным HTTP-сервером. Через правила http она может раздавать файлы, возвращать фиксированные ответы, перенаправлять запросы и передавать их на другие серверы через proxypass. Один порт при такой настройке способен обслуживать и веб-сайт, и прокси-запросы. Административные страницы также используют httpsrv.

Правила доступа научились распознавать регулярные выражения для имён хостов с префиксами pcre: и regex:. Для прозрачного проксирования предусмотрены команды transparent и notransparent: в Linux используются возможности netfilter, в BSD — соответствующие сетевые механизмы. Отдельный TransparentPlugin убран; совместимость конфигураций, которые загружают его, сохранена.

Появилась более гибкая настройка вышестоящих прокси (parent). Вес можно задавать дробью или процентом; нулевой вес означает резервный сервер, который используется после неудачных попыток с основными. Если вышестоящий сервер задан именем и используется nserver, разрешение имени теперь происходит для каждого соединения.

Для 1.0.1 опубликованы и пакеты OpenWrt, рассчитанные на OpenWrt 24.10. При этом некоторые прежние возможности — почтовые и FTP-прокси, а также обработка ftp:// в HTTP-прокси — требуют явного включения при сборке. Для владельцев таких конфигураций это существенное отличие стандартной сборки новой ветки.

Две ветки 3proxy — current и LTS получают общие исправления

Разделение 3proxy на ветки current и lts появилось с выпуском 1.0.0 в августе 2026 года. Первая построена на master и получает новые возможности; вторая основана на ветке 0.9 и предназначена для исправлений ошибок без расширения набора функций.

Характеристика	3proxy 1.0.1	3proxy 0.9.9.1 LTS
Дата выпуска	10 октября 2026 года	10 октября 2026 года
Ветка	`current` (`master`)	`lts` (`0.9`)
Исправление сбоя при `SIGUSR1`	Есть	Есть
Исправления SOCKS5 UDP, IPv6, ACL и PCRE	Есть	Есть
Встроенный HTTP-сервер `httpsrv`	Есть	В изменениях LTS не заявлен
Назначение выпуска	Исправления и развитие функций	Исправления в поддерживаемой ветке

Для обеих линий разработчики публикуют сборки под Windows, пакеты DEB и RPM, а также варианты для OpenWrt. В репозиториях APT и DNF используются каналы current и lts; аналогичное разделение есть у образов Docker. Пакеты и метаданные репозиториев подписываются, а для релизных файлов предусмотрены контрольные суммы и подписи OpenPGP.

Исправления затрагивают устойчивость 3proxy под нагрузкой и точность сетевых правил

Обе версии устраняют ошибку, способную завершить процесс 3proxy при перезагрузке конфигурации, и корректируют поведение UDP-соединений там, где используются IPv6, ограничения доступа и несколько сетевых интерфейсов. В 1.0.1 к этим изменениям добавлен встроенный веб-сервер и новые средства настройки прокси-маршрутов. Версия 0.9.9.1 сохраняет акцент на исправлениях поддерживаемой ветки 0.9.

Официальные материалы фиксируют причины нескольких сбоев и состав внесённых исправлений. Данных о том, насколько часто перечисленные ошибки проявлялись за пределами описанных конфигураций, авторы релиза не приводят.