Skip to content Если у тебя один-три сайта на WordPress или другой PHP-CMS, посещаемость в пределах нескольких тысяч человек в сутки и нет желания становиться администратором сервера, оставайся на обычном хостинге. Он дешевле, обновления, защиту и почту за тебя ведёт провайдер, а приличный shared-тариф сегодня тянет больше, чем принято думать. VPS нужен, когда ты упираешься в то, чего shared не даёт в принципе, или когда сайт регулярно ловит лимиты ресурсов, а оптимизация уже ничего не меняет.
И учти сразу: переход на свой виртуальный сервер не похож на смену тарифа на тариф побольше. На shared ты покупаешь услугу, а на VPS получаешь сервер, которым управляешь сам, со всем, что к этому прилагается. Почти всё остальное в статье вытекает из этой разницы.
| Ситуация | Что делать |
|---|---|
| Сайт работает стабильно, превышений лимитов в панели нет | оставаться на shared |
Превышения случаются эпизодически, в пики, иногда с ошибкой 508 Resource Limit Is Reached или 503 | сначала диагностика: во что упирается сайт и кто его грузит |
Нагрузку создаёт бот, тяжёлый плагин, wp-cron | устранить причину: переезд её не уберёт |
| Кэш и плагины в порядке, трафик живой, а превышения копятся в каждый пик | shared-тариф постарше или VPS |
| Нужен свой софт (постоянно работающее приложение на Node.js или Python, Docker, VPN, Redis), root, открытый порт, своя версия PHP или правила nginx | VPS |
| Сайтов десяток и больше или нужен свой IP без общей почтовой репутации с соседями | VPS, по деньгам он здесь обычно выгоднее |
На практике люди чаще всего оказываются во второй и третьей строке, а читают себя как четвёртую. Превышения лимитов воспринимают как приговор тарифу, хотя нередко сервер помощнее только перенёс бы проблему туда, где решать её придётся уже тебе, а не провайдеру. Как это проверить, разберём сразу.
Как понять, что ты действительно упёрся в лимиты
На большинстве shared-хостингов, особенно с cPanel, стоит CloudLinux. Он нарезает каждому аккаунту свою порцию ресурсов через механизм LVE и честно ведёт статистику, сколько раз ты в эти рамки уткнулся. В cPanel это раздел «Использование ресурсов» (Resource Usage). В ISPmanager и DirectAdmin такой страницы может не быть, тогда статистику LVE по твоему аккаунту можно запросить у поддержки, обычно дают без вопросов.
Названия лимитов выглядят как шифровка, но за каждым стоит вполне конкретный симптом:
- CPU – доля процессора, где 100% означает одно ядро целиком, а 200% два. Упор в него, как правило, ошибок не даёт: CloudLinux притормаживает процессы аккаунта, и сайт открывается медленно, но открывается.
- EP (Entry Processes) – сколько запросов к PHP аккаунт может обрабатывать одновременно. CloudLinux для типового аккаунта рекомендует 20, для мощного 40, но хостеры ставят свои значения, от 10 на дешёвых тарифах до сотни на дорогих. Классически превышение EP даёт ту самую ошибку 508.
- PMEM – физическая память всех процессов аккаунта вместе. При упоре CloudLinux сначала освобождает дисковый кэш аккаунта, а если этого мало, убивает часть процессов. Посетитель чаще всего видит 500 или 503.
- IO и IOPS – скорость и число операций с диском. Бьют по тяжёлым бэкапам, импортам, большим базам.
- NPROC – общее число процессов, включая cron-задачи и SSH-сессии. При упоре новые процессы не запускаются, что тоже обычно заканчивается ошибками 500 или 503.
- Inodes – количество файлов. Это не ресурс нагрузки, но упор в него ломает загрузку файлов и запись кэша.
Какой именно код увидит посетитель, зависит от веб-сервера и настроек конкретного хостинга: у одних упор в память тоже выглядит как 508, у других превышение EP отдаёт 503. Поэтому надёжнее смотреть не на код ошибки, а на счётчики превышений (faults) в статистике ресурсов.
Кстати, PMEM часто путают с memory_limit в PHP. Ошибка Allowed memory size of ... bytes exhausted говорит о лимите одного PHP-скрипта, он правится в настройках PHP прямо в панели, и к нехватке ресурсов тарифа отношения не имеет. Переезжать из-за неё на VPS странно, хотя такие переезды случаются.
Теперь главный вопрос: кто создаёт нагрузку. Если на тарифе есть SSH (на многих shared он есть, только в урезанном виде), посмотри на лог доступа. Путь к нему у каждого провайдера свой, часто это что-то вроде ~/logs/ или ~/access-logs/:
# кто делает больше всего запросов (IP)
awk '{print $1}' ~/logs/access.log | sort | uniq -c | sort -rn | head -20
# кем представляются клиенты (user-agent)
awk -F'"' '{print $6}' ~/logs/access.log | sort | uniq -c | sort -rn | head -20Картина, которую провайдеры видят постоянно: владелец жалуется на 508, просит тариф побольше или уходит на VPS, а в логе половина запросов приходится на пару агрессивных SEO-ботов, которые обходят каталог интернет-магазина по всем комбинациям фильтров. Ещё один частый источник – admin-ajax.php и wp-cron.php в WordPress, которые дёргаются на каждый просмотр страницы. На VPS такой бот никуда не денется: сервер помощнее просто позволит ему обходить те же фильтры быстрее, а процессор он выест так же. Разница только в том, что разбираться с этим теперь тебе, а не поддержке.
Если же в логах живые люди, кэш страниц работает, а превышения всё равно копятся в каждый пик, значит, проект действительно перерос тариф. Дальше выбор между shared-тарифом постарше и VPS, и тут пригодится понимание, чем они отличаются по сути.
Чем они отличаются на самом деле
Популярное объяснение «shared – это когда много сайтов на одном сервере, а VPS – это свой сервер» верно наполовину. На одном физическом сервере живут и те и другие. Разница в том, что именно у тебя своё.
На shared общая вся система: одна операционка, один веб-сервер (Apache или LiteSpeed), один MySQL на всех, один набор версий PHP. Тебе выдают домашнюю папку, панель управления и порцию ресурсов. Ты не можешь выполнить apt install и открыть порт, а постоянно работающие фоновые процессы на большинстве хостингов либо запрещены правилами, либо их снимают автоматически, т.к. shared рассчитан на короткие веб-запросы, а не на демоны. Часть хостеров умеет запускать приложения на Node.js и Python через панель (в CloudLinux для этого есть отдельные селекторы), но такие приложения обычно живут в связке с веб-сервером и просыпаются на входящие запросы. Сайту на Node.js этого хватит, Telegram-боту на вебхуках тоже, а вот боту в режиме long polling, который сам круглосуточно опрашивает серверы Telegram, нужен постоянно работающий процесс, и на shared ему неуютно.
На VPS у тебя виртуальная машина со своей ОС и root-доступом. При виртуализации KVM у гостевой системы своё ядро, поэтому модули ядра, Docker и WireGuard на ней, как правило, работают без плясок. На контейнерной виртуализации (OpenVZ, LXC) root тоже есть, но ядро общее с хостом: что из этого заработает, зависит от того, какие возможности провайдер включил на своей стороне, и Docker или WireGuard там запросто может не подняться. Подробно разница разобрана в статье KVM против OpenVZ; у большинства провайдеров сегодня основная линейка на KVM, но тип виртуализации лучше проверить в описании тарифа.
| Shared-хостинг | VPS | |
|---|---|---|
| Доступ | панель, FTP, иногда урезанный SSH | полный root по SSH |
| Свой софт | только то, что есть в панели | любой, включая постоянно работающие процессы |
| Ресурсы | лимиты аккаунта (CPU, EP, память), в пределах которых сервер делится с соседями | выделенные RAM и диск, vCPU с оговорками |
| Администрирование | провайдер | ты (если тариф unmanaged) |
| Обновления и защита | провайдер, часто с антивирусом и WAF | ты |
| Почта | работает из коробки | нужно настраивать или выносить на внешний сервис |
| Бэкапы | обычно включены в тариф | платная опция или настраиваешь сам |
| Порог входа | нулевой | терминал, базовый Linux |
Строка «Администрирование» в этой таблице весит больше всех остальных вместе взятых. К ней ещё вернёмся.
VPS сам по себе сайт не ускоряет
Это, пожалуй, самое живучее заблуждение в теме. Логика понятна: на shared ресурсы общие, на VPS свои, значит, на VPS быстрее. Но сравнивают обычно не то.
Хороший shared-хостинг работает на мощном сервере с десятками ядер и NVMe-дисками, веб-сервер там часто LiteSpeed со встроенным LSCache, а MySQL настроен людьми, которые занимаются этим каждый день. Лимит аккаунта на недорогих тарифах чаще всего равен одному-двум ядрам (на дорогих бывает и больше). Выглядит скромно, но это ядра современного серверного процессора, и обычному сайту в коротких всплесках их, как правило, хватает. Против этого ставят самый дешёвый VPS: 1 vCPU, 1 ГБ памяти, MariaDB и PHP-FPM с настройками по умолчанию, а сверху ещё панель управления, которая сама по себе съедает заметную часть этого гигабайта.
Дальше события развиваются по одному сценарию настолько часто, что его можно узнать по первой фразе в тикете. Сайт на новом VPS какое-то время летает, потом раз в пару дней WordPress начинает показывать Error establishing a database connection. Перезагрузка помогает, до следующего раза. Причина почти всегда одна: память кончилась, и ядро прибило самый прожорливый процесс, т.е. MySQL. Найти следы можно так:
# сколько памяти свободно и есть ли swap
free -h
# следы OOM killer в журнале ядра
journalctl -k | grep -i "killed process"
# или, если журнал недоступен
dmesg -T | grep -i "out of memory"Самое неприятное в этой ситуации то, что снаружи она выглядит как случайные падения без причины. Лечится она swap-файлом (как его настроить), настройкой числа процессов PHP-FPM (разбор здесь) и урезанием аппетитов MySQL под маленький сервер (вот так). Ну или тарифом с запасом памяти. Сколько памяти нужно, сильно зависит от панели и нагрузки. cPanel, например, по официальным требованиям не ставится меньше чем на 2 ГБ, а рекомендует 4. Лёгкие панели вроде HestiaCP или FastPanel скромнее. Для одного-двух WordPress-сайтов со средней посещаемостью и лёгкой панелью я бы ориентировался примерно на 2 ГБ как на комфортную отправную точку. На 1 ГБ сайт тоже живёт, но обычно без панели, со swap и аккуратной настройкой.
То есть VPS даёт не скорость, а возможность её получить. Настроенный VPS обгонит shared на тяжёлом проекте, особенно когда туда добавляется Redis для объектного кэша и своя конфигурация кэширования. Ненастроенный может проиграть обычному тарифу за те же деньги.
Root-доступ: что ты получаешь и что берёшь на себя
На shared провайдер незаметно делает много работы: ставит обновления безопасности, держит свежие версии PHP, сканирует файлы на вирусы, продлевает SSL-сертификаты, делает бэкапы, следит, чтобы почта доходила. Всё это входит в цену, и пока оно работает, про него не думаешь.
На обычном (unmanaged) VPS провайдер отвечает за железо, сеть и то, чтобы виртуальная машина была запущена. Всё, что внутри, твоё. Первые недели это ощущается как свобода, потом приходит понимание, что свобода включает обязанность.
Чтобы это не звучало абстрактно, поставь любой свежий VPS с открытым SSH и загляни в журнал через сутки:
# Ubuntu, а также Debian с установленным rsyslog
grep -c "Failed password" /var/log/auth.log
# Debian 12 и новее (rsyslog там по умолчанию не ставится)
journalctl -u ssh | grep -c "Failed password"
# AlmaLinux, Rocky
grep -c "Failed password" /var/log/secureСчётчик неудачных попыток входа за первые сутки обычно измеряется сотнями, а бывает и тысячами. Это не атака на тебя лично: боты перебирают пароли на всех адресах подряд, и новый IP попадает в их списки очень быстро. Так что базовая защита на VPS не опция, а первое, что делается после подключения по SSH: ключи вместо пароля, файрвол, Fail2ban, автообновления. Всё это разобрано в статье про базовые меры защиты VPS, а по частям в материалах о UFW и iptables и автоматических обновлениях безопасности.
С бэкапами похожая история. На shared они чаще всего идут в комплекте, и про них вспоминают, когда надо что-то восстановить. На VPS провайдер бэкапы не делает, если ты их отдельно не оплатил, а снимок диска (snapshot) – это ещё не полноценная резервная копия: разница объяснена в статье про snapshot и backup. Схему своих копий лучше продумать до того, как на сервер переедет первый живой сайт, см. основы резервного копирования.
Отдельный подводный камень, о котором при переезде вспоминают последним, это почта. На shared она просто работает: создал ящик в панели, и формы сайта шлют письма. На VPS многие провайдеры по умолчанию закрывают исходящий 25-й порт на новых аккаунтах (так они борются со спамерами), для нормальной доставки нужна обратная DNS-запись (PTR) и записи SPF, DKIM и DMARC, а свежий IP без истории почтовые сервисы встречают настороженно. Поэтому значительная часть владельцев VPS почтовый сервер у себя вообще не поднимает и держит ящики на внешнем сервисе, а сайт отправляет письма через SMTP. Если всё-таки хочешь своё, есть отдельный разбор, стоит ли держать почту на VPS.
Если перспектива всем этим заниматься не радует, есть managed-VPS, где администрирование берёт на себя провайдер. Стоит он заметно дороже, и разница с unmanaged описана в статье управляемый или неуправляемый хостинг.
Соседи есть везде, просто разные
Один из доводов за VPS звучит так: на shared тебя тормозят соседи. Это правда, хотя и неполная. Если соседний сайт на сервере попал под DDoS или его взломали и превратили в рассылку спама, страдают все аккаунты: сервер тормозит целиком, а общий IP улетает в чёрные списки, после чего письма из форм твоего сайта начинают падать в спам. Современный shared с CloudLinux неплохо изолирует файлы и ресурсы аккаунтов друг от друга, но общий IP и общий веб-сервер никуда не деваются.
На VPS соседи тоже есть, только уровнем ниже, на гипервизоре. Проявляются они иначе: виртуальной машине недодают процессорное время. В top это видно по полю st (steal) в строке %Cpu(s). Официального порога здесь нет, это скорее ориентир: единицы процентов обычно считаются нормальным фоном, короткие всплески тоже не повод для паники. Если же steal долго держится на двузначных числах под твоей нагрузкой, вероятнее всего, хост перегружен соседями. Исключение – burstable-тарифы с разделяемым процессором: там высокий steal может означать, что ты исчерпал свою квоту процессорного времени, и это ожидаемое поведение тарифа, а не перепродажа. Подробнее о том, как считаются виртуальные ядра и чем shared CPU отличается от выделенного, в статьях что такое vCPU и shared и dedicated CPU.
Сколько это стоит на самом деле
Сравнивать цену тарифа с ценой тарифа тут бессмысленно. Начальный VPS стоит примерно как средний тариф shared, и кажется, что за те же деньги дают больше. Но в цену shared уже включены панель, бэкапы, почта и труд администратора. На VPS всё это либо докупается, либо делается своими руками, и тогда платишь временем.
Больше всего сюрпризов обычно с панелью управления. Лицензия cPanel на VPS тарифицируется по числу аккаунтов и нередко стоит дороже самого недорогого сервера. ISPmanager и DirectAdmin обходятся дешевле. Есть и бесплатные панели вроде HestiaCP, aaPanel или CloudPanel, у которых свои компромиссы по возможностям и безопасности (сравнение в обзоре панелей управления для VPS). Можно обойтись и вовсе без панели, собрав LEMP-стек руками: экономия памяти и денег, но каждый новый сайт добавляется через конфиги.
К этому добавь хранилище для бэкапов (опция у провайдера или отдельный сервер, об этом в статье про автобэкап на удалённое хранилище) и мониторинг. На shared за состоянием сервера следит провайдер, а о том, что лежит твой VPS, без настроенных оповещений ты рискуешь узнать от посетителей; с чего начать, рассказано в статье про мониторинг нагрузки.
И время. Первые пару недель его уходит прилично, потом система работает сама и требует внимания по большей части при обновлениях. Из чего вообще складывается стоимость сервера, подробно разобрано в статье сколько стоит VPS.
Где VPS однозначно выигрывает по деньгам, так это на количестве проектов. Десять небольших сайтов на shared часто требуют тарифа уровня «бизнес», а на VPS с 2–4 ГБ памяти такой набор обычно помещается, если это визитки и блоги с кэшем страниц, а не интернет-магазины с живой нагрузкой. При таком раскладе каждый следующий сайт почти ничего не стоит. Как их правильно развести по одному серверу, объяснено в статье про несколько сайтов на одном VPS.
Промежуточные варианты
Выбор не бинарный. У многих провайдеров есть shared-тарифы с повышенными лимитами (их называют бизнес-хостингом или хостингом повышенной мощности): это тот же shared, но с бо́льшими EP и памятью, и для WordPress-сайта, который перерос базовый тариф, этого часто хватает без всякого переезда. Есть managed-VPS, о котором шла речь выше. Есть облачные серверы с посекундной или почасовой оплатой, которые удобно масштабировать, если нагрузка скачет (как устроен облачный хостинг). И есть вариант держать основной сайт на shared, а VPS взять под то, что туда не влезает: бота, VPN, скрипт, который крутится круглые сутки.
Если решил переезжать
Порядок, при котором переезд проходит без неожиданностей:
- Составь опись того, что работает на shared: сайты и их версии PHP, базы данных, cron-задачи из панели, почтовые ящики и, главное, где размещена DNS-зона домена.
- Подбери тариф с запасом по памяти (под WordPress с лёгкой панелью ориентир около 2 ГБ, с cPanel от 4) на KVM; как выбрать, описано в статье как выбрать тариф на VPS, а до оплаты сервер стоит протестировать.
- Реши, будет ли панель, и сделай базовую настройку сервера: пользователь, SSH-ключи, файрвол, обновления. Пошагово это есть в статье настройка VPS для новичков.
- Перенеси сайты и проверь их на новом сервере до смены DNS, прописав новый IP для домена у себя в файле
hosts. - За сутки до переключения уменьши TTL у A-записи, потом смени IP.
- Не отключай shared ещё неделю-две: если что-то всплывёт, будет куда откатиться.
Сам перенос файлов и базы подробно описан в статье как перенести сайт на VPS. Здесь стоит задержаться на первом пункте, потому что на нём спотыкаются чаще, чем на технической части. Типичная история выглядит так: сайт переехал, всё работает, старый тариф отключили, и через день перестала приходить почта. Оказывается, домен смотрел на DNS-серверы старого хостинга, вместе с тарифом удалилась вся зона, а с ней MX-записи и заодно A-запись, которую только что так аккуратно поменяли. Поэтому DNS-зону перед отключением стоит переносить к регистратору или на отдельный DNS-сервис, а почту решить заранее, до того как исчезнет старый ящик.
Если выбор провайдера ещё впереди, сравнить тарифы по цене, характеристикам и результатам тестов можно в рейтинге VPS. А если после всего прочитанного shared кажется разумнее, это тоже нормальный вывод: сервер, которым никто не занимается, работает хуже тарифа, за которым следит провайдер…
