Как установить WordPress на Ubuntu Server: Nginx, PHP и MariaDB

Для WordPress не нужен отдельный «специальный сервер»: достаточно обычного Ubuntu Server, веб-сервера Nginx, PHP-FPM и MariaDB. В этом руководстве мы развернём чистый сайт на домене example.com, выпустим HTTPS-сертификат и пройдём путь от пустого сервера до страницы входа в админку.

Инструкция рассчитана на сервер с публичным IP-адресом и доступом по SSH. Команды установки выполняются от пользователя с правами sudo. Если вы подключились к серверу под root, уберите sudo из команд.

Что понадобится до начала

• Ubuntu Server с актуальными обновлениями.
• Домен, который указывает на публичный IP сервера. Для example.com и www.example.com должны быть настроены соответствующие DNS-записи.
• Доступ к серверу по SSH.
• Понимание, что база и сайт будут созданы с нуля. Перенос готового WordPress из резервной копии рассмотрен отдельно в конце.

У WordPress есть минимальные требования к PHP, базе данных и HTTPS; конкретные версии зависят от текущего выпуска Ubuntu. Пакеты ниже устанавливаются из репозитория вашей системы, поэтому сначала проверьте, какую версию PHP она предлагает.

1. Обновляем Ubuntu и устанавливаем компоненты

Обновите индекс пакетов и установленные компоненты, затем установите Nginx, MariaDB, PHP-FPM и расширения PHP, которые понадобятся WordPress и популярным плагинам:

sudo apt update
sudo apt upgrade -y
sudo apt install -y nginx mariadb-server php-fpm php-mysql php-curl php-gd php-mbstring php-xml php-zip php-intl php-imagick curl tar rsync

Здесь php-fpm запускает PHP отдельно от Nginx, а php-mysql даёт PHP возможность работать с MariaDB. GD и Imagick отвечают за обработку изображений. Если пакет не найден, проверьте версию Ubuntu и подключённые репозитории, а не устанавливайте случайные пакеты с незнакомых сайтов.

Посмотрите версию PHP и имя сокета PHP-FPM:

php -v
ls -l /run/php/

В дальнейшей конфигурации Nginx путь к сокету показан для PHP 8.5: /run/php/php8.5-fpm.sock. На другом выпуске Ubuntu имя может отличаться. Используйте имя файла, которое действительно выводит команда ls.

2. Настраиваем DNS и межсетевой экран

До выпуска сертификата домен должен открываться снаружи: записи A для корневого домена и www должны указывать на IP сервера. Если настроена запись AAAA, сервер также должен быть доступен по IPv6; неверную запись лучше исправить у DNS-провайдера.

Перед включением UFW разрешите SSH и веб-трафик:

sudo ufw allow OpenSSH
sudo ufw allow 'Nginx Full'
sudo ufw status
sudo ufw enable

Если SSH работает не на стандартном порту 22, заранее добавьте правило для своего порта, например sudo ufw allow 2222/tcp. Иначе включение firewall может оборвать доступ к серверу. Профиль Nginx Full открывает HTTP и HTTPS — порты 80 и 443. MariaDB наружу открывать не нужно: WordPress подключается к ней локально.

3. Создаём отдельную базу и пользователя

Для сайта лучше завести отдельную базу и отдельную учётную запись. Тогда WordPress не получит административный доступ ко всем базам сервера.

Сгенерируйте длинный пароль из букв и цифр, например так:

openssl rand -hex 24

Сохраните результат в менеджере паролей. Откройте консоль MariaDB:

sudo mariadb

Выполните SQL-команды, заменив ВСТАВЬТЕ_СВОЙ_СЛУЧАЙНЫЙ_ПАРОЛЬ на сгенерированное значение:

CREATE DATABASE wordpress_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
CREATE USER 'wp_user'@'localhost' IDENTIFIED BY 'ВСТАВЬТЕ_СВОЙ_СЛУЧАЙНЫЙ_ПАРОЛЬ';
GRANT ALL PRIVILEGES ON wordpress_db.* TO 'wp_user'@'localhost';
FLUSH PRIVILEGES;
EXIT;

Звёздочка в wordpress_db.* относится только к таблицам этой базы. Не выдавайте пользователю WordPress глобальные привилегии и не используйте для сайта пароль администратора MariaDB.

Проверьте вход под новой учётной записью. Ключ -p попросит пароль интерактивно, поэтому он не попадёт в историю команд в открытом виде:

mariadb -u wp_user -p wordpress_db

Введите пароль, выполните SHOW TABLES; и выйдите командой EXIT;. Пустая база покажет, что соединение работает, а таблиц пока нет.

