Свой прокси на Ubuntu я впервые поднял года четыре назад. Нужен был шлюз для парсера маркетплейсов: сорок потоков, ротация, стабильность. Убил на это полдня. Сначала не собирался 3proxy, потом сервис молча падал после перезагрузки, а на третий день выяснилось, что мой порт 3128 уже кто-то методично перебирает паролями. Сейчас вся установка занимает минут двадцать, если не отвлекаться. Ниже - ровно то, что я делаю на каждой новой машине, без академической воды.
Свой прокси на VPS нужен не всем. Если задача - иногда заходить на пару сайтов из браузера, дешевле и быстрее взять готовый адрес. Свой сервер оправдан там, где нужен контроль: авторизация, логи, ACL, предсказуемая задержка и никаких чужих людей на канале.
Где свой прокси на VPS реально окупается
Первый сценарий - сбор данных. Когда с одного адреса улетает 40-80 запросов в минуту, площадка начинает отдавать капчу. Свой узел с SOCKS5 и пулом апстримов решает это аккуратнее, чем десяток случайных публичных адресов.
Второй - корпоративный шлюз. Офис на 15 человек, весь трафик через один узел: кто куда ходил, во сколько, сколько гигабайт съел. Squid тут король, потому что умеет ACL и кэш, а кэш в офисе с одинаковыми запросами к одним и тем же сервисам реально экономит канал.
Третий - работа из публичных сетей. Кафе, коворкинг, аэропорт: один раз настроенный шлюз на своём VPS даёт понятный маршрут трафика и шифрование до точки входа, вместо надежды на честность местного роутера.
Четвёртый - тесты и QA. Проверить, как интерфейс выглядит для пользователя из другой страны, поймать гео-зависимые баги в вёрстке и ценах. Тут достаточно одного стабильного адреса в нужной локации.
3proxy против Squid: разница в архитектуре, а не в хайпе
Squid - зрелый HTTP/HTTPS-прокси с кэшем, ACL и внятной документацией. Ставится из штатного репозитория одной командой, живёт годами, обновляется с системой. Минусы: прожорливость (на гигабайте RAM с включённым кэшем он спокойно займёт 200-300 МБ) и то, что SOCKS5 он не отдаёт - только HTTP-туннель через CONNECT.
3proxy легче на порядок: процесс на десяток потоков ест 10-15 МБ и отдаёт сразу и HTTP, и SOCKS5, и умеет цепочки из нескольких прокси. Плата за это - отсутствие в репозиториях Ubuntu и сборка из исходников руками. Плюс конфиг у него свой, не squid-подобный, и это сбивает с толку первых полчаса.
Моя логика выбора простая. Нужен кэш и тонкие ACL для офиса - Squid. Нужен SOCKS5 для парсера или приложений - 3proxy. Нужно и то и другое - ставим оба, только разводим порты, иначе получите конфликт на 3128 и полчаса недоумения.
Что нужно от сервера перед установкой
Ubuntu 22.04 или 24.04 LTS, доступ по SSH с ключом. Один vCPU и 1 ГБ RAM хватает на десятки одновременных соединений и пару сотен тысяч запросов в сутки. Если планируете 50+ потоков парсинга, берите 2 ГБ: дело не в самом прокси, а в том, что рядом обычно крутится скрипт, база и парсер.
Отдельно про безопасность на берегу. Прокси, открытый в интернет без авторизации, находят сканеры за 20-40 минут после появления нового IP. Дальше ваш сервер становится бесплатным выходом для чужого трафика, а провайдер присылает письмо про абузы. Авторизация - не опция, а обязательный минимум.
Сборка 3proxy из исходников
Ставим инструментарий. build-essential тянет gcc и make, libssl-dev нужен для работы с TLS:
sudo apt-get update
sudo apt-get install -y build-essential wget tar libssl-dev
Дальше качаем архив версии 0.9.3 с сайта проекта в /usr/local/src, распаковываем и собираем. Ссылку на архив берём с официальной страницы, я её тут не привожу, чтобы вы не тянули случайный файл из первого поискового результата:
cd /usr/local/src && wget <архив 3proxy-0.9.3.tar.gz> && tar -xzf 3proxy-0.9.3.tar.gz && cd 3proxy-0.9.3
make -f Makefile.Linux
На одном ядре сборка идёт секунд сорок. Бинарник появляется в bin/3proxy, копируем его в систему:
sudo cp bin/3proxy /usr/bin/
Проверка простая: 3proxy -v должен вывести версию. Если ругается на отсутствующие библиотеки - значит libssl-dev поставили после сборки. Пересоберите с нуля, make clean перед этим, иначе получите тот же бинарник.
Отдельный пользователь для сервиса
Прокси от root - подарок для любого, кто найдёт дыру. Делаем системного пользователя без домашней папки и без возможности логина:
sudo adduser --system --no-create-home --disabled-login --group proxy3
Смотрим его uid и gid, они понадобятся в конфиге:
id proxy3
В ответе будет что-то вроде uid=109(proxy3) gid=115(proxy3). Цифры у вас свои, запишите их. Именно они идут в строки setuid и setgid, и именно на них чаще всего забивают, а потом удивляются, почему процесс работает от root.
Конфигурация 3proxy: разбираем по строкам
Создаём файл настроек:
sudo nano /etc/3proxy/3proxy.cfg
Первое - привилегии. Сервис стартует от root, чтобы занять порт, и сразу сбрасывает права на proxy3:
setgid 115
setuid 109
Дальше DNS. Без явно указанного резолвера 3proxy будет использовать системный, и в контейнерах это регулярно заканчивается таймаутами:
nserver 8.8.8.8
nserver 1.1.1.1
nscache 65536
Кэш на 65536 записей - с большим запасом, память почти не ест, зато повторные запросы к одним и тем же доменам не дёргают резолвер.
Таймауты и логи. Формат строки лога задаём сами, иначе разбирать потом больно:
timeouts 1 5 30 60 180 1800 15 60
log /var/log/3proxy/3proxy.log D
rotate 30
logformat "L%t %U %C:%c %R:%r %i %o %T"
Авторизация и пользователи. Режим strong требует логин и пароль, CL означает пароль в открытом виде в конфиге (файл будет доступен только владельцу, это нормально для одиночного сервера):
auth strong
users parser:CL:сложный_пароль_на_20_символов
allow parser
И собственно сервисы. Флаг -a требует авторизацию для каждого подключения, -i задаёт интерфейс прослушивания:
proxy -p3128 -i0.0.0.0 -a
socks -p1080 -i0.0.0.0 -a
Если прокси нужен только для процессов на самом сервере, меняйте 0.0.0.0 на 127.0.0.1 и забудьте про файрвол. Это самый безопасный вариант, к которому я пришёл после пары инцидентов.
Права на файлы и папка логов
Здесь спотыкаются почти все. 3proxy не запустится, если конфиг читается кем-то кроме владельца, и молча выйдет с кодом ошибки в journalctl:
sudo chown proxy3:proxy3 -R /etc/3proxy
sudo chmod 444 /etc/3proxy/3proxy.cfg
sudo chown proxy3:proxy3 /usr/bin/3proxy
Логи пишутся от пользователя proxy3, значит папку тоже отдаём ему:
sudo mkdir -p /var/log/3proxy
sudo chown proxy3:proxy3 /var/log/3proxy
Если в конфиге вы используете отдельный файл паролей .proxyauth, ему нужен chmod 400. Права 444 на конфиг и 400 на пароли - не паранойя, а требование самого демона.
Автозапуск через systemd
Без юнита прокси умрёт при первой перезагрузке, и вы об этом узнаете от парсера в три часа ночи. Создаём файл:
sudo nano /etc/systemd/system/3proxy.service
[Unit]
Description=3proxy proxy server
After=network.target
[Service]
Type=simple
User=proxy3
Group=proxy3
ExecStart=/usr/bin/3proxy /etc/3proxy/3proxy.cfg
ExecReload=/bin/kill -HUP $MAINPID
Restart=always
RestartSec=3
[Install]
WantedBy=multi-user.target
Активируем и проверяем:
sudo systemctl daemon-reload
sudo systemctl enable --now 3proxy
systemctl status 3proxy
Статус active - хорошо. Статус activating с перезапусками - читайте journalctl -u 3proxy -n 50, там будет причина: чаще всего права на конфиг или занятый порт.
Файрвол: закрываем всё лишнее
Открывать прокси всему интернету стоит только с авторизацией и желательно с ограничением по источнику. На ufw это выглядит так: разрешаем SSH, разрешаем порт только своему офисному адресу, включаем.
sudo ufw allow 22/tcp
sudo ufw allow from 203.0.113.10 to any port 3128 proto tcp
sudo ufw allow from 203.0.113.10 to any port 1080 proto tcp
sudo ufw enable
Если IP динамический, вместо allow from ставьте fail2ban на логи 3proxy: правило на 5 неудачных авторизаций и бан на час снимает 99% шума от сканеров.
Проверка, что прокси действительно живой
Локально, чтобы исключить файрвол:
curl -x socks5://parser:пароль@127.0.0.1:1080 -I https://example.com
Ждём HTTP/2 200 в ответе. Для HTTP-порта то же самое через -x http://parser:пароль@127.0.0.1:3128. Дальше проверяем снаружи, с другой машины, подставив публичный IP сервера. Если локально работает, а снаружи нет - это файрвол, и гадать не нужно.
Полезно посмотреть, какой адрес видит внешний сервис. Откройте через прокси любой сервис определения IP и убедитесь, что там адрес вашего VPS, а не провайдера. Заодно проверьте задержку: у меня на нормальном хосте в Европе выходит 15-25 мс до крупных площадок, 200+ мс означают проблемы с маршрутом или DNS.
Squid: когда нужен HTTP с кэшем и ACL
Ставится за минуту, в отличие от 3proxy:
sudo apt update && sudo apt install -y squid apache2-utils
Пароли делаем через htpasswd, файл читает сам Squid:
sudo htpasswd -b -c /etc/squid/passwd parser сложный_пароль
В /etc/squid/squid.conf добавляем порт, провайдер авторизации и правило доступа: http_port 3129, строка auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd, затем acl auth_users proxy_auth REQUIRED и http_access allow auth_users. Порт беру 3129, чтобы не драться с 3proxy на одной машине.
Проверка конфига и инициализация кэша обязательны, иначе Squid не стартует:
sudo squid -k parse
sudo squid -z
sudo systemctl restart squid && sudo systemctl enable squid
Кэш включайте осознанно: для парсинга он вреден, потому что вы получаете старые ответы вместо свежих. Для офиса с одинаковыми запросами к корпоративным порталам - наоборот, экономия канала до 30%. В обсуждениях на Reddit администраторы отдельно отмечают, что на виртуалках с малым объёмом диска кэш Squid лучше ограничить директивой cache_dir, иначе диск забивается за неделю.
Пять мест, где установка ломается чаще всего
- Права на конфиг. Демон не читает файл и выходит без внятной ошибки в консоли, смотрите journalctl.
- DNS. Системный резолвер в контейнере недоступен процессу, и все запросы падают по таймауту. Лечится строками nserver.
- Порядок запуска. Прокси стартует раньше сети и умирает. After=network.target и Restart=always закрывают вопрос.
- Открытый порт. Сканеры приходят в течение часа. Авторизация и allow from по IP обязательны.
- Рост логов. Без rotate файл на активном парсинге доходит до гигабайт за неделю и забивает диск VPS на 20 ГБ.
Один IP - это один IP: где заканчивается домашний прокси
Дальше начинается честная практика. Свой сервер даёт вам ровно один адрес. Для парсинга в 200 потоков, для проверки цен по 12 регионам, для работы с площадками, которые считают запросы с адреса, одного IP мало физически. Путей два.
Первый - строить пул самому: десяток VPS в разных локациях, свой балансировщик, ротация, мониторинг. Работает, но это уже инфраструктурный проект на месяц, и адреса всё равно останутся датацентровыми, что многие площадки видят сразу.
Второй - взять готовый пул. Я держу под рукой каталог прокси, где адреса фильтруются по стране, типу (IPv4, IPv6, резидентские, датацентровые) и протоколу - SOCKS5 или HTTP. Для разовых задач берётся пакет на день, для постоянного парсинга - подписка. Экономия времени очевидная: не нужно поднимать пять VPS и потом объяснять провайдеру, что это не ботнет.
Хороший гибрид - оставить свой 3proxy как единую точку входа и настроить в нём parent-прокси из пула. Тогда приложение ходит на локальный 127.0.0.1:1080, а ротацию и гео делает внешний сервис. Конфиг 3proxy это поддерживает строкой parent, и менять код парсера не придётся вообще. В каталоге прокси как раз удобно подобрать апстримы под нужные страны и не держать их список в голове.
Что сделать в первые сутки после запуска
Снимите снапшот VPS. Это две минуты, которые спасут вечер, если эксперименты с конфигом пойдут не туда. Дальше поставьте fail2ban, настройте logrotate на /var/log/3proxy и включите unattended-upgrades для security-пакетов.
Проверьте поведение под нагрузкой: запустите 20 параллельных curl через SOCKS5 и посмотрите на load average и потребление памяти. У меня 3proxy на 1 ГБ держит 50 соединений при 12% CPU, дальше упирается в канал, а не в софт.
И запишите конфиг в git или хотя бы в заметки. Через полгода вы не вспомните, почему стоит именно 65536 в nscache и откуда взялся второй порт. Я так однажды пересобирал сервер по памяти и потерял два часа на поиск причины, по которой авторизация не работала: оказалось, забыл флаг -a в строке socks.
Начните с одного тестового VPS и локального варианта с привязкой к 127.0.0.1. Убедитесь, что curl возвращает 200 и в логах появляются записи. Только после этого открывайте порт наружу, желательно сразу с ограничением по IP. Всё остальное - вопрос масштаба, и для масштаба есть готовый каталог прокси вместо трёх недель сборки своей инфраструктуры.