Хостинг REG.RU — наплевать на клиента

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

Простои без предупреждения: самый заметный симптом

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

• Плановые работы, о которых не уведомили заранее или уведомили письмом в папку «Промоакции».
• Авария на уровне дата-центра: питание, сеть, канал связи.
• Перегрузка физического сервера, на котором вместе с вами живут ещё сотни сайтов.
• Миграция вашего аккаунта на другую ноду без согласования времени.
• Сбой веб-сервера или базы данных, который не перезапустили автоматически.

Полезно понимать, что скрывается за красивыми цифрами доступности в рекламе. Заявленные 99,9 процента — это около 43 минут простоя в месяц. 99,5 процента — уже примерно 3,5 часа. А 99 процентов, которые тоже иногда подают как достойный показатель, дают более семи часов недоступности ежемесячно. Для сайта, который приносит заявки, семь часов в месяц — это потерянные деньги и подпорченная репутация.

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

Медленный отклик сервера: когда тормозит не сайт

Второй по частоте сценарий выглядит мягче простоя, но бьёт по конверсии сильнее. Сайт открывается, но открывается долго: сначала белый экран на две-три секунды, потом всё разом. Классический признак того, что дело в сервере, а не в вёрстке, — плавающее время до первого байта. Сегодня страница отвечает за 300 миллисекунд, завтра та же самая страница без единой правки отвечает за четыре секунды, послезавтра снова за 300.

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

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

Блокировки за нагрузку и за вредоносный код

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

Блокировка за превышение нагрузки. На виртуальном хостинге вам выделяют долю ресурсов физической машины. Когда сайт систематически выходит за лимит, аккаунт приостанавливают, чтобы он не мешал соседям. Причиной бывает и реальный рост посещаемости, и тяжёлый плагин, и криво написанное расписание задач, которое запускает выгрузку каталога каждую минуту, и парсер, который методично обходит сайт в десять потоков. Здесь важно не спорить, а запросить конкретику: какие процессы дали пик, в какие минуты, какие URL запрашивались. Без этих данных разговор превращается в обмен эмоциями.

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

Устаревшее ПО, потерянные письма и отсутствие бэкапов

Эти три беды тихие. Они не роняют сайт, но медленно разрушают бизнес-процесс.

Подробнее об этом — в статье «Как выбрать хостинг для сайта».

Старые версии ПО. Если на площадке нельзя переключить версию PHP из панели, а предлагаемая ветка снята с поддержки, вы одновременно теряете скорость и получаете дыру в безопасности. Современные CMS и плагины рано или поздно перестают работать со старыми версиями, и однажды обновление просто не встанет. Тот же вопрос касается версии базы данных и наличия свежих модулей вроде кеширования байткода.

Письма с форм, которые не доходят. Самая обидная потеря — заявка, которую клиент отправил, а вы не увидели. Причины: отправка стандартной функцией напрямую с сервера без настроенной аутентификации домена, отсутствие корректных записей SPF и DKIM, попадание общего IP-адреса сервера в спам-листы из-за соседей, жёсткие лимиты на количество писем в час. Проверять надо не «пришло ли мне на почту», а весь путь: страница благодарности показалась, запись в журнале формы появилась, письмо ушло, письмо доставлено.

Помогу с продвижением: продвижение сайта в поиске — вывожу сайты в топ Яндекса белыми методами.

Бэкапы, которых нет. Фраза «резервные копии делаются» ничего не значит, пока вы не знаете три вещи: как часто, на какую глубину и сколько стоит восстановление. Копия суточной давности при ежедневном обновлении каталога — это потеря дня работы. Копия, которая хранится на том же диске, что и сайт, — не копия. И самое главное: восстановление надо хотя бы раз проверить в спокойной обстановке, а не в день аварии.

Как отличить проблему хостинга от проблемы сайта

Прежде чем писать гневное письмо, потратьте пятнадцать минут на диагностику. Порядок действий простой.

