Как запустить WordPress на Debian без типовых сбоев

Если WordPress на Debian не открывается или ломается при обновлении, сначала проверьте связку веб-сервера и PHP, права на файлы и журналы. Я разбираю пять частых причин и даю безопасный порядок диагностики: без универсальных chmod, случайного увеличения RAM и перезапуска не той службы.

1. Раздать всем права — не значит починить сайт

Ошибка 500 не доказывает, что виноваты права. Это общий ответ сервера на внутреннюю ошибку: причина может быть в PHP, конфигурации веб-сервера, плагине или доступе к файлу. Я начинаю с журнала и проверки владельца, группы и режима конкретного файла. Для обычной установки WordPress каталоги часто имеют режим 755, файлы — 644, но это отправная точка, а не универсальный рецепт для любой схемы запуска. Подробно настраивая безопасность сайта, я сначала выясняю, от какого пользователя работает PHP и каким способом администратор обновляет код. Иначе «исправление» лишь передвигает проблему.

Не делайте chown -R www-data:www-data только потому, что сайт расположен в Debian. При такой схеме веб-процесс сможет менять и исполняемый код, если права это позволяют; после взлома последствия будут шире. WordPress рекомендует оставить основные файлы владельцу установки и разрешать запись веб-серверу лишь там, где она действительно нужна. Обычно это отдельные каталоги загружаемого содержимого, а права зависят от пользователя PHP и группы. Папки wp-admin и wp-includes не обязаны быть доступны на запись веб-серверу. wp-config.php требует отдельного внимания: ограничьте чтение теми учётными записями, которым оно необходимо.

Сначала найдите корень установки, затем посмотрите владельца и режимы: ls -ld /путь/к/сайту /путь/к/сайту/wp-content и namei -l /путь/к/сайту/wp-config.php. Если у PHP-FPM отдельный пользователь или пул, www-data может вообще оказаться не тем субъектом, которому нужна запись. Меняйте разрешения точечно, после резервной копии и с пониманием способа обновления. Команда chmod 755 /var/www/html/wordpress затрагивает только сам каталог, а не вложенные файлы; команда с * не охватывает скрытые файлы и вложенные папки. Рекурсивно применять режимы «на всякий случай» — способ создать новую неисправность быстрее старой.

• find /путь/к/сайту -type d -exec chmod 755 {} \;
• find /путь/к/сайту -type f -exec chmod 644 {} \;
• namei -l /путь/к/сайту/wp-config.php

2. Проверить PHP в командной строке — ещё не проверить сайт

WordPress исполняется в PHP, а база данных подключается через соответствующий драйвер, обычно mysqli. При этом проверка php -m показывает модули CLI, а сайт может обслуживаться другой версией PHP-FPM с отдельным набором расширений и настройками. Если админка сообщает об отсутствующем расширении, проверяйте именно версию PHP, которую использует веб-сайт. Для этого сопоставьте конфигурацию Nginx или Apache с пулом FPM, затем проверьте phpinfo() временно в закрытой среде либо используйте панель и журналы. Не оставляйте файл phpinfo доступным из интернета: он раскрывает подробности конфигурации.

Не всякий модуль из случайного списка является обязательным для ядра WordPress. В справочнике хостинга WordPress перечислены требуемые и рекомендуемые расширения; некоторые влияют на отдельные функции, совместимость плагинов или обработку изображений. mysqli нужен для доступа к MySQL, а curl, gd, intl, mbstring и XML-компоненты нельзя безоговорочно объявить все обязательными для каждого сайта. Установите недостающее по фактической диагностике и требованиям используемой версии WordPress и расширений. Команда apt install php-gd может поставить модуль не для того FPM, если на сервере несколько веток PHP.

В Debian имена пакетов и служб зависят от доступной версии PHP и подключённых репозиториев. Поэтому команда systemctl restart php8.2-fpm подходит только серверу, где установлен именно такой пакет и служба. Сначала узнайте установленную версию: php -v, systemctl list-units --type=service 'php*-fpm.service', apt-cache policy php-fpm. После установки модуля перезапустите или перезагрузите соответствующую службу FPM и проверьте её состояние через systemctl status. Не перезагружайте весь сервер из-за одного расширения: это не диагностика, а более крупный перерыв.

• php -v
• php -m
• systemctl list-units --type=service "php*-fpm.service"

3. Не путать лимит PHP с оперативной памятью сервера

В требованиях к WordPress часто всплывает число 128 МБ. Речь о минимальном PHP memory_limit, достаточном для базовой установки без дополнительных тем и плагинов, а не о гарантированном объёме RAM для всей машины. Серверу кроме PHP нужны память для ОС, веб-сервера, базы данных и других процессов. Для типового сайта в рекомендациях WordPress Hosting Handbook указано 256M как разумное стартовое значение PHP-лимита, но и это не обещает стабильность при любом наборе плагинов. Проверяйте фактические пики и сообщения об исчерпании памяти, а не лечите число из статьи числом побольше.

