Перейти к содержимому
BXWiki

Белая страница вместо сайта - разбор причин

Сайт открывается, но страница пустая: ни текста, ни сообщения об ошибке. Разбираем причины по убыванию частоты, начиная с журналов сервера.

С чего начать

Смотрим, что отдаёт сервер на самом деле:

Окно терминала
curl -sI https://example.com/ | head -3
curl -s https://example.com/ | wc -c
# код 200 при пустом теле - это белая страница, а не ошибка сервера
# код 500 означает другой разбор: там причину ищут иначе
# заголовок ответа приходит и при пустом теле: его отдаёт веб-сервер

Пустое тело при успешном коде ответа отличает белую страницу от ошибки сервера. Это важное разделение: в первом случае PHP отработал и промолчал, во втором он до ответа не добрался вовсе.

Читаем три журнала подряд:

Окно терминала
tail -50 /var/log/php-fpm/bx0-error.log | grep -iE 'fatal|error'
tail -50 /home/bitrix/www/bitrix/php_interface/error.log 2>/dev/null
tail -20 /var/log/nginx/error.log
# фатальная ошибка почти всегда уже записана в первом из них

Причина белой страницы обычно лежит в журнале процессов PHP целиком, вместе с файлом и номером строки. Пустой журнал сам по себе - тоже подсказка: значит, запись ошибок выключена и её надо включить.

Включаем запись ошибок в журнал платформы:

// /bitrix/.settings.php, вывод на экран на боевом сайте не включаем
'exception_handling' => ['value' => [
    'debug' => false,
    'handled_errors_types' => E_ALL & ~E_NOTICE & ~E_DEPRECATED,
    'log' => ['settings' => ['file' => 'bitrix/modules/error.log']],
]],

Запись в журнал даёт то же самое, что и вывод на экран, но не показывает пути и куски запросов посетителям. На боевом сайте это единственный приемлемый способ увидеть скрытую ошибку.

Отключаем свой код одним движением:

Окно терминала
mv /home/bitrix/www/local/php_interface/init.php /home/bitrix/www/local/php_interface/init.php.off
curl -s https://example.com/ | wc -c    # тело появилось - причина в своём коде
mv /home/bitrix/www/local/php_interface/init.php.off /home/bitrix/www/local/php_interface/init.php

Проверка занимает полминуты и сразу делит поиск надвое. Если страница ожила, дальше отключают подключаемые файлы по одному, пока виновник не найдётся.

Причины

  1. Фатальная ошибка при выключенном выводе сообщений примерно 35% случаев

    ПризнакКод ответа успешный, тело пустое, сайт побелел разом и целиком.

    ПроверкаЧитаем журнал процессов PHP: фатальная ошибка записана туда вместе с файлом и строкой.

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

  2. Ошибка в своём коде обработчиков примерно 25% случаев

    ПризнакБелая и публичная часть, и административная: код обработчиков выполняется на любом запросе.

    ПроверкаВременно переименовываем файл обработчиков и повторяем запрос к сайту.

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

  3. Скрипту не хватает памяти на этой странице примерно 20% случаев

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

    ПроверкаИщем в журнале сообщение об исчерпанной памяти и смотрим ограничение для этого пула.

    Что делатьПравим код на порционную обработку, а лимит поднимаем только как временную меру.

  4. Ошибка в шаблоне компонента или шаблоне сайта примерно 12% случаев

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

    ПроверкаВозвращаем штатный шаблон компонента и смотрим, появляется ли содержимое блока.

    Что делатьПравим свой шаблон: чаще всего это незакрытая конструкция или вызов несуществующего метода.

  5. Пустая страница пришла из кэша примерно 8% случаев

    ПризнакБелую страницу видят только гости, а под своей учётной записью сайт открывается.

    ПроверкаСравниваем страницу в обычном окне и в окне без входа на сайт.

    Что делатьСбрасываем кэш страницы и композита: пустой ответ успел попасть в готовый файл.

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

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

Вывод сообщений на экран на боевом сайте выключен намеренно, и это правильно. Ошибка при этом никуда не девается: её пишут в журнал, откуда и читают.

Белая только админка, публичная часть работает.

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

Помогает ли увеличение памяти?

Помогает, если в журнале есть сообщение об исчерпанной памяти. В остальных случаях это лечение симптома: ошибка вернётся на следующем объёме данных.

Может ли белая страница появиться после обновления?

Да, обычно из-за своего кода или стороннего решения, зовущего исчезнувший метод. Журнал называет файл и строку, и правят именно их, а не платформу.

Что делать, если журналы пустые?

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

Смежное

Первоисточник