3Proxy что это и как сделать?

3Proxy — это лёгкий высокопроизводительный прокси-сервер, который стартует за секунды, потребляет минимум ресурсов и отлично подходит для мобильных прокси, парсинга по регламенту, верификации рекламы и работы с распределёнными аккаунтами. Если вам нужно управлять сессиями, изолировать IP-адреса, настраивать ротацию и при этом не тянуть сложные монолиты — 3Proxy закрывает эту задачу без лишнего шума.

Теперь к сути. Бизнес сталкивается не с «дефицитом IP», а с дефицитом управляемости: нестабильные сессии, скачущие задержки, антифрод-алгоритмы, чувствительные к частоте запросов и «подозрительной» сетевой телеметрии; плюс требования комплаенса и логирования. Мобильные прокси на базе 3Proxy дают предсказуемую инфраструктуру: вы контролируете порты, типы прокси (HTTP/HTTPS, SOCKS5), sticky-сессии, ротацию IP по расписанию или событиям, а также безопасность и аудит. В статье покажу пошагово, как развернуть 3Proxy, собрать архитектуру с мобильными модемами и не попасть в зону риска с точки зрения комплаенса. А ещё — дам цифры по окупаемости и реальные метрики.

Базовое развёртывание 3Proxy на Linux (Debian/Ubuntu) занимает 15–30 минут. Сначала определитесь с инфраструктурой: один сервер на 2–4 ядра и 4–8 ГБ RAM вытянет сотни одновременных соединений при грамотных таймаутах и keep-alive. Устанавливаем зависимости (build-essential, make, gcc), ставим 3Proxy из репозитория или собираем из исходников — сборка позволяет включить нужные модули и точно контролировать версии. Далее проектируем файл конфигурации. В 3Proxy всё строится на директивах: указываем пользователей (аутентификация логин/пароль или по IP-списку), задаём ACL (allow/deny по источнику/назначению), включаем нужные протоколы (proxy для HTTP/HTTPS без MITM и socks для SOCKS5), настраиваем timeouts, keepalive, pconn и лимиты на одновременные соединения. Быстрое ядро — это хорошо, но важно не «открыть шлюзы»: поставьте limit на количество коннектов с одного IP, зафиксируйте порты (пример: proxy -p3128 -a -n и socks -p1080 -a), привяжите исходящий интерфейс, если у сервера несколько адресов (например, internal/external или отдельные подсети для мобильных модемов). Для DNS укажите устойчивые резолверы (nserver 1.1.1.1, nserver 9.9.9.9) и активируйте кэш (nscache), чтобы снизить латентность и нагрузку. Логирование — через директивы log и rotate: заведите отдельную директорию, примените ротацию по размеру/дате и используйте syslog/journald, чтобы собирать события в ELK или Loki. Запуск — через daemon или unit для systemd с Restart=always и watchdog-секциями. На уровне ОС — firewall (nftables/iptables) для белых списков по входящим IP и ограничений по портам, плюс fail2ban на обнаружение брутфорса. Для тестов используйте curl и прокси-клиенты с явным указанием протокола; обязательно проверяйте HTTP 200/407 и корректность авторизации. Когда базовая схема стабильно работает, можно контейнеризировать: Docker удобен для тиражирования и версионирования, но следите за сетевой производительностью — используйте host-сеть или macvlan для предсказуемых метрик. Если планируете мобильные прокси, продумайте привязку портов 3Proxy к конкретным модемам: каждый модем — свой порт или пул портов с sticky-сессиями и «мягкой» ротацией. Для ротации IP в мобильном сегменте интегрируйте управляющий скрипт (AT-команды, MBIM/QMI), который по сигналу перезапускает соединение и вызывает graceful перезахват сессий на стороне 3Proxy. Нагрузочное тестирование сделайте заранее: инструментами вроде vegeta/ab/hey померите latency p50/p95/p99, throughput и поведение на длинных keep-alive. И да, думайте о техподдержке будущей вас: помечайте конфиги комментариями, заведите git-репозиторий, используйте шаблоны для портов и имён пользователей, чтобы не утонуть в операционке.

• Подготовка сервера: обновление ОС, установка зависимостей, настройка systemd unit и firewall с белыми списками.
• Конфиг 3Proxy: пользователи, ACL, протоколы (HTTP/HTTPS, SOCKS5), таймауты, логирование, лимиты на соединения.
• Тестирование и автоматизация: проверка curl, нагрузочное тестирование, ротация логов, контейнеризация/оркестрация.

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

