Если сайт на 1С-Битрикс не открывается, сначала нужно определить уровень сбоя. Одинаковый белый экран в браузере может означать неверный DNS, истекший сертификат, остановленный nginx, ошибку PHP после обновления, недоступную базу данных, сбой обработчика в local/php_interface/init.php или поврежденный кеш. Попытка сразу переустановить ядро или удалить все временные каталоги часто уничтожает полезные следы и добавляет новые проблемы.

Безопасная диагностика идет снаружи внутрь: домен и TLS, HTTP-ответ, веб-сервер, PHP-FPM, база данных и только затем код 1С-Битрикс. Перед изменениями сохраняют конфигурацию, журналы, список последних обновлений и резервную копию базы. Отладочные сообщения не выводят посетителям, потому что они могут раскрыть пути, SQL и параметры окружения.

Определите масштаб и точный симптом

Проверьте сайт из другой сети и без старого кеша браузера. Уточните, недоступны все страницы или только каталог, карточка товара, оформление заказа и административная часть. Если статический файл открывается, а PHP-страницы нет, DNS и веб-сервер, скорее всего, работают, а поиск сужается до PHP и приложения. Если не открывается только `/bitrix/admin/`, причина может быть в авторизации, сессиях, правилах доступа или отдельном обработчике.

  • какой HTTP-код возвращается: 301, 403, 404, 500, 502, 503 или 504;
  • есть ли ошибка сертификата, DNS или невозможность установить соединение;
  • открывается ли статический файл в корне сайта;
  • работает ли административная часть отдельно от публичной;
  • видят ли проблему все пользователи или только один регион и провайдер;
  • когда сайт работал последний раз и что менялось перед сбоем;
  • есть ли рост времени ответа, памяти, CPU, диска или числа соединений.

Зафиксируйте время проверки с точностью до минуты и request id, если он есть в заголовках. Это позволит сопоставить запрос с журналами nginx, Apache, PHP-FPM и приложения. Скриншот без URL, времени и HTTP-кода почти не помогает определить источник ошибки.

Сначала проверьте DNS, сертификат и внешний HTTP-ответ

Если домен указывает не на тот IP, PHP и Битрикс на рабочем сервере вообще не участвуют в запросе. Сравните A и AAAA, проверьте вариант с www и без него, убедитесь, что IPv6 действительно настроен. После переноса часть пользователей может попадать на старый адрес из-за TTL или локального кеша. Проверяйте авторитетные DNS-серверы и фактический адрес подключения, а не только результат одного онлайн-сервиса.

Ошибка TLS возникает до выполнения CMS. Проверьте срок сертификата, цепочку, соответствие имени, SNI и конфигурацию нужного виртуального хоста. Не отключайте HTTPS и проверку сертификата как постоянное решение. Временно сравнить HTTP и HTTPS можно только для диагностики, не передавая учетные данные по незащищенному соединению.

curl -I https://example.ru/ curl -I https://www.example.ru/ nslookup example.ru

Команды выполняют с заменой домена на свой. Они не изменяют сервер и показывают код, редиректы и доступность. Бесконечный цикл 301/302 часто связан с противоречивыми правилами HTTPS, прокси или настройкой доверенных заголовков, а не с ядром Битрикс.

Расшифруйте HTTP-код до изменения файлов

  • 403 — проверьте права, владельца, правила доступа, WAF и конфигурацию location;
  • 404 для всех PHP-страниц — проверьте document root, index и правила маршрутизации;
  • 500 — ищите исключение PHP, fatal error, ошибку конфигурации или приложения;
  • 502 — веб-сервер не получил корректный ответ от PHP-FPM или upstream;
  • 503 — сервис временно недоступен, исчерпан пул или включена заглушка обслуживания;
  • 504 — upstream не завершил обработку вовремя: возможны база, внешний API или тяжелый код;
  • 200 с пустым телом — возможна скрытая PHP-ошибка, преждевременный exit или неверный шаблон.

Один код не доказывает причину, но определяет следующий журнал. При 502 нет смысла очищать кеш CMS до проверки PHP-FPM. При ошибке DNS бессмысленно менять `.settings.php`. Такой порядок сокращает время восстановления и уменьшает число случайных изменений.

