Настройка Nginx для WordPress: что проверить до старта

WordPress на Nginx обычно начинает работать не после одной строки в конфиге, а после проверки четырёх вещей: домен указывает на сервер, PHP-FPM слушает правильный сокет, каталог сайта доступен пользователю Nginx, а запросы без физического файла передаются в index.php. Ниже — базовая настройка для WordPress 6.x, Nginx 1.24+ и PHP 8.2 или 8.3 на Debian/Ubuntu. Если всё готово, первый рабочий ответ сайта можно получить за 20–40 минут.

Что подготовить до настройки

• Сервер с Debian или Ubuntu и доступом по SSH через учётную запись с правами sudo.
• Установленный Nginx версии 1.24 или новее.
• PHP 8.2 или 8.3 и PHP-FPM той же версии.
• Домен, A-запись которого указывает на публичный IP сервера. Для IPv6 нужна также корректная AAAA-запись.
• Распакованный WordPress в отдельный каталог, например /var/www/example.com.
• Имя PHP-сокета. На Debian и Ubuntu оно обычно выглядит как /run/php/php8.2-fpm.sock или /run/php/php8.3-fpm.sock, но проверять его нужно на конкретном сервере.

Проверьте версии и состояние служб:

nginx -v
php -v
systemctl list-units --type=service 'php*-fpm.service' --no-pager
ls -la /run/php/

Проверка: команда Nginx показывает версию не ниже 1.24, PHP — ветку 8.2 или 8.3, а в каталоге /run/php/ есть файл с расширением .sock.

Главная ошибка новичка — копировать конфигурацию с чужого сервера, не сверив путь к PHP-сокету и каталог сайта. Nginx может быть настроен правильно, но PHP всё равно не запустится.

Сноска. FastCGI — протокол, через который Nginx передаёт PHP-FPM запрос на выполнение PHP-файла и получает готовый ответ. Сам Nginx PHP-код не исполняет.

Пошаговая настройка

1. Проверьте DNS и каталог сайта. В браузере домен пока может не открываться, если DNS ещё обновляется. На сервере убедитесь, что файлы WordPress действительно лежат в выбранном каталоге:

   sudo ls -la /var/www/example.com
   sudo test -f /var/www/example.com/index.php && echo OK

   Если каталог создан с другим именем, замените путь во всех следующих командах и в конфигурации. Проверка: команда печатает OK, а в каталоге видны wp-admin, wp-content, wp-includes и index.php.

2. Проверьте пользователя веб-сервера и права. На Debian и Ubuntu Nginx и PHP-FPM часто работают от имени www-data. Каталоги должны быть доступны для чтения, а каталог загрузок — для записи. Не выдавайте всему дереву права 777:

   ps -eo user,comm | grep -E 'nginx|php-fpm' | grep -v grep
   sudo find /var/www/example.com -type d -exec chmod 755 {} \;
   sudo find /var/www/example.com -type f -exec chmod 644 {} \;
   sudo mkdir -p /var/www/example.com/wp-content/uploads
   sudo chown -R www-data:www-data /var/www/example.com/wp-content/uploads
   sudo -u www-data test -w /var/www/example.com/wp-content/uploads && echo WRITABLE

   Если у вас настроен отдельный пользователь для деплоя, не меняйте владельца всего проекта без необходимости: это может сломать обновление файлов через Git или CI. Проверка: последняя команда выводит WRITABLE.

3. Создайте конфигурацию виртуального хоста. В Debian и Ubuntu файл обычно кладут в /etc/nginx/sites-available/. Конфигурация ниже рассчитана на HTTP до выпуска сертификата. Замените домен, каталог и путь к сокету PHP-FPM:

   server {
       listen 80;
       listen [::]:80;
   
       server_name example.com www.example.com;
       root /var/www/example.com;
       index index.php index.html;
   
       client_max_body_size 64M;
   
       location / {
           try_files $uri $uri/ /index.php?$args;
       }
   
       location ~* ^/wp-content/uploads/.*\.php$ {
           deny all;
       }
   
       location ~ \.php$ {
           include fastcgi_params;
           fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
           fastcgi_pass unix:/run/php/php8.2-fpm.sock;
       }
   
       location ~ /\. {
           deny all;
       }
   }

   Строка try_files нужна для постоянных ссылок WordPress: если файла нет на диске, запрос уходит в index.php. Блок для uploads не даёт исполнять загруженный PHP-файл как программу. Проверка: файл сохранён без синтаксических обрывов, а путь в fastcgi_pass совпадает с существующим файлом из проверки выше.