4. Загружаем файлы WordPress

Создайте корневой каталог сайта и скачайте архив WordPress с официального домена проекта:

sudo mkdir -p /var/www/example.com
cd /tmp
curl -fsSLO https://wordpress.org/latest.tar.gz
tar -xzf latest.tar.gz
sudo rsync -a wordpress/ /var/www/example.com/

Проверьте, что файлы лежат прямо в /var/www/example.com, а не во вложенной папке /var/www/example.com/wordpress:

ls -l /var/www/example.com/index.php

Назначьте владельцем файлов системного пользователя, от которого работает PHP-FPM, и выставьте базовые права:

sudo chown -R www-data:www-data /var/www/example.com
sudo find /var/www/example.com -type d -exec chmod 755 {} \;
sudo find /var/www/example.com -type f -exec chmod 644 {} \;

Права 755 для каталогов и 644 для файлов дают веб-серверу возможность читать сайт, не делая файлы общедоступными для записи. Не используйте chmod -R 777.

5. Сначала запускаем сайт по HTTP

На этом шаге сертификата ещё нет, поэтому сначала создайте HTTP-конфигурацию. Откройте новый файл:

sudo nano /etc/nginx/sites-available/example.com.conf

Вставьте конфигурацию. Замените домены и, если нужно, путь к сокету PHP-FPM:

server {
    listen 80;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.php index.html;
    client_max_body_size 32M;

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

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.5-fpm.sock;
    }

    location = /wp-config.php {
        deny all;
    }
}

try_files передаёт WordPress запросы к страницам, которых нет отдельными файлами, поэтому работают постоянные ссылки. Директива client_max_body_size 32M задаёт максимальный размер тела запроса в Nginx. Стандартный лимит Nginx — 1 МБ; если загрузить больше, запрос будет отклонён ещё до PHP. Отдельный блок запрещает получать wp-config.php напрямую по HTTP.

Активируйте конфигурацию символической ссылкой, проверьте её и перезагрузите Nginx:

sudo ln -s /etc/nginx/sites-available/example.com.conf /etc/nginx/sites-enabled/example.com.conf
sudo nginx -t
sudo systemctl reload nginx

Если команда ln сообщает, что файл уже существует, не удаляйте ссылку вслепую: проверьте, куда она ведёт, командой ls -l /etc/nginx/sites-enabled/. При ошибке nginx -t исправьте конфиг и не выполняйте перезагрузку до успешной проверки.

6. Выпускаем HTTPS-сертификат

Когда домен уже указывает на сервер, а сайт отвечает по HTTP, установите Certbot с модулем для Nginx и запросите сертификат для обоих имён:

sudo apt install -y certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

Следуйте подсказкам Certbot. Если предложено перенаправлять HTTP на HTTPS, выберите перенаправление. Certbot проверяет владение доменом и обновляет конфигурацию Nginx, добавляя пути к сертификату. Если проверка не проходит, сначала проверьте DNS, доступность порта 80 и отсутствие блокировки со стороны внешнего firewall у хостинг-провайдера.

После успешного выпуска приведите конфигурацию к такому виду. В примере оставлен сокет PHP 8.5; укажите фактический путь из /run/php/. Пути сертификатов должны соответствовать домену, для которого Certbot выпустил сертификат.

server {
    listen 443 ssl;
    server_name example.com www.example.com;

    root /var/www/example.com;
    index index.php index.html;
    client_max_body_size 32M;

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

    location ~ \.php$ {
        include snippets/fastcgi-php.conf;
        fastcgi_pass unix:/run/php/php8.5-fpm.sock;
    }

    location = /wp-config.php {
        deny all;
    }

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;
    ssl_dhparam /etc/letsencrypt/ssl-dhparams.pem;
}

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Это итоговый вариант для одного сайта: HTTPS обслуживается первым блоком, второй перенаправляет HTTP на HTTPS. Если Certbot создал собственную конфигурацию, не заменяйте её целиком вслепую — сравните блоки и сохраните другие настройки, добавив нужные директивы в существующий серверный блок.

Проверьте синтаксис и перезагрузите Nginx только при успешной проверке:

sudo nginx -t && sudo systemctl reload nginx
sudo certbot renew --dry-run

7. Создаём конфигурацию WordPress

Создайте файл настроек из шаблона:

cd /var/www/example.com
sudo cp wp-config-sample.php wp-config.php
sudo nano wp-config.php

Найдите параметры базы и замените значения на свои:

define( 'DB_NAME', 'wordpress_db' );
define( 'DB_USER', 'wp_user' );
define( 'DB_PASSWORD', 'ВСТАВЬТЕ_СВОЙ_СЛУЧАЙНЫЙ_ПАРОЛЬ' );
define( 'DB_HOST', 'localhost' );

Вместо строки-заполнителя вставьте тот же пароль, который задали при создании пользователя MariaDB. Не публикуйте его в статье, скриншоте терминала, Git-репозитории или команде, где пароль виден в списке процессов.

В этом же файле замените стандартные ключи и соли авторизации. Их задача — сделать куки входа непредсказуемыми. Можно получить новый набор командой:

curl -fsS https://api.wordpress.org/secret-key/1.1/salt/

Скопируйте выведенные определения вместо соответствующего блока ключей в wp-config.php. Затем ограничьте доступ к файлу настроек:

sudo chown www-data:www-data /var/www/example.com/wp-config.php
sudo chmod 640 /var/www/example.com/wp-config.php

8. Завершаем установку в браузере

Откройте https://example.com. Мастер установки попросит выбрать язык, указать название сайта и создать первого администратора WordPress. Используйте отдельный длинный пароль и уникальное имя пользователя; не называйте администратора admin, если можно выбрать другое имя. Email нужен для системных уведомлений и восстановления доступа.

После входа в админку откройте Настройки → Постоянные ссылки и выберите подходящий формат URL. Nginx не читает .htaccess, поэтому правила красивых ссылок должны находиться в конфигурации сервера. Приведённая выше директива try_files передаёт такие запросы WordPress.

9. Проверяем, что всё запущено

Узнайте имя службы PHP-FPM и проверьте состояние компонентов:

systemctl list-units --type=service 'php*-fpm.service'
systemctl is-active nginx mariadb
sudo nginx -t
curl -I https://example.com
mariadb -u wp_user -p wordpress_db -e "SHOW TABLES;"

Для установленного PHP выполните systemctl is-active php8.5-fpm, заменив 8.5 на свою версию. После завершения веб-установки запрос SHOW TABLES должен показать созданные WordPress таблицы. Ответ curl со статусом 200 или перенаправлением на HTTPS означает, что домен отвечает; ошибку нужно разбирать по журналам Nginx и PHP-FPM.

Если не загружаются большие изображения

Размер файла ограничивается сразу в нескольких местах. Nginx должен принять запрос, PHP — принять файл и весь POST-запрос, а WordPress — суметь обработать картинку. Для файлов до 32 МБ пример выше задаёт client_max_body_size 32M. В конфигурации PHP-FPM можно установить согласованные значения:

upload_max_filesize = 32M
post_max_size = 40M
memory_limit = 256M
max_execution_time = 120
max_input_time = 120

Изменяйте /etc/php/ВЕРСИЯ/fpm/php.ini, а не только CLI-файл PHP. Значение post_max_size должно быть выше upload_max_filesize; лимит Nginx тоже должен быть не ниже размера файла вместе с POST-данными. После изменения PHP-FPM перезапустите именно свою службу, например sudo systemctl restart php8.5-fpm. Затем повторно проверьте фактические лимиты через информацию о PHP-FPM или инструмент «Здоровье сайта» в WordPress.

Не повышайте число PHP-FPM-процессов вслепую. Каждый процесс расходует память, а на сервере её делят PHP, MariaDB и операционная система. Если в журнале FPM есть сообщение server reached pm.max_children, сначала оцените потребление памяти и длительность запросов.

Если переносите существующий сайт

Для чистой установки импорт SQL-дампа не нужен: WordPress сам создаст таблицы при первом запуске. При переносе сначала создайте пустую базу и пользователя, затем импортируйте резервную копию:

mariadb -u wp_user -p wordpress_db < /путь/к/резервной-копии.sql

После импорта в wp-config.php укажите учётные данные именно этой базы и перенесите файлы сайта, включая wp-content/uploads. Не выполняйте импорт в действующую базу без свежей резервной копии: дамп может заменить или повредить содержимое сайта. Если домен меняется, адреса сайта внутри базы обновляют отдельной безопасной процедурой, которая корректно обрабатывает сериализованные данные WordPress.

Коротко о главном

Надёжная установка складывается из нескольких простых частей: домен смотрит на сервер, Nginx передаёт PHP-запросы в PHP-FPM, WordPress подключается к отдельной базе, а HTTPS закрывает соединение браузера с сайтом. Сначала добейтесь успешной проверки nginx -t, затем проверьте HTTP, выпустите сертификат и только после этого заканчивайте установку в браузере.