Проверьте веб-сервер и PHP-FPM

Убедитесь, что nginx или Apache и нужный пул PHP запущены, виртуальный хост указывает на правильный каталог, сокет или порт совпадает с конфигурацией. После обновления PHP имя сокета может измениться, а старый путь останется в nginx. При нескольких сайтах важно проверить именно тот pool, от которого работает Битрикс.

  • статус сервиса и причина последнего перезапуска;
  • наличие свободного места и inode на разделах с сайтом, логами и временными файлами;
  • лимит процессов PHP-FPM, очередь listen и сообщения pool exhausted;
  • права на сокет PHP-FPM и соответствие пользователя веб-сервера;
  • корректный document root и запрет выполнения PHP в каталогах загрузки;
  • таймауты веб-сервера, FastCGI и балансировщика;
  • ошибки OOM и принудительное завершение процесса ядром.

Не увеличивайте таймауты и лимиты памяти до бесконечности. Если запрос зависает на блокировке базы или внешнем API, больший таймаут лишь удержит больше процессов и ускорит исчерпание пула. Сначала найдите длительный этап по журналам и slow log.

Смотрите журналы в момент контрольного запроса

Запросите одну безопасную страницу и сразу проверьте error log веб-сервера, журнал PHP-FPM и журнал приложения. Ищите запись по времени, URI, IP тестового клиента или request id. Старые ошибки могут не относиться к текущему сбою. Если журнал огромный, не удаляйте его перед диагностикой: настройте ротацию после сохранения нужного фрагмента.

  • PHP Fatal error и Uncaught exception с первым файлом проекта в стеке;
  • Allowed memory size exhausted и размер выделения;
  • Maximum execution time exceeded с местом остановки;
  • Permission denied, No such file or directory и open_basedir;
  • ошибки подключения MySQL и превышение max connections;
  • не найденный класс, функция или расширение после смены PHP;
  • ошибки загрузки модуля или обработчика событий Битрикс;
  • upstream timed out и prematurely closed connection.

Публичный `display_errors` на рабочем сайте оставляют выключенным. Для временной диагностики направляют подробности в защищенный журнал, доступный только администратору. После исправления отладочный режим возвращают в обычное состояние и проверяют, что логи не содержат пароли, токены и персональные данные.

Проверьте совместимость PHP и обязательные расширения

Сайт может перестать открываться сразу после переключения версии PHP. Причиной бывает несовместимый код шаблона или модуля, удаленная функция, более строгая обработка типов, неподходящая версия ionCube или отсутствующее расширение. Сравните версию CLI и версию PHP-FPM: команда в консоли может запускать другой бинарный файл и другой php.ini.

Проверьте требования установленной версии 1С-Битрикс и сторонних модулей. Наличие расширений mysqli, mbstring, curl, json, xml, zip, gd или imagick зависит от функций проекта. Не устанавливайте случайный набор и не понижайте PHP без резервной копии. Если откат необходим для восстановления, зафиксируйте его как временную меру и подготовьте совместимое обновление кода.

Проверьте подключение к базе в `.settings.php` и `dbconn.php`

Современная конфигурация подключения обычно находится в `/bitrix/.settings.php`, а старые проекты могут использовать `/bitrix/php_interface/dbconn.php` или сочетание настроек. После переноса меняются host, имя базы, пользователь, пароль, порт или сокет. Ошибка подключения может выглядеть как пустая страница, 500 или долгое ожидание.

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

  • есть ли свободное место у MySQL и не включен ли read-only режим;
  • не достигнут ли лимит соединений;
  • нет ли долгих блокировок и зависших транзакций;
  • совпадает ли кодировка и collation с ожидаемой конфигурацией;
  • не изменилась ли политика TLS или метод аутентификации пользователя;
  • работают ли отдельные реплики и не отправлена ли запись на read-only узел.

Прямое изменение системных таблиц Битрикс ради быстрого восстановления опасно. Сначала восстановите обычное подключение и получите точную ошибку. Если база повреждена, работайте с копией и штатными средствами СУБД, а не выполняйте случайные repair-команды на единственном экземпляре.

Изолируйте пользовательский код и обработчики событий

Частая причина полного падения — код, который подключается при каждом запросе: `/local/php_interface/init.php`, старый `/bitrix/php_interface/init.php`, автозагрузчик, обработчик события или bootstrap собственного модуля. Ошибка в редкой функции могла существовать давно, но проявиться после обновления PHP или библиотеки.

На копии сайта или в коротком контролируемом окне временно изолируйте последний измененный обработчик, а не переименовывайте весь каталог local. Делайте одно изменение за раз и сохраняйте возможность отката. Если сайт открылся, это еще не доказывает окончательное исправление: найдите конкретную строку, восстановите необходимую логику и протестируйте связанные события.

  • сравните файлы с последней рабочей версией в Git или резервной копии;
  • проверьте порядок автозагрузки и регистр имени файла на Linux;
  • ищите преждевременный exit, die, редирект и вывод до заголовков;
  • проверьте подключение внешнего API без таймаута в глобальном обработчике;
  • не выполняйте тяжелые запросы и синхронизацию при каждом открытии страницы;
  • оберните необязательную интеграцию контролируемой обработкой ошибки, но не скрывайте исключение пустым catch.

Проверьте сторонние модули и результат обновления

Если сбой начался после обновления ядра или модуля, зафиксируйте точный список измененных пакетов. Не копируйте весь каталог `/bitrix/modules` из случайной версии: ядро, база и обновления должны быть согласованы. Частично прерванное обновление может оставить новые файлы при незавершенной миграции базы или наоборот.

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

Очищайте кеш только после сохранения причины

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

Если административная часть доступна, используйте штатную очистку нужного типа кеша. При недоступной CMS удаляйте только документированные временные данные, заранее сохранив копию и исключив пользовательские загрузки. Каталог `/upload` не является кешем. После очистки откройте одну страницу, следите за CPU, базой и логами, затем постепенно проверяйте остальные разделы.

Проверьте `.htaccess`, rewrite и маршрутизацию Битрикс

Если главная открывается, а ЧПУ-страницы возвращают 404 или цикл редиректов, сравните правила веб-сервера, `.htaccess`, `urlrewrite.php` и настройки виртуального хоста. При переносе с Apache на nginx директивы `.htaccess` не выполняются автоматически. Нужен эквивалентный `try_files` или согласованная конфигурация маршрутизации.

Не направляйте все запросы без исключений в один PHP-файл: статические ресурсы, служебные каталоги и реальные файлы должны обрабатываться корректно. Проверьте base path, подкаталог установки, несколько сайтов в одной инсталляции и правила HTTPS. Изменяйте редиректы с отдельным тестом www, без www, HTTP, HTTPS и нескольких типовых URL.

Если сайт медленно открывается и уходит в 504

504 часто возникает из-за тяжелого запроса к базе, зависшего внешнего API, блокировки сессии, бесконечного агента в hit-режиме или исчерпанного пула PHP. Проверьте slow query log, PHP-FPM slowlog и длительность внешних вызовов. У каждого HTTP-клиента должны быть разумные connect и total timeout, а необязательная интеграция не должна блокировать отрисовку всей страницы.

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

Исключите нехватку диска и неверные права

При заполненном диске Битрикс не записывает кеш, сессии, временные файлы и логи. MySQL может перейти в аварийное состояние. Проверьте не только гигабайты, но и inode. Найдите источник роста: резервные копии в web-root, логи без ротации, временные архивы, кеш изображений или неочищаемые сессии.

Не применяйте `chmod -R 777` как универсальное решение. Оно расширяет возможность записи и маскирует неверного владельца. Определите пользователя PHP-FPM, группу деплоя и каталоги, которым действительно нужна запись. Файлы ядра и конфигурации не должны быть доступны для изменения любому процессу. После исправления проверьте создание кеша и загрузку тестового файла штатным интерфейсом.

Пошаговый порядок безопасного восстановления

  1. зафиксируйте URL, время, HTTP-код, масштаб сбоя и последние изменения;
  2. сохраните конфигурацию, журналы и резервную копию базы перед правками;
  3. проверьте DNS, TLS, внешний HTTP-ответ и цепочку редиректов;
  4. подтвердите работу веб-сервера, PHP-FPM, диска и нужного виртуального хоста;
  5. выполните один контрольный запрос и найдите его в error log и PHP-журнале;
  6. сравните версию PHP, расширения и конфигурацию FPM с требованиями проекта;
  7. проверьте безопасным способом подключение к базе и состояние MySQL;
  8. изолируйте последнее изменение в init.php, модуле, шаблоне или обработчике;
  9. проверьте результат обновления и согласованность файлов с базой;
  10. очищайте только нужный кеш после фиксации первопричины;
  11. восстановите страницу, затем административную часть и критичные бизнес-сценарии;
  12. удалите временную диагностику, обновите мониторинг и задокументируйте причину.

Как проверить сайт после исправления

  • главная, типовая внутренняя страница и реальный 404 возвращают правильные коды;
  • административная часть открывается только после штатной авторизации;
  • работают каталог, поиск, корзина, заказ и платежный callback;
  • отправляются почтовые события и выполняются нужные агенты;
  • обмен с 1С, CRM, доставкой и складом не создает дубли;
  • загрузка файлов сохраняет ограничения типа и каталога;
  • в error log нет новых fatal error, timeout и повторяющихся предупреждений;
  • время ответа и использование PHP-FPM вернулись к базовым значениям;
  • после перезапуска сервисов сайт продолжает работать;
  • резервная копия создается и проходит тест восстановления.

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

Типичные ошибки при восстановлении 1С-Битрикс

  • включить публичный вывод PHP-ошибок и раскрыть конфигурацию посетителям;
  • удалить весь кеш и логи до фиксации первопричины;
  • выдать всем файлам права 777 вместо исправления владельца;
  • заменить ядро файлами от другой версии без согласования с базой;
  • понизить PHP и считать временный откат окончательным решением;
  • увеличить timeout при зависшей базе или внешнем API;
  • переименовать весь каталог local и потерять бизнес-логику;
  • редактировать рабочую базу вручную без копии и точного плана;
  • очищать `/upload`, принимая пользовательские файлы за кеш;
  • проверить только браузер администратора и не увидеть проблему внешней сети;
  • восстановить открытие страниц, но не проверить заказы, почту и обмены;
  • оставить временные отладочные файлы и тестовые endpoint в web-root.

Как предотвратить повторное падение сайта

Обновления ядра, модулей и PHP сначала проверяйте на staging-копии с обезличенной базой. Код проекта храните в системе контроля версий, а конфигурацию окружения — отдельно от репозитория и web-root. Перед релизом создавайте согласованную резервную копию файлов и базы, после релиза запускайте короткий smoke test критичных сценариев.

  • мониторьте HTTP-код, время ответа, срок TLS и доступность из внешней сети;
  • настройте ротацию логов, контроль диска, inode, памяти и пула PHP-FPM;
  • используйте slowlog PHP и slow query log с разумными порогами;
  • задавайте timeout и fallback для внешних API;
  • не выполняйте тяжелую синхронизацию в глобальном обработчике страницы;
  • регулярно проверяйте резервные копии восстановлением на отдельном контуре;
  • ограничивайте права PHP и запрещайте выполнение скриптов в каталогах загрузки;
  • фиксируйте версии PHP, расширений, ядра и сторонних модулей;
  • держите понятный план отката, который не перезаписывает новые рабочие данные.

Когда нужна помощь с восстановлением Битрикс

Если сайт на 1С-Битрикс не открывается, возвращает 500/502/504 или упал после обновления, я могу определить уровень сбоя, проверить сервер, PHP, базу, конфигурацию и пользовательские обработчики, затем восстановить работу с резервной копией и контрольными тестами. Сначала сохраняются журналы и текущие данные, после исправления проверяются административная часть, заказы, почта и обмены. Для оценки достаточно домена, времени начала сбоя, HTTP-кода и обезличенного фрагмента ошибки; пароли, ключи лицензии и доступы в открытом сообщении передавать не нужно.