Маленький хостинг-провайдер хочет поднять много VPS с отдельными IPv4: что выгоднее — dedicated server + /24 или обычный VPS-реселлинг

Когда небольшой хостинг-провайдер начинает продавать VPS, первая идея обычно выглядит просто: взять мощный сервер, добавить много IPv4, поставить Proxmox или Virtualizor и продавать виртуальные серверы с отдельным IP каждому клиенту. На бумаге всё красиво. На практике основная проблема почти всегда не в CPU, RAM или диске, а в IPv4.

IPv4-адреса стали отдельной экономикой внутри хостинг-бизнеса. Маленький провайдер может купить или арендовать хороший dedicated server, поставить NVMe, поднять виртуализацию, автоматизировать выдачу VPS, но всё равно упереться в простой вопрос: сколько стоит один IPv4, кому его можно выдать, как обосновать использование и что делать с абузом.

Эта статья для тех, кто хочет запустить или расширить VPS-направление и выдавать клиентам отдельные публичные IPv4. Разберём, когда нужен dedicated server с /24, когда достаточно меньшего пула, как считать экономику IP, что учитывать при IP justification, чем отличаются Proxmox и Virtualizor, и почему дешёвые VPS с большим количеством IPv4 часто оказываются убыточными.

Почему VPS-бизнес упирается в IPv4 быстрее, чем в сервер

Мощный dedicated server можно загрузить не сразу. Например, сервер с хорошим CPU, 128–256 GB RAM и NVMe может держать десятки небольших VPS. Но если каждому VPS нужен отдельный публичный IPv4, лимитом становится не железо, а количество адресов.

Типичный пример: вы хотите продавать недорогие VPS по 1 IPv4 на клиента. Даже если сервер технически способен разместить 80–120 маленьких VPS, без достаточного IP-пула вы не сможете продать эти места. Если у вас только 16 или 32 IPv4, сервер может простаивать по CPU и RAM, но коммерчески уже будет ограничен.

Поэтому для маленького провайдера вопрос звучит не “какой сервер взять”, а “какой сервер и какой IP-пул вместе дадут нормальную маржу”. Dedicated server без адресов не решает задачу VPS-провайдера. Подсеть /24 без нормальной виртуализации, мониторинга и абуз-процесса тоже не решает.

Что такое /24 и сколько VPS реально можно разместить

Подсеть /24 — это 256 IPv4-адресов. Но считать её как “256 VPS” неправильно. Часть адресов может использоваться под сетевые нужды, gateway, инфраструктуру, тесты, резерв, мониторинг, DNS, служебные VM, антиабуз, панель управления или будущие миграции.

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

Нормальный подход — не продавать 100% пула сразу. Если у вас /24, оставьте запас. Иначе при первой миграции, замене IP, жалобе на репутацию, блокировке адреса у клиента или необходимости выдать дополнительный IP вы окажетесь без манёвра.

Dedicated server + /24: когда это правильная схема

Dedicated server с IPv4 /24 имеет смысл, если вы строите не один сайт и не один проект, а именно VPS-направление. Такая схема подходит, если вы хотите:

• продавать VPS с отдельным публичным IPv4 для каждого клиента;
• размещать много небольших VPS на одном физическом сервере;
• использовать Virtualizor, Proxmox или другую платформу виртуализации;
• подключить WHMCS для автоматической продажи VPS;
• контролировать плотность размещения клиентов;
• управлять IP-пулом централизованно;
• иметь понятную экономику по серверу, RAM, CPU, NVMe и IPv4;
• развивать услугу VPS как отдельный продукт, а не как разовую перепродажу.

Но есть важное условие: dedicated server + /24 должен окупаться не “когда-нибудь”, а по понятной модели. Если вы не считали себестоимость одного VPS с учётом цены IP, лицензии панели, биллинга, саппорта, абуза, налогов, платёжных комиссий и резервов, вы пока не готовы запускать VPS-линейку.