Если у вас десятки портов и высокие требования к latency — берите «железо» рядом с модемами. Для распределённой команды и быстрого тиражирования — VPS и Docker (host-сеть или macvlan). Гибридный подход тоже рабочий: управляющий сервер в контейнерах, а узлы с модемами — на «голом» Linux с systemd. Главное — не усложнять раньше времени и держать в фокусе метрики SLA (uptime, p95 latency, ошибки аутентификации).

Мобильный прокси-узел — это связка из USB-модемов (LTE/4G/5G), SIM-карт, USB-хабов с питанием, контроллера (x86/ARM) и 3Proxy, который раздаёт порты наружу. Каждый модем получает адрес от оператора связи, а 3Proxy привязывает один или несколько портов к конкретному модему, обеспечивая sticky-сессии. Ротация IP делается управляемо: скрипт переводит модем в переинициализацию (AT-команды, MBIM/QMI), а 3Proxy по событию мягко завершает активные сессии и поднимает новые. Важна дисциплина: не «крутить» адрес каждую минуту, а придерживаться разумных интервалов и контекста — так вы снижаете триггеры антифрода и сохраняете стабильность рекламных интеграций, API и кабинетов. По метрикам: пинг до популярных сервисов в LTE обычно 40–120 мс, пропускная способность одного модема — до 20–80 Мбит/с в пике, но критичнее всего не throughput, а предсказуемая задержка и устойчивость сессий.

• Привязка портов: 1 модем = 1–5 портов с независимыми сессиями и ограничениями по коннектам.
• Sticky-сессии: «липкая» привязка IP к клиенту на 10–60 минут, чтобы не рвать куки и не сбивать поведенческие сигналы.
• Ротация по событиям: расписание, превышение ошибок, падение скорости, лимиты запросов — через управляющий сервис.

Для большинства задач маркетинга и аналитики работает шаблон: на каждый порт выдаётся уникальный логин, а на стороне 3Proxy сессия помечается по комбинации (логин + порт). Смена IP не обнуляет «личность» порта, пока не истечёт TTL сессии. Это позволяет клиентским приложениям спокойно жить в рамках одного контекста: куки, токены, fingerprint остаются, а ротация выглядит «естественной». Если нужна жёсткая изоляция — одна учётка = один порт = один модем.

Мобильные сети чувствительны к «дёрганиям». Оптимальная частота ротации — раз в 10–30 минут для длинных потоков, 3–10 минут для интенсивных коротких операций. Логика ротации должна учитывать ошибки соединений (рост HTTP 429/5xx, скачок p95 latency в 2+ раза), лимиты по трафику и расписание. Важно: делайте graceful-drain — перед перезапуском модема закрывайте новые коннекты и дожидайтесь завершения текущих в пределах таймаута. Так вы не теряете транзакции и не плодите «битые» сессии.

Масштабирование горизонтальное: добавляете узлы с модемами, а управляющий слой (оркестратор) распределяет нагрузку и следит за здоровьем. На одном контроллере с USB 3.0 и нормальным питанием стабильно работают 20–40 модемов; дальше лучше дробить на стойки. 3Proxy хорош тем, что порты — это просто процессы/дескрипторы: вы можете поднимать сотни портов и управлять ими шаблонами конфигов. Следите за файловыми дескрипторами (ulimit -n), очередями сетевого стека и диском под логи.

Безопасность мобильных прокси — это три слоя: доступ, поведение и аудит. На доступе — строгая аутентификация (логин/пароль + привязка к IP), белые списки источников, ограничения по скорости/количеству соединений, блок нежелательных портов (25/SMTP, 23/Telnet и т.д.). На поведении — корректные таймауты, лимиты запросов, предсказуемая ротация IP, отсутствие «шумного» трафика. На аудите — структурированные логи запросов: время, источник, порт, целевой домен, код ответа, байты, задержка; без хранения лишних персональных данных. С точки зрения комплаенса в России — держите в порядке договоры с операторами связи, регламенты использования, политику хранения логов и доступов; соблюдайте требования по защите информации и обработке персональных данных (минимизация, шифрование, контроль доступа). Интеграция с SIEM (например, через syslog) поможет отслеживать аномалии и формировать отчётность для бизнеса.