Код 502 тоже не является диагнозом нехватки RAM. Nginx может показать 502, если не отвечает upstream — например, PHP-FPM завершился, не слушает указанный сокет или отклоняет соединение. Ищите соседние по времени записи в журнале Nginx и журнале FPM, затем смотрите состояние процессов и памяти. Если PHP пишет Allowed memory size exhausted, проверяйте лимит конкретного пула и запрос, который его исчерпал. Если система сообщает об OOM, проблема уже на уровне памяти машины. Это разные неисправности, хотя внешне страница может выглядеть одинаково печально.

Начните с free -h, ps и журналов, после чего решайте, что менять: лимит PHP, число одновременных процессов FPM, код или ресурсы виртуальной машины. Большое число воркеров умножает расход памяти; маленькое ограничивает параллельную обработку. Значение pm.max_children подбирают исходя из доступной памяти и измеренного потребления одного процесса, а не копируют из чужого файла. Swap может дать системе время пережить краткий пик, но значительно медленнее RAM и не устраняет устойчивый дефицит. Создавать swap через dd размером «на глаз» и объявлять сервер готовым к нагрузке — плохая инженерная шутка.

• free -h
• journalctl -u ИМЯ-СЛУЖБЫ --since "15 minutes ago"

4. PHP-FPM не слушает порты 80 и 443

Здесь исходная версия статьи перепутала роли служб. Обычно Nginx или Apache принимает HTTP/HTTPS на портах 80 и 443, а PHP-FPM обрабатывает PHP-запросы через Unix-сокет либо отдельный FastCGI-порт, часто доступный только локально. MySQL/MariaDB слушает собственный порт, обычно 3306, и не конкурирует с веб-сервером за 80 или 443. Поэтому фраза «PHP-FPM попытался занять 80-й порт» описывает неверную конфигурацию, а не нормальный конфликт при установке WordPress. Если сообщение Address already in use появилось при старте Nginx, ищите второй процесс, который действительно занял адрес и порт.

Проверьте владельца сокета командой ss -ltnp для TCP и ss -lxnp для Unix-сокетов. Затем сравните listen в блоке Nginx с listen в конфигурации пула FPM. В Nginx директива listen 8080; меняет порт, на котором он принимает HTTP; она не «выделяет WordPress отдельный порт» автоматически и не устраняет конфликт, если другой процесс уже слушает этот же адрес. Для обычного сайта часто не требуется менять публичный порт вообще: несколько доменов обслуживаются виртуальными хостами Nginx на общих портах, а запрос к PHP передаётся в FPM.

Если меняли конфигурацию, сначала выполните проверку синтаксиса: nginx -t или соответствующую проверку Apache, затем перечитайте конфигурацию или перезапустите только нужную службу. Успешный systemctl reload nginx не доказывает, что соединение Nginx с FPM работает: проверьте журнал ошибок и маршрут до сокета. При миграции особенно легко оставить старый виртуальный хост включённым, указать неправильный root или сослаться на исчезнувший сокет. Это даёт 404, 502 или отказ запуска по разным причинам; не сводите их все к «конфликту портов». Диагностика по точному сообщению экономит часы и не требует наугад переставлять сервисы.

• ss -ltnp
• ss -lxnp
• nginx -t

5. Включать отладку нужно с планом и сроком

Когда сайт отвечает ошибкой, журнал обычно полезнее предположений. В тестовой среде можно включить WP_DEBUG и WP_DEBUG_LOG: WordPress будет записывать сообщения в wp-content/debug.log (если путь не переопределён и PHP может туда писать). WP_DEBUG_DISPLAY управляет выводом диагностических сообщений в HTML. Важно: оба параметра логирования и показа работают в связке с включённым WP_DEBUG. Разместите определения до строки «That’s all, stop editing!» в wp-config.php, иначе они могут оказаться после загрузки конфигурации и не сработать как ожидается. Документация WordPress рекомендует режим отладки для разработки и тестирования, не для постоянной работы публичного сайта.

Для короткого диагностического окна конфигурация выглядит так. Но WP_DEBUG_DISPLAY со значением false не заменяет настройки PHP display_errors во всех окружениях и не превращает публичный журнал в безопасный файл. Если debug.log доступен по HTTP, в нём могут оказаться пути, имена файлов, детали запросов и сообщения плагинов. Ограничьте доступ к журналу, предпочтительно пишите его вне публичного каталога, если конфигурация это позволяет, и удалите или архивируйте его после диагностики по правилам хранения. Не назначайте журналу 666 ради того, чтобы «заработало»: найдите правильного владельца и минимальные права записи.

После воспроизведения ошибки сохраните нужные строки, сопоставьте время с журналами PHP-FPM и Nginx, затем верните WP_DEBUG в false на рабочем сайте. Иначе поток предупреждений замусорит журнал, а чувствительные подробности могут стать видны посетителю. Если debug.log не появился, проверьте права на каталог, путь WP_CONTENT_DIR, конфигурацию PHP и то, что диагностика включена в том экземпляре, который обслуживает сайт. Одна команда tail не объясняет проблему; полезен контекст до и после записи. Я не считаю «включить всё и забыть» диагностикой. Это просто ещё одна настройка, за которой потом никто не следит.

• define( 'WP_DEBUG', true );
• define( 'WP_DEBUG_LOG', true );
• define( 'WP_DEBUG_DISPLAY', false );

Частые вопросы