Белый экран на сайте — это симптом: сервер или приложение не смогли сформировать нормальный ответ, а подробная ошибка осталась скрыта. Чаще всего причина находится в PHP, расширении CMS, шаблоне, версии PHP, PHP-FPM, правах доступа, заполненном диске или последнем обновлении.

Если сайт нужен прямо сейчас: не переустанавливайте CMS и не меняйте несколько настроек одновременно. Сначала зафиксируйте время сбоя, получите HTTP-код и найдите запись в error log. По одной строке Fatal error часто можно определить причину быстрее, чем за час случайных правок.

Что делать при белом экране сайта — короткий алгоритм

  1. Откройте проблемный URL и запомните точное время проверки.
  2. Проверьте HTTP-код: 200, 500, 502, 503 или 504 ведут к разным причинам.
  3. Откройте error log веб-сервера и PHP за эту же минуту.
  4. Вспомните последнее изменение: PHP, CMS, плагин, шаблон, перенос, Composer, права, конфигурация.
  5. Если сбой начался сразу после одного изменения — сначала отмените только его.
  6. Проверьте диск, inode, память и состояние PHP-FPM, если есть SSH/root.
  7. После исправления снова откройте страницу и убедитесь, что новая ошибка не появляется в журнале.

Ниже есть два маршрута: обычный виртуальный хостинг/ISPmanager без root и VPS/VDS/выделенный сервер с SSH. Выбирайте свой вариант и не выполняйте серверные команды, если у вас нет соответствующих прав.

Белый экран: что означает HTTP-код

HTTP-кодЧто чаще всего означаетЧто проверить первым
200, но страница пустая
вачена, пустой результат CMSPHP log, журнал CMS, шаблон, последний изменённый файл
500Fatal error PHP, неверная конфигурация, .htaccess, приложениеerror log PHP/Apache/Nginx, php -l, последнее изменение
502Nginx не получил нормальный ответ от upstreamPHP-FPM, socket/port, состояние службы, журнал Nginx
503Сервис недоступен или достигнут лимит ресурсов
остинга, maintenance, нагрузка
504Backend не успел ответитьдолгий PHP/SQL/API-запрос, таймауты, нагрузка
403Права, WAF/ModSecurity, запрет конфигурацииpermissions, владелец, правила безопасности, .htaccess

Если у вас обычный хостинг или ISPmanager и нет root-доступа

На виртуальном хостинге не нужно начинать с SSH-команд. Главная задача — получить журнал конкретного домена и проверить активную версию PHP.

Порядок проверки в ISPmanager

  1. Откройте нужный сайт в панели и убедитесь, что для него включён Error log.
  2. В настройках PHP включите log_errors. Для диагностики можно включить регистрацию всех ошибок, но вывод ошибок посетителю после проверки должен оставаться выключенным.
  3. Откройте белую страницу ещё раз и сразу посмотрите свежие строки журнала.
  4. Если проблема появилась после переключения версии PHP — временно верните предыдущую рабочую версию. После восстановления сайта уже исправляйте несовместимый код.
  5. В файловом менеджере отсортируйте файлы по времени изменения и проверьте то, что менялось непосредственно перед сбоем.
  6. Если CMS ведёт собственный журнал, сравните его время с серверным error log.

На сервере с ISPmanager ошибки сайта обычно собираются в журнал домена вида /var/www/httpd-logs/DOMAIN.error.log. Пользователю хостинга этот же журнал может быть доступен прямо из панели — без доступа root.

Практический совет: сначала копируйте последние 20–50 строк журнала в отдельный файл, и только потом очищайте кэш CMS или откатывайте обновление. Иначе можно стереть самый полезный след проблемы.

Если есть SSH: быстро посмотреть журнал сайта в ISPmanager

BASH
# Замените example.com на свой домен
sudo tail -n 100 /var/www/httpd-logs/example.com.error.log

# Смотреть новые ошибки в момент обновления белой страницы
sudo tail -f /var/www/httpd-logs/example.com.error.log

Если у вас VPS, VDS или выделенный сервер

На сервере с SSH можно проверить не только PHP, но и весь путь запроса: веб-сервер → PHP-FPM → CMS → база данных. Для разных дистрибутивов отличаются имена служб и стандартные каталоги логов.