Когда /24 брать рано

Подсеть /24 не нужна, если у вас нет потока клиентов или понятного плана продаж. Маленький провайдер часто ошибается: сначала покупает большой IP-пул, а потом думает, кому его продать. Это слабая модель.

/24 может быть преждевременным решением, если:

• у вас пока нет стабильного спроса на VPS;
• вы не понимаете, сколько клиенты готовы платить за VPS с IPv4;
• у вас нет антиабуз-процесса;
• вы не проверяете клиентов перед выдачей большого количества IP;
• вы хотите продавать слишком дешёвые VPS и надеетесь заработать на объёме;
• вы не умеете работать с Proxmox, Virtualizor, маршрутизацией и сетевыми шаблонами;
• вы не заложили расходы на поддержку;
• вы не понимаете, что делать при жалобах на spam, malware, phishing, сканирование и copyright abuse.

В таком случае лучше начать с dedicated server и меньшего пула IPv4 или с VPS/VDS-ресурсов для теста продаж. Масштабироваться до /24 нужно тогда, когда уже понятно, что IP будут использоваться легально, стабильно и с нормальной маржой.

IP justification: зачем провайдер спрашивает, для чего нужны IPv4

IP justification — это обоснование использования IPv4-адресов. Провайдер, LIR или владелец подсети может запросить описание проекта, количество нужных IP, сценарий использования, темп роста и техническую схему.

Это не формальность и не “лишняя бюрократия”. IPv4 — ограниченный ресурс. Если клиент просит 64, 128 или 256 адресов, нормальный провайдер должен понимать, зачем они нужны, как будут использоваться и не создадут ли они высокий риск абуза.

Для маленького VPS-провайдера хорошее обоснование может выглядеть так:

• планируется запуск VPS-линейки на базе dedicated server;
• каждый VPS получает один публичный IPv4;
• виртуализация: Proxmox VE или Virtualizor KVM;
• биллинг: WHMCS или аналогичная система;
• основные клиенты: разработчики, малый бизнес, администраторы, тестовые окружения, легальные веб-проекты;
• запрещены spam, phishing, malware, botnet, bruteforce, нелегальный контент и массовые нарушения сети;
• есть процедура обработки abuse-жалоб;
• есть лимиты на выдачу дополнительных IP одному клиенту;
• есть план загрузки пула по месяцам.

Плохое обоснование выглядит так: “нужно много IP для клиентов”, “будем продавать всем”, “потом разберёмся”, “под VPN/proxy без деталей”. Такое описание повышает риск отказа или дополнительных вопросов.

Какие вопросы нужно задать себе до аренды /24

• Сколько VPS вы реально продадите за первый месяц?
• Какая минимальная цена VPS с IPv4 покрывает себестоимость?
• Сколько стоит один IPv4 в вашей модели?
• Будет ли отдельная плата за дополнительный IPv4?
• Будете ли вы разрешать VPN, proxy, mail, scraping, crawling, crypto, игровые серверы?
• Какой abuse policy будет у ваших клиентов?
• Через сколько жалоб клиент блокируется?
• Будет ли KYC или ручная проверка заказов?
• Кто будет отвечать на жалобы от дата-центра и сетевых операторов?
• Сколько IP вы оставите в резерве?
• Как будете менять IP клиенту, если адрес попал в blacklist?
• Как будете вести учёт, какой IP кому выдан?

Если на эти вопросы нет ответов, покупать /24 рано. Не потому что идея плохая, а потому что вы пока не управляете рисками.

Экономика VPS с отдельными IPv4

Главная ошибка маленьких провайдеров — считать только стоимость dedicated server. Например, сервер стоит условно одну сумму в месяц, значит можно разделить её на количество VPS и получить себестоимость. Это неверно.

В себестоимость VPS нужно закладывать:

• аренду dedicated server;
• аренду IPv4 или подсети;
• лицензию Virtualizor, если используется Virtualizor;
• WHMCS или другой биллинг;
• резервные IP;
• потери от неоплаченных счетов и chargeback;
• платёжные комиссии;
• время поддержки;
• обработку abuse;
• резерв на замену IP или миграцию клиента;
• мониторинг и backup-инфраструктуру.

Простая формула:

себестоимость VPS = (сервер + IP-пул + лицензии + биллинг + поддержка + резерв) / количество реально проданных VPS

Ключевое слово — реально проданных. Не нужно делить расходы на 200 VPS, если в первые месяцы вы продадите 20–40. На старте себестоимость одного VPS почти всегда выше, чем кажется.

Почему нельзя продавать IPv4 слишком дешево

Если IPv4 стоит для вас дорого, а вы продаёте VPS с отдельным IP слишком дёшево, вы фактически субсидируете клиента. Это особенно опасно, если клиент использует много трафика, часто обращается в поддержку или создаёт abuse-риск.

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

Здоровая модель для маленького провайдера — продавать VPS не как “самый дешёвый сервер с IP”, а как стабильный ресурс с понятными правилами, нормальной сетью, поддержкой и честной ценой за IPv4.

Proxmox или Virtualizor: что выбрать маленькому VPS-провайдеру

Proxmox VE хорош, если у вас сильная техническая команда и вы хотите гибко управлять виртуализацией, сетью, storage, кластером, backup и шаблонами. Он часто удобен для инженеров, лабораторий, внутренних платформ и провайдеров, которые готовы сами строить процессы вокруг него.

Virtualizor чаще выбирают, когда нужна более “хостинговая” логика: VPS-панель для клиентов, IP pools, OS templates, интеграция с WHMCS, управление VPS из биллинга, переустановка ОС, reboot, rescue и базовая автоматизация для продаж.

Для маленького провайдера выбор обычно такой:

• если нужна быстрая коммерческая VPS-линейка с WHMCS — чаще смотрят в сторону Virtualizor;
• если нужна гибкая инфраструктура и команда умеет администрировать виртуализацию — можно использовать Proxmox;
• если нет опыта в сетях, IP-пулах и маршрутизации — не начинайте с кастомной сложной схемы;
• если планируется много клиентов, нужна автоматизация, шаблоны, лимиты и клиентский self-service.

Слабая идея — поставить Proxmox только потому, что он знакомый, а потом вручную выдавать VPS, IP, доступы и переустановки. Для коммерческого VPS-хостинга ручные операции быстро становятся источником ошибок.

Сетевая схема: bridge, routed или NAT

Для VPS с отдельными публичными IPv4 обычно используются bridge или routed-схемы. NAT подходит для частных адресов, тестов или внутренних сервисов, но не для классического VPS-продукта, где клиент ожидает полноценный публичный IPv4 на своей виртуальной машине.

Bridge-схема часто проще для понимания: виртуальные машины подключаются к bridge-интерфейсу, который связан с физическим интерфейсом сервера. Но возможность такой схемы зависит от сети дата-центра, фильтрации MAC-адресов, gateway и правил апстрима.

Routed-схема используется, когда подсеть маршрутизируется на сервер, а сам сервер дальше маршрутизирует адреса до VPS. Такая схема часто чище для провайдерской инфраструктуры, но требует аккуратной настройки forwarding, маршрутов, firewall и шаблонов сети.

Перед заказом dedicated server и /24 нужно уточнить у поставщика:

• как именно будет выдана подсеть: routed или on-link;
• нужен ли отдельный gateway;
• разрешены ли дополнительные MAC-адреса;
• есть ли фильтрация по MAC/IP;
• можно ли использовать Proxmox bridge;
• можно ли использовать Virtualizor IP Pool;
• как работает rDNS;
• как обрабатывается abuse;
• можно ли анонсировать свою подсеть через BGP, если это BYOIP;
• есть ли ограничения по трафику и типам проектов.

