Сайт не запускается на новом хостинге: где искать проблему

Расскажем, что может случиться с сайтом при переезде, как это вовремя заметить и исправить, а по возможности — предотвратить.

Привет! Меня зовут Алексей Солдатов, я руководитель техподдержки SpaceWeb. В этой статье расскажу, какие проблемы возникают при смене хостинга — от самых частых до наименее очевидных.

Суть: при переносе потерялся один файл или несколько. Как правило, файлы теряются, если переносить папку с сайтом по FTP. При миграции по SSH риск потери файлов меньше.

Диагностика: зависит от того, какого файла не хватает. Если потерян:

Если проблема в исполняемых файлах, утилита strace поможет понять, в какой момент происходит обращение к несуществующему файлу.

Лечение: найти и заменить потерянный файл. Здесь нет гарантий, что он единственный и, когда вы его загрузите, сайт заработает. Другой вариант — заново скопировать все файлы.

Профилактика: для миграции использовать rsync. Утилита умеет копировать данные между серверами с гарантией сохранности. Если это невозможно, например у вас нет SSH-доступа к хостингу, надо сформировать архив, перенести его одним файлом и распаковать на новом хостинге.

Суть: базу данных (БД) перенесли на новый хостинг не полностью или не перенесли вообще. Это происходит, когда в дамп попадает не вся БД или его некорректно импортируют.

Диагностика: на некоторых страницах появляется ошибка 500 или пустые блоки. Чтобы убедиться, что проблема в БД, нужно посмотреть логи системы управления базой данных (СУБД). Там будет запись об обращении к несуществующей таблице или базе.

Лечение: скопировать на новый хостинг корректный дамп БД и восстановить базу. Чтобы выгрузить дамп, можно использовать SSH и утилиту mysqldump. Если версия mySQL будет совпадать, ошибка не должна повториться.

Суть: CMS не может получить доступ к базе данных. Это случается, когда не удаётся пройти аутентификацию, СУБД вообще не запущена или CMS ищет её по неправильному адресу.

Диагностика: на страницах сайта появляются пустые блоки и ошибки 500. Не работает вообще всё, что связано с БД. В логах БД нет записей, а в логах CMS есть записи о безуспешных обращениях к БД.

Лечение: проверить настройки СУБД и CMS — имя базы данных, имя пользователя, пароль, адрес и порт. Убедиться, что СУБД запущена и «слушает» тот порт, на который обращается CMS.

Суть: на новом хостинге установлены не те версии ПО, на которые рассчитан сайт, — например, более старая или новая версия PHP. Проблема проявляется по-разному — от полного отказа сайта до некорректной работы отдельных функций.

Диагностика: нужно смотреть error.log — там хранятся описания ошибок при обращении к сайту:

Лечение: установить на новый хостинг такие же версии ПО, как на старом, если есть root-доступ. Если root-прав нет, связаться с хостинг-провайдером. Он может обновить ПО, если обновление не нарушит работу для других пользователей. Другой вариант — внести изменения на сайт, чтобы он заработал с текущими версиями ПО.

Профилактика: выяснять, какое ПО есть на хостинге и есть ли у вас право его установки/переустановки, до того, как принимать решение о переезде.

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

Диагностика: сайт работает медленно или возникает ошибка «невозможно подключиться к серверу». Если появилась ошибка, то проблема в квотах — их можно узнать на панели управления хостингом — или в нехватке оперативной памяти.

Если тормозят страницы, на которых много динамических данных, значит, медленно работает БД. Не хватает оперативной памяти или скорости жёсткого диска. Частый случай — когда сайт перенесли с хостинга, где был SSD, на хостинг с HDD. Скорость работы с БД может ощутимо упасть.

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

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

Проблема: cайт хостится на сервере, который расположен физически далеко от месторасположения посетителей сайта. Например, серверы хостинг-провайдера размещены в дата-центре в одном регионе, а основная целевая аудитория сайта сконцентрирована в другом.

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

Лечение: перенести сайт в дата-центр, который ближе всего к вашим клиентам. Например, магазину цветов во Владивостоке нужен дата-центр на Дальнем Востоке, а не в Центральной России. Запросы будут обрабатываться быстрее.

Если проблема в скорости отдачи статики, её можно решить с помощью CDN — это сеть доставки контента. Дополнительные серверы кешируют статический контент, и, когда поступает запрос от пользователя, удалённого от главного сервера, часть данных отдаёт ближайший сервер CDN-сети. Скорость при этом выше.

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

Проблема: запрещено соединение между сайтом и внешним ресурсом, к которому он обращается. Например, IP-адрес хостинга находится в чёрном списке ресурса. Или, наоборот, IP-адрес ресурса находится в чёрном списке хостинга. Чаще всего такое бывает с зарубежными сервисами.

Диагностика: не работает функциональность, связанная со сторонним API. В error.log есть записи о том, что доступ к ресурсу запрещён.

Лечение: сменить IP, если проблема точечная и отдельному IP-адресу просто не повезло попасть под блокировку. Если блокировки распространяются на целую подсеть, нужно снова переезжать на новый хостинг или искать альтернативу стороннему API, в идеале — отечественную.

Профилактика: минимизировать зависимость от зарубежных сервисов.

Правило 1: настроиться на новом хостинге и только потом отключать старый

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

Сайт на новом хостинге можно разместить на отдельном техническом домене. Но некоторые платные CMS лицензируются под конкретный домен. Бесплатные CMS тоже бывают к нему «привязаны», — например, если он указывается в настройках, чтобы CMS могла генерировать правильные ссылки. Поэтому перенос на технический домен может привести к потере функциональности.

Но есть и другой путь: на компьютере, с которого будете тестировать сайт, откройте файл hosts и укажите, что ваш основной домен должен быть связан с IP-адресом нового хостинга.

Правило 2: проверять все сценарии использования сайта

Это поможет понять, насколько проблема глобальна и с чем связана. Например, если вы видите ошибку 500 на динамических страницах, а статика отдаётся нормально, можно поискать проблему с PHP.

Вы также увидите локальные малозаметные проблемы. Например, если сайт использует ImageMagick для ресайза изображений, проблема с версией ImageMagick проявится только при попытке изменить размер изображения.

Правило 3: использовать браузерные инструменты разработчика

Если сайт загружается, но вам кажется, что страница работает некорректно, откройте инструменты разработчика. В большинстве браузеров это клавиша F12. Перейдите на вкладку Network и перезагрузите страницу. Вы увидите все запросы, которые совершает браузер на странице. Это поможет понять проблему, если она не со страницей целиком, а с какой-то её частью, — например, когда не подгружаются стили.

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

А у вас бывали трудности при переносе сайта на новый хостинг? Как вы их диагностировали и исправляли? Делитесь мнением в комментариях!