Для доступных у провайдера систем удобно разделить команды на три группы:

  • Debian/Ubuntu: Ubuntu 22.04/24.04/26.04, Debian 12/13;
  • RHEL-подобные: AlmaLinux 8/9/10, Rocky Linux 8/9/10, CentOS Stream 9/10, Oracle Linux 8/9, Fedora 43/44;
  • FreeBSD: FreeBSD 14 ZFS.

Пути ниже — типовые. На сервере с панелью управления или нестандартной конфигурацией лог может быть перенесён, поэтому дополнительно смотрите активную конфигурацию Nginx/Apache и PHP-FPM.

Ubuntu и Debian: первичная диагностика

BASH
# HTTP-код и конечный URL
curl -sS -L -o /dev/null \
  -w "HTTP=%{http_code} final=%{url_effective} time=%{time_total}s\n" \
  https://example.com/problem-page

# Nginx / Apache
sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/apache2/error.log

# Состояние сервисов
systemctl list-units --type=service --all --no-pager \
  | grep -Ei 'nginx|apache2|php.*fpm|mariadb|mysql'

# Журналы за последние 10 минут
sudo journalctl --since "-10 min" --no-pager \
  | grep -Ei 'php|fpm|nginx|apache|fatal|error|oom'

# Диск, inode, память
df -h
df -i
free -h

# Проверка конфигурации
sudo nginx -t
sudo apache2ctl configtest

# Проверить конкретный изменённый PHP-файл
php -l /var/www/example.com/file.php

AlmaLinux, Rocky Linux, CentOS Stream, Oracle Linux и Fedora

BASH
# HTTP
curl -sS -L -o /dev/null \
  -w "HTTP=%{http_code} final=%{url_effective} time=%{time_total}s\n" \
  https://example.com/problem-page

# Логи
sudo tail -n 100 /var/log/nginx/error.log
sudo tail -n 100 /var/log/httpd/error_log

# Сервисы
sudo systemctl --no-pager --full status nginx
sudo systemctl --no-pager --full status httpd
sudo systemctl --no-pager --full status php-fpm

# Журнал PHP-FPM и web
sudo journalctl -u php-fpm --since "-10 min" --no-pager
sudo journalctl -u nginx -u httpd --since "-10 min" --no-pager

# Ресурсы
df -h
df -i
free -h

# Конфигурация
sudo nginx -t
sudo httpd -t

# PHP
php --ini
php -l /var/www/example.com/file.php

FreeBSD 14 ZFS: что проверить

BASH
# Сервисы
service nginx status
service apache24 status
service php_fpm status

# Слушающие порты и процессы
sockstat -4 -6 -l

# Ресурсы
df -h
swapinfo -h

# Типовые логи — фактические пути сверяйте в конфигурации
tail -n 100 /var/log/nginx/error.log

# Проверка конфигурации
nginx -t
apachectl configtest

# PHP
php -v
php --ini
php -l /usr/local/www/example/file.php

Как понять, где именно ломается запрос

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

HTTP 200, но экран полностью белый

Это часто означает, что веб-сервер и PHP отработали формально успешно, но приложение вернуло пустой вывод. Проверяйте журнал CMS, шаблон, ранний exit/die, обработчик исключений, ошибки шаблонизатора и конкретный маршрут.

HTTP 500

Ищите Fatal error, Parse error, необработанное исключение, неверную директиву конфигурации или ошибку после изменения кода. Код 500 — не диагноз; диагноз находится в журнале.

HTTP 502 или 504

Сначала проверяйте PHP-FPM/upstream и его журнал. 502 часто возникает, когда Nginx не может обратиться к нужному socket/port PHP-FPM; 504 — когда backend слишком долго отвечает.

Проверка HTTP без браузера

BASH
# Только статус
curl -sS -o /dev/null -w "%{http_code}\n" https://example.com/

# С редиректами и временем ответа
curl -sS -L -o /dev/null \
  -w "final=%{url_effective}\nHTTP=%{http_code}\nIP=%{remote_ip}\ntime=%{time_total}s\n" \
  https://example.com/