Минимальная архитектура для запуска VPS-направления

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

• 1 dedicated server под виртуализацию;
• публичная IPv4-подсеть или пул адресов;
• Proxmox VE или Virtualizor KVM;
• шаблоны популярных ОС: Debian, Ubuntu, AlmaLinux;
• отдельная административная сеть или закрытый доступ к панели;
• firewall на уровне хоста;
• мониторинг CPU, RAM, disk I/O, network, load, SMART/NVMe health;
• учёт выданных IP;
• rDNS-процесс;
• правила использования сервиса;
• процедура abuse-уведомлений;
• резервный доступ через IPMI/KVM.

Если используется WHMCS, заранее проверьте связку биллинга и панели виртуализации. Клиент должен получить VPS, IP, доступы и возможность базового управления без ручной работы оператора. Иначе вы не провайдер, а человек, который вручную создаёт виртуалки по тикетам.

Как правильно выдавать дополнительные IPv4 клиентам

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

Нормальная практика:

• один IPv4 входит в базовый VPS;
• дополнительные IPv4 выдаются только по запросу;
• клиент должен объяснить назначение дополнительных IP;
• для большого количества IP нужна ручная проверка;
• неиспользуемые адреса можно отозвать по правилам сервиса;
• массовая выдача IP новым аккаунтам без истории — высокий риск;
• для спорных категорий проектов лучше требовать больше информации до выдачи.

Отдельно важно вести историю: какой IP, какому клиенту, когда выдан, под какой сервис, когда были жалобы и какие действия предпринимались. Без этого abuse-разбор превращается в хаос.

Abuse: главный риск маленького VPS-провайдера

Маленький провайдер часто недооценивает abuse. Кажется, что главное — продать VPS. На деле важно продать VPS такому клиенту, который не уничтожит репутацию вашей подсети.

Типовые проблемы:

• spam;
• phishing;
• malware;
• bruteforce;
• сканирование сетей;
• copyright complaints;
• боты;
• открытые proxy;
• взломанные VPS клиентов;
• жалобы на вредоносный трафик.

Если у вас нет процесса обработки abuse, /24 станет не активом, а проблемой. Нужны правила: как быстро вы уведомляете клиента, сколько времени даёте на исправление, когда ограничиваете сеть, когда блокируете VPS, когда расторгаете услугу.

Что написать в правилах для клиентов VPS

Правила должны быть понятными до оплаты. Не нужно прятать важные ограничения в длинный юридический текст, который никто не читает. Для VPS с IPv4 особенно важно явно запретить:

• spam и массовую рассылку без согласия получателей;
• phishing и поддельные страницы;
• malware, botnet, loaders, stealers и вредоносный код;
• bruteforce и сетевое сканирование без разрешения;
• DDoS-атаки и участие в атакующей инфраструктуре;
• размещение нелегального контента;
• нарушение прав третьих лиц;
• использование сервиса так, чтобы это вредило IP-репутации и сети.

Также нужно указать, что дополнительные IPv4 выдаются при наличии свободного пула и после проверки назначения. Это защищает вас от клиентов, которые покупают дешёвый VPS и сразу требуют десятки адресов без понятной причины.

Как считать цену дополнительного IPv4

Цена дополнительного IPv4 должна покрывать не только аренду адреса, но и риск. Если вы сдаёте IP слишком дёшево, вы берёте на себя расходы по репутации, абузу и поддержке, но не получаете нормальной маржи.

При расчёте цены учитывайте:

• сколько стоит аренда IP-пула;
• какая часть пула остаётся в резерве;
• сколько адресов реально продаётся;
• сколько времени уходит на поддержку;
• какой риск abuse у вашей аудитории;
• какая комиссия платёжной системы;
• какая минимальная прибыль нужна с одного IP;
• сколько стоит замена или потеря проблемного клиента.