1. Замерьте время ответа главной страницы несколько раз подряд и запишите разброс. Стабильные значения говорят об одном, скачки от 0,2 до 5 секунд — совсем о другом.
2. Положите в корень сайта отдельную лёгкую страницу без подключения CMS и замерьте её отдельно. Если она тоже отвечает медленно, сайт почти наверняка ни при чём.
3. Сравните отдачу статики и динамики: файл изображения против страницы каталога.
4. Загляните в журнал ошибок веб-сервера и в журнал доступа. Всплеск запросов с одного адреса, сотни обращений к странице поиска или бесконечные обращения к файлу расписания задач видны сразу.
5. Проверьте нагрузку от расширений: временно отключите тяжёлые модули на тестовой копии и сравните время генерации страницы.
6. Посмотрите медленные запросы к базе, если такой журнал доступен. Один неудачный запрос без индекса способен съесть весь лимит процессора.

Ключевой принцип: сравнивайте одно и то же в разное время и разное в одно и то же время. Именно контраст показывает, где узкое место.

Таблица диагностики: симптом, проверка, действие

Что видит владелец	Как проверить	Что делать дальше
Сайт периодически недоступен, ошибка 502 или 503	Внешний мониторинг с интервалом в минуту, журнал ошибок веб-сервера	Собрать точные метки времени и передать в поддержку с требованием указать причину
Страницы открываются то быстро, то очень медленно	Серия замеров времени до первого байта утром, днём и ночью	Сопоставить пики с расписанием задач и нагрузкой; запросить статистику потребления ресурсов
Медленно открывается вообще всё, включая картинки	Замер отдачи статического файла и лёгкой страницы без CMS	Проблема на стороне площадки: диск, сеть или перегрузка сервера
Тормозит только каталог или поиск	Журнал медленных запросов, профилирование страницы	Оптимизировать запросы и индексы, кешировать выдачу — это задача сайта, не сервера
Аккаунт приостановлен за нагрузку	Запросить детализацию: процессы, минуты пиков, запрошенные адреса	Отсечь парсеры, переписать расписание задач, включить кеш; при повторах — менять тариф или площадку
Не приходят письма с форм	Проверить журнал отправки, записи SPF и DKIM, доставку на три разных почтовых сервиса	Настроить отправку через внешний почтовый сервис с аутентификацией домена
Сайт отключён за вредоносный код	Получить список помеченных файлов и дату их появления	Лечить сайт, менять пароли, обновлять CMS; проверить, не ложное ли срабатывание
Невозможно обновить CMS	Посмотреть доступные версии PHP и базы данных в панели	Если переключение невозможно — это прямой повод к переезду

Техподдержка как главный критерий выбора

Железо у большинства площадок сопоставимое. Разница между спокойной работой и постоянной нервотрёпкой почти всегда упирается в людей, которые отвечают на тикеты. Оценивать поддержку стоит по четырём параметрам.

• Скорость первого ответа. Не среднее время «по рекламе», а фактическое: сколько прошло от вашего сообщения до первой осмысленной реплики живого человека. Ночью и в выходные — отдельно.
• Компетентность. Понимает ли собеседник, что такое время до первого байта, лимит процессов, журнал медленных запросов. Первая линия не обязана быть системным администратором, но обязана уметь эскалировать.
• Готовность разобраться. Хорошая поддержка приносит данные: выдержку из журнала, график нагрузки, точное время сбоя. Плохая присылает предположение и закрывает тикет.
• Честность. Признание аварии с указанием причины и сроков лучше, чем бодрое «у нас всё работает» при явной недоступности.

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

Как проверить поддержку до покупки

Проверка занимает один вечер и экономит месяцы. Ещё до оплаты напишите в поддержку и задайте несколько предметных вопросов — по ответам сразу видно уровень.

1. Какие точные лимиты действуют на тарифе: процессорное время, число одновременных процессов, оперативная память на процесс, количество файлов.
2. Какие версии PHP доступны и переключаются ли они самостоятельно из панели для каждого сайта отдельно.
3. Как часто делаются резервные копии, на какую глубину, где хранятся и сколько стоит восстановление по запросу.
4. Есть ли тестовый поддомен для проверки сайта до смены DNS.
5. Что происходит при превышении лимитов: предупреждение, ограничение или отключение без уведомления.
6. Помогают ли с переносом сайта и в каком объёме.

Отправьте вопросы поздно вечером или в выходной — это честная проверка режима работы. Оцените не только скорость, но и содержание: ответили ли на все пункты или выборочно на два лёгких.

Тему разбирал отдельно: «Как я вывел сайт клиента на первое место в Яндекс за неделю».

На что смотреть в тарифе

Реклама обычно продаёт объём диска, хотя место сейчас стоит дёшево и почти никогда не бывает узким местом. Смотреть надо на другое.

Параметр	Почему важно	Что считать нормой
Лимит процессорного времени и процессов	Определяет, сколько посетителей сайт выдержит одновременно	Лимиты названы явно в цифрах, а не формулировкой «разумное использование»
Память на один процесс PHP	Тяжёлые импорты и генерация выгрузок падают при малом лимите	Возможность поднять значение до 256 мегабайт и выше
Версии PHP и базы данных	Безопасность, скорость и совместимость с CMS	Актуальные ветки, переключение из панели, отдельно для каждого сайта
HTTP/2 или HTTP/3 и сжатие	Заметно ускоряет загрузку страниц с большим числом файлов	Включено по умолчанию, сжатие текстовых файлов работает
Резервные копии	Единственная страховка от потери данных и неудачного обновления	Ежедневно, глубина не менее семи дней, хранение вне основного сервера, самостоятельное восстановление
Панель управления	Скорость решения рутинных задач без обращений в поддержку	Свои базы, почта, задачи по расписанию, журналы, сертификаты в пару кликов
Доступ по SSH	Нормальная работа с CMS, миграциями и большими дампами	Есть на тарифе или включается по запросу без доплаты
Бесплатный TLS-сертификат и автопродление	Просроченный сертификат мгновенно роняет трафик	Автоматическое продление без ручных действий
Тестовый адрес до смены DNS	Возможность проверить сайт до переключения домена	Технический поддомен выдаётся сразу
Почта и журналы отправки	Контроль доставки заявок с форм	Видимый журнал отправки, поддержка внешнего почтового сервиса

Почему «безлимитных» тарифов не бывает

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

Практический вывод простой: тариф без названных цифр — это тариф, условия которого определяются в момент конфликта. Пока сайт маленький, разницы не видно. Как только появляется трафик, вы узнаёте о лимитах из письма о приостановке. Тариф с честно указанными числами предпочтительнее щедрой рекламы без конкретики, даже если формально числа выглядят скромно.

Как проверить площадку перед переездом

Выбирать вслепую не нужно — почти всё проверяется заранее.

• Тестовый период. Разверните копию сайта, не переключая домен, и погоняйте её несколько дней.
• Замеры. Снимите время ответа копии в разное время суток, включая вечерний пик и раннее утро, когда обычно идут резервные копии и антивирусные проверки.
• Нагрузочная проба. Проверьте, как ведёт себя копия при десятках одновременных запросов к тяжёлой странице.
• Страница статуса и история инцидентов. Наличие публичного журнала аварий — хороший признак: компания не прячет сбои.
• Отзывы именно о простоях и поддержке. Отзывы про цену бесполезны, ищите описания конкретных аварий и того, как их решали.
• Проверка почты. Отправьте с тестовой копии заявку через форму на три разных почтовых сервиса и посмотрите, куда она попадёт.

Когда пора уходить

Менять площадку из-за одного сбоя не стоит: аварии случаются у всех. Уходить надо, когда проблема системная.