# Только заголовки
curl -sS -I https://example.com/

Как включать PHP-диагностику и не показывать ошибки посетителям

На production-сайте безопаснее записывать ошибки в журнал, а не выводить их в HTML. PHP прямо предупреждает, что сообщения об ошибках могут раскрывать служебные данные. Поэтому для рабочей среды используйте log_errors=On и display_errors=Off.

Если нужен визуальный вывод ошибок, делайте это только на staging/локальной копии или запускайте проблемный PHP-файл из CLI.

Безопасные настройки PHP для рабочего сайта

INI
; php.ini / .user.ini — если хостинг разрешает переопределение
display_errors=Off
display_startup_errors=Off
log_errors=On
error_reporting=E_ALL

Показать ошибку только при запуске PHP из CLI

BASH
php -d display_errors=1 \
    -d display_startup_errors=1 \
    -d error_reporting=-1 \
    /path/to/problem-script.php

Типичная ошибка в логе → что она означает

Фрагмент ошибкиВероятная причинаЧто делать
Allowed memory size exhaustedPHP исчерпал memory_limit или код потребляет слишком много памяти
; лимит повышать только после анализа
Parse error / unexpected tokenСинтаксическая ошибка PHPphp -l проблемный файл, вернуть корректную версию
Call to undefined functionНет расширения PHP или несовместимая версия кодаphp -m, версия PHP, требуемое расширение
Class ... not foundАвтозагрузка/Composer/дополнение CMSпроверить vendor/autoload, пакет, совместимость
Permission deniedНеверный владелец/права/политика безопасностипроверить owner/group и права конкретного пути
No space left on deviceЗаполнен диск или inodedf -h и df -i, освободить место
connect() to unix:... failedPHP-FPM socket отсутствует или другой путьсостояние PHP-FPM, listen/socket в конфигурации
upstream timed outBackend/SQL/API работает слишком долгожурнал приложения, медленные запросы, нагрузка, timeout
Primary script unknownNginx/PHP-FPM смотрят на разные пути SCRIPT_FILENAMEпроверить fastcgi_param и root
Too many redirects / rewrite cycleОшибка rewrite/.htaccess/Nginxпроверить правила маршрутизации и журнал web-сервера

Белый экран после обновления PHP

Это один из самых частых сценариев: сайт работал на старой версии, после переключения PHP появляется пустая страница или 500. Быстрый способ вернуть доступ — временно выбрать предыдущую рабочую версию PHP в панели, а затем отдельно искать несовместимость.

После восстановления сравните:

  • версию PHP и SAPI;
  • набор модулей php -m;
  • memory_limit и другие ini-параметры;
  • совместимость CMS и дополнений;
  • Composer platform requirements, если проект использует Composer;
  • фатальные ошибки в журнале сразу после загрузки проблемной страницы.

Не оставляйте старую версию PHP навсегда только потому, что она «заработала». Откат — это способ быстро восстановить сервис и получить время на исправление несовместимого кода.

PHP после обновления: сравнить окружение

BASH
php -v
php --ini
php -m
php -r 'echo "memory_limit=".ini_get("memory_limit").PHP_EOL;'
php -r 'echo "error_log=".ini_get("error_log").PHP_EOL;'

# Если используется Composer
composer check-platform-reqs
composer diagnose

Отдельно для MODX Revolution

У MODX один из первых файлов, который стоит сохранить и открыть, — core/cache/logs/error.log. Там часто уже указаны класс, плагин, сниппет, файл или PHP-ошибка, из-за которой запрос оборвался.

  1. Сделайте копию последних строк core/cache/logs/error.log.
  2. Воспроизведите белый экран и снова посмотрите конец журнала.
  3. Если проблема появилась после установки Extra или правки плагина — проверяйте именно это изменение.
  4. Только после сохранения журнала очищайте кэш.
  5. Проверьте совместимость текущей версии PHP с MODX и используемыми дополнениями.

Если Manager MODX отдаёт 500, документация MODX также рекомендует проверить/пересоздать кэш. Но сначала сохраните журнал: он полезнее самого факта, что очистка кэша временно помогла.

MODX: журнал и кэш

