Белый экран сайта на PHP: как найти ошибку на shared-хостинге
Если вместо сайта открывается полностью белая страница без текста, первым делом не переустанавливайте сайт, не удаляйте файлы и не меняйте права доступа на 777. Чаще всего PHP столкнулся с ошибкой, но показ сообщения посетителю отключён. Самый безопасный путь — сделать копию затрагиваемых файлов, открыть журнал ошибок хостинга и воспроизвести проблему один раз.
Белый экран не всегда означает серьёзную потерю данных. Нередко причина оказывается в одной строке PHP, несовместимой версии PHP, отсутствующем расширении, повреждённом файле после загрузки или неудачном обновлении. Но угадывать причину по советам из форумов хуже, чем потратить несколько минут на чтение лога: одна точная строка ошибки часто сразу показывает файл и место сбоя.
Коротко: что сделать сразу
- Не удаляйте сайт и не импортируйте старую базу поверх текущей.
- Если недавно меняли
.htaccess,config.php, PHP-файлы или базу, сначала сделайте их резервную копию. - Обновите проблемную страницу и запомните точное время появления белого экрана.
- В панели хостинга найдите раздел ошибок или журнал PHP и посмотрите самые свежие записи.
- Проверьте, менялись ли перед поломкой версия PHP, расширения, файлы сайта, плагины или настройки.
- Показывать PHP-ошибки прямо посетителям включайте только временно и только если журнал недоступен.
Сначала определите, что именно сломалось
Не все белые страницы одинаковы. Откройте несколько адресов сайта: главную, внутреннюю страницу и, если она есть, административную часть. Если белый экран только на одной странице, проблема чаще связана с кодом именно этого маршрута, шаблоном или данными, которые он обрабатывает. Если не работает вообще ничего, круг причин шире: общий файл конфигурации, автозагрузка классов, версия PHP, расширение, общий bootstrap-файл или настройки веб-сервера.
Полезно также узнать HTTP-статус ответа. В Chrome, Edge и Firefox нажмите F12, откройте вкладку Network или «Сеть», перезагрузите страницу и выберите первый запрос с типом document. 500 обычно означает, что сервер не смог нормально выполнить запрос. 200 при совершенно пустом ответе говорит о том, что запрос формально завершился успешно, но приложение ничего не вывело либо выполнение оборвалось в конфигурации, где ошибка была перехвачена.
Если вместе с белым экраном браузер показывает ERR_TOO_MANY_REDIRECTS, ошибку сертификата, 403 или сообщение самого хостинга, это уже другой сценарий. Не пытайтесь лечить его настройкой display_errors: PHP может вообще не успевать запускаться.
Перед диагностикой сохраните то, что собираетесь менять
На shared-хостинге легко исправить одну проблему и случайно создать вторую. Поэтому перед правкой .htaccess, config.php, .user.ini, базы данных или основного PHP-файла скачайте копию исходного варианта. Если панель хостинга умеет создавать резервную копию сайта и базы одним действием, это ещё удобнее.
Не нужно скачивать многогигабайтный архив всего аккаунта перед каждым тестом. Если вы проверяете один недавно изменённый файл, достаточно сохранить его рабочую копию с понятным именем. Но если неизвестно, что именно повредилось после массового обновления или переноса сайта, лучше иметь полноценный бэкап файлов и MySQL.
Особенно осторожно обращайтесь с конфигурационными файлами: в них могут находиться пароль базы, SMTP-пароль, API-ключи и другие секреты. Не публикуйте полный текст таких файлов на форумах и не оставляйте их копии с расширением вроде .txt внутри доступной из интернета папки.
Где найти настоящий журнал ошибок PHP
Названия разделов у хостеров отличаются. В cPanel это могут быть «Errors», «Metrics», «MultiPHP INI Editor» или журналы конкретного домена. В ISPmanager ищите разделы со словами «Журналы», «WWW-домены», «PHP», «Логи» или «Ошибки». В собственной панели хостера ориентируйтесь не на точное название из инструкции, а на смысл: нужен журнал выполнения сайта или PHP для конкретного домена.
Сначала откройте проблемную страницу ещё один раз, затем сразу обновите журнал. Смотрите записи с текущим временем. Это помогает не перепутать свежую поломку со старой ошибкой, которая произошла неделю назад и уже не имеет отношения к белому экрану.
Для рабочего сайта безопаснее получать подробности из журнала, а не показывать их всем посетителям. Сообщение PHP может раскрывать полный путь к файлу, внутренние имена каталогов, название используемой библиотеки и другие технические детали. Поэтому постоянный display_errors = On на публичном сайте — плохое решение. Если панель позволяет управлять параметрами PHP, для обычной работы оставляйте отображение ошибок выключенным, а журналирование — включённым.
Если журнал пустой, убедитесь, что вы смотрите лог именно нужного домена и нужной версии PHP. На одном аккаунте может быть несколько сайтов, каждый со своими журналами. Если панель вообще не показывает PHP-лог, поддержка хостинга обычно может подсказать его расположение или проверить свежую серверную ошибку по времени запроса.
Как читать типичные ошибки, не будучи программистом
В длинной строке лога не пытайтесь понять каждое слово. Сначала найдите тип ошибки, путь к файлу и номер строки. Часто этого уже хватает, чтобы связать поломку с последним изменением.
Parse error или Syntax error
PHP не может разобрать код. Такое бывает после ручной правки файла, незавершённой загрузки или ошибки при объединении двух версий. Если лог указывает на недавно изменённый файл, сравните его с резервной копией. Не исправляйте наугад десятки соседних строк: реальная ошибка иногда находится чуть выше указанного номера.
Uncaught Error, Call to undefined function или Class not found
Код пытается вызвать функцию или класс, которого сейчас нет. Причиной может быть отсутствующее PHP-расширение, неполная загрузка файлов, сломанная автозагрузка зависимостей или несовместимость кода с выбранной версией PHP. Здесь особенно бесполезно просто увеличивать лимиты памяти.
Allowed memory size exhausted
Процесс исчерпал выделенную PHP память. Однократное разумное увеличение memory_limit иногда действительно помогает тяжёлому импорту или обработке изображения, но постоянный рост потребления может означать цикл, слишком большой запрос или ошибку приложения. Увеличивать лимит до максимально возможного значения без понимания причины не стоит.
Failed opening required или No such file or directory
Приложение ожидает файл, которого нет по указанному пути. Проверьте, полностью ли загрузился архив сайта, не отличается ли регистр букв в имени и не был ли файл удалён при обновлении. На Linux-хостинге Config.php и config.php могут восприниматься как разные имена.
Permission denied
PHP не может прочитать файл, открыть каталог или записать данные. Не лечите это установкой прав 777 на весь сайт. Сначала сравните права с соседними рабочими файлами и уточните рекомендуемые значения у хостера. Иногда проблема не в цифрах доступа, а во владельце файла после переноса.
Maximum execution time exceeded
Скрипт выполнялся слишком долго. Увеличение таймаута может быть оправдано для известной тяжёлой операции, но если обычная главная страница внезапно выполняется десятки секунд, лучше искать зависший запрос к базе, внешний сервис или цикл в коде.
Если белый экран появился после смены версии PHP
В панели хостинга найдите раздел, похожий по смыслу на «Версия PHP», «PHP Selector», «MultiPHP Manager» или настройки WWW-домена. Сначала запишите текущую версию и список включённых расширений. Не переключайте варианты один за другим без фиксации результата.
Если сайт гарантированно работал на предыдущей версии PHP и перестал открываться сразу после переключения, временный возврат к последней рабочей конфигурации — нормальный диагностический шаг. Если сайт ожил, причина почти наверняка связана с совместимостью кода или расширений. Это не означает, что нужно навсегда оставаться на устаревшей версии: следующий шаг — обновить приложение или исправить несовместимый участок, а затем повторно проверить его на актуальной поддерживаемой версии.
После смены PHP проверьте расширения, которые требуются сайту: например, драйвер базы данных, обработку изображений, XML, ZIP или другие модули. Конкретный набор зависит от проекта. Не включайте все доступные расширения «на всякий случай» — ориентируйтесь на документацию движка и сообщение в логе.
Если панель содержит MultiPHP INI Editor или похожий редактор параметров, меняйте настройки для нужного домена, а не глобально для всего аккаунта. На shared-хостинге разные сайты одного владельца могут работать на разных конфигурациях.
Почему лучше откатить последнее изменение, чем чинить всё сразу
Если сайт работал утром, а после загрузки нового файла стал белым, первым подозреваемым должен быть этот файл. То же относится к обновлению CMS, модуля, шаблона, библиотеки и изменению конфигурации. Чем меньше действий между рабочим и сломанным состоянием, тем проще найти причину.
Откатывайте по одному изменению и каждый раз проверяйте результат. Если одновременно заменить PHP-версию, восстановить базу, перезаписать .htaccess и загрузить старый архив, вы можете получить работающий сайт, но так и не узнать причину. При следующем обновлении проблема повторится.
При частично завершившейся загрузке через FTP сравните размер и количество файлов с исходным архивом. Нулевой размер PHP-файла или отсутствующая библиотека способны дать белую страницу сразу на всём сайте.
Если перед поломкой менялась база данных, не импортируйте старый дамп поверх текущей базы вслепую. Сначала сохраните текущую копию. Иначе можно восстановить сайт ценой потери новых заказов, заявок, пользователей или контента.
Когда виноваты кеш, DNS или другой сервер
Обычная PHP-ошибка не исправляется очисткой DNS, но после переноса сайта ситуация может выглядеть странно: у владельца белый экран, а у другого человека всё работает. Если недавно менялись DNS-записи домена, разные провайдеры некоторое время могут обращаться к разным серверам из-за кеширования записей.
Обновление DNS часто становится заметно через несколько минут или часов, но полное обновление кешей у разных резолверов может занять до 24–48 часов в зависимости от TTL и предыдущего кеша. Поэтому после переезда сначала убедитесь, что записи A, AAAA или CNAME соответствуют данным нового хостинга. Не меняйте DNS повторно каждые несколько минут: так диагностика только усложнится.
Если DNS не менялся, проверьте кеш приложения, PHP OPcache и CDN, если он используется. После исправления PHP-файла старая страница иногда ещё некоторое время отдаётся из кеша. Но очистка кеша имеет смысл только после того, как причина ошибки найдена, а не вместо чтения журнала.
Как понять, что проблема действительно решена
Недостаточно увидеть главную страницу один раз. После исправления проверьте несколько типов страниц и основные действия сайта: открытие карточек или статей, авторизацию, форму обратной связи, поиск, корзину или другой важный функционал проекта.
Затем снова откройте журнал PHP. Если свежих Fatal Error и Parse Error больше нет, это хороший признак. Отдельные Warning или Deprecated требуют оценки по контексту, но они не должны автоматически считаться причиной прежнего белого экрана.
Если для диагностики вы временно включали показ ошибок посетителю, обязательно отключите его после проверки. Рабочий сайт должен записывать технические ошибки в журнал, а пользователю показывать нормальную страницу или безопасное сообщение приложения.
Наконец, зафиксируйте причину: какой файл, модуль, PHP-версия или настройка вызвала сбой и что было сделано. Такая короткая запись экономит много времени при следующем обновлении или переносе.
Когда лучше остановиться и не экспериментировать
Не продолжайте случайные изменения, если в журнале появились ошибки базы данных, повреждения таблиц, сообщения о невозможности загрузить основной конфигурационный файл или проблема возникла после взлома сайта. В таких ситуациях последовательность действий важнее скорости.
Также лучше остановиться, если единственная актуальная резервная копия находится на том же хостинге и вы не уверены, что она рабочая; если сайт принимает оплаченные заказы; если в базе есть новые данные, которые нельзя потерять; либо если для восстановления предлагают удалить базу и импортировать старую копию без предварительного сохранения текущей.
Не отключайте проверку SSL, не ставьте права 777 на весь сайт и не размещайте пароли в открытых диагностических файлах. Эти действия иногда маскируют исходную проблему, одновременно создавая новую уязвимость.
Если из лога понятно только то, что ошибка находится внутри чужого модуля или сложной цепочки библиотек, сохраните сам лог, время возникновения ошибки и список последних изменений. Этого уже достаточно, чтобы специалист начал диагностику не с нуля.
Частые вопросы
Нужно ли включать display_errors, если сайт показывает белый экран?
Не обязательно. Сначала лучше открыть журнал PHP на хостинге. На публичном сайте подробные ошибки безопаснее записывать в лог. Показ ошибок посетителям имеет смысл включать только временно для диагностики и затем обязательно отключить.
Почему после смены PHP сайт стал белым?
Новая версия PHP может быть несовместима со старым кодом, а также может отличаться набор включённых расширений. Проверьте свежую запись в логе, текущую версию PHP и модули. Если до переключения сайт работал, временный возврат к последней рабочей конфигурации поможет подтвердить причину.
Можно ли поставить права 777, чтобы сайт снова заработал?
Не стоит. Права 777 дают чрезмерный доступ и не устраняют многие реальные причины Permission denied. Сравните права с рабочими файлами и используйте значения, рекомендованные вашим хостером.
Что делать, если в панели хостинга нет PHP error log?
Поищите разделы «Ошибки», «Журналы», «Logs», «WWW-домены» или настройки конкретного сайта. Названия отличаются у cPanel, ISPmanager и собственных панелей. Если журнала действительно нет, сообщите поддержке домен и точное время воспроизведения ошибки.
Почему сайт работает у одного человека, но показывает ошибку у другого?
После недавнего переноса это может быть связано с DNS-кешем и обращением к разным серверам. В других случаях проверьте CDN, кеш приложения и балансировку. Если DNS недавно менялся, обновление у разных провайдеров может происходить не одновременно.
Читайте также:
Вывод
Белый экран PHP-сайта лучше диагностировать не подбором случайных настроек, а по цепочке: зафиксировать симптом → сохранить изменяемые файлы → открыть свежий лог → определить файл и тип ошибки → проверить последнее изменение → исправить одну причину → повторно проверить сайт и журнал.
Такой подход одинаково полезен на cPanel, ISPmanager и большинстве панелей shared-хостинга, даже если названия пунктов отличаются. Если сайт коммерческий, содержит важную базу или ошибка появилась после переноса, обновления PHP либо массовой загрузки файлов, настройку хостинга и восстановление сайта можно поручить CompMaster / Remote Help — без экспериментов над единственной рабочей копией.