Признак	Почему это критично	Срочность
Простои повторяются несколько раз в месяц	Падает обход роботами, теряются заявки, страдает репутация	Высокая: планировать переезд сразу
Поддержка отказывается разбираться и закрывает тикеты шаблоном	Каждая следующая авария будет решаться так же	Высокая
Нельзя переключить версию PHP или базы данных	Невозможно обновлять CMS, растёт риск взлома	Высокая
Регулярные блокировки за нагрузку без детализации	Сайт не может расти, любой всплеск трафика заканчивается отключением	Средняя: сперва оптимизация, затем переезд
Нет рабочих резервных копий или восстановление платное и долгое	Одна ошибка обновления способна стоить всего сайта	Средняя
Письма с форм систематически уходят в спам с адреса сервера	Прямая потеря обращений	Средняя: часто лечится внешним почтовым сервисом
Время ответа держится выше секунды даже на лёгких страницах	Хуже поведенческие показатели, дороже реклама	Средняя
Изменились условия тарифа без внятного уведомления	Непредсказуемость расходов и лимитов	Низкая: наблюдать и готовить запасной вариант

Переезд без потери позиций: порядок действий

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

Этап	Что делаем	Как проверяем
1. Подготовка	Снижаем TTL записей домена до 300 секунд за сутки-двое до переезда	Проверка значения TTL через любой сервис проверки DNS
2. Копия	Переносим файлы и дамп базы данных на новую площадку	Сверяем размер каталога, число файлов и число строк в ключевых таблицах
3. Тестовый адрес	Открываем копию на техническом поддомене новой площадки	Обходим сайт краулером: коды ответа, заголовки, внутренние ссылки
4. Проверка функций	Формы, корзина, личный кабинет, поиск, фильтры, задачи по расписанию	Тестовая заявка доходит на почту, а не только показывает страницу благодарности
5. Заморозка	Запрещаем правки контента и заказов на время синхронизации	Финальная синхронизация базы и загруженных файлов
6. Переключение	Меняем записи домена на новый IP, выпускаем сертификат заранее	Сайт открывается по HTTPS без предупреждений браузера
7. Контроль	Следим за кодами ответа, журналом ошибок и скоростью первые сутки	Массовая проверка адресов: 200 там, где ожидается 200, редиректы не изменились
8. Уведомление поисковых систем	Отправляем ключевые страницы на переобход, проверяем доступность карты сайта	Панели вебмастеров не показывают роста ошибок обхода
9. Хвост	Держим старый сервер включённым минимум неделю	Смотрим по журналам, что обращений к старому IP больше нет

Если нужна помощь по теме — разработка сайта под ключ.

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

Чего не делать при переезде

• Не менять структуру адресов одновременно с переездом. Если сместятся и сервер, и URL, при падении позиций вы не поймёте, что стало причиной. Сначала переезд, две-три недели наблюдения, потом изменения структуры.
• Не совмещать переезд со сменой шаблона, CMS или протокола. Одно изменение за раз — единственный способ сохранить управляемость.
• Не выключать старый сервер в день переключения. Часть пользователей и роботов ещё сутки-двое ходит по старому адресу.
• Не закрывать тестовую копию от индексации так, чтобы запрет уехал в продакшн. Забытая строка запрета в файле robots или заголовок noindex после переключения обходятся дорого.
• Не переезжать в пятницу вечером и в разгар сезона. Лучшее время — начало недели и период спада спроса.
• Не забывать про задачи по расписанию. Выгрузки в маркетплейсы, синхронизация с учётной системой и отправка писем часто настроены отдельно и на новом сервере просто не запускаются.

Как фиксировать инциденты, чтобы разговор был предметным

Претензия «у вас всё время лежит сайт» не даёт ничего. Претензия с журналом инцидентов заставляет разбираться. Ведите простую таблицу — в ней достаточно шести колонок.

Смежный материал по теме — «Влияет ли хостинг на продвижение сайта».

Поле записи	Что писать
Дата и точное время	С точностью до минуты и с указанием часового пояса
Адрес страницы	Полный URL, на котором воспроизвелась проблема
Код ответа и текст ошибки	502, 503, 504, тайм-аут, сообщение из журнала ошибок
Доказательство	Скриншот, выдержка из журнала, данные внешнего мониторинга
Что делали в этот момент	Обновление, импорт, рекламный запуск, обычный трафик
Номер тикета и ответ	Идентификатор обращения и суть полученного ответа

