VPS для WordPress

Что такое VPS и чем он отличается от виртуального хостинга

VPS (он же VDS) — это изолированная виртуальная машина на физическом сервере провайдера. У вас своя операционная система, свой набор процессов, свой IP-адрес и root-доступ. Всё, что вы делаете внутри, соседей не касается, и наоборот: их всплеск нагрузки не отнимает вашу память.

Практическая разница с виртуальным хостингом сводится к трём вещам. Ресурсы выделены, а не поделены — 2 гигабайта памяти означают именно 2 гигабайта, а не «до 2, если повезёт». Стек ваш — можно поставить PHP 8.4, собрать Nginx с нужным модулем, включить Redis с той конфигурацией, которая вам нужна. И вся эксплуатация тоже ваша: провайдер отвечает за то, что машина включена и сеть работает, за всё остальное отвечаете вы.

Есть ещё одно различие, о котором в описаниях тарифов обычно молчат, — тип виртуализации. KVM — полноценная виртуализация: своё ядро, свой swap, ресурсы честно зарезервированы. OpenVZ (и его наследник LXC-контейнеры у некоторых провайдеров) — контейнерная: ядро общее с соседями, память часто продана с overcommit. На практике это выглядит так: у соседа по ноде пошёл всплеск, доступной памяти на хосте не хватило, и OOM-killer убивает ваш MySQL. Сайт падает с «Error establishing a database connection», а в вашем мониторинге нагрузка при этом нормальная.

Как понять, что перед вами: у KVM-тарифов это указано прямо в характеристиках или в тегах. Если тип виртуализации не назван вообще, а цена подозрительно низкая — почти наверняка OpenVZ. Под боевой WordPress берите KVM: RuVDS, например, продаёт только KVM, и это видно в описании тарифа.

Когда WordPress действительно перерастает shared

Пороги, при которых переезд оправдан:

• Посещаемость выше 10 000 в сутки — при условии, что заметная часть трафика идёт мимо кэша.
• Магазин на WooCommerce от 500 товаров или с регулярными пиками после рассылок и рекламы.
• Больше 30 активных плагинов — каждый добавляет запросы к базе и хуки на каждой загрузке.
• Мультисайтовая сеть — на shared она упирается в лимит баз и inodes почти сразу.
• Регулярный импорт или синхронизация — выгрузка каталога из 1С, обмен с CRM, парсеры. Это часы фоновой работы PHP, которых лимит shared не переживёт.
• Нужен конкретный софт: своя версия PHP, ImageMagick с определёнными делегатами, Node.js для сборки, специфичное расширение.

Но сначала исключите три вещи, которые выглядят как «не хватает сервера», а на деле лечатся бесплатно. Тяжёлая тема с конструктором: Elementor или WPBakery на странице с двадцатью секциями генерируют по 300–500 запросов к базе — на любом сервере это будет медленно. Неоптимизированные изображения: фотография на 4 МБ прямо с телефона в шапке страницы кладёт LCP независимо от того, где стоит сайт. Отсутствие кэша страниц — самая частая причина; сайт без кэша на VPS за 1500 ₽ работает медленнее, чем сайт с кэшем на shared за 119 ₽.

Проверить просто: включите Query Monitor, откройте типовую страницу и посмотрите число SQL-запросов и время генерации. Больше 150 запросов или больше 800 мс на генерацию — проблема в сайте, а не в железе, и переезд её увезёт с собой.

Сколько ресурсов нужно под задачу

Два уточнения к таблице.

Почему NVMe, а не SSD. WordPress — это сотни мелких операций чтения на каждый запрос: файлы плагинов, шаблоны темы, чтение таблиц базы. На таких операциях NVMe даёт задержку в десятки микросекунд против сотен у SATA SSD. В синтетике разница выглядит как «в 5 раз быстрее», в реальном TTFB — как 20–40 миллисекунд, что при цели «до 100 мс» существенно. Тариф с обычным HDD под WordPress не рассматривайте вообще, даже под тестовый сайт.

Почему память важнее ядер. Один PHP-процесс WordPress занимает 60–120 МБ, с WooCommerce — до 200 МБ. MySQL хочет 512 МБ–1 ГБ под буферный пул, чтобы держать индексы в памяти, Redis — ещё 128–256 МБ. На 2 гигабайтах это укладывается впритык с 6–8 воркерами PHP-FPM. Добавив ядро при той же памяти, вы не получите ничего: воркеры упрутся в RAM раньше, чем в процессор. Обратное тоже верно — на 4 ГБ с 2 ядрами WordPress живёт нормально, а вот на 2 ГБ с 4 ядрами начинается своп и деградация.

