Ниже — практичный маршрут, который обычно проходит без “магии”: от подготовки VPS в Беларуси и веб-сервера до корректной выдачи сертификата и перевода WordPress на HTTPS. Подходит для типичной связки Nginx + MariaDB + PHP-FPM (LEMP).
Термины, которые дальше встретятся: VPS — виртуальный сервер; WordPress — CMS; HTTPS — защищённый протокол с сертификатом (часто Let’s Encrypt); домен — имя сайта, например example.by.
Подготовка VPS в Беларуси: доступ, DNS и базовая схема
Выбор ОС, пользователь и обновления
Начните с управляемого Linux-дистрибутива, где вы уверены в пакетах (часто это Ubuntu или Debian). Под WordPress критичны не “бренд ОС”, а стабильность обновлений и поддержка нужных модулей PHP.
Создайте отдельного пользователя для работы (не используйте root для ежедневных команд), затем обновите систему и включите базовые утилиты:
«`bash sudo apt update && sudo apt -y upgrade sudo apt -y install curl unzip zip ufw ca-certificates «`
Если VPS выдают без настроенного firewall, это не проблема, но его лучше включить сразу: ошибки “HTTPS не выдаётся” часто связаны с закрытым портом 80.
Домен и DNS-записи: что должно получиться в итоге
Чтобы Let’s Encrypt выдал сертификат по HTTP-01, доменное имя должно резолвиться в IP вашего VPS и быть доступным извне.
Обычно нужно:
- A-запись домена на IPv4 вашего сервера
- (опционально) AAAA-запись на IPv6, если он есть
Проверьте резолв локально и с другой сети, если есть возможность:
«`bash nslookup example.by «`
Типичная ошибка на этом шаге: домен указывает на один IP, а VPS имеет другой (например, после пересоздания). Сертификат в таком случае либо не выдастся, либо будет выдаваться “не на тот” сервер.
Firewall: открываем только нужное
Для WordPress и HTTPS обычно нужны:
- 22/tcp (SSH)
- 80/tcp (HTTP для проверки Let’s Encrypt)
- 443/tcp (HTTPS)
Если используете ufw, стартовая настройка выглядит так:
«`bash sudo ufw default deny incoming sudo ufw default allow outgoing sudo ufw allow 22/tcp sudo ufw allow 80/tcp sudo ufw allow 443/tcp sudo ufw enable sudo ufw status «`
Если вы планируете получать сертификат позже, всё равно держите 80 открытым до момента выпуска SSL. На практике закрытый 80 — одна из самых частых причин “certbot падает”.
Установка LEMP на VPS: Nginx, PHP-FPM и MariaDB для WordPress
Установка Nginx
Поставьте Nginx и убедитесь, что он слушает порт 80:
«`bash sudo apt -y install nginx sudo systemctl enable nginx —now sudo ss -lntp | grep :80 «`
Проверьте, что сайт в принципе отвечает: временно создайте “заглушку” и откройте домен в браузере. Это нужно, чтобы понять: проблема потом в WordPress, а не в сети или конфигурации Nginx.
PHP и расширения, которые реально нужны WordPress
WordPress потребляет PHP и ряд расширений. Минимальный набор обычно включает:
- mysqli (или pdo_mysql)
- mbstring
- xml
- cURL
- zip
- gd (если планируете обработку изображений)
- opcache (для производительности)
На Ubuntu часто встречается php8.1-fpm. Если у вас другая версия, замените номер соответствующим пакетом:
«`bash sudo apt -y install php8.1-fpm php8.1-mysql php8.1-mbstring php8.1-xml php8.1-curl php8.1-zip php8.1-gd php8.1-opcache sudo systemctl enable php8.1-fpm —now sudo ss -lntp | grep :9000 «`
Nginx обычно ходит в PHP-FPM через сокет или TCP. В конфигурациях ниже будем использовать сокет, но если у вас он отличается — подправьте fastcgi_pass под вашу среду.
MariaDB: база данных и права для WordPress
Установите MariaDB, затем создайте базу и пользователя с правами только на нужную БД.
«`bash sudo apt -y install mariadb-server sudo systemctl enable mariadb —now sudo mariadb-secure-installation «`
Дальше в MariaDB выполните:
«`sql CREATE DATABASE wordpressdb CHARACTER SET utf8mb4 COLLATE utf8mb4unicode_ci; CREATE USER ‘wordpressuser’@’localhost’ IDENTIFIED BY ‘strongpassword’; GRANT ALL PRIVILEGES ON wordpressdb.* TO ‘wordpressuser’@’localhost’; FLUSH PRIVILEGES; «`
Самая частая ошибка тут: пользователь создан для localhost, а вы затем настраиваете WordPress так, будто БД доступна удалённо. Если база на том же сервере — оставляйте localhost, это безопаснее и проще.
Директория сайта и права
Для удобства дальше будем считать, что сайт лежит в /var/www/example.by. Создайте структуру:
«`bash sudo mkdir -p /var/www/example.by sudo chown -R $USER:$USER /var/www/example.by «`
После распаковки WordPress поменяйте владельца на пользователя веб-сервера (часто это www-data). Права важны: слишком “широкие” — это риск, слишком “узкие” — 403 и 500 при обновлениях плагинов.
Развёртывание WordPress: установка и wp-config.php без лишних проблем
Установка WordPress из официального архива
Скачайте свежий архив WordPress и распакуйте в директорию сайта:
«`bash cd /tmp curl -O https://wordpress.org/latest.zip unzip latest.zip sudo rsync -av wordpress/ /var/www/example.by/ «`
Затем выставьте права:
«`bash sudo chown -R www-data:www-data /var/www/example.by «`
Если ваш процесс отличается (например, вы используете не www-data), приведите владельца к вашему реальному пользователю Nginx.
Подключение базы: wp-config.php
Создайте wp-config.php на основе шаблона и подставьте данные для БД:
«`bash cd /var/www/example.by sudo cp wp-config-sample.php wp-config.php «`
Отредактируйте wp-config.php (nano, vim — как удобнее). В блоке подключения базы должны быть:
- DBNAME: wordpressdb
- DBUSER: wordpressuser
- DBPASSWORD: strongpassword
- DB_HOST: localhost
После этого можно открыть домен в браузере и завершить установку через веб-интерфейс: название сайта, логин админа, почта.
Если на шаге установки WordPress ругается на доступ к файлам, чаще всего виноваты права на директорию и файлы. Убедитесь, что Nginx может читать файлы, а WordPress при необходимости может создавать/обновлять свои файлы.
Настройки wp-config для стабильной работы
Минимально полезные определения:
- ключи безопасности WordPress (их можно сгенерировать через официальный генератор)
- корректные URL (особенно перед включением HTTPS)
- выключение отображения ошибок наружу в production
Пример безопасных ориентиров:
«`php define(‘WP_DEBUG’, false); «`
И не забывайте: время на сервере влияет на задачи по расписанию. Проверьте часовой пояс и синхронизацию NTP:
«`bash timedatectl «`
Типичные ошибки на старте и как их распознать
1. 500 Internal Server Error
Чаще всего это PHP-ошибка или неверные права/владельцы. В Nginx смотрите error_log, а в PHP-FPM — соответствующие логи.
2. 403 Forbidden
Обычно Nginx не пускает из-за root/alias путей или прав на директории. Часто помогает проверить владельца и права на /var/www/example.by и вложенные папки.
3. 502 Bad Gateway
Почти всегда проблема между Nginx и PHP-FPM: сокет не существует, fastcgi_pass неверный, PHP-FPM не запущен. Сначала проверьте systemctl status php-fpm, затем конфиг Nginx.
Настройка Nginx для WordPress: корректная конфигурация server и location
Базовый server block для WordPress
Сконфигурируйте Nginx так, чтобы он отдавал статические файлы напрямую, а PHP отправлял в PHP-FPM. Пример для /etc/nginx/sites-available/example.by.conf (путь и имя файла выбирайте по стандартам вашей системы):
«`nginx server { listen 80; listen [::]:80; server_name example.by;
root /var/www/example.by; index index.php index.html;
clientmaxbody_size 64M;
access_log /var/log/nginx/example.by.access.log; error_log /var/log/nginx/example.by.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; }
location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff2?)$ { expires 30d; access_log off; }
location = /favicon.ico { accesslog off; lognot_found off; }
location = /robots.txt { accesslog off; lognot_found off; } } «`
Важно: fastcgi_pass должен указывать на ваш реальный сокет. Если в системе сокет отличается, получите 502. Быстро проверить можно так:
«`bash ls -l /run/php/ | grep fpm «`
Дальше включите конфиг и проверьте синтаксис:
«`bash sudo ln -s /etc/nginx/sites-available/example.by.conf /etc/nginx/sites-enabled/ sudo nginx -t sudo systemctl reload nginx «`
Ограничения, которые избавляют от “странных” падений
WordPress иногда загружает изображения, плагины и темы. Если clientmaxbody_size слишком мал, при загрузке появятся ошибки формы. 64M — рабочий уровень для большинства сценариев, но если у вас большие файлы, поднимайте с учётом ресурсов VPS и ограничений хостинга.
Также имеет смысл ограничить доступ к чувствительным файлам и отключить выполнение PHP в папках кэша и загрузок. Однако аккуратно: некоторые плагины и сценарии могут хранить php в нестандартных директориях. Делайте это точечно, когда понимаете, что именно защищаете.
Gzip и базовый кэш: где грань между полезно и сломано
Включение gzip обычно не мешает. Но агрессивные кэши для WordPress могут приводить к “старым” страницам или конфликтовать с плагинами. На старте ограничьтесь корректной компрессией и короткими expires для статики (как в примере выше).
Если позже подключите кэширование (например, через плагин), включайте его по инструкции самого плагина и тестируйте: после очистки кэша сайт должен обновляться мгновенно.
HTTPS для WordPress: Let’s Encrypt, редиректы и перевод в WordPress без циклов
Let’s Encrypt на VPS в Беларуси: получение сертификата по HTTP-01
Наиболее простой путь без ручной возни — использовать certbot и режим для Nginx. Установите certbot:
«`bash sudo apt -y install certbot python3-certbot-nginx «`
Убедитесь, что Nginx доступен извне по 80 (firewall открыт, домен указывает верно). Затем выполните:
«`bash sudo certbot —nginx -d example.by «`
Если всё правильно, certbot сам поправит конфигурацию Nginx и добавит listen 443 + сертификаты.
Если certbot ругается на невозможность проверить домен, почти всегда причина одна из трёх:
- DNS не совпадает с IP VPS
- порт 80 закрыт или блокируется
- Nginx не слушает 80 для этого server_name
Проверка сертификата и цепочки
Даже когда certbot “успешен”, стоит быстро проверить, что цепочка корректная и браузер не показывает предупреждения.
Проверка через openssl:
«`bash echo | openssl s_client -connect example.by:443 -servername example.by 2>/dev/null | grep -E «subject=|issuer=|Verify» «`
Если видите ошибки проверки или предупреждения в браузере, иногда помогает повторный выпуск или убедиться, что нужные файлы сертификата подключены в конфиг.
Включение HTTPS в WordPress: home и siteurl
После выдачи сертификата сайт может быть доступен по https, но WordPress продолжит генерировать ссылки на http. Это приведёт к смешанному контенту и нестабильной работе некоторых страниц.
Есть три подхода:
1. Ручная правка wp-config.php через WPHOME и WPSITEURL
Это удобно, если вы хотите жёстко закрепить URL.
2. Обновление параметров в базе данных (siteurl и home)
Подходит, но легче ошибиться, если нет бэкапа.
3. WP-CLI (если вы его настроили)
Быстро и повторяемо.
Если WPHOME/WPSITEURL хотите в wp-config.php, добавьте до строки, где определяется абсолютный путь, пример логики:
«`php define(‘WP_HOME’, ‘https://example.by’); define(‘WP_SITEURL’, ‘https://example.by’); «`
После этого обновите WordPress админку, проверьте, что редиректы не прыгают между http и https.
Устранение проблем после включения HTTPS
1. Редирект-цикл (слишком много переадресаций)
Почти всегда причина: siteurl/home не совпали с тем, что отдаёт Nginx, или в цепочке есть лишние редиректы. Временно переключите всё на один источник истины: либо параметры WordPress, либо настройки Nginx, и уберите дубли.
2. Ошибки в админке, но сайт открывается
Часто админка загружается по https, но в базе по-прежнему http, или браузер кеширует старые редиректы. Очистите кэш браузера, проверьте siteurl/home, и убедитесь, что переменная HTTPS правильно распознаётся Nginx (fastcgi_param по умолчанию обычно ок).
3. Mixed content (часть ресурсов остаётся http)
Ищите ссылки на изображения/скрипты, которые WordPress продолжает выдавать как http. Полезный метод: проверить исходный HTML страницы и найти источник. Иногда это следствие старых записей, а иногда — настройка конкретного плагина.
Безопасность и эксплуатация: что сделать на VPS в Беларуси после запуска
Права, обновления и минимизация поверхности
Держите систему и компоненты обновлёнными: пакеты, Nginx, PHP, MariaDB. WordPress тоже обновляйте регулярно, но делайте это после бэкапа.
Не храните админку на “случайном” совпадении. Настройте:
- длинный пароль администратора
- двухфакторную аутентификацию (если поддерживается вашим набором)
- смену логина админа (если вы понимаете последствия для старых авторов и ролей)
Проверьте, что в директории сайта нет лишних прав на запись для “чужих” пользователей. Владелец файлов и владелец процесса PHP-FPM должны совпадать по логике: обычно www-data для обоих в LEMP.
Бэкапы: делайте не “по плану”, а так, чтобы можно было восстановить
Бэкап — это не файл “в облаке”, а гарантированное восстановление. Минимальный набор: бэкап базы MariaDB и бэкап директории wp-content (иногда и всего сайта).
Хорошая практика:
- делать регулярные дампы БД
- архивировать wp-content
- хранить бэкапы отдельно от VPS (S3/другой сервер/репозиторий)
- тестировать восстановление раз в период (хотя бы на тестовом VPS или в контейнере)
Если вы используете плагин бэкапа, всё равно держите “нижний уровень” в виде дампа БД. Плагин может перестать работать из-за повреждения файлов или конфликтов после обновления.
Логи и мониторинг: что смотреть при проблемах
Два главных файла для старта — accesslog и errorlog Nginx. По ним можно быстро понять: PHP не работает, отдача статических файлов сломалась или Nginx неверно обрабатывает запросы.
Дополнительно полезно:
- логи php-fpm
- журнал systemd для php-fpm и nginx
- метрики загрузки VPS (CPU, RAM, диски), чтобы понимать, где “узкое место”
Команды, которые обычно помогают: «`bash sudo tail -n 200 /var/log/nginx/example.by.error.log sudo systemctl status nginx php8.1-fpm «`
Производительность: OPcache, статическая оптимизация и CDN
Для WordPress на VPS основной выигрыш часто дают:
- OPcache в PHP
- корректная настройка заголовков для статики
- сжатие (gzip)
- CDN для изображений и статических ресурсов, если ваш трафик разный по регионам
OPcache включается через параметры php.ini или отдельный конфиг. Убедитесь, что он не конфликтует с вашим стилем деплоя: при обновлениях PHP-кода важно, чтобы кэш обновлялся.
Чек-лист перед запуском и контроль после включения HTTPS
Перед тем как считать настройку WordPress завершённой
Проверьте по пунктам:
- Домен резолвится на IP VPS
- Nginx отдаёт главную страницу по http без ошибок
- WordPress установился и подключился к MariaDB
- wp-config.php содержит корректные данные БД
- PHP-FPM работает, 502 отсутствуют
- Загрузки изображений и файлов не падают по лимитам
Если хотя бы один пункт “не проходит”, не переходите дальше к HTTPS. Иначе вы потратите время на поиск SSL-ошибки, которая на самом деле была HTTP/права/fastcgi.
После выдачи сертификата и включения HTTPS
Дальше проверьте:
- сайт открывается по https без предупреждений браузера
- редирект с http на https работает один раз и не зацикливается
- WordPress генерирует https-ссылки (home/siteurl совпали)
- нет mixed content (в консоли браузера по странице)
- админка открывается по https и корректно загружает ресурсы
И обязательно проверьте автоматическое продление сертификата. Certbot обычно добавляет systemd timer, но убедиться не помешает:
«`bash systemctl list-timers | grep certbot «`
Итог: как довести WordPress на VPS в Беларуси до HTTPS без ошибок
Большинство проблем при настройке WordPress на VPS связано не с “редкими багами”, а с предсказуемыми расхождениями: DNS не совпал с IP, закрыт порт 80, fastcgi_pass указан неправильно, siteurl/home не перевели на https, а в итоге получаются редирект-циклы или смешанный контент.
Пройдите путь в указанной последовательности: сначала Nginx и WordPress в http, затем HTTPS через Let’s Encrypt, и только после этого закрепляйте URL в WordPress. Такой порядок экономит время и делает результат воспроизводимым. Если хотите, напишите вашу ОС (Ubuntu/Debian и версию), используете ли Nginx или Apache, и есть ли IPv6 — подстрою команды под вашу конкретику.