Переходим от установки компонентов к их интеграции: в этой статье настраиваем связку Nginx-PHP-FPM для обработки запросов, создаём защищённую БД для WordPress, автоматизируем получение SSL и завершаем настройку в админ-панели.
Работаем на примере обычного VPS с root‑доступом, возможностью редактировать конфигурации вручную и гибкой настройкой под конкретные задачи сайта.
Настройка базы данных для 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 и автоматизируем резервное копирование.
Читайте в блоге:
- Ubuntu 24.04 LTS против 22.04: стоит ли обновляться
- Ansible с Ubuntu 24.04: быстрый старт автоматизации
- Настройка swap и ZRAM в Ubuntu 24.04 LTS на VPS