Как установить HTTPS прокси-сервер на Linux с использованием 3proxy: пошаговое руководство

Как установить HTTPS прокси-сервер на Linux с использованием 3proxy: пошаговое руководство

Самый частый сюрприз в этой теме: «HTTPS прокси» обычно не означает, что ваш прокси расшифровывает HTTPS. В 99% случаев это обычный HTTP-прокси, который умеет туннелировать HTTPS-сайты через метод CONNECT. Браузер договаривается с прокси, строит туннель до домена:443, а дальше шифрование идет напрямую между вами и сайтом.

3proxy как раз про это: он легкий, быстрый и умеет HTTPS (CONNECT) прокси. При этом он не кеширует страницы как Squid и не пытается играть в «умный» DPI, зато идеально подходит для личного прокси на VPS или для контролируемого доступа из офиса домой.

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

Еще одна особенность 3proxy, о которой легко споткнуться: после установки он использует chroot и два конфига. Один выполняется до chroot и обычно трогать его не надо, второй основной. Это описано в официальном README, и это реально экономит нервы.

1) Установка 3proxy на Linux: сборка из исходников без боли

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

Если вы на Debian/Ubuntu и при сборке видите «make: command not found», это не ошибка 3proxy. Это просто не установлен набор для сборки. Ставится одним пакетом build-essential.

Сборка занимает пару минут и выглядит максимально прямолинейно: клонируем репозиторий, выбираем Makefile для Linux, собираем и делаем install. Эти команды один в один приведены в README проекта.

Шаги ниже рассчитаны на Debian/Ubuntu. На CentOS/Alma/Rocky меняется только установка зависимостей (gcc, make, git), логика та же.

  1. Поставьте зависимости для сборки:

    sudo apt update
     sudo apt install -y git build-essential
  2. Скачайте и соберите 3proxy:

    git clone https://github.com/3proxy/3proxy.git
     cd 3proxy
     ln -s Makefile.Linux Makefile
     make
     sudo make install
  3. Проверьте, что бинарник на месте (пути могут отличаться, поэтому лучше проверять командой):

    command -v 3proxy || true
     ls -la /usr/local/3proxy || true
     ls -la /etc/3proxy || true
  4. Запомните ключевую деталь про конфиги (из README): основной конфиг обычно лежит по пути /etc/3proxy/conf/3proxy.cfg и является ссылкой на файл внутри chroot, а файл /etc/3proxy/3proxy.cfg выполняется до chroot и обычно не редактируется.

Источник по структуре конфигов, командам сборки и скрипту добавления пользователей: README проекта 3proxy на GitHub.

2) Базовая настройка: HTTP CONNECT прокси для HTTPS и пользователи

Чтобы прокси «понимал HTTPS», вам не нужно отдельное «https-приложение». Нужен сервис proxy (HTTP proxy), который поддерживает CONNECT. Это тот самый режим, при котором клиент строит туннель на порт 443 и гонит шифрованный трафик сквозь прокси как через трубу.

Следующая важная часть - аутентификация. В 3proxy есть режим auth strong, который требует логин и пароль. Если его не включить и одновременно слушать внешний интерфейс, вы почти гарантированно получите публичный прокси.

Третья часть - правила доступа (ACL). В 3proxy они работают как у сетевого роутера: можно ограничивать по IP источника, по пользователю, по портам назначения и даже по типу запроса. Для практики удобно начать с простого: разрешать только вашему пользователю и только нужные порты (80/443).

Наконец, не забудьте про DNS внутри chroot: если 3proxy запущен в «песочнице», ему нужен nserver, иначе резолв хостов может не работать. Это не баг, это ожидаемая настройка.

  • Добавьте пользователя штатным скриптом (он упоминается в README как рекомендуемый способ):

    sudo /etc/3proxy/conf/add3proxyuser.sh alex StrongPassHere
  • Откройте основной конфиг и приведите его к понятному минимальному виду:

    sudo nano /etc/3proxy/conf/3proxy.cfg

Пример минимального конфига, который поднимает HTTP/HTTPS CONNECT прокси на 3128, требует пароль и разрешает только 80/443 (плюс типичные альтернативы):

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-%y%m%d.log D
 rotate 30
 
 auth strong
 
 # Разрешаем только вашему пользователю, добавленному через add3proxyuser.sh
 allow alex
 
 # Разрешаем web-порты (HTTP/HTTPS)
 allow alex * * 80,8080 HTTP
 allow alex * * 443,8443 HTTPS
 
 proxy -p3128
 
 flush

Подсказка: в 3proxy порядок команд важен. Конфиг воспринимается как скрипт, который выполняется построчно, это описано в man-странице 3proxy.cfg.

3) Автозапуск через systemd и firewall: чтобы работало и не светилось

