Белый экран: где сайт прячет отчёт о поломке
Раздел практики: техника.
- 1Экранвременно включить вывод ошибок на тестовой копии
- 2error_log в папкеобычно лежит рядом с поломанным файлом
- 3Логи хост-панелираздел «Ошибки» или Logs
- 4Логи серверана VPS: /var/log и журнал PHP-FPM
- 5Дневник CMSу движков свои плашки и debug-режимы
Сделайте сегодня: найдите в панели хостинга раздел с логами ошибок и кликните туда один раз на здоровом сайте. Когда он понадобится, вы уже будете знать дорогу.
Сайт побелел в четыре утра, и первая мысль — «где посмотреть». Правильный ответ зависит от хостинга и настройки PHP, но обычно ответ есть: ошибка никуда не делась, она просто молчит там, где вы не искали. Разбираем по порядку, где живёт отчёт о поломке и как заставить его говорить.
Почему экран белый, а не с текстом
Настойчивость display_errors=Off на проде — гигиена: посетитель не должен видеть, в каком файле и строке всё умерло, это подсказка для злоумышленника. Флаг log_errors при этом обычно включён — значит, ошибка записана. Где — решает хостер: стандартная жизнь error_log — в папке сайта, рядом с исполняющим файлом; аккуратные панели собирают его в один видный лог; на VPS путь задаёт php.ini.
Читать и понимать
Формат записи скучен и полезен: дата, уровень, файл, строка, текст. Из всей простыни нужны три уровня. Fatal error — всё умерло, белая страница объяснена; в 90% случаев имя файла указывает на вчерашний плагин или правку. Warning и Notice — сайт жив, но подтачивает: отсутствие файла, не та переменная — предвестники будущей фатальной. Deprecated — функция, которой пользовалась CMS, помечена на смерть: сегодня работает, завтра на новом PHP — нет. И ещё колонка — частота: одна ошибка в сутки — баг, пятьсот в минуту — пожар, и тушить надо уже источник обращений.
Диагноз по характеру записей
Логи читаются не только содержимым, но и ритмом. Ошибка в момент публикации — ваша правка. Ровный поток одинаковых ошибок от чужих IP — подбираются или сканируют: смотреть надо в доступность (см. разбор взлома). Ошибки, приуроченные к пику трафика — упираетесь в лимиты: память, процессор, соединения. И самая коварная запись — её отсутствие: если страница белая, а лог пуст, значит процесс убит на уровне выше PHP — таймаут, OOM-killer, упавший сервис; эти логи живут рядом, в системных журналах.
Как не потерять логи в будущем
Три привычки. Первая: не отключать логи «для экономии дискового пространства» — типичный error_log на лёгком сайте весит мегабайты в месяц, а экономия на нём — ночи дежурства. Вторая: включить в CMS режим отладки на копии, а не на проде, и запомнить тумблер: он есть у всех движков. Третья: раз в месяц бегло просматривать лог на здоровом сайте — предупреждения копятся молча и дружно оживают после обновления PHP (обновления без слома).
Типичный случай
Магазин на «Битриксе» каждое утро ложился на минуту: страница оформления заказа белела и отходила. Логи PHP молчали — там нечего было ловить: умирал не php-код, а внешняя служба доставки, к которой сайт ходил за расчётом с таймаутом в минуту. Нашлось в логах веб-сервера, где строка «upstream timed out» стояла ровной колонной с 8:59. Код не правили: таймаут вызова внешней службы сократили до трёх секунд с ответом «рассчитаем вручную».
Дальше: практика: техника · 404-я страница · базовый курс.