BASH
# Посмотреть последние ошибки MODX
tail -n 120 /path/to/site/core/cache/logs/error.log

# Следить за журналом при обновлении проблемной страницы
tail -f /path/to/site/core/cache/logs/error.log

# Сначала сохраните error.log, и только потом очищайте кэш
cp /path/to/site/core/cache/logs/error.log \
   /path/to/site/core/cache/logs/error-before-clear.log

# Очистка содержимого cache — выполняйте только если понимаете путь проекта
rm -rf /path/to/site/core/cache/*

Отдельно для WordPress

В WordPress белая страница часто связана с fatal error плагина, темы или пользовательского кода. В современных версиях WordPress есть Recovery Mode, который может прислать администратору ссылку для входа и отключения проблемного компонента.

Если письма Recovery Mode нет, включайте запись отладки в файл, но не показывайте её посетителям. После воспроизведения ошибки смотрите wp-content/debug.log.

WordPress: записать ошибку в debug.log, но не показывать на сайте

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

Если белый экран появился после правки одного PHP-файла

Не загружайте файл на production повторно наугад. Сначала проверьте его синтаксис. Команда php -l не выполняет бизнес-логику файла, а только проверяет синтаксис.

Проверить синтаксис PHP-файла

BASH
php -l /path/to/file.php

# Найти PHP-файлы, изменённые за последние 2 дня
find /path/to/site -type f -name '*.php' -mtime -2 \
  -printf '%TY-%Tm-%Td %TH:%TM %p\n' 2>/dev/null \
  | sort -r | head -n 50

Что не стоит делать при белом экране

  • Не ставьте chmod 777 на весь сайт. Исправляйте владельца и права конкретного каталога.
  • Не включайте display_errors надолго на production. Ошибки могут раскрыть пути, SQL и другие служебные данные.
  • Не обновляйте одновременно CMS, PHP, плагины и тему. После этого невозможно быстро определить виновника.
  • Не удаляйте логи до диагностики. Особенно перед очисткой кэша или восстановлением резервной копии.
  • Не увеличивайте memory_limit вслепую. Сначала убедитесь, что в коде нет цикла или неконтролируемой выборки.
  • Не переустанавливайте сайт поверх текущего состояния. Это может уничтожить полезные следы и усложнить восстановление.

Как убедиться, что сайт действительно исправлен

  • проблемный URL отдаёт ожидаемый HTTP-код;
  • страница отображается полностью и без PHP warning/fatal в свежем логе;
  • открывается административная панель;
  • работают формы, AJAX, авторизация, корзина и другие критичные сценарии;
  • после очистки штатного кэша проблема не возвращается;
  • при повторной проверке журнал не заполняется той же ошибкой.

Готовый набор диагностики для скачивания

Чтобы не копировать команды вручную, ниже приложены тестовые файлы. Пакет не исправляет сайт автоматически — он помогает быстро собрать факты и понять, на каком уровне находится проблема.

  • white-screen-check.sh — проверяет Linux-сервер, HTTP, PHP, диск, inode, сервисы и стандартные логи;
  • check-site.bat + check-site.ps1 — проверка URL с Windows: DNS, HTTP-код, время ответа;
  • php-cli-diagnostics.php — безопасный CLI-отчёт по PHP и расширениям;
  • user.ini.example — шаблон production-safe логирования PHP;
  • ZIP — все файлы одним архивом.

Перед отправкой отчёта постороннему человеку просмотрите его. Error log может содержать внутренние пути, IP, параметры URL и другую служебную информацию.

Быстрые команды — можно просто скопировать

Если не нужен полный диагностический набор, используйте короткие команды ниже. Они не исправляют сайт автоматически, а помогают быстро найти уровень, на котором возникла ошибка.

Linux/VPS: HTTP, диск и последние ошибки

BASH
# Проверить HTTP-код
curl -sS -L -o /dev/null -w "HTTP=%{http_code} time=%{time_total}s\n" https://example.com/

# Проверить диск и inode
df -h
df -i

# Nginx
sudo tail -n 80 /var/log/nginx/error.log

# Apache на Ubuntu/Debian
sudo tail -n 80 /var/log/apache2/error.log

# PHP-FPM и web-сервер за последние 10 минут
sudo journalctl --since "-10 min" --no-pager | grep -Ei 'php|fpm|nginx|apache|fatal|error'

PHP: безопасно писать ошибки в журнал

INI
display_errors=Off
display_startup_errors=Off
log_errors=On
error_reporting=E_ALL

MODX Revolution: посмотреть error.log

BASH
tail -n 120 /path/to/site/core/cache/logs/error.log

# Смотреть новые ошибки в момент обновления страницы
tail -f /path/to/site/core/cache/logs/error.log

WordPress: записывать ошибки в debug.log

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

Скачать готовый набор диагностики

Готовый набор диагностики белого экрана сайта — ZIP

Какие программы действительно полезны при диагностике

  • DevTools браузера — Network показывает HTTP-код и проблемные AJAX-запросы; Console помогает отделить frontend-ошибку от серверной.
  • WinSCP — удобен для SFTP и безопасной замены/отката файлов на сервере.
  • Windows Terminal / OpenSSH — SSH-доступ к VPS без отдельного тяжёлого клиента.
  • curl — проверяет HTTP-код, редиректы и время ответа без браузера.
  • journalctl / tail — позволяют видеть ошибку в момент её появления.
  • php -l — обязательная быстрая проверка PHP-файла после ручной правки.

Специальная «программа для исправления белого экрана» обычно не нужна. Полезнее хороший журнал ошибок и возможность безопасно откатить одно конкретное изменение.

Какие изображения стоит добавить в эту статью

Для этой темы лучше использовать не декоративные картинки, а 3–4 практических изображения с подписями:

  1. DevTools → Network: пример запроса со статусом 500 и где смотреть код ответа.
  2. ISPmanager: где включён Error log и где открыть журнал сайта. Домены, IP и логины на скриншоте нужно скрыть.
  3. Терминал: пример tail -f error.log с выделенной Fatal error.
  4. Схема диагностики: браузер → Nginx/Apache → PHP-FPM → CMS → база данных, с пояснением, где искать лог на каждом этапе.

Alt-тексты должны описывать действие, а не повторять заголовок статьи: например «Ошибка 500 в Network DevTools при белом экране сайта» и «Просмотр PHP error log в ISPmanager».

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

Почему сайт белый, но HTTP-код 200?

Веб-сервер мог успешно вернуть ответ, а CMS или шаблон сформировали пустое содержимое. Проверяйте PHP log, журнал CMS, шаблонизатор и код конкретного маршрута.

Что делать, если белый экран появился сразу после обновления PHP?

Для быстрого восстановления временно верните предыдущую рабочую версию PHP, сохраните error log и затем исправляйте несовместимость. После этого можно повторить переход на новую версию.

Где смотреть ошибки на обычном хостинге?

В панели управления сайтом: error log домена и настройки PHP. В ISPmanager PHP-ошибки могут попадать в журнал сайта, а на сервере этот журнал обычно расположен в /var/www/httpd-logs/DOMAIN.error.log.

Нужно ли включать display_errors?

На рабочем сайте — нет. Лучше включить log_errors и читать журнал. display_errors используйте только в контролируемой тестовой среде.

Можно ли просто очистить кэш CMS?

Иногда это помогает, особенно при повреждённом кэше, но сначала сохраните error log. Иначе можно потерять информацию о реальной причине сбоя.

Почему после исправления белый экран возвращается?

Чаще всего устранён симптом, а не причина: несовместимый код продолжает выполняться, ресурс снова исчерпывается или фоновая задача повторяет ошибку. Сравните свежий лог с первоначальным.

Читайте также по теме

Итог: белый экран нужно превращать в конкретную ошибку

Самое полезное действие при белом экране — не угадывать причину, а получить факты: HTTP-код, свежую строку error log и список последних изменений. После этого проблема обычно сводится к конкретному файлу, версии PHP, сервису, плагину, правам или ресурсу сервера.

Если вы обращаетесь к разработчику, приложите URL, точное время ошибки и диагностический отчёт из этой статьи. Это значительно сокращает этап «а у меня не воспроизводится» и помогает сразу перейти к исправлению.