Настройка WordPress на VPS обычно упирается в три вещи: правильный Nginx перед PHP, безопасный SSL и продуманное кеширование, чтобы страницы отдавались быстро и стабильно. Дальше разложим по шагам схему, которая хорошо работает на типичном VPS: Nginx + PHP-FPM + MariaDB/MySQL, HTTPS через Let’s Encrypt и несколько уровней кеша.
Ниже приведён практический план под Ubuntu 22.04. Если у тебя другой дистрибутив, логика останется той же, но команды пакетов и пути конфигов могут отличаться.
Что нужно подготовить перед стартом
Ресурсы VPS и ожидания по производительности
WordPress сам по себе не тяжёлый, но скорость упирается в связку CPU, RAM и диска. Если планируешь 1–5 тыс. визитов в сутки и стандартный блог, обычно хватает 1–2 vCPU и 2–4 ГБ RAM при включённом кешировании. Если сайт растёт и появляются плагины тяжёлого типа (сложные визуальные конструкторы, офлайн-индексация, большие отчёты), лучше сразу закладывать запас.
Ещё момент: VPS с “медленным” диском резко ухудшает время ответа базы и PHP. Это лечится не только кешом, но и правильными настройками MariaDB и выбором типа диска у провайдера.
Домен, DNS и доступ по SSH
Перед настройкой убедись, что домен указывает на IP VPS, и доступ по SSH работает.
Для SSL через Let’s Encrypt удобно иметь:
- основной домен, например example.com
- при необходимости поддомен www, например www.example.com
Если www пока не настроен, проще сначала выпустить сертификат на один домен, а потом добавить второй.
Установка Nginx, PHP-FPM и базы данных
Установка Nginx и MariaDB
Обнови индексы пакетов и установи базовые компоненты.
«`bash sudo apt update sudo apt install -y nginx sudo apt install -y mariadb-server sudo systemctl enable nginx sudo systemctl enable mariadb «`
После установки MariaDB желательно выполнить базовую настройку безопасности.
«`bash sudo mysqlsecureinstallation «`
На этом шаге выставь пароль root, отключи анонимный доступ и запрети вход root извне.
Создание пользователя и базы для WordPress
Для WordPress лучше отдельная БД и отдельный пользователь. Пример:
«`bash sudo mariadb -u root «`
Дальше в консоли MariaDB:
«`sql CREATE DATABASE wordpress CHARACTER SET utf8mb4 COLLATE utf8mb4unicodeci; CREATE USER ‘wpuser’@’localhost’ IDENTIFIED BY ‘СЮДА_ПАРОЛЬ’; GRANT ALL PRIVILEGES ON wordpress.* TO ‘wpuser’@’localhost’; FLUSH PRIVILEGES; EXIT; «`
Так проще контролировать доступ и безопаснее, чем использовать root.
Установка PHP и расширений под WordPress
WordPress корректнее всего работает с современными версиями PHP. На Ubuntu 22.04 по умолчанию может быть PHP 8.1. Можно и 8.2, если репозиторий доступен.
Базовый набор модулей:
«`bash sudo apt install -y php-fpm php-mysql php-xml php-mbstring php-curl php-gd php-intl php-zip php-imagick «`
Если Imagick не нужен для твоих задач, можно не ставить. Но многие сайты с обработкой изображений выигрывают от него.
Настройка PHP-FPM: лимиты и opcache
Открой конфиг PHP-FPM для пула www. Путь зависит от версии PHP, обычно это:
«`bash ls /etc/php/*/fpm/pool.d/ «`
Чаще всего редактируют /etc/php/8.1/fpm/pool.d/www.conf (замени версию).
Ключевые параметры:
- listen: обычно лучше оставить unix-сокет
- pm: режим пула
- pm.max_children: лимит процессов
- php-fpm slowlog: помогает видеть узкие места
Типовой пример для умеренной нагрузки:
«`ini pm = dynamic pm.max_children = 20 pm.start_servers = 4 pm.minspareservers = 2 pm.maxspareservers = 6 requestterminatetimeout = 60s «`
Теперь opcache. Создай или проверь файл:
«`bash sudo nano /etc/php/8.1/fpm/conf.d/10-opcache.ini «`
Пример настройки:
«`ini opcache.enable=1 opcache.enable_cli=0 opcache.memory_consumption=128 opcache.maxacceleratedfiles=100000 opcache.validate_timestamps=1 opcache.revalidate_freq=2 «`
Для продакшена часто validate_timestamps можно держать включённым на короткий интервал. Если сайт на активной разработке, это спасает от ситуации “изменения не видны”.
После правок:
«`bash sudo systemctl restart php*-fpm 2>/dev/null || true sudo systemctl restart nginx «`
Первичная конфигурация Nginx для WordPress
Базовый server block для HTTP
Создай конфигурацию сайта:
«`bash sudo nano /etc/nginx/sites-available/example.com «`
Пример для HTTP (потом добавим HTTPS):
«`nginx server { listen 80; listen [::]:80; server_name example.com www.example.com;
root /var/www/example.com/public; index index.php index.html;
clientmaxbody_size 50m;
access_log /var/log/nginx/example.com-access.log; error_log /var/log/nginx/example.com-error.log;
location / { try_files $uri $uri/ /index.php?$args; }
location ~ \.php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.1-fpm.sock; fastcgiparam SCRIPTFILENAME $documentroot$fastcgiscript_name; include fastcgi_params; }
location ~* \.(js|css|png|jpg|jpeg|gif|ico|svg|woff|woff2|ttf|eot)$ { expires 30d; access_log off; add_header Cache-Control «public, max-age=2592000, immutable»; }
location ~* \.(zip|gz|tar|tgz|rar)$ { expires 7d; access_log off; add_header Cache-Control «public, max-age=604800»; } } «`
Важно: путь к сокету fastcgi_pass может отличаться. Узнать можно так:
«`bash ls /run/php/ «`
Включи конфиг:
«`bash sudo ln -s /etc/nginx/sites-available/example.com /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx «`
Права на каталог сайта
WordPress обычно кладут в /var/www/example.com/public. Создай папку и дай нужные права:
«`bash sudo mkdir -p /var/www/example.com/public sudo chown -R www-data:www-data /var/www/example.com/public «`
Если ты будешь загружать файлы через FTP/SFTP под другим пользователем, лучше сразу продумать права, чтобы не появлялись ошибки записи в wp-content.
Установка WordPress в подготовленную структуру
Скачай WordPress и распакуй:
«`bash sudo apt install -y unzip curl cd /var/www/example.com/public curl -O https://wordpress.org/latest.zip unzip latest.zip rm latest.zip sudo chown -R www-data:www-data /var/www/example.com/public «`
Дальше в браузере запусти мастер установки, укажи:
- адрес базы данных
- пользователя и пароль
- префикс таблиц (по умолчанию ок, если нет требований по безопасности)
SSL для WordPress: Let’s Encrypt и безопасные редиректы
Установка certbot и выпуск сертификата
Установи certbot для Nginx:
«`bash sudo apt install -y certbot python3-certbot-nginx «`
Выпусти сертификат:
«`bash sudo certbot —nginx -d example.com -d www.example.com «`
Certbot обычно сам внесёт нужные правила в Nginx и создаст HTTPS server block. Если ты планируешь полностью контролировать конфиг вручную, можно использовать режим с —certonly, но для большинства задач автоматизация удобнее.
Проверь автообновление сертификата:
«`bash sudo systemctl list-timers | grep certbot «`
HTTPS server block: минимальные требования к конфигу
Если certbot уже всё сделал, можно не переписывать конфиг целиком. Но понимание параметров важно.
В HTTPS сервере должны быть:
- корректный root и location блоки
- редирект с 80 на 443
- современные заголовки безопасности
Проверить, что редирект включён, можно через браузер или curl:
«`bash curl -I https://example.com «`
HSTS и типичные ошибки SSL
Если сайтом пользуются только по HTTPS, включение HSTS иногда уместно. В Nginx добавь в HTTPS server block:
«`nginx add_header Strict-Transport-Security «max-age=31536000; includeSubDomains» always; «`
Включать HSTS стоит, когда ты уверен, что HTTPS стабилен. Иначе можно “запереть” пользователей на неправильный режим, пока браузер не обновит кеш.
Типичные ошибки при Let’s Encrypt:
- домен не указывает на IP VPS (DNS не обновился)
- закрыт 80/443 порт (firewall мешает валидации)
- сайт отдаёт не то содержимое на момент проверки
Почини это до усиления конфигов. SSL — как фундамент: пока не выровнен, остальные стройки бессмысленны.
Кеширование на уровне Nginx и PHP: чтобы страницы отдавались быстрее
Кеширование можно строить слоями. На практике чаще всего дают результат:
- gzip и корректные заголовки на статику
- FastCGI cache в Nginx для страниц WordPress
- opcache для PHP
- объектный кеш (например, Redis) для ускорения запросов из WordPress
Начнём с тех вещей, которые проще и дают быстрый эффект.
Gzip и корректные заголовки
Убедись, что gzip включён. Файл может быть /etc/nginx/nginx.conf или отдельный include. Пример фрагмента:
«`nginx gzip on; gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript; gzipminlength 1024; gzipcomplevel 5; «`
Статика в конфиге выше уже получила expires и Cache-Control. Это помогает браузерам не запрашивать одно и то же по многу раз.
FastCGI cache для WordPress
FastCGI cache — это кеш ответов PHP-FPM на стороне Nginx. Для WordPress он полезен, когда:
- сайт имеет много контента, который редко меняется
- у тебя нет строгих требований к “мгновенному отображению” изменений для каждого пользователя
- ты аккуратно исключаешь страницы, которые нельзя кэшировать
Создай директорию под кеш и настрой параметры:
«`bash sudo mkdir -p /var/cache/nginx/fastcgi_cache sudo chown -R www-data:www-data /var/cache/nginx «`
Теперь добавь в server block для HTTPS (или HTTP, но лучше для HTTPS) фрагмент. Пример, который обычно работает:
«`nginx
fastcgi_cache_path /var/cache/nginx/fastcgi_cache
levels=1:2
keys_zone=WORDPRESS:100m
inactive=60m
use_temp_path=off;
map $http_cookie $skip_cache {
default 0;
«~*(comment_author|wordpress_logged_in|wp-postpass|wordpress_sec)» 1;
}
map $request_method $skip_cache_method {
default 1;
GET 0;
HEAD 0;
}
Внутри server {}:
set $no_cache 0;
if ($skip_cache = 1) {
set $no_cache 1;
}
if ($skip_cache_method = 1) {
set $no_cache 1;
}
location ~ .php$ {
include snippets/fastcgi-php.conf;
fastcgi_pass unix:/run/php/php8.1-fpm.sock;
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
include fastcgi_params;
fastcgi_buffers 16 16k;
fastcgi_buffer_size 32k;
fastcgi_cache WORDPRESS;
fastcgi_cache_bypass $no_cache;
fastcgi_no_cache $no_cache;
fastcgi_cache_valid 200 301 302 1h;
fastcgi_cache_valid 404 1m;
add_header X-FastCGI-Cache $upstream_cache_status always;}
Пара важных замечаний:
- логика исключений зависит от того, какие плагины ты используешь (комментарии, формы входа, корзина)
- если на сайте есть динамика для разных ролей, часть страниц нужно обходить кешом
- для мультиязычных сайтов ключи кеша могут требовать учёта параметров языка
После внесения изменений:
«`bash sudo nginx -t sudo systemctl reload nginx «`
Как понять, что FastCGI cache реально работает
Сделай запрос и посмотри заголовок. В конфиге выше добавлен X-FastCGI-Cache.
«`bash curl -s -D — https://example.com/ | head «`
Ожидаемые статусы:
- HIT: ответ взят из кеша
- MISS: ответ пересчитан
- BYPASS: кеш пропущен правилами
Если всегда MISS, проверь:
- нет ли ошибок в include fastcgi_params
- не настроены ли правила для skip_cache
- не отдается ли в ответах код, который кеш не хранит (например, 403/500)
Кеширование на уровне WordPress: Redis и объектный кеш
FastCGI cache ускоряет выдачу страниц. Но WordPress тратит время ещё и на “кучу маленьких операций”: выборки опций, метаданных, трансляция языков, расчёт запросов для тем. Это ускоряет объектный кеш в памяти.
Самый распространённый вариант на VPS — Redis.
Установка Redis и подключение
Установи Redis:
«`bash sudo apt install -y redis-server sudo systemctl enable redis-server sudo systemctl start redis-server «`
Дальше нужен PHP-клиент для Redis. Ставь расширение:
«`bash sudo apt install -y php-redis sudo systemctl restart php*-fpm 2>/dev/null || true «`
Проверь, что PHP видит расширение (на уровне CLI):
«`bash php -m | grep redis «`
Настройка Redis в WordPress через wp-config.php
Объектный кеш можно подключить и без сложных плагинов, если ты контролируешь конфигурацию и знаешь, что делаешь. Часто используют plugin “Redis Object Cache”, потому что он сам подхватывает параметры. Если нужен вариант на уровне кода, пример идей такой:
- включить кеш для редис-инстанса
- настроить префикс
- установить порт/хост
Минимально убедись, что Redis доступен по сокету или через TCP. Например, localhost:6379 обычно ок.
Если используешь плагин, следуй его настройкам: он подстроит параметры под твою версию WordPress.
Что именно кешировать и что не стоит
Объектный кеш ускоряет чтение данных. Но он не отменяет необходимость кешировать страницы. Работает комбинация:
- FastCGI cache держит готовые HTML
- Redis держит данные, которые WordPress постоянно читает во время сборки страницы
Не пытайся “кешировать всё подряд”. По логике многие данные завязаны на пользователях: корзина, покупки, личные кабинеты, результаты поиска. Их лучше исключить из кэширования на странице и/или ограничить объём объектного кеша.
Для проверки можно смотреть, меняется ли заголовок X-FastCGI-Cache от страницы к странице при разных состояниях: залогинен/не залогинен, есть cookie/нет cookie.
Клиентское кеширование и фронтенд-подготовка
Даже идеальный серверный кеш можно “сломать” медленными фронтенд-запросами. Поэтому стоит добить базу: статика, заголовки и размер ответов.
Cache-Control для статики: практическая схема
Для статических файлов (CSS/JS/шрифты/картинки) логика такая:
- файлы с уникальными именами (с хешем в имени) можно кэшировать дольше
- файлы без хеша (например, styles.css) — кэшировать осторожно
Если в твоём шаблоне статике имена не хешируются, лучше не ставить immutable, иначе обновления могут приезжать к пользователям только после того, как они обновят кеш.
В конфиге Nginx выше используется immutable для распространённых файлов. Если в проекте таких гарантий нет, убери immutable или сократи max-age.
Вариант с CDN
Если аудитория географически распределена, CDN может дать заметный прирост без сложных правок в WordPress. CDN обычно берёт на себя:
- отдачу статических файлов
- сжатие
- иногда агрегацию и минимизацию
Но CDN не отменяет FastCGI и Redis. Он дополняет: пока один слой ускоряет “тяжёлую” часть, другой слой ускоряет “лёгкую” статику.
Проверка скорости и диагностика проблем
Быстрая проверка ответов и заголовков
Проверь, какие заголовки отдаёт Nginx:
«`bash curl -I https://example.com/ «`
Смотри на:
- Content-Type
- Cache-Control для статики (для HTML часто другое)
- X-FastCGI-Cache (если FastCGI включён)
Для статики проверяй отдельно, например:
«`bash curl -I https://example.com/wp-content/uploads/2024/01/image.jpg «`
Если видишь, что браузер продолжает перезагружать один и тот же файл, значит настройки expires/Cache-Control либо не применяются, либо файлы без нужных имён.
Логи Nginx и php-fpm: что искать при сбоях
Когда что-то не работает, обычно причина видна в логах.
Nginx:
- /var/log/nginx/example.com-error.log
- /var/log/nginx/example.com-access.log
PHP-FPM: открой slowlog, если включал. Если медленно — можно увидеть трассу. Даже без медленных запросов полезно посмотреть error logs php-fpm пула.
Также проверь права на каталог wp-content. Ошибки записи часто проявляются как “не обновляются плагины” или “не загружаются файлы”.
Частые ошибки при включении кеширования
1. Ошибки логина/админки после включения FastCGI
Обычно это происходит, когда правила skip_cache не исключили cookie, связанные с авторизацией, или исключения срабатывают неправильно. Решение: расширить список исключений по cookie и методам, и убедиться, что залогиненный пользователь не получает закешированную HTML-версию.
2. 404 для страниц с ЧПУ
Если tryfiles настроен неправильно, WordPress permalinks могут возвращать 404. Проверь блок location / в Nginx и наличие tryfiles $uri $uri/ /index.php?$args.
3. Слишком частые перегенерации
Если кеш всегда MISS, убедись, что:
- сервер отдаёт коды, которые ты разрешил кешировать
- нет строгих ограничений, которые обходят кеш
- не включены плагины, которые подменяют ответы или всегда добавляют cookie
4. “Кеш не очищается” после изменений
FastCGI cache и объектный кеш живут по времени. В WordPress обычно есть механизмы очистки, но зависит от интеграции. Если у тебя есть процесс релизов, удобно иметь команду очистки кеша на уровне Nginx и Redis после обновлений.
Пакетный чек-лист перед запуском
- Проверены базовые компоненты: Nginx работает, PHP-FPM отвечает, база подключается из WordPress
- DNS настроен: домен указывает на IP VPS
- SSL выдан Let’s Encrypt и продлится автоматически
- Включены редиректы с HTTP на HTTPS
- В Nginx корректно настроены:
- try_files для WordPress
- fastcgi_pass на правильный сокет PHP-FPM
- обработка статики с Cache-Control и expires
- Включён opcache в PHP
- Включён FastCGI cache в Nginx с корректными bypass/exclude правилами
- Включён объектный кеш (Redis) и он реально активен для WordPress
- Проверены заголовки ответов:
- есть ли X-FastCGI-Cache
- корректные Cache-Control для статики
- Логи Nginx и php-fpm готовы к диагностике (пути известны, конфиг протестирован nginx -t)
Заключение
Настройка WordPress на VPS в связке Nginx + SSL + кеширование даёт наибольший эффект, когда ты выстраиваешь систему слоями: FastCGI cache ускоряет выдачу страниц, opcache ускоряет PHP, Redis ускоряет чтение данных из WordPress, а корректные Cache-Control и gzip уменьшают время загрузки в браузере.
Если хочешь быстро проверить результат, сделай две вещи: убедись, что HTTPS стабилен (curl -I и лог ошибок пустой), и убедись, что X-FastCGI-Cache переходит в HIT на повторных запросах к одной и той же странице при одинаковых условиях. После этого можно точечно подгонять правила обхода кеша под плагины и роли пользователей.