Если клиенту нужно много IPv4, лучше переводить разговор из “добавьте ещё IP к VPS” в формат отдельного коммерческого предложения: dedicated server + подсеть, понятное назначение, правила использования, проверка проекта и отдельные условия по abuse.

Когда клиенту лучше предложить dedicated server + подсеть, а не много VPS

Если клиент просит десятки IPv4, много VPS и стабильную сеть, не всегда правильно продавать ему пачку мелких виртуальных серверов. Часто лучше предложить dedicated server с выделенной подсетью.

Dedicated server + /24 подходит клиенту, если:

• ему нужны десятки или сотни IPv4;
• он сам управляет виртуализацией;
• ему важна предсказуемая производительность;
• нужны отдельные VM под разные сервисы;
• требуется своя маршрутизация, firewall или NAT-схема;
• проект долгосрочный и готов платить за отдельную инфраструктуру;
• нужно меньше ограничений по плотности размещения, чем на обычном VPS-хостинге.

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

Proxmox: что проверить перед запуском

Если вы используете Proxmox, заранее проверьте сеть на тестовых VM. Не надо загружать подсеть клиентами, пока вы не убедились, что маршруты, gateway, firewall и rDNS работают правильно.

Минимальная проверка:

ip a
ip r
ping -c 4 8.8.8.8
ping -c 4 gateway_ip
traceroute 8.8.8.8

На тестовой VM проверьте:

ip a
ip r
ping -c 4 gateway_ip
ping -c 4 1.1.1.1
curl -4 ifconfig.me

Если VM пингует gateway, но не выходит в интернет, смотрите маршруты и forwarding. Если внешний мир не пингует VM, проверяйте схему выдачи подсети, firewall, MAC-фильтрацию и правила дата-центра.

Virtualizor: что проверить перед продажами

Virtualizor удобен для VPS-хостинга, но IP Pool нужно настроить аккуратно. Нельзя просто добавить диапазон адресов и считать, что всё готово.

Проверьте:

• правильный тип виртуализации: KVM, если нужны полноценные VPS;
• корректный IP Pool;
• gateway и netmask;
• nameserver внутри шаблона;
• bridge или routed-схему в зависимости от сети;
• шаблоны ОС;
• автоматическую выдачу IP;
• интеграцию с WHMCS;
• переустановку ОС из клиентской панели;
• reboot, shutdown, rebuild и доступ к консоли;
• лимиты CPU, RAM, disk, bandwidth;
• логи создания VPS и ошибок.

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

Как проверить, что VPS с отдельным IPv4 работает правильно

После создания тестового VPS проверьте не только доступ по SSH, но и полноценную сетевую работу.

ip a
ip r
ping -c 4 1.1.1.1
curl -4 ifconfig.me
dig -x VPS_IP
mtr -rw 1.1.1.1

Снаружи проверьте:

ping VPS_IP
traceroute VPS_IP
nmap -Pn -p 22 VPS_IP

Если IP не отвечает снаружи, не спешите обвинять VPS. Сначала проверьте firewall внутри VM, firewall на хосте, схему маршрутизации, gateway, MAC-фильтрацию и корректность IP Pool.

Частые ошибки маленьких VPS-провайдеров

• Покупают /24 без плана продаж и потом пытаются срочно слить IP дешёвыми VPS.
• Считают только стоимость сервера, забывая про цену IPv4, поддержку, abuse и лицензии.
• Выдают много IP новым клиентам без проверки.
• Не ведут учёт, какой IP кому выдан.
• Не делают резерв адресов под миграции и замены.
• Продают VPS слишком дёшево и получают аудиторию с высоким abuse-риском.
• Используют Proxmox без автоматизации и вручную создают клиентские VPS.
• Настраивают Virtualizor IP Pool без тестов на разных шаблонах ОС.
• Не проверяют rDNS и потом получают жалобы от клиентов.
• Не имеют понятной политики по spam, phishing, malware и сетевому сканированию.
• Не мониторят загрузку хоста, диск, I/O wait, сетевой трафик и состояние NVMe.
• Не оставляют rollback-план при изменении сетевой конфигурации.

