Зеленый статус в панели хостинга означает далеко не то же самое, что работающий сайт. Сервер может быть доступен, пока приложение не подключается к базе или не получает ресурсов для ответа. Чтобы вернуть сайт, нужно определить, на каком участке обрывается запрос, и передать исполнителю именно эти наблюдения.
Сервер сайта не работает — или проблема видна только вам
Сначала зафиксируйте точный адрес страницы, время с часовым поясом и текст ошибки. Сравните открытие той же публичной страницы с компьютера и телефона через мобильную сеть: как отличить проблему браузера от поломки сайта, разобрано отдельно. Если сбой виден в одной сети, это повод проверить ее маршрут и DNS; если в нескольких — расширить проверку. Это еще не доказывает вину хостинга.
Уточните масштаб: недоступна главная, отдельный раздел или весь сайт. Запишите, постоянно ли возникает ошибка, когда было последнее успешное открытие и что меняли перед сбоем. Запись «сайт не открывается с 14:10 по Москве в двух сетях» полезнее, чем «сервер упал».
Панель управления — отдельная точка проверки. Даже если она открывается, запрос посетителя к домену может не доходить до приложения.
DNS, HTTPS и ответ сайта: три разных вопроса
Попросите специалиста обозначить последний подтвержденный этап: домен разрешается в ожидаемый адрес, соединение устанавливается, приходит HTTP-ответ. DNS помогает найти адрес сервера, а HTTP используется для запроса и передачи ресурсов — это разные части загрузки, описанные в документации MDN.
Ошибка DNS направляет проверку к настройкам домена и разрешению имени. Предупреждение HTTPS требует проверки защищенного соединения; обходить его и отключать проверку сертификата не нужно. Если сервер вернул страницу ошибки, сохраните ее код и адрес: ответ еще не означает, что нужное приложение исправно.
Коды 500, 503 и 504 помогают сузить поиск, но сами по себе не назначают виновного. Для разбора конкретного тайм-аута есть отдельная статья об ошибке 504; здесь важнее получить от исполнителя вывод об участке сбоя.
Ответ хостинга должен содержать границу проверки
Границы работ зависят от услуги и договора. На виртуальном хостинге и на сервере без администрирования они различаются: нельзя заранее считать, что провайдер обслуживает все установленное ПО. Например, для Amazon EC2 управление гостевой ОС и установленными программами отнесено к стороне заказчика в документации AWS. Свой тариф нужно сверять отдельно.
В обращение приложите собранные адреса, время, текст ошибки и результаты из разных сетей. Вместо вопроса «почему не работает хостинг сайта» запросите конкретные ответы:
- Был ли в этот интервал инцидент сети, оборудования или хранилища, затрагивающий вашу услугу?
- Есть ли ограничения или блокировки для услуги, превышения выделенных ресурсов?
- До какого компонента доходит запрос к указанному домену и чем это подтверждается?
- Какие проверки выполнены и что передается администратору сервера или разработчику?
Ответ «сервер включен» закрывает только этот вопрос. Попросите указать время проверки и наблюдение, на котором основан вывод. Если поддержка не проверяет приложение по условиям услуги, нужен следующий исполнитель с четко названной задачей, а не повторное обращение с тем же описанием.
Задача разработчику: связать PHP, базу и ресурсы
Передайте разработчику ответ хостинга вместе с исходными наблюдениями. Попросите сопоставить журналы приложения и серверных служб за один интервал, проверить последние изменения и объяснить, какое из них связано со сбоем. Если он не администрирует сервер, назначьте администратора и ответственного за общий вывод.
По PHP нужен ответ, принимает ли обработчик запросы и не образуется ли очередь; по базе — устанавливается ли соединение и выполняются ли запросы приложения. По диску и правам — хватает ли места и может ли приложение читать и записывать нужные файлы. По нагрузке — какой процесс и какой ресурс ограничивают работу в момент ошибки. Это вопросы исполнителю, а не предложение владельцу менять настройки наугад.
До перезапуска попросите сохранить доступные журналы и показатели. Например, счетчики очереди и достижения лимита процессов PHP-FPM сбрасываются при его перезапуске — это указано в руководстве PHP. Успешное открытие после рестарта подтверждает текущую доступность, но не объясняет причину остановки.
Результат диагностики должен помещаться в понятную запись: где обнаружен сбой, какое наблюдение его подтверждает, кто исправляет и как проверяется результат. Если причина пока не установлена, так и фиксируют, отдельно от временного восстановления.
Исправление или перенос: чем закончить восстановление
Когда найден дефект конфигурации или приложения, сначала оценивают его исправление на текущей площадке. Перенос обсуждают, если подтвержденные ограничения инфраструктуры не позволяют обеспечить работу или условия обслуживания не подходят проекту. Переезд с той же ошибкой в коде не заменяет исправление; до него нужен план переноса без потери SEO.
После работ повторите исходные проверки адресов из разных сетей, включая раздел, где возникал сбой. Согласуйте проверку основных действий пользователя и период наблюдения, охватывающий условия прежней ошибки. Исполнитель должен подтвердить по журналам и показателям, что симптом не повторяется в этот период, а владелец — получить список изменений и ответственного на случай повторения.
Для начала диагностики подготовьте адрес сайта, время сбоя и ответ хостинга. По этим данным можно определить следующий участок проверки и согласовать состав восстановления, не превращая владельца в посредника между двумя поддержками.