Интеграция WordPress с Nginx и MariaDB на Ubuntu 24.04: от базы данных до SSL

Содержание

Переходим от установки компонентов к их интеграции: в этой статье настраиваем связку Nginx-PHP-FPM для обработки запросов, создаём защищённую БД для WordPress, автоматизируем получение SSL и завершаем настройку в админ-панели.

Работаем на примере обычного VPS с root‑доступом, возможностью редактировать конфигурации вручную и гибкой настройкой под конкретные задачи сайта.

Аренда VPS/VDS от 219 руб/месяц

Преимущества VPS в AdminVPS:

✓ Бесплатное администрирование

✓ Только быстрые NVMe-диски

✓ Защита от DDoS-атак

✓ Быстрая техподдержка

Аренда VPS/VDS виртуального сервера от AdminVPS — это прозрачная и честная услуга с доступной ценой

Настройка базы данных для WordPress

Пришло время превратить голую СУБД в рабочую базу для WordPress. Начнём с mysql_secure_installation — скрипта, который проведёт базовую настройку безопасности.

Запустите его:

sudo mysql_secure_installation

Запустится интерактивный диалог. Первым делом скрипт предложит настроить валидацию паролей через плагин cracklib — ответьте Y, если хотите автоматически блокировать слабые пароли, такие как «123456» или «qwerty». Далее задайте пароль для root-пользователя (этот пароль понадобится только для администрирования СУБД, он не для повседневной работы с WordPress).

Следующие этапы скрипта:

Удаление анонимных пользователей (выберите Y) — закрывает возможность для локального доступа без логина.
Запрет удалённого входа под root (Y) — позволяет блокировать большинство брутфорс-атак на СУБД.
Удаление тестовой БД (Y) — демо-база test часто становится мишенью хакеров.
Перезагрузка привилегий (Y) — применение изменений без перезапуска службы.

Теперь создадим пользователя для WordPress через MariaDB-консоль. Подключитесь к консоли, введя пароль, заданный на предыдущем этапе:

sudo mysql -u root -p

В консоли выполните три ключевых SQL-запроса. Первый:

CREATE DATABASE wp_db CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

Он создаёт базу с правильной кодировкой для поддержки эмодзи и всех языков. Обратите внимание на utf8mb4 вместо устаревшего utf8 — это критично для корректного хранения современного контента.

Второй запрос создаёт пользователя:

CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'пароль';

Здесь @'localhost' ограничивает подключения только с локального сервера — никогда не используйте @'%' для веб-приложений! Третий запрос выдаёт привилегии:

GRANT SELECT, INSERT, UPDATE, DELETE, CREATE, ALTER, INDEX, DROP 
ON wp_db.* TO 'wp_user'@'localhost';

Не давайте GRANT OPTION (делегирование прав) и SUPER (админ-привилегии) — все выданные привилегии должны быть минимально необходимыми. Завершите сессию командой FLUSH PRIVILEGES; и выходом exit.

Для проверки подключитесь под новым пользователем:

mysql -u wp_user -p -e "USE wp_db; SELECT 1;"

Вы должны увидеть в выводе 1 — это означает, что пользователь может подключиться к БД и выполнить простейший запрос, то есть база готова к работе с WordPress.

Если планируется масштабирование, на этом этапе стоит настроить репликацию или кластер Galera (кластерная репликация MariaDB), но для большинства сайтов достаточно standalone-конфигурации.

Создание виртуального хоста в Nginx и настройка маршрутизации

Без правильной конфигурации веб-сервер не поймёт, как обрабатывать запросы к вашему домену. Начнём с создания конфигурационного файла в директории /etc/nginx/sites-available/, где имя файла должно точно соответствовать вашему домену:

sudo nano /etc/nginx/sites-available/example.ru

Внутри файла пропишем базовую конфигурацию блока server:

server_name example.ru www.example.ru; — перечисление доменов, которые будут обслуживаться этим хостом (через пробел);
root /var/www/example.ru; — абсолютный путь к файлам WordPress;
index index.php index.html; — порядок поиска индексных файлов (важно, чтобы index.php был первым).

Обработка PHP-запросов настраивается через блок location:

location ~ \.php$ { 
    include snippets/fastcgi-php.conf; 
    fastcgi_pass unix:/var/run/php/php8.3-fpm.sock; 
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name; 
    include fastcgi_params; 
}

Убедитесь, что путь соответствует вашей версии PHP.

Важный параметр здесь:

fastcgi_pass unix:/var/run/php/php8.3-fpm.sock;

Он указывает на Unix-сокет PHP-FPM версии 8.3, через который Nginx передаёт PHP-скрипты на обработку. Проверить существование сокета можно командой:

ls /var/run/php/php8.3-fpm.sock

Для обработки постоянных ссылок WordPress (ЧПУ) добавьте:

location / { 
    try_files $uri $uri/ /index.php$is_args$args; 
}

Эта директива ищет сначала реальный файл ($uri), затем директорию ($uri/), и если ничего не найдено — передаёт запрос в index.php, сохраняя параметры запроса ($is_args$args).

Защитите системные файлы от доступа:

location ~ /\.ht { 
    deny all; 
}

Этот блок запрещает доступ ко всем файлам, начинающимся с .ht (включая .htaccess), которые могут содержать чувствительные данные.

После сохранения файла активируйте хост, создав символическую ссылку в директории sites-enabled:

sudo ln -s /etc/nginx/sites-available/example.ru /etc/nginx/sites-enabled/

Перед перезагрузкой Nginx обязательно проверьте конфигурацию:

sudo nginx -t

Если вывод показывает syntax is ok и test is successful, примените изменения:

sudo systemctl reload nginx

Nginx обрабатывает location блоки в определённом порядке:

точные совпадения (location = /path),
префиксные совпадения с ^~,
регулярные выражения (в порядке объявления),
стандартные префиксные совпадения.

Поэтому блок обработки PHP (location ~ \.php$) должен находиться после блока location / — чтобы избежать конфликта приоритетов. Если вы столкнётесь с ошибкой 404 при доступе к PHP-файлам, проверьте порядок location-блоков.

Диагностика проблем:

502 Bad Gateway — проверьте статус PHP-FPM:

systemctl status php8.3-fpm;

403 Forbidden — убедитесь, что www-data имеет права на чтение файлов:

sudo -u www-data ls -l /var/www/example.ru

домен не разрешается — временно добавьте в /etc/hosts строку:

127.0.0.1 example.ru

Первичная настройка wp-config.php

wp-config.php — связующее звено между WordPress и базой данных. Начните с копирования шаблона в корневой директории сайта:

sudo -u www-data cp /var/www/example.ru/wp-config-sample.php /var/www/example.ru/wp-config.php

Используйте www-data, чтобы сразу установить правильного владельца файла — это предотвратит ошибки доступа при работе WordPress. Права на wp-config.php могут варьироваться в зависимости от настроек сайта и требований безопасности: 400, 440, 600 или 640.

Теперь откройте файл для редактирования:

sudo nano /var/www/example.ru/wp-config.php

Нужно изменить три директивы, которые WordPress использует для подключения к базе данных:

define( 'DB_NAME', 'wp_db' );          // имя базы, созданной в MariaDB
define( 'DB_USER', 'wp_user' );        // пользователь, которого вы создали
define( 'DB_PASSWORD', 'пароль' ); // пароль из GRANT-запроса

Для дополнительной безопасности измените префикс таблиц с wp_ на уникальный вариант (в строке $table_prefix = 'wp_';), например xq7_. Это защитит от массовых SQL-инъекций, эксплуатирующих стандартный префикс.

Следующий критический этап — генерация уникальных ключей аутентификации. Эти 64-символьные строки используются для шифрования куков и защиты от CSRF-атак. Никогда не оставляйте значения по умолчанию, используйте официальный генератор WordPress:

Откройте https://api.wordpress.org/secret-key/1.1/salt/
Скопируйте весь блок с define('AUTH_KEY'...
Замените им соответствующий раздел в wp-config.php

Для автоматизации можно использовать WP-CLI:

sudo -u www-data wp config shuffle-salts

Также добавьте две важные директивы безопасности в конец файла:

define('FORCE_SSL_ADMIN', true);     // принудительный HTTPS для админки
define('DISALLOW_FILE_EDIT', true);  // отключает редактор тем/плагинов

Начиная с PHP 7.1, wp-config.php поддерживает типобезопасные константы. Вместо define('WP_DEBUG', false); можно использовать const WP_DEBUG = false;, что быстрее обрабатывается OPcache, но для совместимости с плагинами лучше придерживаться классического define().

Альтернативный метод — создание конфига через WP-CLI без ручного редактирования:

sudo -u www-data wp config create \
  --dbname=wp_db \
  --dbuser=wp_user \
  --dbpass='пароль' \
  --dbhost=localhost \
  --dbprefix=xq7_ \
  --force
sudo -u www-data wp config shuffle-salts

Проверьте работоспособность конфига (команда проверяет только синтаксис!):

sudo -u www-data php -l /var/www/example.ru/wp-config.php

Ожидаемый вывод:

No syntax errors detected

При первой загрузке сайта WordPress автоматически создаст необходимые таблицы в базе данных. Если столкнётесь с ошибкой Error establishing a database connection, то проверьте логи MariaDB:

sudo tail -f /var/log/mysql/error.log

Также убедитесь, что пользователь имеет права:

SHOW GRANTS FOR 'wp_user'@'localhost';

Проверьте корректность имени хоста; для локального сервера используйте localhost, а не 127.0.0.1. Обратите внимание, что обычно используйте localhost, если в конфигурации сервера не указано иное.

Никогда не храните резервные копии wp-config.php в публичном доступе. Этот файл содержит ключи доступа к вашей базе данных.

Установка SSL через Let’s Encrypt

Начнём с установки Certbot — официального клиента для Let's Encrypt:

sudo apt install certbot python3-certbot-nginx -y

python3-certbot-nginx — это плагин для автоматической интеграции с конфигами Nginx, без него пришлось бы вручную прописывать все SSL-директивы и перенаправления, что увеличивает риск ошибок.

Команда получения сертификата:

sudo certbot --nginx --agree-tos --email admin@example.ru -d example.ru -d www.example.ru --redirect --hsts --staple-ocsp

Опции:

--nginx указывает плагину работать с конфигами Nginx,
--agree-tos — обязательное согласие с условиями Let's Encrypt,
--email — почта администратора,
-d — домены (через пробел основной + www-версия),
--redirect — автоматическое перенаправление HTTP → HTTPS (код 301),
--hsts — включает HTTP Strict Transport Security (принудительный HTTPS на 6+ месяцев),
--staple-ocsp — активирует OCSP Stapling для быстрой проверки отзыва сертификатов.

Во время работы Certbot выполнит DNS-проверку через временный файл в /.well-known/acme-challenge/, поэтому убедитесь, что:

домен указывает на IP-адрес сервера,
порт 80 открыт в UFW,
виртуальный хост Nginx для домена активен.

После успешной генерации Certbot автоматически:

добавит SSL-директивы в конфиг Nginx,
настроит перенаправление HTTP→HTTPS,
создаст задачу для автоматического обновления сертификатов,
обновит цепочки доверия для поддержки старых устройств.

Если вы конфигурируете Nginx вручную, укажите полные пути к сертификатам:

ssl_certificate /etc/letsencrypt/live/example.ru/fullchain.pem; 
ssl_certificate_key /etc/letsencrypt/live/example.ru/privkey.pem;

Проверьте работу SSL командой:

curl -I https://example.ru

В заголовках должны присутствовать:

HTTP/2 200 
Strict-Transport-Security: max-age=31536000 
Content-Type: text/html; charset=UTF-8

Тест автоматического продления:

sudo certbot renew --dry-run

Если видите The dry run was successful, значит система настроена корректно.

Для ручной проверки срока действия:

sudo openssl x509 -in /etc/letsencrypt/live/example.ru/cert.pem -noout -dates

Альтернатива для сложных сценариев — Wildcard-сертификаты (*.example.ru):

certbot certonly --manual --preferred-challenges=dns -d *.example.ru

Но это действие требует ручного добавления DNS TXT-записи.

Мультидоменные сертификаты (SAN) — один сертификат выдаётся на несколько доменов или поддоменов:

certbot --nginx -d example.ru -d blog.example.ru -d shop.example.ru

Диагностика проблем:

Failed authorization procedure — проверьте доступность домена:

curl -I http://example.ru/.well-known/acme-challenge/test

SSL_ERROR_BAD_CERT_DOMAIN — убедитесь, что все домены перечислены после -d.

Завершение установки через веб-интерфейс

Откройте в браузере ваш домен — вы увидите стартовый экран выбора языка. WordPress автоматически определяет язык сервера, но если в Ubuntu 24.04 не установлены языковые пакеты, локализация может пройти с ошибкой. Поэтому заранее выполните команду для поддержки русского языка:

sudo apt install language-pack-ru-base

После выбора языка система перенаправит вас на экран «Добро пожаловать», где нужно ввести данные администратора:

Название сайта — используйте краткое, SEO-оптимизированное название (не более 60 символов), оно станет частью тега <title> и повлияет на ранжирование.
Логин администратора — создайте уникальное имя (ни в коем случае не admin или administrator) — это усложнит брутфорс-атаки.
Пароль — сгенерируйте сложную комбинацию через встроенный инструмент (12+ символов, включающую спецзнаки, цифры). Безопаснее хранить его в менеджере паролей, а не в браузере.
E-mail администратора — лучше, если это будет адрес на собственном домене, а не публичные сервисы.

После заполнения нажмите «Установить WordPress». Если всё настроено правильно, вы увидите сообщение об успешной установке — это означает, что WordPress:

создал 12 основных таблиц в базе данных (от wp_options до wp_comments);
сгенерировал уникальный ID сайта в таблице wp_options;
сохранил хеши паролей с использованием современного алгоритма bcrypt;
установил часовую зону из настроек PHP.

Перейдите по ссылке «Войти» и авторизуйтесь в /wp-admin. Убедитесь, что:

адресная строка показывает HTTPS (не HTTP);
в левом меню нет ошибок типа «У вас недостаточно прав»;
пункт Консоль → Обновления доступен и показывает актуальную версию.

Проведите стресс-тест:

откройте https://example.ru/wp-admin/plugins.php — должна появиться пустая таблица плагинов;
попробуйте создать черновик поста через Записи → Добавить новую;
загрузите тестовое изображение в Медиафайлы.

Если возникли проблемы:

страница не найдена — проверьте .htaccess (файл должен содержать стандартные правила WordPress):

sudo nano /var/www/example.ru/.htaccess

ошибка CSRF — добавьте в wp-config.php:

define('FORCE_SSL_ADMIN', true);

Сразу после установки удалите файл readme.html в корне сайта — он содержит информацию о версии WordPress, что упрощает атаки злоумышленникам:

sudo -u www-data rm /var/www/example.ru/readme.html

Заключение

Вы успешно настроили базовый стек WordPress на Ubuntu 24.04. Ваш сайт теперь доступен по HTTPS, а админ-панель готова к работе. В следующей статье мы перейдём к продвинутой оптимизации — настроим PHP-FPM, OPcache, Redis, защитим сайт с помощью WAF (ModSecurity), реализуем сжатие Brotli и автоматизируем резервное копирование.

Читайте в блоге: