Установка 3proxy на Ubuntu с парольной защитой

Небольшая практическая инструкция: как поднять на Ubuntu свой прокси-сервер 3proxy — сразу HTTP и SOCKS5, с доступом по логину и паролю. Проверено на версии 3proxy 0.9.6.

Отдельно разберу подводный камень, на котором залипают почти все, кто ставит 3proxy впервые: сервис показывает active (running), но порты не открывает. Причина неочевидная, а лечится одной командой — об этом ниже.

Что получим в итоге

• HTTP-прокси на порту 3128
• SOCKS5-прокси на порту 1080
• Доступ только по логину и паролю (auth strong)

Установка из .deb

Начиная с версии 0.9.6 у 3proxy есть готовые .deb-пакеты — компилировать из исходников больше не нужно.

cd /tmp
wget https://github.com/3proxy/3proxy/releases/download/0.9.6/3proxy-0.9.6.x86_64.deb
sudo apt install ./3proxy-0.9.6.x86_64.deb

Актуальную версию проверьте на странице релизов — номер в имени файла со временем меняется.

После установки в системе появляется:

• бинарник — /usr/bin/3proxy
• systemd-юнит — /usr/lib/systemd/system/3proxy.service
• конфиг — /etc/3proxy/3proxy.cfg
• утилита генерации хешей — 3proxy_crypt

Важная деталь, которая аукнется в пункте про лог: юнит по умолчанию запускает сервис от пользователя proxy:proxy.

Генерация хеша пароля

Пароль в открытом виде хранить не надо. Генерируем crypt-хеш с солью — он надёжнее, чем NT-хеш:

3proxy_crypt 'ВашПароль'

Команда выдаст строку вида $1$xxxxxxxx$yyyyyyyy... — копируем её целиком. В конфиге пользователь записывается в формате логин:CR:$1$..., где CR означает crypted-пароль.

Конфиг

Заменяем содержимое /etc/3proxy/3proxy.cfg:

# DNS для резолвинга (поставьте свои резолверы)
nserver 77.88.8.8
nserver 8.8.8.8
nscache 65536

timeouts 1 5 30 60 180 1800 15 60

# Лог
log /var/log/3proxy/3proxy.log D
logformat "L%d-%m-%Y %H:%M:%S %U %C:%c %R:%r %O %I %h %T"
rotate 30

# Пользователи: логин:CR:хеш
users proxyuser:CR:$1$xxxxxxxx$yyyyyyyy...

# Строгая аутентификация по паролю
auth strong

# Разрешить только этого пользователя
# (для безопасности лучше ограничить подсетью — см. раздел «Безопасность»)
allow proxyuser

# HTTP-прокси на 3128
proxy -p3128

# SOCKS5 на 1080
socks -p1080

Ключевые строки: auth strong требует логин и пароль, а allow без него означал бы запрет для всех.

Каталог лога — главный подводный камень

А вот и обещанная засада. Сервис работает от пользователя proxy, поэтому каталог лога должен принадлежать именно ему. Если этого не сделать, сервис будет в статусе active (running), но порты не откроет. Логика такая: строка log в конфиге не отрабатывает из-за нехватки прав, а следом за ней не выполняются и proxy с socks.

Самое коварное здесь — что systemctl status показывает зелёный running, и кажется, будто всё в порядке. А прокси при этом мёртвый.

Лечится одной парой команд:

sudo mkdir -p /var/log/3proxy
sudo chown -R proxy:proxy /var/log/3proxy

Если в юните указан другой User/Group — сверьтесь и назначьте владельца каталога соответствующему пользователю:

systemctl cat 3proxy | grep -Ei 'user|group'

Запуск и проверка

sudo systemctl enable --now 3proxy
sudo systemctl restart 3proxy

# порты должны появиться:
sudo ss -tlnp | grep -E '3128|1080'

Ожидаемый вывод — два LISTEN на 0.0.0.0:3128 и 0.0.0.0:1080.

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

sudo -u proxy /usr/bin/3proxy /etc/3proxy/3proxy.cfg

Важный момент: обычный запуск от root проблему прав не воспроизводит — именно поэтому её так трудно поймать. Диагностировать нужно от того пользователя, под которым реально работает сервис.

Открываем порты

Здесь два уровня, и про второй часто забывают.

Локальный firewall:

sudo ufw allow 3128/tcp
sudo ufw allow 1080/tcp

Firewall провайдера (security group). На публичных IP у облачных провайдеров (Selectel, Yandex Cloud, Timeweb и подобных) есть отдельный сетевой экран на стороне облака — правки ufw его не затрагивают. Порты 3128 и 1080/tcp нужно открыть ещё и в панели провайдера.

Если порты слушаются локально, но снаружи вы получаете Couldn't connect to server — причина почти всегда именно здесь.

Проверка подключения

# отдельные поля логина/пароля (надёжно, спецсимволы не мешают):
curl -x http://СЕРВЕР:3128 --proxy-user 'ЛОГИН:ПАРОЛЬ' https://ifconfig.me

# единым URL — спецсимволы в пароле нужно URL-энкодить (@ -> %40, : -> %3A и т.д.):
curl -x 'http://ЛОГИН:ПАР%40ОЛЬ@СЕРВЕР:3128' https://ifconfig.me

# SOCKS5:
curl --socks5 'ЛОГИН:ПАРОЛЬ@СЕРВЕР:1080' https://ifconfig.me

Признак успеха — в ответе виден внешний IP прокси-сервера, а не ваш реальный адрес.

Символ @ (а также : / # ?) в пароле ломает разбор URL. Либо используйте --proxy-user, либо URL-энкодьте пароль. Чтобы не возиться — проще сразу выбрать пароль без этих символов.

Безопасность

allow proxyuser пускает пользователя с любого адреса. И вот что важно понимать: открытый прокси на публичном IP сканеры находят за считанные часы и начинают гонять через него чужой трафик — даже при наличии пароля.

Если вы подключаетесь с фиксированных адресов, ограничьте источники по подсети:

# users proxyuser:CR:$1$...
auth strong
allow proxyuser 203.0.113.0/24

Дополнительно стоит:

• привязать слушатели к конкретному интерфейсу: proxy -p3128 -e<внешний_IP>
• ограничить порты назначения через ACL: allow ... * * 80,443
• держать порты закрытыми в security group для всех, кроме доверенных адресов

Шпаргалка по диагностике

Полезные команды

sudo systemctl status 3proxy
sudo journalctl -u 3proxy -n 30 --no-pager
sudo ss -tlnp | grep -E '3128|1080'
systemctl cat 3proxy
sudo -u proxy /usr/bin/3proxy /etc/3proxy/3proxy.cfg   # диагностика в foreground