Интернет-магазин OpenCart перестал открываться: браузер показывает HTTP 500, белый экран, бесконечный редирект, ошибку базы данных или сообщение от хостинга. Первое желание — очистить все кеши, обновить CMS или заменить файлы ядра. Такие действия без диагностики часто уничтожают полезные следы ошибки и добавляют новую проблему поверх исходной.

Восстанавливать магазин безопаснее по слоям: домен и TLS, CDN или прокси, веб-сервер, PHP, база данных и только затем OpenCart, тема и расширения. На каждом шаге нужно получить проверяемый факт и не менять production до резервной копии.

Сначала уточните, что именно не открывается

  • не отвечает весь домен, включая статические изображения и robots.txt;
  • главная страница падает, но панель администратора доступна;
  • витрина работает, а административная часть возвращает ошибку;
  • не открывается только карточка товара, корзина или оформление заказа;
  • ошибка видна только по HTTPS, через www или после подключения CDN;
  • магазин открывается у владельца, но недоступен из другой сети или страны.

Проверьте сайт из мобильной сети и через внешний HTTP-монитор, но не делайте вывод по одному браузеру. Запишите точный URL, HTTP status, время, текст ошибки и последние изменения: обновление модуля, смена PHP, перенос, выпуск сертификата, правка DNS или заполнение диска.

Что сделать до исправлений

  1. Сохраните копию файлов магазина, базы данных и конфигурации веб-сервера.
  2. Зафиксируйте текущую версию OpenCart, PHP, тему и недавно измененные расширения.
  3. Скопируйте журналы за период сбоя, пока ротация не удалила нужные строки.
  4. Если магазин частично работает, включите контролируемую страницу обслуживания без изменения данных заказов.
  5. Не запускайте обновление и не восстанавливайте старый бэкап до определения причины.

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

Быстрая диагностика по HTTP-ответу

curl -I https://example.com/ curl -I https://example.com/image/catalog/test.jpg curl -I https://example.com/admin/ # Проверяйте status, Location, Server и время ответа
  • ошибка DNS или timeout указывает на домен, сеть, firewall либо недоступный сервер;
  • 502 и 504 обычно означают, что прокси не получает корректный ответ от PHP-FPM или upstream;
  • 500 требует проверки журналов PHP, веб-сервера и OpenCart;
  • 403 связан с правами, правилами безопасности, WAF или конфигурацией виртуального хоста;
  • 404 на всех динамических URL при рабочей главной часто связан с rewrite-конфигурацией;
  • цикл 301/302 появляется при конфликте HTTPS, www, CDN и настроек URL магазина.

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

Где искать настоящую ошибку OpenCart

Путь к журналу зависит от версии и конфигурации. Ориентируйтесь на константу каталога логов и настройки storage, а не на случайный путь из чужой инструкции. Обычно нужны сразу три источника: журнал OpenCart, error log веб-сервера и журнал PHP-FPM.

  • OpenCart показывает исключения модулей, событий, моделей и запросов к базе;
  • PHP-FPM фиксирует fatal error, нехватку памяти, timeout и падение worker;
  • Nginx или Apache показывает upstream error, запрет доступа, rewrite loop и отсутствующий файл;
  • MySQL или MariaDB сообщает об отказе подключения, блокировках, повреждении таблиц и нехватке места;
  • журнал CDN или WAF объясняет блокировку запроса до сервера.

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

Частые причины, по которым OpenCart не открывается

Несовместимая версия PHP или расширения

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

Ошибка в config.php или admin/config.php

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

База данных недоступна

Причиной бывает неверный host, смена пароля, превышение лимита соединений, остановленный MySQL, заполненный диск или долгий запрос. Подключение нужно проверять с того же сервера и с теми же параметрами, что использует магазин. Не тестируйте production-пароль через сторонние сайты.

Закончились место или inode

При заполненном диске PHP не пишет сессии и кеш, база не создает временные файлы, а журналы перестают обновляться. Отдельно проверяйте свободные гигабайты и inode. Сначала найдите источник роста — логи, backup, изображения, кеш или временные файлы — и только затем удаляйте безопасные данные.