Стек под WordPress: что ставить на чистый сервер

Базовый набор, который закрывает 95% случаев:

• Nginx — принимает соединения, отдаёт статику, проксирует PHP. Здесь же настраивается кэш на уровне сервера (FastCGI cache) — это самый быстрый вариант кэширования из существующих, страница отдаётся вообще без запуска PHP.
• PHP-FPM 8.3 с OPcache и JIT. Пул воркеров считается по памяти: (доступная RAM − MySQL − Redis) / средний размер процесса. Ставить pm.max_children наугад — прямой путь к OOM при первом всплеске.
• MariaDB 10.11 или MySQL 8. Ключевой параметр — innodb_buffer_pool_size, примерно 50–60% доступной памяти на сервере, отданном только под базу, или 25–30% на совмещённом.
• Redis для объектного кэша плюс плагин Redis Object Cache. Снимает с базы повторяющиеся SELECT — на WooCommerce и любом сайте с авторизацией это разница в разы, а не в проценты.
• Certbot для SSL с автопродлением — на VPS сертификат никто за вас не выпустит.

Альтернатива для тех, кто не хочет возиться с конфигами кэша, — OpenLiteSpeed вместо Nginx плюс плагин LiteSpeed Cache. Кэш настраивается из админки WordPress, ESI-блоки позволяют кэшировать страницу целиком, оставляя динамической только корзину. Собирается такой стек за вечер и дальше почти не требует внимания — разумный компромисс, если полный контроль нужен, а возиться с конфигами Nginx не хочется.

Что будет, если пропустить компоненты. Без OPcache PHP пересобирает байт-код на каждом запросе — плюс 100–200 мс к TTFB на ровном месте. Без Redis каждая загрузка страницы заново тянет опции и метаданные из базы. Без кэша страниц сервер генерирует один и тот же HTML для каждого посетителя — и вот тогда VPS за 1500 ₽ проигрывает shared за 119 ₽, о чём ниже.

Панель управления: ставить или обойтись

Панель съедает 300–500 МБ памяти и немного процессора — на сервере с 2 ГБ это ощутимая доля. Взамен она берёт на себя выпуск и продление SSL, создание баз и пользователей, настройку cron, бэкапы по расписанию, добавление сайтов и почтовых ящиков.

Мешает панель в одном сценарии, но мешает сильно: она владеет конфигами. Вы правите nginx.conf руками, панель при следующем изменении сайта перезаписывает файл своим шаблоном — и правка исчезает. Лечится это только через механизм пользовательских шаблонов конкретной панели, и у каждой он свой.

Позиция простая: нет опыта администрирования — ставьте панель, потери на памяти окупятся первым же вечером, когда не придётся гуглить синтаксис certbot. Есть опыт — не ставьте, чистый сервер предсказуемее.

Что придётся делать самому

На shared всё перечисленное делал провайдер. На VPS это переходит к вам целиком:

1. Обновления системы и стека. apt upgrade раз в 2–4 недели, отдельно — критические патчи PHP и MySQL. Настройте unattended-upgrades хотя бы для security-обновлений.
2. Firewall. ufw или nftables: наружу открыты 80, 443 и SSH — всё остальное закрыто. По умолчанию на свежем сервере открыто всё.
3. Бэкапы и проверка восстановления. Бэкап, который ни разу не разворачивали, — это не бэкап. Раз в квартал поднимайте копию из архива на тестовом сервере и убеждайтесь, что сайт заводится. Хранить копии нужно вне этого же VPS: снапшот диска не спасёт, если аккаунт заблокировали за неоплату.
4. Мониторинг. Минимум — внешняя проверка доступности каждую минуту и алерт на почту или в телеграм. Плюс контроль места на диске: переполненный /var роняет MySQL наглухо.
5. Реакция на инциденты. Сайт упал в три часа ночи — поднимаете вы. Поддержка провайдера ответит «ваш сервер работает, проблема внутри ОС», и формально будет права.
6. Продление SSL. Certbot обновляет сертификат сам, но только если таймер жив и порт 80 доступен. Проверяйте раз в квартал.