Три-четыре такие записи превращают эмоциональный спор в аргументированный разговор. Они же становятся основанием для возврата средств или для решения о переезде — и они же покажут вам самим, действительно ли сбоев стало больше или так просто кажется.

Подключите внешний мониторинг доступности с интервалом в одну минуту и уведомлениями — он снимает главный вопрос «а точно ли лежало» и даёт независимые данные, которые нельзя оспорить.

Чек-лист выбора площадки под задачи бизнеса

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

Тип проекта	Что критично	Разумный вариант
Сайт-визитка, лендинг	Стабильность, сертификат, доставка писем с форм	Простой виртуальный хостинг с честными лимитами
Корпоративный сайт с блогом	Скорость на динамике, бэкапы, актуальные версии PHP	Виртуальный хостинг среднего тарифа с кешированием
Интернет-магазин до нескольких тысяч товаров	Ресурсы под фильтры и импорт, SSH, ежедневные копии	Старший тариф виртуального хостинга или небольшой VPS
Магазин с большим каталогом и интеграциями	Выделенные ресурсы, контроль версий ПО, отдельная база	VPS с администрированием или выделенный сервер
Сайт с сезонными пиками	Возможность быстро увеличить ресурсы без переезда	Площадка с гибким масштабированием тарифа
Сеть сайтов и поддоменов	Управление многими сайтами, отдельные версии PHP	VPS с удобной панелью управления

Финальный список вопросов к себе перед оплатой: названы ли лимиты в цифрах, есть ли тестовый период, отвечает ли поддержка ночью, доступны ли актуальные версии PHP, ежедневные ли копии и умею ли я восстановиться сам, есть ли SSH, дают ли технический адрес для проверки до смены DNS, публикует ли компания историю аварий. Восемь «да» — можно платить. Три-четыре «нет» — ищите дальше.

Частые вопросы

Как быстро понять, что сайт лежит именно из-за сервера, а не из-за моего интернета?
Проверьте доступность через любой внешний сервис проверки и откройте сайт с мобильного интернета. Если недоступен отовсюду и в журнале ошибок сервера пусто, а браузер получает 502 или 504, дело почти наверняка в площадке.

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

Стоит ли переходить на VPS, если тормозит виртуальный хостинг?
Только после диагностики. Если сайт тратит четыре секунды на генерацию страницы из-за неоптимизированных запросов, на VPS он будет тратить те же четыре секунды — вы просто заплатите больше. Сначала выясняете причину, потом выбираете тариф.

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

Что делать, если поддержка утверждает, что проблема на моей стороне, а я вижу обратное?
Соберите журнал инцидентов с точным временем, кодами ответа и данными внешнего мониторинга, приложите замеры лёгкой страницы без CMS и попросите предоставить выгрузку нагрузки за те же минуты. Если конкретных данных в ответ не дают, это и есть ответ на вопрос, оставаться или уходить.

Как узнать, на каком хостинге стоит сайт, и почему это важно:

1:30

Коротко

• Типичные беды одинаковы у всех: внезапные простои, плавающее время ответа, блокировки за нагрузку и вирусы, старые версии ПО, потерянные письма с форм и бэкапы, которых нет.
• Прежде чем спорить, проведите диагностику: серия замеров, лёгкая страница без CMS, сравнение статики и динамики, журналы ошибок и медленных запросов.
• Главный критерий выбора — не цена и не объём диска, а поддержка: скорость первого ответа, компетентность и готовность приносить данные вместо шаблонов. Проверяется до оплаты парой предметных вопросов ночью.
• Смотрите на лимиты в цифрах, версии PHP, бэкапы и их глубину, SSH и тестовый адрес; безлимит существует только в рекламе, реальные ограничения всегда есть в документации.
• Уходить пора при систематических простоях, отказе разбираться, невозможности обновить ПО и постоянных блокировках; переезжать надо отдельно от любых других изменений, с проверкой на тестовом адресе, контролем кодов ответа и переобходом.

Проверить, что тормозит ваш сайт, и спланировать переезд помогу на SEO-консультации.