Сломался модуль, тема или система модификаций

Ошибка часто появляется после установки OCMOD, обновления расширения или изменения темы. Нельзя просто удалить папку модуля: его события, настройки и модификации могут остаться в базе или кеше. Восстановите предыдущую согласованную версию файлов и базы либо отключайте расширение по документированному сценарию.

Неверные права и владелец файлов

После распаковки от root веб-процесс может потерять доступ к storage, кешу, логам и загрузкам. Исправляйте владельца и минимально необходимые права для конкретных каталогов. chmod 777 не устраняет причину и создает риск записи постороннего кода.

Конфликт HTTPS, CDN и редиректов

Если CDN завершает TLS, а приложение считает запрос HTTP, OpenCart или веб-сервер может снова перенаправлять на HTTPS. Проверьте доверенные proxy headers, канонический домен, URL магазина и единое место, где выполняется редирект. Не добавляйте очередное правило наугад.

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

  1. Проверьте DNS, сертификат, доступность IP и ответ CDN или балансировщика.
  2. Убедитесь, что веб-сервер и PHP-FPM запущены, а сокет или порт upstream совпадает с конфигурацией.
  3. Проверьте диск, inode, память, нагрузку и лимиты процессов.
  4. Найдите первую релевантную ошибку в логах OpenCart, PHP и веб-сервера.
  5. Проверьте подключение к базе, но не выполняйте repair или изменение схемы без копии.
  6. Сопоставьте ошибку с последним изменением и подготовьте точечный rollback.
  7. Исправьте одну причину, очистите только соответствующий кеш и повторите проверку.
  8. После восстановления витрины отдельно протестируйте административную часть, корзину, заказ и фоновые задачи.

Как откатывать модуль или обновление

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

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

Официальные рекомендации OpenCart также предполагают полную копию файлов и базы перед обновлением и предварительное тестирование на staging. Для интернет-магазина откат только файлов без базы может оставить несовместимую схему данных.

Что не стоит делать

  • включать display_errors для всех посетителей и показывать пути, SQL и секреты;
  • выдавать 777 всему сайту;
  • удалять storage, cache или modification целиком без понимания версии и назначения каталогов;
  • переустанавливать OpenCart поверх рабочего магазина;
  • восстанавливать вчерашнюю базу, не сохранив сегодняшние заказы и клиентов;
  • отключать WAF или firewall полностью вместо проверки конкретного правила;
  • менять PHP, Nginx, базу и модули одновременно — после этого причина останется неизвестной.

Проверка магазина после восстановления

  • главная, категории, поиск и карточки товаров возвращают корректные статусы;
  • изображения и стили загружаются без mixed content и 404;
  • регистрация, вход, корзина и оформление заказа работают в новой сессии;
  • тестовый платеж проходит только в разрешенном безопасном режиме;
  • письма, webhook, экспорт, cron и интеграции выполняются без очереди ошибок;
  • панель администратора доступна только ожидаемым пользователям;
  • журналы не получают новые fatal error, а место на диске стабильно;
  • внешний монитор видит сайт из нескольких точек и проверяет не только главную.

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

Настройте контроль HTTP, срока сертификата, свободного диска, PHP-FPM, базы и страницы оформления заказа. Храните ежедневные копии вне сервера и регулярно проверяйте восстановление. Любое обновление ядра, темы или расширения сначала проводите на staging с копией данных, где персональная информация обезличена.

Ведите журнал изменений: время, исполнитель, версия, список файлов, миграции и способ отката. Тогда фраза «сайт внезапно перестал работать» превращается в конкретное сравнение до и после деплоя.

Когда нужна помощь с OpenCart

Если OpenCart не открывается, я могу провести диагностику от DNS и PHP-FPM до базы, модулей и модификаций, безопасно восстановить магазин и проверить оформление заказа. Для оценки пришлите URL, время начала сбоя, HTTP status, версию OpenCart и PHP, последние изменения и фрагмент error log без паролей, токенов и персональных данных.