Настройка Nginx для WordPress: ошибки новичков

За 20–30 минут вы настроите Nginx для WordPress 6.x на сервере с PHP-FPM 8.2: главная страница и админка начнут открываться, ЧПУ перестанут отдавать 404, а PHP-файлы не будут скачиваться как обычный текст. Ниже — рабочая последовательность и ошибки, которые чаще всего ломают сайт у новичков.

Что нужно подготовить до начала

Инструкция рассчитана на Linux-сервер с Nginx 1.24 или новее, PHP-FPM 8.2 и WordPress 6.x. Команды могут немного отличаться в зависимости от дистрибутива, но структура конфигурации остаётся той же.

• SSH-доступ с правами sudo;
• домен, который уже указывает на IP сервера;
• установленные Nginx, PHP-FPM и расширения PHP, необходимые WordPress;
• путь к файлам сайта, например /var/www/example.com;
• имя Unix-сокета PHP-FPM. Для PHP 8.2 в Debian и Ubuntu это часто /run/php/php8.2-fpm.sock, но путь нужно проверить на своём сервере.

Проверьте версию Nginx командой nginx -v, а версию PHP — командой php -v. Если PHP-FPM использует другой сокет, замените его в конфигурации ниже. Неправильный путь к сокету — одна из главных причин ошибки 502.

Термин: ЧПУ — человекопонятные URL вроде /blog/nginx-wordpress/, а не адреса с параметром ?p=123.

Шаг 1. Проверьте корень сайта и права

Скопируйте файлы WordPress в каталог, который будет указан в директиве root. В нём должны находиться wp-admin, wp-content, wp-includes и файл index.php.

Проверка:

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

Если файл принадлежит пользователю, под которым работает PHP-FPM, веб-сервер сможет его прочитать. Точный пользователь зависит от системы; часто это www-data. Не выдавайте каталогу права 777: это маскирует проблему доступа и расширяет права для всех процессов.

Проверка владельца:

stat -c '%U:%G %a %n' /var/www/example.com /var/www/example.com/index.php

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

Шаг 2. Создайте отдельный server-блок

Создайте файл виртуального хоста, например /etc/nginx/sites-available/example.com. Замените домен, путь к сайту и сокет PHP-FPM на свои значения.

server {
    listen 80;
    listen [::]:80;

    server_name example.com www.example.com;
    root /var/www/example.com;
    index index.php index.html;

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

    location ~ \.php$ {
        try_files $uri =404;
        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. Без этого правила главная страница может работать, а любой красивый URL будет возвращать 404.

Проверка синтаксиса:

sudo nginx -t

Нормальный результат содержит строки syntax is ok и test is successful. Если Nginx сообщает о неизвестной директиве или пропущенной скобке, не перезагружайте сервис: сначала исправьте файл.

Шаг 3. Включите сайт и отключите конфликтующий хост

В Debian и Ubuntu сайт обычно включают символической ссылкой:

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

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

sudo rm /etc/nginx/sites-enabled/default
sudo nginx -t
sudo systemctl reload nginx

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

Шаг 4. Проверьте PHP-FPM

Если браузер показывает 502 Bad Gateway, сначала проверьте службу PHP-FPM и совпадение сокета в конфигурации.

sudo systemctl status php8.2-fpm --no-pager
ls -l /run/php/php8.2-fpm.sock

Имя службы может быть другим, например php8.3-fpm. В конфигурации Nginx значение fastcgi_pass должно указывать на реально существующий сокет. После исправления выполните sudo nginx -t и sudo systemctl reload nginx. Проверка: PHP-страница WordPress открывается, а запрос к несуществующему PHP-файлу не исполняется.

В конфигурации WordPress важнее не количество директив, а совпадение трёх вещей: корня сайта, правила передачи запросов в index.php и сокета PHP-FPM.

Шаг 5. Настройте постоянные ссылки

В панели WordPress откройте «Настройки» → «Постоянные ссылки», выберите структуру URL и сохраните изменения. В Nginx не нужно добавлять правила Apache с .htaccess: Nginx этот файл не читает.

Проверка: откройте запись, страницу и URL /wp-admin/ в приватном окне браузера. Все адреса должны отдавать страницы, а не 404. Если после изменения ссылок появилась ошибка, снова проверьте блок location / и наличие строки /index.php?$args.

Частые ошибки новичков

404 на записях и страницах

Обычно в location / оставляют только try_files $uri $uri/ =404;. Для WordPress это означает: если файла с таким именем нет, Nginx сразу вернёт 404 и не передаст запрос CMS. Используйте try_files $uri $uri/ /index.php?$args;.

502 Bad Gateway

Nginx не может подключиться к PHP-FPM. Причины — остановленная служба, неправильная версия сокета или отсутствие прав на него. Смотрите журнал Nginx командой sudo tail -n 50 /var/log/nginx/error.log: там часто прямо указано connect() to unix:/run/php/... failed.

Скачивание PHP-файлов

Если браузер предлагает сохранить index.php, PHP-запросы не передаются в PHP-FPM. Проверьте, что блок location ~ \.php$ находится внутри нужного server, а в нём есть fastcgi_pass и подключены параметры FastCGI.

403 Forbidden после переноса

Проверьте существование каталога, права на каждый каталог в пути и директиву root. Ошибка также появляется, если в каталоге нет индексного файла и отключён просмотр содержимого. Не включайте автоматический список файлов для публичного сайта без необходимости.

Работает только домен без www или наоборот

Оба имени должны быть перечислены в server_name, а DNS-записи должны указывать на тот же сервер. Для постоянного перенаправления одного варианта на другой нужен отдельный server-блок; настройка HTTPS и редиректов — следующий этап, а не часть базовой проверки PHP.

Если не получилось: короткая диагностика

1. Выполните sudo nginx -t. Если тест не проходит, исправьте синтаксис до перезагрузки.
2. Проверьте, какой конфигурацией реально запущен Nginx: sudo nginx -T. Найдите свой домен и убедитесь, что активен нужный server-блок.
3. Посмотрите журнал ошибок: sudo tail -n 50 /var/log/nginx/error.log. Для ошибок PHP дополнительно проверьте журнал PHP-FPM.
4. Убедитесь, что DNS уже указывает на этот сервер. При старой DNS-записи браузер может обращаться к другому Nginx.
5. Проверьте ответ без браузера: curl -I http://example.com/. В заголовках будет виден HTTP-код, который помогает отделить проблему Nginx от проблемы WordPress.

Что делать дальше

После базовой проверки настройте HTTPS через доверенный сертификат, сделайте резервную копию конфигурации и проверьте обновление WordPress на копии сайта. В продакшене наблюдайте за error.log, временем ответа PHP и количеством процессов PHP-FPM. Кеширование страниц, ограничения для xmlrpc.php и правила для загрузок требуют отдельной проверки: не добавляйте их вслепую в рабочий конфиг.