По времени: 1–3 часа на первичную настройку с панелью, 4–8 часов на ручную сборку стека, если делаете это не в первый раз. Дальше — 1–2 часа в месяц в спокойном режиме и непредсказуемое количество в день инцидента.

Если этих часов у вас нет, честнее не героически осваивать администрирование, а взять managed-хостинг: там обновления, кэш, бэкапы и мониторинг входят в тариф.

Безопасность VPS под WordPress

На shared провайдер закрывал базовые дыры сам. На своём сервере это ваша зона ответственности, и начинать атаковать вас начнут в первые же сутки после того, как домен появится в CT-логах.

• Вход по SSH-ключу, пароль отключён. PasswordAuthentication no в sshd_config. Порт можно сменить с 22 — это не защита, но убирает 90% фонового шума в логах.
• fail2ban на SSH и на wp-login.php. Для WordPress нужен отдельный фильтр по логам Nginx: подбор паролей к админке идёт непрерывно и десятками попыток в минуту.
• Автоматические обновления безопасности — unattended-upgrades для системных пакетов.
• Отдельный системный пользователь под каждый сайт, PHP-FPM работает от него. Тогда взлом одного сайта на сервере не даёт доступа к остальным.
• Закрытие XML-RPC, если не используете приложение WordPress и Jetpack. Это классический вектор и для брутфорса, и для усиления DDoS.
• Права 644 на файлы и 755 на каталоги, wp-config.php — 640. Веб-серверу не нужны права на запись везде.
• Запрет выполнения PHP в wp-content/uploads. Если через дыру в плагине туда зальют шелл, он просто не запустится. Одна директива в конфиге Nginx, которая экономит недели разбирательств.

Сколько на самом деле стоит VPS

Цена в прайсе — не вся стоимость. Складывать надо так:

Панель стоит проверить отдельно: RuVDS отдаёт лицензию ISPmanager 6 Lite бесплатно, FirstVDS дарит месяц ispmanager 6 lite. Это экономит те самые 600 ₽ в месяц, если вы не готовы администрировать сервер из консоли.

Отдельная статья расходов, которую забывают, — SSL и бэкапы. На виртуальном хостинге они входят в тариф, на чистом VPS их не существует, пока вы сами не настроите certbot и не оплатите место под резервные копии.

Точка безубыточности с managed считается по времени. Managed-тариф при сопоставимых ресурсах стоит примерно на 300–700 ₽/мес дороже, чем VPS с бесплатной панелью. Если ваш час стоит хотя бы 500 ₽, а на обслуживание уходит два часа в месяц, managed выходит дешевле — при том, что снимает и риск инцидента в три часа ночи. VPS выигрывает в двух случаях: когда нужен нестандартный софт, которого в managed не поставить, и когда администрирование и так входит в чьи-то рабочие обязанности.

Когда VPS брать не надо

Самый распространённый антипаттерн — блог с посещаемостью 500 человек в сутки, переехавший на VPS «на вырост». На чистом сервере с дефолтными настройками PHP-FPM, без OPcache-тюнинга, без Redis и без кэша страниц такой сайт работает медленнее, чем на нормальном shared, где провайдер уже настроил LiteSpeed и объектный кэш. Владелец платит вдвое больше и получает худший TTFB — а причина не в железе, а в том, что железо никто не настроил. Прежде чем менять тариф, стоит пройти по разбору скорости WordPress: в половине случаев проблема решается кэшем и версией PHP.

Второй случай — VPS без администрирования. Сервер, на который полгода не приходили обновления, — это гарантированный взлом через известную уязвимость. На shared за обновлениями системы следит провайдер, здесь — нет. VPS без человека, который его обслуживает, менее безопасен, чем самый дешёвый виртуальный хостинг.

Третий — попытка сэкономить на памяти. VPS с 1 ГБ RAM под WordPress с WooCommerce технически запустится и даже покажет главную страницу. Первый же импорт товаров или пять одновременных посетителей корзины отправят его в своп, а затем в OOM.

Если вы не уверены, что готовы к эксплуатации, начните с виртуального хостинга и оптимизации сайта, а на VPS переезжайте, когда упрётесь в реальные лимиты. Для магазина сразу посмотрите требования к хостингу под WooCommerce, а общие критерии выбора — в чек-листе. Сравнение провайдеров по TTFB, аптайму и цене — в рейтинге хостингов.