Как установить и настроить прокси для парсинга на VPS

MAATRIX

Парсер, который стучится в сайт с одного адреса, живёт до первой блокировки: несколько сотен запросов — и в ответ капча или 429. Свой прокси для парсинга на VPS решает проблему по-инженерному: вы получаете чистый выделенный IP, полный контроль над лимитами и возможность нарастить пул адресов, когда данных станет больше. Разберём установку с нуля.

Зачем поднимать свой прокси, а не брать готовый

Публичные и дешёвые общие прокси — это лотерея. На одном адресе сидят десятки чужих ботов, IP давно в чёрных списках, а скорость плавает от секунды к минуте. Для стабильного парсинга это тупик: вы не управляете нагрузкой и не знаете, когда сосед спалит адрес.

Свой прокси на VPS даёт три вещи, которых нет у арендованных списков:

• Чистый IP. Адрес принадлежит только вам, его репутацию портите только вы. Никакой сосед не спалит его спамом за час до вашего запуска.
• Контроль лимитов. Вы сами задаёте задержки и параллелизм, подстраиваясь под целевой сайт, а не молитесь на чужие настройки.
• Предсказуемость. Сервер не исчезнет и не сменит адрес посреди задачи, а логи всегда под рукой.

Разница ощущается сразу, как только объём собираемых данных выходит за пределы разового эксперимента. Готовые списки прокси хорошо смотрятся в рекламе, но на длинной дистанции превращаются в постоянную борьбу с отвалами: половина адресов мертва, вторая половина отвечает через раз, а поддержка кормит обещаниями. Когда парсинг встроен в рабочий процесс — обновляет цены каждый час или собирает выдачу к отчёту, — такая нестабильность стоит дороже самого сервера.

Минус своего решения назову честно: один VPS — это один IP. Для агрессивного парсинга сотен тысяч страниц понадобится пул из нескольких серверов или дополнительные адреса, и это отдельная статья расходов. Но для большинства реальных задач — мониторинг цен, сбор карточек товаров, аналитика поисковой выдачи, отслеживание конкурентов — одного чистого адреса с грамотными задержками хватает надолго. Начинать всегда стоит с одного сервера и расширяться, только когда упрётесь в потолок.

Выбор локации и конфигурации сервера

Прокси не считает и не рендерит — он только пересылает трафик, поэтому железо нужно скромное: 1 ядро, 1 ГБ RAM, 10 ГБ диска. Упор делайте на сеть и локацию.

Локацию берите под цель парсинга, и это не формальность. Если собираете данные с зарубежных площадок, которые режут российские адреса, берите VPS в США или UK: их IP выглядят органично для западных сайтов и открывают контент без региональных заглушек и принудительных редиректов на локализованную версию. Парсите российские магазины и маркетплейсы — берите RU-локацию, чтобы отдавать местный адрес, не ловить гео-редиректы и получать ту же выдачу, что видит обычный покупатель из России. Ошибка с локацией часто выглядит как «сайт отдаёт не те данные», хотя дело всего лишь в стране исходящего IP.

По диску не экономьте до предела только в одном случае — если включаете кэширование в Squid: тогда заложите 20–40 ГБ под кэш, иначе он быстро упрётся в лимит и начнёт вытеснять свежие ответы. Для чистого проксирования без кэша хватает базового диска.

Оплатить сервер из России бывает сложнее, чем настроить его: половина зарубежных провайдеров просто не принимает российские карты. MAATRIX принимает карты российских банков, СБП, криптовалюту и токен MAAT, поэтому иностранная карта не нужна, а сервер в нужной локации поднимается за пару минут без танцев с платёжными системами.

Установка 3proxy: лёгкий и гибкий вариант

3proxy — компактный прокси-сервер, который умеет HTTP и SOCKS5 в одном демоне и ест минимум ресурсов. Для парсинга это рабочая лошадка. Соберём из исходников на Ubuntu 24.04:

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

Создайте конфиг /etc/3proxy/3proxy.cfg:

nserver 1.1.1.1
nserver 8.8.8.8
nscache 65536
timeouts 1 5 30 60 180 1800 15 60
users parser:CL:ваш_пароль
auth strong
allow parser
proxy -p3128 -a
socks -p1080 -a

Здесь proxy -p3128 поднимает HTTP-прокси на порту 3128, socks -p1080 — SOCKS5 на 1080, а auth strong требует логин и пароль при каждом подключении. Директива nscache включает кэш DNS-запросов — при парсинге тысяч страниц с одного домена это заметно снижает задержку. Блок timeouts задаёт тайминги соединений; значения по умолчанию подходят большинству задач, но если целевой сайт отвечает медленно, увеличьте предпоследнее число. Пароль в поле users можно хранить в открытом виде (CL) или в виде хэша — для продакшена лучше хэш, который генерируется утилитой mycrypt из комплекта 3proxy.

Запустите демон и добавьте в автозагрузку:

3proxy /etc/3proxy/3proxy.cfg &
systemctl enable 3proxy 2>/dev/null || echo "добавьте unit вручную"

Установка Squid: когда нужен кэш и ACL

Если парсите много однотипных страниц или хотите тонкие правила доступа, поставьте Squid — он кэширует ответы и снижает нагрузку на целевой сайт:

apt install -y squid apache2-utils
htpasswd -c /etc/squid/passwd parser

Минимальный /etc/squid/squid.conf для парсинга:

http_port 3128
auth_param basic program /usr/lib/squid/basic_ncsa_auth /etc/squid/passwd
acl auth_users proxy_auth REQUIRED
http_access allow auth_users
http_access deny all
forwarded_for delete
via off

Строки forwarded_for delete и via off убирают заголовки X-Forwarded-For и Via, которые выдают факт использования прокси, — для парсинга это важно, иначе целевой сайт сразу понимает, что перед ним посредник. Squid кэширует ответы в памяти и на диске, поэтому повторные обращения к тем же URL отдаются мгновенно и не нагружают целевой ресурс лишний раз — это заодно снижает риск блокировки за частоту. Перезапустите после правки конфига: systemctl restart squid, а корректность настроек проверьте командой squid -k parse, которая покажет ошибки до запуска.

Выбор между 3proxy и Squid простой: если нужен лёгкий SOCKS5 без кэша и с минимумом зависимостей — берите 3proxy; если парсите много повторяющихся страниц и хотите тонкие правила доступа по спискам ACL — Squid оправдан. Оба спокойно работают на минимальном VPS.

Ротация IP и обход лимитов

Один адрес рано или поздно упрётся в лимит запросов. Есть три честных пути наращивания:

1. Дополнительные IP на один VPS. Многие провайдеры выдают несколько адресов на сервер; вешаете их на интерфейс и раскидываете исходящие соединения через outgoing в 3proxy.
2. Пул из нескольких VPS. Поднимаете одинаковый конфиг на 3–5 серверах и балансируете запросы на стороне парсера.
3. Разумные задержки. Даже с одним IP time.sleep(1.5) между запросами и случайный User-Agent растягивают ресурс адреса в разы.

В 3proxy привязка исходящего адреса делается так:

proxy -p3128 -e203.0.113.10

Каждый порт можно повесить на свой внешний IP и чередовать их в парсере по кругу.

Безопасность прокси: не отдайте сервер чужим

Открытый прокси без авторизации найдут сканеры за часы и превратят в чужой шлюз для спама. Защита обязательна:

ufw allow 22/tcp
ufw allow from ВАШ_IP to any port 3128
ufw enable

Правило ufw allow from ВАШ_IP пускает на порт прокси только ваш адрес — это надёжнее любого пароля. Дополнительно держите auth strong в 3proxy или proxy_auth в Squid, меняйте пароли и не публикуйте IP:порт в открытых репозиториях. Логи (logformat в 3proxy) помогут увидеть, если кто-то стучится лишний раз.

Чтобы запустить парсинг без блокировок, нужен VPS с чистым выделенным IP в правильной локации. У MAATRIX такой сервер поднимается за пару минут, с оплатой картой РФ, СБП или криптой — и вы сразу работаете, а не воюете с платёжкой.

Частые вопросы