Как установить HTTPS-прокси на Linux через 3proxy: пошаговая инструкция и безопасная схема

Поэтому нормальная схема выглядит так. Сначала поднимаем обычный 3proxy с паролем, логами и закрытым доступом. Потом, если прокси нужен через публичный интернет, добавляем TLS-обертку для самого прокси. Ниже именно такая инструкция. 

Используйте прокси только там, где есть законное основание и право доступа. Не поднимайте открытый прокси для обхода чужих ограничений, не давайте доступ посторонним и не нарушайте правила провайдера, работодателя или сервиса.

Что именно будем строить

Что понадобится для установки 3proxy на Linux

• Сервер с Linux и публичным IP
• Права sudo или root
• Открытый TCP-порт, обычно 3128 для базового прокси
• Домен и сертификат, если нужен именно https://-прокси

По состоянию на март 2026 года у проекта есть последний стабильный релиз 0.9.5 с исправлением безопасности. Готовые .deb и .rpm уже существуют, но сборка из исходников остается самым предсказуемым вариантом. Пути, структура каталогов и поведение после установки там лучше совпадают с официальной документацией.

Шаг 1. Устанавливаем 3proxy из исходников

На Debian и Ubuntu достаточно набора для сборки и git.

sudo apt update
 sudo apt install -y git build-essential
 
 git clone https://github.com/3proxy/3proxy
 cd 3proxy
 ln -s Makefile.Linux Makefile
 make
 sudo make install

После установки 3proxy создает двухступенчатую схему конфигурации. Первый файл работает до chroot и обычно не требует правок. Второй файл, уже внутри chroot, и есть основная рабочая конфигурация.

/etc/3proxy/3proxy.cfg                # служебный файл до chroot
 /etc/3proxy/conf/3proxy.cfg           # основной конфиг
 /var/log/3proxy                       # логи
 /usr/local/3proxy/conf/3proxy.cfg     # тот же основной конфиг через symlink

Подробности по синтаксису и порядку команд есть в официальной документации. Для практической настройки хватит рабочего шаблона ниже.

Шаг 2. Создаем безопасный базовый конфиг 3proxy

Ниже минимальная конфигурация для личного HTTP-прокси с поддержкой HTTPS-сайтов через CONNECT. Схема простая: DNS, кеш резолвинга, логирование, аутентификация, один пользователь, один порт.

sudo cp /etc/3proxy/conf/3proxy.cfg /etc/3proxy/conf/3proxy.cfg.bak
 
 sudo tee /etc/3proxy/conf/3proxy.cfg > /dev/null <<'EOF'
 daemon
 
 nserver 1.1.1.1
 nserver 8.8.8.8
 nscache 65536
 timeouts 1 5 30 60 180 1800 15 60
 
 log /logs/3proxy.log D
 rotate 30
 
 internal 0.0.0.0
 external YOUR_SERVER_PUBLIC_IP
 
 auth strong
 users proxyuser:CL:ChangeThisPasswordNow
 
 allow proxyuser
 proxy -a -p3128
 flush
 EOF

Что здесь важно.

internal 0.0.0.0 разрешает принимать подключения на всех IPv4-интерфейсах. На сервере с несколькими интерфейсами лучше подставить конкретный адрес.

external YOUR_SERVER_PUBLIC_IP задает исходящий адрес для соединений прокси. На типичном VPS с одним публичным адресом строка полезна. В контейнерах, NAT-схемах и нестандартной маршрутизации строка иногда мешает. Если после запуска соединение не выходит наружу, сначала проверьте маршруты, потом временно уберите external и протестируйте еще раз.

auth strong включает логин и пароль. Пароль в примере хранится открытым текстом, потому что так проще показать рабочую схему. Для продакшена лучше перейти на CR-хэш через утилиту mycrypt, но даже хэш в файле не решает главную проблему: при plain HTTP-прокси авторизация по сети все равно идет без TLS.

proxy -a -p3128 поднимает HTTP/HTTPS-прокси на порту 3128. Флаг -a скрывает клиентские заголовки вроде Forwarded и X-Forwarded-For.

Шаг 3. Ограничиваем доступ, чтобы не получить открытый прокси

Один пароль лучше, чем ничего. Но пароль без IP-фильтра на публичном сервере все равно слабая защита. Если домашний адрес статический, добавьте источник прямо в ACL.

auth strong
 users proxyuser:CL:ChangeThisPasswordNow
 
 allow proxyuser 203.0.113.25
 proxy -a -p3128
 flush

Если адрес плавающий, хотя бы закройте порт фаерволом и открывайте доступ только с нужных сетей или поверх WireGuard. Для UFW достаточно одного правила.

sudo ufw allow 3128/tcp
 sudo ufw status

Если нужен доступ только с одного IP, правило лучше сделать сразу адресным, а не общим.

sudo ufw allow from 203.0.113.25 to any port 3128 proto tcp

Шаг 4. Запускаем 3proxy через systemd

Официальная установка на Linux не делает красивого универсального unit-файла под все случаи. Проще создать свой, чтобы сервис переживал перезагрузку и нормально перезапускался после падения.

sudo tee /etc/systemd/system/3proxy.service > /dev/null <<'EOF'
 [Unit]
 Description=3proxy tiny proxy server
 After=network-online.target
 Wants=network-online.target
 
 [Service]
 Type=simple
 ExecStart=/usr/local/bin/3proxy /etc/3proxy/3proxy.cfg
 ExecReload=/bin/kill -USR1 $MAINPID
 Restart=on-failure
 RestartSec=2
 LimitNOFILE=65535
 
 [Install]
 WantedBy=multi-user.target
 EOF
 
 sudo systemctl daemon-reload
 sudo systemctl enable --now 3proxy
 sudo systemctl status 3proxy --no-pager

Если сервис не стартует, первым делом смотрите журнал.

sudo journalctl -u 3proxy -n 100 --no-pager

Шаг 5. Проверяем, что прокси действительно работает

Быстрый тест с сервера или с клиентской машины через curl показывает сразу три вещи: соединение дошло, авторизация прошла, внешний IP сменился на адрес сервера.

curl -x http://proxyuser:ChangeThisPasswordNow@SERVER_IP:3128 https://api.ipify.org
 echo

Для проверки обычного HTTPS-запроса по заголовкам подойдет и такой вариант.

curl -I -x http://proxyuser:ChangeThisPasswordNow@SERVER_IP:3128 https://example.org

Если в ответ приходит внешний адрес сервера, а сайт по -I открывается, базовая схема уже жива.

Что не нравится в такой схеме

Главный минус простой настройки в том, что клиент общается с прокси по обычному HTTP. Да, дальше 3proxy строит туннель до HTTPS-сайта, но логин, пароль и служебная часть сеанса до самого прокси при таком варианте не защищены TLS. Для домашней сети или VPN поверх прокси проблема меньше. Для кафе, аэропорта, гостиницы и чужого офиса проблема уже реальная.

Именно поэтому 3proxy как «прокси для HTTPS-сайтов» и 3proxy как «настоящий https://-прокси» не одно и то же. Многие статьи смешивают оба смысла в одну кучу, а потом читатель удивляется, почему браузер требует схему http://, а не https://.

Шаг 6. Если нужен именно HTTPS-прокси, добавляем TLS перед 3proxy

Самый практичный путь в 2026 году выглядит так: оставляем 3proxy на локальном plain-порту 3128 и ставим сверху TLS-обертку, например stunnel. Такой подход проще и стабильнее, чем сразу упираться в редкие сборки с SSLPlugin. Официальная документация 3proxy уже описывает TLS server и https://-proxy через SSLPlugin, но в реальной жизни в некоторых пакетных сборках плагина нет, а ручная сборка плагина у новичков часто превращается в отдельный квест.

Схема получается такой: клиент подключается по TLS к stunnel, stunnel передает расшифрованный HTTP-трафик в локальный 3proxy, а 3proxy уже делает CONNECT до нужного сайта.

Устанавливаем stunnel

sudo apt update
 sudo apt install -y stunnel4

Нужен домен, который смотрит на сервер, и обычный сертификат. Самоподписанный сертификат технически сработает, но клиенты будут ругаться, а часть приложений вообще откажется подключаться. Ниже пример с сертификатом Let’s Encrypt.

sudo tee /etc/stunnel/3proxy.conf > /dev/null <<'EOF'
 foreground = no
 pid = /var/run/stunnel4/3proxy.pid
 
 [https-proxy]
 accept = 8443
 connect = 127.0.0.1:3128
 cert = /etc/letsencrypt/live/proxy.example.com/fullchain.pem
 key = /etc/letsencrypt/live/proxy.example.com/privkey.pem
 EOF

На Debian и Ubuntu пакет stunnel4 нередко не стартует, пока в /etc/default/stunnel4 не включен флаг запуска. Если после старта сервис молчит, откройте файл и убедитесь, что там стоит ENABLED=1.

sudo sed -i 's/^ENABLED=.*/ENABLED=1/' /etc/default/stunnel4
 sudo systemctl enable --now stunnel4
 sudo systemctl status stunnel4 --no-pager

После этого клиент может использовать уже настоящий HTTPS-прокси, если приложение умеет работать со схемой https://.

curl -x https://proxyuser:ChangeThisPasswordNow@proxy.example.com:8443 https://api.ipify.org
 echo

У схемы есть ограничение. Не каждое приложение понимает HTTPS-прокси как отдельный тип подключения. Браузеры и curl обычно умеют. Старые клиенты, некоторые мессенджеры и часть мобильных приложений ждут только обычный HTTP proxy или SOCKS5.

Типичные ошибки при настройке 3proxy на Linux

Ошибка 407 Proxy Authentication Required

Чаще всего причина банальна: неверный логин или пароль, либо приложение не отправляет авторизацию на прокси. У curl логин и пароль лучше указывать прямо в URL прокси. У браузеров сначала проверьте, что выбран именно тип «HTTP proxy», а не SOCKS.

Соединение есть, но сайты не открываются

Сначала проверьте DNS в конфиге и журнал сервиса. Потом посмотрите, не ломает ли строка external исходящую маршрутизацию. На VPS с одним адресом строка полезна, в контейнере или за NAT строка иногда только мешает.

Прокси доступен всем подряд

Причина обычно одна из трех: забыли auth, оставили слишком широкое правило allow или открыли порт в фаерволе для всего интернета. Публичный open proxy живет недолго. Сканеры находят такие узлы очень быстро.

Логин и пароль утекут в чужой сети

Да, если клиент идет к 3proxy по plain HTTP. Для публичного интернета добавляйте TLS-обертку, WireGuard или хотя бы SSH-туннель. CONNECT защищает трафик между клиентом и сайтом, но не защищает саму авторизацию на прокси.

Практический вывод

Если нужен рабочий прокси на Linux без тяжелого комбайна, 3proxy остается очень удобным вариантом. Для базового сценария достаточно собрать проект, заменить основной конфиг, включить логин и пароль, закрыть доступ фаерволом и запускать сервис через systemd. Такая схема отлично подходит для личного VPS, лаборатории и контролируемой сети.

Если задача звучит как «мне нужен именно HTTPS-прокси, чтобы участок клиент - прокси тоже был зашифрован», одного стандартного 3proxy мало. Самый спокойный путь, который не ломается от нюансов сборки, это 3proxy на локальном порту плюс stunnel с нормальным сертификатом. Так получится не красивый маркетинговый ярлык, а реально безопасная и понятная схема.