• Пример 1: Ограничение доступа по IP + сильные пароли + fail2ban против брутфорса.
• Пример 2: Ротация логов ежедневно, хранение агрегированных метрик 90 дней, алерты на всплески 5xx/timeout.
• Пример 3: ACL на блок потенциально рискованных направлений и лимит коннектов с одного пользователя.

Комбинируйте «auth strong» с «allow» по конкретным пользователям и подсетям, а на уровне хоста режьте всё лишнее firewall’ом. Раздельные аккаунты для каждого бизнес-процесса упрощают аудит: видно, кто, когда и куда стучался. Дополнительно ограничьте диапазоны портов и задайте «pconn» с адекватными таймаутами, чтобы не держать зомби-соединения.

Практика: сырые логи соединений храните 14–30 дней, агрегированные метрики (RPS, latency, коды ответов, трафик) — до 90 дней. Путь в прод: 3Proxy пишет в файл/rsyslog, дальше — парсинг в Logstash/Fluent Bit, хранение в Elasticsearch/ClickHouse и дешёвые дашборды в Grafana/Kibana. Не сохраняйте тела запросов, достаточно метаданных. Шифруйте архивы, разграничивайте доступы и протоколируйте выдачу логов.

Собирайте технические и бизнес-метрики: аптайм узлов, задержки p95/p99, ошибки 4xx/5xx, количество активных портов, расход трафика, а также KPI команд — скорость запуска новых портов, стоимость порта, доля успешных задач. Настройте алерты в два уровня: критика (падение узла, взрыв 5xx) и предупреждения (рост p95 на 50%, деградация throughput). Итог — предсказуемая инфраструктура, которую можно масштабировать без сюрпризов.

3Proxy сам по себе бесплатен, поэтому главный вопрос — стоимость аппаратуры и поддержки. Возьмём пример: 50 портов на 50 модемах. CAPEX: модемы 50 × 4 000 ₽ = 200 000 ₽, хабы и питание ~50 000 ₽, стойка и мелочи ~30 000 ₽ — итого около 280 000 ₽ единовременно. OPEX: сервер/узел 5 000 ₽/мес, SIM 50 × 300 ₽ = 15 000 ₽/мес, электричество и связь ~5 000 ₽/мес — всего около 25 000 ₽/мес. Сравнение с арендой: средняя цена мобильного порта на рынке 600–800 ₽ в неделю. Для 50 портов это 50 × 600 × 4 = 120 000 ₽/мес (минимум). Вы экономите около 95 000 ₽/мес, а стартовые вложения 280 000 ₽ окупаются за 3 месяца, дальше — чистая экономия. Плюс нематериальные выгоды: контроль ротации, SLA, прозрачные логи и гибкая масштабируемость без «чёрного ящика» посредника. В реальных кейсах наших клиентов окупаемость колеблется 2–4 месяца, если порты загружены хотя бы на 60–70%. Важное условие — дисциплина: фиксированные конфиги 3Proxy, мониторинг p95, аккуратная ротация и комплаенс. Тогда мобильные прокси перестают быть «серой зоной» и становятся понятным, управляемым активом.

Вопрос: Чем 3Proxy лучше альтернатив для мобильных прокси?
Ответ: Он легче, быстрее стартует, прозрачно конфигурируется и не перегружен лишними функциями. Для задач с сотнями портов критичны именно управляемость, таймауты, логирование — здесь 3Proxy даёт удобный баланс простоты и гибкости.

Вопрос: Сколько портов выдержит один сервер?
Ответ: На 2–4 ядрах и 4–8 ГБ RAM реалистично держать 100–200 портов при разумных таймаутах и pconn. Ключ — ulimit, быстрый диск под логи и аккуратный firewall. Далее масштабируйте горизонтально.

Вопрос: Как часто ротировать IP в мобильной сети?
Ответ: Безопасный диапазон — раз в 10–30 минут для длительных задач и 3–10 минут для коротких. Делайте ротацию по событиям (ошибки, рост p95), а не только по таймеру, и используйте graceful-drain.

Вопрос: Какие логи хранить и сколько?
Ответ: Метаданные: время, порт, пользователь, хост/URI без персональных данных, код ответа, задержка, байты. Сырые логи 14–30 дней, агрегированные метрики — до 90 дней, с контролем доступа и шифрованием архивов.

Вопрос: Можно ли использовать IPv6 для мобильных прокси?
Ответ: Да, если оператор связи и ваши целевые сервисы стабильно работают по IPv6. На практике чаще комбинируют IPv4 с dual-stack; тестируйте latency и совместимость заранее.