4. Включите сайт и проверьте конфигурацию. Если в системе уже есть стандартный сайт Nginx, его можно отключить, чтобы он не перехватывал запросы:

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

   Удаляйте ссылку на default только если она действительно не нужна для других сайтов. Проверка: nginx -t заканчивается сообщением syntax is ok и test is successful, после чего reload завершается без ошибки.

5. Откройте WordPress и проверьте PHP. Перейдите на домен. При первом запуске WordPress покажет мастер выбора языка и подключения базы данных. Если видите страницу установки, Nginx уже отдаёт PHP в правильный обработчик. После установки откройте «Настройки» и сохраните постоянные ссылки, даже если выбран простой формат. Проверка: главная страница и URL записи открываются с HTTP-статусом 200, а не с 404 или скачиванием файла index.php.

6. Добавьте HTTPS после проверки HTTP. Сертификат выпускайте только после того, как домен открывается по HTTP и DNS указывает на этот сервер. При включении HTTPS добавьте отдельный серверный блок для 443 и перенаправление с 80. Конкретные команды зависят от выбранного центра сертификации и политики хостинга, поэтому не вставляйте в продакшен случайный готовый конфиг без проверки. Проверка: адрес с https:// открывается без предупреждения браузера, а в панели WordPress URL сайта использует HTTPS.

Что означают ключевые строки конфигурации

Маршрутизация WordPress

try_files $uri $uri/ /index.php?$args; сначала ищет реальный файл или каталог. Для изображения Nginx отдаст файл напрямую, а для записи блога передаст исходный путь WordPress. Удалять эту строку и заменять её на простой index index.php нельзя: главная страница может работать, а постоянные ссылки начнут возвращать 404.

Передача PHP в FPM

Блок location ~ \.php$ перехватывает PHP-запросы. Параметр SCRIPT_FILENAME сообщает PHP-FPM, какой файл запускать. Если путь к сокету отличается от фактического, Nginx обычно отвечает ошибкой 502.

Лимит загрузки

client_max_body_size 64M задаёт верхний предел для тела HTTP-запроса на уровне Nginx. Он не меняет лимиты PHP upload_max_filesize и post_max_size. Если загрузка медиафайла всё ещё не проходит, проверяйте все три значения и не поднимайте лимит без причины.

Если не получилось

• 502 Bad Gateway. Чаще всего Nginx не видит PHP-FPM. Проверьте systemctl status php8.2-fpm и совпадение пути в fastcgi_pass с файлом в /run/php/. Версию службы замените на свою.
• 404 на страницах записей, но главная открывается. Проверьте строку try_files, активный виртуальный хост и сохранение постоянных ссылок в WordPress. Не добавляйте отдельные правила для каждого URL.
• В браузере скачивается index.php. Nginx не передаёт PHP в FPM или PHP-блок находится не в том серверном блоке. Сначала выполните nginx -t, затем проверьте fastcgi_pass.
• 403 Forbidden. У пользователя Nginx нет права пройти в один из каталогов пути или отсутствует индексный файл. Проверьте права на /var, /var/www и каталог сайта, а также журнал /var/log/nginx/error.log.
• 413 Request Entity Too Large. Файл больше client_max_body_size. Увеличивайте лимит только вместе с PHP-настройками и учитывайте свободное место на диске.

Что проверить перед публикацией

После базового запуска не закрывайте задачу только потому, что главная страница открылась. Проверьте несколько URL, админку, загрузку изображения и обновление страницы после очистки браузерного кеша. Посмотрите логи при одном тестовом запросе:

sudo tail -n 50 /var/log/nginx/error.log
sudo journalctl -u php8.2-fpm -n 50 --no-pager

Затем настройте резервное копирование базы данных и каталога wp-content, включите HTTPS и ограничьте доступ к панели администратора дополнительным уровнем защиты. Кеширование, CDN и правила для xmlrpc.php лучше добавлять отдельно: они меняют поведение сайта и могут сломать плагины.