Если вы запускаете 3proxy руками в терминале, вы очень быстро забудете, что меняли в конфиге, какой порт открывали и почему после ребута все умерло. Поэтому нормальная схема для Linux - systemd unit + явное открытие порта в firewall.

Хорошая новость: после make install у 3proxy уже есть ожидаемая структура каталогов, а логи обычно живут в /var/log/3proxy как ссылка на директорию внутри chroot. Поэтому systemd сводится к правильному ExecStart и аккуратному рестарту.

Еще один нюанс: бинарник 3proxy может оказаться в разных местах в зависимости от сборки. Самый честный способ - подставить путь, который вернул command -v 3proxy, либо использовать /usr/local/3proxy/bin/3proxy, если он есть.

Firewall обязателен, даже если у вас пароль. Пароль защищает от случайных гостей, а firewall защищает от идеи «а давайте посканим весь интернет и попробуем слабые креды». В идеале разрешайте доступ только со своих IP.

Пример systemd unit:

sudo nano /etc/systemd/system/3proxy.service
[Unit]
 Description=3proxy proxy server
 After=network-online.target
 Wants=network-online.target
 
 [Service]
 Type=simple
 ExecStart=/usr/local/3proxy/bin/3proxy /etc/3proxy/conf/3proxy.cfg
 Restart=on-failure
 RestartSec=2
 
 [Install]
 WantedBy=multi-user.target

Активируем и запускаем:

sudo systemctl daemon-reload
 sudo systemctl enable --now 3proxy
 sudo systemctl status 3proxy --no-pager

Открываем порт (пример для UFW):

sudo ufw allow 3128/tcp
 sudo ufw status

Если хотите разрешить доступ только с одного IP (лучший вариант для личного прокси):

sudo ufw delete allow 3128/tcp || true
 sudo ufw allow from 203.0.113.10 to any port 3128 proto tcp

4) Проверка, типичные проблемы и опционально: «настоящий» HTTPS proxy до прокси

Проверять прокси лучше не браузером, а утилитой, которая честно покажет, что происходит. Для HTTP/HTTPS CONNECT самый удобный тестер - curl. Он умеет и обычный прокси, и прокси с авторизацией, и явно показывает ошибки подключения.

Если CONNECT не работает, чаще всего виноваты две вещи: не открыт порт в firewall или ACL в 3proxy режут исходящие порты. Вторая история особенно типична, если вы ограничили разрешения только 80/443, а приложение ходит на 8443 или 8080.

Еще одна классика: забыли nserver при работе в chroot, и 3proxy не резолвит домены. Тогда по IP все идет, по доменному имени нет. Это выглядит как «прокси живой, но сайты не открываются».

А теперь про термин «HTTPS proxy» во втором, более редком смысле: когда соединение клиент->прокси тоже шифруется (то есть вы используете прокси по схеме https://proxy:port). В 3proxy есть TLS (SSL) сервер, который может работать в этом режиме, но на практике проще и прозрачнее обернуть 3128 через stunnel и получить TLS-вход на 443.

Тест CONNECT прокси через curl:

curl -v -x http://alex:StrongPassHere@YOUR_SERVER_IP:3128 https://example.com/ -o /dev/null

Быстрый тест «какой IP видит интернет» (подставьте любой сервис проверки IP, который вы доверяете):

curl -x http://alex:StrongPassHere@YOUR_SERVER_IP:3128 https://ifconfig.me

Опционально: TLS-обертка через stunnel (получаем https:// прокси на 443, который внутри прокидывает на локальный 3128):

sudo apt install -y stunnel4 openssl
 sudo openssl req -x509 -newkey rsa:2048 -nodes -keyout /etc/stunnel/3proxy.key -out /etc/stunnel/3proxy.crt -days 365
sudo nano /etc/stunnel/3proxy.conf
[https-proxy]
 client = no
 accept = 443
 connect = 127.0.0.1:3128
 cert = /etc/stunnel/3proxy.crt
 key  = /etc/stunnel/3proxy.key

Запуск stunnel и открытие 443:

sudo systemctl enable --now stunnel4
 sudo ufw allow 443/tcp

Проверка TLS-прокси в curl (обратите внимание на https:// в параметре -x):

curl -v -x https://alex:StrongPassHere@YOUR_SERVER_IP:443 https://example.com/ -o /dev/null
Alt text
Обращаем внимание, что все материалы в этом блоге представляют личное мнение их авторов. Редакция SecurityLab.ru не несет ответственности за точность, полноту и достоверность опубликованных данных. Вся информация предоставлена «как есть» и может не соответствовать официальной позиции компании.

Патч для мозга

Устраняем критические пробелы в твоих знаниях быстрее, чем Microsoft выпускает обновления по вторникам.

Обнови прошивку!

Юрий Кочетов

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