Защита сайта от DDoS на хостинге: что реально может сделать владелец shared-хостинга

Коротко: что сделать сразу

1. Проверьте статус хостинга, графики CPU/памяти/процессов и журналы ошибок за время недоступности.
2. Напишите в поддержку хостера и спросите, видят ли они аномальный трафик или сетевую атаку на ваш адрес.
3. Если у хостера есть штатная DDoS-защита, CDN или WAF, уточните, включена ли она для вашего тарифа и домена.
4. Перед изменением DNS сохраните все записи, включая MX, SPF, DKIM и DMARC.
5. Не отключайте HTTPS, не ставьте 777 и не устанавливайте случайный «anti-DDoS PHP» — это не защищает канал от сетевой атаки.

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

Начните с времени события. В панели shared-хостинга найдите разделы вроде Использование ресурсов, Resource Usage, Статистика, Логи или Error Log. В cPanel, ISPmanager и собственных панелях названия отличаются, поэтому ищите раздел по смыслу.

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

Сохраните фрагменты access/error log за проблемный интервал. Полезны число запросов, повторяющиеся URL, коды 429/502/503/508, User-Agent и время. Не публикуйте логи целиком, если в них есть токены, параметры форм или персональные данные.

Что защищает хостер, а что может сделать сам сайт

DDoS бывает разным. Атаки на сетевом и транспортном уровне могут забивать канал или создавать огромный поток пакетов. Если трафик не доходит до веб-сервера в нормальном виде, PHP-код и .htaccess не способны его «отфильтровать» — фильтрация должна происходить раньше, на стороне провайдера или специализированной сети.

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

Поэтому вопрос «есть ли DDoS-защита» слишком общий. Нужно уточнять, какие уровни защищаются, где фильтруется трафик и что происходит при атаке на ваше приложение.

Что спросить у хостера до подключения платной защиты

Напишите в поддержку конкретно: «Какая защита от DDoS включена на моём тарифе и домене?». Затем уточните несколько вещей.

• Фильтрация включена постоянно или активируется только после обнаружения атаки?
• Защищается только сеть или также HTTP/HTTPS на прикладном уровне?
• Есть ли WAF и ограничения частоты запросов?
• Меняется ли IP сайта при подключении защиты?
• Нужно ли менять DNS и какие записи?
• Есть ли ограничения по объёму атаки, числу запросов или стоимости фильтрации?
• Можно ли получить отчёт или подтверждение атаки после события?
• Как защита влияет на поисковых роботов, API, формы и вебхуки?

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

CDN и защитный прокси: почему важен исходный IP

Защитный CDN или reverse proxy принимает запросы посетителей на свои адреса, фильтрует их и передаёт допустимый трафик на ваш сервер. Это помогает только тогда, когда злоумышленнику не оставлен простой обход к исходному серверу.

Перед подключением сервиса сохраните текущую DNS-зону. После изменения A/CNAME-записей обновление кэшей у разных провайдеров занимает от нескольких минут до 24–48 часов в зависимости от TTL. В это время часть посетителей может идти по старому маршруту, поэтому переключение лучше планировать, а не делать во время паники.

Если на домене работает почта, не удаляйте MX, SPF, DKIM и DMARC при переносе DNS. Эти записи не относятся к веб-сайту, но их потеря способна остановить корпоративную почту.

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

Что можно безопасно усилить на уровне приложения

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

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

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

Что почти не помогает против настоящего DDoS

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

Права 777. Они не имеют отношения к защите от нагрузки и только ухудшают безопасность файлов.

Отключение HTTPS. Это не устраняет поток запросов и создаёт риск перехвата данных.

Случайный PHP-скрипт «anti-DDoS». Если запрос уже дошёл до PHP, сервер потратил часть ресурсов. При сетевой атаке такой код вообще не решает проблему.

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

Что делать во время атаки или резкого всплеска

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

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

Как понять, что защита работает

• Сайт отвечает стабильно во время повторного всплеска трафика.
• Ошибки 502/503/508 и превышение лимитов заметно сократились.
• Поддержка хостера подтверждает фильтрацию аномального трафика.
• Реальные посетители могут открыть страницы и отправить форму.
• Поисковые роботы и нужные API не заблокированы ошибочным правилом.
• Исходный сервер не доступен по старому обходному адресу, если архитектура должна его скрывать.

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

Когда лучше остановиться и не экспериментировать

Остановитесь перед сменой DNS, если на домене есть почта и вы не сохранили все записи. Не меняйте NS во время атаки без понимания, где после переключения окажутся MX, DKIM и остальные записи.

Если сайт приносит значимый доход, а shared-хостинг регулярно упирается в ограничения даже без атаки, проблема может быть архитектурной. В таком случае нужно сравнивать более защищённый shared-тариф, управляемый VPS, CDN или специализированную инфраструктуру, а не бесконечно добавлять правила в .htaccess.

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

Вывод

Владелец shared-хостинга не должен пытаться «отбить DDoS» одним PHP-файлом. Сначала подтвердите характер нагрузки по логам и данным хостера, затем определите уровень атаки и подключайте защиту там, где она эффективна: у провайдера, CDN/WAF или перед приложением. Чем точнее диагностика, тем меньше риск заплатить за лишнюю услугу или случайно заблокировать собственных клиентов.