Как быстро починить типовые проблемы

Если новый VPS получил IP, но сети нет, проверьте маршрут:

ip r
ping -c 4 gateway_ip
ping -c 4 1.1.1.1

Если gateway не пингуется, ошибка обычно в IP-настройках VM, bridge, routed-схеме или gateway. Если gateway пингуется, но интернет недоступен, смотрите маршруты, forwarding, firewall и правила дата-центра.

Если VPS выходит в интернет, но снаружи недоступен, проверьте firewall:

iptables -S
nft list ruleset
ufw status
systemctl status firewalld

Если IP показывает не тот rDNS, настройте PTR-запись у поставщика IP или в панели, если делегирование rDNS доступно.

Если Virtualizor не выдаёт IP из пула, проверьте сам IP Pool, привязку к серверу, тип пула, занятость адресов и логи Virtualizor.

Если после добавления новой подсети VM не пингуется, не копируйте старую схему вслепую. Уточните, новая подсеть routed или on-link. Разные типы выдачи требуют разных сетевых настроек.

Какая конфигурация dedicated server подходит для VPS с IPv4

Минимальная конфигурация зависит от размера VPS, которые вы продаёте. Но для коммерческого запуска лучше не брать сервер “впритык”. Нужен запас по RAM, IOPS и CPU.

Для маленькой VPS-линейки стоит смотреть на:

• современный CPU с достаточным количеством потоков;
• 128 GB RAM и выше, если планируется много VPS;
• NVMe-диски, желательно с резервированием;
• 1 Gbps порт как минимум, для более плотной загрузки — выше;
• IPMI/KVM для аварийного доступа;
• понятную схему подключения IPv4-пула;
• возможность апгрейда RAM и дисков;
• стабильный дата-центр и понятные правила по abuse.

Если вы планируете продавать VPS с высокой нагрузкой на диск, обычные SSD или перегруженный storage быстро испортят качество услуги. Для VPS-хостинга NVMe часто важнее, чем кажется, потому что десятки VM одновременно пишут логи, обновляют пакеты, работают с базами и создают random I/O.

Как HSTQ может помочь

HSTQ может быть полезен маленьким хостинг-провайдерам, которым нужен не просто один сервер, а связка: dedicated server, IPv4-пул или подсеть, помощь с сетевой схемой и понимание задач VPS-хостинга.

Если вам нужно поднять много VPS с отдельными IPv4, лучше сразу обсуждать dedicated server + подсеть, а не пытаться докупать адреса по одному без плана. Для таких задач важны IP justification, схема виртуализации, правила использования, лимиты на выдачу IP, rDNS, abuse-процесс и дальнейшее масштабирование.

Для проектов, которым нужны IPv4-блоки, можно рассмотреть аренду IPv4 и подбор сервера под Proxmox или Virtualizor. Перед заказом стоит подготовить описание проекта: сколько VPS планируется, сколько IP нужно на старте, какая панель будет использоваться, какие клиенты будут размещаться, какие типы проектов запрещены и какой рост ожидается в ближайшие месяцы.

Если вы только тестируете спрос, не начинайте с максимального пула. Разумнее взять конфигурацию, которая позволит проверить продажи, поддержку и abuse-нагрузку. Если спрос подтверждается, можно масштабироваться до /24, отдельного dedicated server, нескольких нод и более строгой автоматизации через WHMCS.

Главное — не строить VPS-бизнес вокруг идеи “купим IP и как-нибудь продадим”. В 2026 году слабая экономика IPv4 быстро съедает прибыль. Устойчивый вариант — считать себестоимость, фильтровать клиентов, правильно настраивать виртуализацию и продавать VPS с отдельными IPv4 только там, где это технически и коммерчески оправдано.