[Главная](https://servghost.com/ru) /
[Руководства по приватному хостингу](https://servghost.com/ru/guides) /
Защита VPS от DDoS: где заканчивается хостер и начинается уровень 7






Эксплуатация


# Как пережить DDoS-атаку на свой VPS



Каждый тариф хостинга обещает «Защита от DDoS включена», и везде это означает одно и то же узкое: сеть поглощает флуды, измеряемые в гигабитах. Атаки, которые на самом деле кладут небольшие сайты, измеряются в запросах в секунду, стоят атакующему почти ничего и выглядят совершенно легитимно. Это руководство проводит границу между двумя видами атак, показывает, как за минуту понять, с каким из них вы столкнулись, и разбирает, что действительно держит оборону на той стороне границы, которая принадлежит вам.


[Читать руководство](#guide-body)
[FAQ](#guide-faq)






## На этой странице




- [Руководство](#guide-body)

- [FAQ](#guide-faq)

- [Похожие руководства](#guide-related)

- [Рекомендуемые страницы](#guide-cta)






Без KYC
Только крипто
Без логов
DMCA игнорируется
Полный root
NVMe SSD





23 мин чтения
Обновлено Sep 2026

На этой странице

[01Два разных вида атак под одним названием](#Два-разных-вида-атак-под-одним-названием)
[02Что на самом деле покупает фраза «Защита от DDoS включена»](#Что-на-самом-деле-покупает-фраза-Защита-от-ddos-включена)
[03Сначала выясните, атака ли это вообще](#Сначала-выясните-атака-ли-это-вообще)
[04Читаем атаку прямо с сервера](#Читаем-атаку-прямо-с-сервера)
[05Первые десять минут](#Первые-десять-минут)
[06Ограничения, которые действительно держат, и ошибка, которую совершают все](#Ограничения-которые-действительно-держат-и-ошибка-которую-со)
[07Кеширование — самая дешёвая защита, которую вы когда-либо развернёте](#Кеширование-самая-дешёвая-защита-которую-вы-когда-либо-разве)
[08Потолки, которые решают, устоите вы или нет](#Потолки-которые-решают-устоите-вы-или-нет)
[09Ставим что-то перед источником](#Ставим-что-то-перед-источником)
[10Скрытый источник стоит дороже любого фильтра](#Скрытый-источник-стоит-дороже-любого-фильтра)
[11Выбор железа и локации, чтобы атаки оставались скучными](#Выбор-железа-и-локации-чтобы-атаки-оставались-скучными)
[12Пять вещей, которых не стоит делать](#Пять-вещей-которых-не-стоит-делать)
[13Коротко](#Коротко)
[FAQЧастые вопросы](#guide-faq)
[→Рекомендуемые страницы](#guide-cta)







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

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

## Два разных вида атак под одним названием

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

| | Объёмная — уровни 3 и 4 | Прикладная — уровень 7 |
| --- | --- | --- |
| Что приходит | SYN-флуд, UDP-амплификация через открытые DNS-, NTP- или memcached-отражатели, ACK-флуд, обычный мусорный трафик | Обычные HTTP-запросы: GET-флуд, POST-флуд, slow-loris, query-строки, обходящие кеш |
| Измеряется в | Гигабитах и миллионах пакетов в секунду | Запросах в секунду — часто всего в нескольких тысячах |
| Пропускная способность, нужная для вреда | Огромная. Это состязание по ёмкости канала | Почти никакая. Хватит одного ноутбука, если эндпоинт достаточно дорогой |
| Где это нужно остановить | **Выше по потоку, у вашего провайдера.** К моменту, когда пакеты достигают вашего порта, ущерб уже нанесён | **На вашем сервере, вами самими** — или на прокси перед ним, который вы контролируете |
| Как это выглядит на сервере | Интерфейс насыщен, счётчики пакетов зашкаливают, CPU может простаивать | Скромная полоса пропускания, но все воркеры заняты, нагрузка растёт, очередь к базе данных увеличивается |
| Кто это исправляет | Фильтрация трафика на стороне хостера, автоматически, обычно за секунды | Ваша конфигурация — ограничение частоты запросов, кеширование, потолки соединений |

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

Объёмные флуды фильтруются выше по потоку, там, где есть для этого ёмкость. То, что проходит сквозь этот фильтр, — обычный на вид трафик, и останавливать его — ваша задача, а не вашего хостера.

## Что на самом деле покупает фраза «Защита от DDoS включена»

Защита на сетевом уровне реальна, ценна и почти всегда неправильно понимается. Когда провайдер заявляет о фильтрации L3/L4, это значит, что его сеть отслеживает трафик, идущий на ваш адрес, и при обнаружении флуда трафик перенаправляется через оборудование для очистки, которое отбрасывает вредоносную часть и пропускает дальше то, что выглядит легитимным. Это происходит без обращения в поддержку и обычно незаметно для вас, если не считать короткого сбоя.

За этой короткой фразой стоит немало, поэтому стоит разобрать, что она покрывает, а что нет:

- **Она покрывает атаки, которые вы не переживёте в одиночку.** Флуд усиления на 200 Gbps против сервера с портом на 1 Gbps — это не вопрос настройки. Это арифметика. Фильтрация выше по потоку — единственный существующий ответ.

- **Она не имеет состояния относительно вашего приложения.** Фильтр не знает, какие из ваших URL дорогие, какие посетители авторизованы, и что запрос к поисковому эндпоинту стоит в четыреста раз дороже запроса на логотип.

- **Она реагирует на порог, а не на ваши страдания.** Обнаружение срабатывает по объёму трафика. Атака, которая никогда не пересекает порог, никогда его не запустит — независимо от того, насколько полно она уже положила ваш сайт.

- **В крайних случаях она может ненадолго увести адрес в null-route.** У любой сети есть потолок. Если атака угрожает общей инфраструктуре, адрес может быть отключён на время — это стандартная, повсеместная практика, и о ней стоит знать заранее, а не в момент, когда это уже происходит.

**Если коротко:** ваш хостер защищает свою сеть, и вы от этого выигрываете. Он не защищает ваше приложение и не может этого делать. Уровень 7 — это не платная опция, которую от вас утаили, — это уровень, внутрь которого ваш провайдер не может заглянуть, не терминировав ваш TLS, а для тех, кто размещается офшорно, это сделка со своей серьёзной ценой.

## Сначала выясните, атака ли это вообще

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

- **Вы стали популярны.** Ссылка на крупном агрегаторе даёт форму трафика, которая выглядит точно как L7-флуд, — за исключением того, что referrer настоящие, а запросы идут на страницы, которые человек действительно хочет увидеть. Это проблема ёмкости со счастливой причиной; ограничивать её частоту — вредить самому себе.

- **Краулер потерял манеры.** Агрессивные скраперы и боты для обучения ИИ способны без труда обогнать небольшой сервер. User-agent обычно выдаёт себя сам, и решение — robots.txt плюс точечное ограничение, а не общее.

- **Вы что-то сломали.** Деплой, отключивший кеширование, взбесившаяся cron-задача, база данных, потерявшая индекс, — всё это выглядит как «внезапная нагрузка без очевидной причины». Если время совпадает с изменением, которое вы вносили, — верьте этому изменению.

- **Флуд создаёт ваш собственный мониторинг.** Редко, стыдно и куда чаще, чем кто-либо готов признать. Цикл health-check, который повторяет попытки без backoff, способен создать по-настоящему впечатляющую частоту запросов.

Различающий вопрос прост: *хочет ли этот трафик чего-то конкретного?* У реальной нагрузки — даже выглядящей враждебно — есть форма. Она попадает на страницы, которые существуют, переходит по ссылкам, загружает ресурсы и приходит из правдоподобного набора сетей. Атака обычно этим не утруждается.

## Читаем атаку прямо с сервера

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

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

- vnstat -tr 10 — средняя пропускная способность за десять секунд, самый быстрый честный показатель насыщения канала.

- cat /proc/net/dev дважды с интервалом в секунду — разница пакетов и байтов по каждому интерфейсу, без дополнительных инструментов.

**Это SYN-флуд?** Полуоткрытые соединения скапливаются в состоянии SYN-RECV. Несколько штук — это нормально; тысячи — нет:

- ss -s — сводная строка, количество соединений по состояниям одним взглядом.

- ss -tn state syn-recv | wc -l — конкретное число, которое имеет значение.

**Это уровень 7?** Если полоса пропускания ничем не примечательна, а всё при этом медленно, посчитайте запросы на клиента в логе доступа. Один адрес с десятками тысяч обращений — это любитель; сто тысяч адресов по три обращения каждый — вот это уже серьёзно:

- tail -n 100000 access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -30

- Замените $1 на $7, чтобы вместо этого ранжировать запрашиваемые пути. Если доминирует один дорогой эндпоинт, вы нашли и цель атаки, и половину решения.

**Что именно исчерпано?** Load average сам по себе мало что скажет. Ищите конкретный потолок, в который вы упёрлись: все процессы PHP-FPM заняты, соединения с базой данных на пределе, файловые дескрипторы исчерпаны, либо воркеры зависли в состоянии D в ожидании диска. Именно этот потолок — а не трафик — положил сайт, и поднять его часто быстрее, чем что-либо фильтровать.

**Держите это в уме, пока разбираетесь:** если вы держите приватность-ориентированный сервис, именно во время атаки сильнее всего тянет включить расширенное логирование и оставить его включённым. Включите, если необходимо, но затем выключите обратно и агрессивно ротируйте файлы. Инцидент, после которого на диске остаётся месяц подробных логов посетителей, обменивает одну проблему на другую — худшую и более долгоживущую. Дисциплина, к которой это относится, разобрана в нашем [руководстве по опсеку сервера](https://servghost.com/ru/guides/server-opsec-staying-anonymous).

## Первые десять минут

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

- **Сначала классифицируйте, потом действуйте.** Насыщенный интерфейс означает объёмную атаку; спокойный интерфейс при занятых воркерах — уровень 7. Тридцать секунд здесь избавят вас от часа исправления не того уровня.

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

- **Если это уровень 7, начните с кеша.** Включить агрессивное полностраничное кеширование для анонимных посетителей — самый быстрый способ превратить простой в пожатие плечами, и это единственная мера, которая помогает и против реального трафика тоже.

- **Затем — ограничение частоты запросов**: сначала для целевого эндпоинта, потом для всего остального. Начинайте консервативно. Лимит, который выбивает ваших собственных пользователей, — это самим же собой продолженная атака.

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

- **При необходимости осознанно сбрасывайте нагрузку.** Статическая страница «идут технические работы» для неавторизованных посетителей удерживает сервер живым, держит API на ходу и покупает время на размышление. Лучше самому решить, чем жертвовать, чем позволить этому решиться за вас.

- **Записывайте, что вы сделали.** Каждое временное правило, которое вы добавили, — мина замедленного действия для вас же в будущем. Правила, которые помогли, становятся постоянными; остальные убираются завтра.

## Ограничения, которые действительно держат, и ошибка, которую совершают все

Ограничение частоты запросов — основной инструмент против уровня 7, и nginx делает это хорошо с помощью двух директив, решающих две по-настоящему разные задачи. limit_req ограничивает *частоту* запросов — как часто клиент может обращаться. limit_conn ограничивает *конкурентность* — сколько соединений один клиент может держать открытыми одновременно. Флудам противостоит первая; slow-loris-атакам, которые держат тысячи почти неактивных соединений, чтобы исчерпать пул ваших воркеров, — вторая. Разверните только одну — и вы закрыты лишь от половины проблемы.

Три детали отличают ограничение, которое работает, от того, что существует лишь для вида:

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

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

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

**Ошибка, которая незаметно обнуляет всё это:** если перед вашим сервером что-то стоит — CDN, балансировщик нагрузки, ваш собственный обратный прокси, — каждый запрос приходит с *его* адреса, а не адреса посетителя. Ограничение на клиента тогда считает весь интернет одним клиентом и либо не сработает вообще, либо разом забанит всю вашу аудиторию. Источник реального IP нужно настроить (в nginx — set_real_ip_from для диапазонов прокси плюс real_ip_header для заголовка, который он передаёт) *прежде*, чем ограничения обретут хоть какой-то смысл. Ограничьте это доверие диапазонами самого прокси: если довериться заголовку, который может прислать любой клиент из открытого интернета, атакующий сможет подделывать новую личность на каждый запрос и беспрепятственно проходить сквозь любое ваше ограничение.

## Кеширование — самая дешёвая защита, которую вы когда-либо развернёте

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

Что важно, когда вы включаете это в разгар боя:

- **Кешируйте только для анонимных посетителей.** Обход по cookie сессии. Отдать страницу одного авторизованного пользователя другому — куда худший инцидент, чем простой, который вы пытались устранить.

- **Осознанно отдавайте устаревшее содержимое.** proxy_cache_use_stale в nginx вместе с updating error timeout означает, что, пока бэкенд испытывает трудности, посетители получают чуть устаревшую страницу вместо ошибки. Во время атаки это разница между сайтом, который выглядит нормально, и сайтом, который выглядит мёртвым.

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

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

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

## Потолки, которые решают, устоите вы или нет

Большинство серверов падают не потому, что кончился CPU. Они падают потому, что упираются в невидимый потолок, который никто сознательно не устанавливал, — значение по умолчанию десятилетней давности, имевшее смысл на железе, которым уже никто не пользуется. Под атакой первыми ломаются именно эти вещи:

- **Воркеры приложения.** pm.max_children у PHP-FPM, количество воркеров Python, размер кластера Node. Это реальный предел конкурентности вашего сайта. Когда все они заняты, каждый следующий посетитель встаёт в очередь, и сайт лежит независимо от того, насколько простаивает CPU. Поднимайте это значение лишь настолько, насколько позволяет память, — уход в своп хуже, чем ожидание в очереди.

- **Очередь на приём.** net.core.somaxconn и backlog прослушивающего сокета определяют, сколько соединений может ждать приёма. Маленький backlog превращает переживаемый всплеск в отказанные соединения.

- **SYN cookies.** net.ipv4.tcp_syncookies позволяет ядру отвечать на SYN-флуд, не выделяя состояние для соединений, которые никогда не завершатся. Современные ядра включают это по умолчанию; проверьте это, а не считайте само собой разумеющимся, — это ничего не стоит и спасает от самого распространённого вида флуда.

- **Файловые дескрипторы.** Каждое соединение — это дескриптор. Лимит nofile по умолчанию часто ниже, чем число соединений, которые вы пытаетесь обслужить, а режим отказа — accept проваливается, хотя всё выглядит здоровым, — по-настоящему сбивает с толку в три часа ночи.

- **Соединения с базой данных.** Увеличение числа воркеров без увеличения пула соединений просто переносит очередь туда, где её труднее увидеть. Эти два числа нужно менять вместе.

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

## Ставим что-то перед источником

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

| Подход | Что вы получаете | Чего это стоит |
| --- | --- | --- |
| Источник напрямую открыт, но защищён | Простота, отсутствие третьей стороны, отсутствие неподконтрольной вам терминации TLS | Ваш адрес публичен и постоянен. Уровень 7 — целиком на вас |
| Коммерческий CDN или сервис фильтрации | Огромная поглощающая способность, страница проверки в один клик, глобальное кеширование | Канал для жалоб с собственным мнением о вашем контенте, и компания, которая видит ваш трафик. Для офшорных или чувствительных к DMCA проектов это может стать самым слабым звеном в остальной аккуратно выстроенной схеме |
| Собственный фронт-узел — небольшой VPS с nginx, проксирующий на источник за файрволом | Полный контроль, отсутствие третьей стороны на пути запроса, адрес, который можно сжечь и заменить, и реальный адрес, который остаётся скрытым | Собственные пределы ёмкости и ещё одна машина, которую нужно поддерживать. Два-три фронта в разных сетях заметно усложняют задачу вывода из строя |

Фронт-узел на собственной инфраструктуре заслуживает больше внимания, чем ему обычно достаётся, — особенно для тех, кто выбрал офшорный хостинг по причинам, которые крупному CDN могут быть не близки. Схема неброская: дешёвые прокси-узлы спереди, источник за файрволом, принимающий соединения только от этих узлов, DNS, указывающий на фронты. Если фронт атакуют, вы заменяете его новым адресом за минуты, а источник этого даже не замечает. Полная версия этой архитектуры — включая шесть способов, которыми исходный адрес всё равно утекает, — тема нашего руководства о [скрытии IP исходного сервера](https://servghost.com/ru/guides/hiding-your-origin-server-ip).

## Скрытый источник стоит дороже любого фильтра

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

Это важнее, чем звучит, потому что исходные адреса утекают постоянно и незаметно. Исторические записи DNS с времён до того, как вы поставили прокси спереди, переживают это изменение на годы. Почта, отправляемая напрямую из приложения, несёт адрес в своих заголовках. TLS-сертификат, выпущенный на голый адрес, навсегда публикуется в журналах Certificate Transparency. Страница ошибки, редирект или малоприметный поддомен, который никогда не проксировался, — всё это выдаёт адрес. Если вы поставили CDN перед сервером, который раньше был открыт напрямую, считайте старый адрес известным, пока не смените его.

**Следствие из этого — правило файрвола, и это самая ценная строка во всём руководстве:** как только что-то встаёт спереди, источник должен отказывать в соединениях на портах 80 и 443 всем, кроме адресов этого фронта. Без этого прокси — лишь пожелание: любой, кто узнает реальный адрес, просто обходит его и атакует вас напрямую, а всё, что вы настроили на фронте, превращается в декорацию.

## Выбор железа и локации, чтобы атаки оставались скучными

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

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

- **Ваш ли это порт.** На общем виртуализированном хосте атакованный сосед может ухудшить и вашу работу, а ваш собственный потолок защиты — общий с другими. [Выделенное железо](https://servghost.com/ru/dedicated) с собственным портом убирает оба эффекта. Для проекта, который ожидает враждебное внимание, это самая очевидная причина перейти с [VPS](https://servghost.com/ru/vps) на что-то большее — весомее, чем количество ядер или объём RAM.

- **Где физически находится сеть.** Хорошо связанная европейская сеть с реальной транзитной ёмкостью поглотит флуд, который плохо связанная сеть — нет, и юрисдикция, выбранная по юридическим причинам, тоже обладает сетевыми характеристиками. Стоит проверить оба этих момента при выборе среди доступных [локаций](https://servghost.com/ru/locations).

Есть и аргумент масштаба, который незаметно играет в пользу простоты. Статический сайт за кешем на скромном сервере крайне сложно положить; тот же контент на тяжёлой CMS с некешируемым поисковым эндпоинтом может сломать один упорный человек со скриптом. Уменьшение доли динамики — это тоже защита, и она бесплатна. Если ваш проект действительно живёт под постоянной нагрузкой, вопрос выбора конфигурации под неё раскрыт в наших заметках о [хостинге для высоконагруженных проектов](https://servghost.com/ru/use-cases/high-traffic-hosting).

## Пять вещей, которых не стоит делать

Здесь сценарии провала достаточно устойчивы, чтобы их перечислить, и каждый уже стоил кому-то выходных:

- **Не отправляйте в null-route себя сами.** Заблокировать собственный адрес — значит закончить атаку самым буквальным способом из возможных: до вас больше не сможет достучаться никто, включая ваших пользователей. Это инструмент последней надежды для вашего провайдера, а не действие, которое вы предпринимаете добровольно.

- **Не считайте fail2ban защитой от DDoS.** Это хороший инструмент против перебора с нескольких адресов. Против распределённого флуда он реагирует за минуты на то, что происходит за секунды, а правило, банящее тысячи адресов, может обойтись обработке файрвола дороже, чем сама атака.

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

- **Не мстите.** Помимо того, что это незаконно практически везде, источники атаки — скомпрометированные третьи стороны. Вы будете атаковать жертв, причём с адреса, однозначно принадлежащего вам.

- **Не переезжайте в панике.** Смена хостинга посреди атаки означает, что новый адрес станет публичным за считаные минуты, а рабочей конфигурации у вас ещё нет. Сначала стабилизируйтесь, переезжайте осознанно потом — а если решите переехать, наше руководство о [переезде без простоя](https://servghost.com/ru/guides/migrate-website-to-offshore-hosting) существует именно для того, чтобы переезд не стал вторым инцидентом.

## Коротко

Без рассуждений рабочая модель умещается в восемь пунктов:

- **Сначала классифицируйте.** Насыщенный интерфейс означает объёмную атаку и относится к вашему хостеру. Спокойный интерфейс с исчерпанными воркерами означает уровень 7 и относится к вам.

- **Для объёмной атаки заведите тикет** с адресом, временной меткой и вашими счётчиками — а затем перестаньте трогать сервер.

- **Агрессивно кешируйте для анонимных посетителей,** отдавайте устаревшее содержимое под нагрузкой и схлопывайте повторные промахи. Это изменение с наибольшей отдачей из всех, что вы можете внести.

- **Ограничивайте и по частоте запросов, и по конкурентности,** жёстче всего — на самых дорогих эндпоинтах, и возвращайте 429.

- **Прежде всего этого настройте определение реального IP,** иначе любое ограничение на клиента за прокси окажется либо бесполезным, либо катастрофическим.

- **Знайте свои потолки** — воркеры, backlog, дескрипторы, соединения с базой данных — и поднимайте их осознанно в спокойный день.

- **Держите адрес источника в секрете и за файрволом,** открытым только для ваших фронт-узлов. Это стоит дороже, чем все фильтры вместе взятые.

- **Берите безлимитный трафик,** чтобы незапрошенный трафик никогда не оборачивался ещё и счётом.

Ничто из этого не делает вас неуязвимым, и всякий, кто продаёт неуязвимость, продаёт нечто иное. Это лишь выводит вас из категории тех, кого укладывает офлайн заскучавший подросток, и переводит в категорию тех, для чьего беспокойства нужны настоящие ресурсы и настоящее намерение, — а для подавляющего большинства проектов это неотличимо от полной безопасности. Всё остальное — та же неброская работа, которая делает сервер хорошим во всём остальном: [защищённым с первого дня](https://servghost.com/ru/guides/first-hour-vps-hardening-checklist), [восстановимым в худший из них](https://servghost.com/ru/guides/vps-backup-strategy), и работающим там, где к вашему трафику относятся как к вашему делу.





FAQ

## DDoS на небольшом сервере — частые вопросы





### 01
Значит ли фраза «Защита от DDoS включена», что я защищён от всего?



Нет, и пробел здесь вполне конкретный, а не расплывчатый. Включённая защита — это фильтрация на сетевом уровне: она отбрасывает объёмные флуды — SYN-флуд, UDP-амплификацию, потоки мусорных пакетов — ещё до того, как они достигнут вашего порта. Это именно та категория, с которой вы объективно не справитесь в одиночку, поэтому её и включают по умолчанию. Она не анализирует ваше приложение, поэтому HTTP-флуд в несколько тысяч запросов в секунду по дорогому эндпоинту проходит сквозь неё нетронутым и кладёт сайт, пока все сетевые графики выглядят нормально. Уровень 7 — это конфигурация, за которую отвечаете вы сами: кеширование, ограничение частоты запросов и потолки соединений.





### 02
Как отличить DDoS-атаку от всплеска трафика?



Спросите себя, хочет ли этот трафик чего-то конкретного. Реальные посетители — даже внезапным потоком с популярной ссылки — запрашивают существующие страницы, подгружают их ресурсы, приходят с правдоподобными referrer и распределены по множеству сетей естественным образом. Атака обычно долбит по одному пути, игнорирует ресурсы, шлёт неправдоподобные или отсутствующие user-agent и показывает распределение, которое выглядит синтетическим. Проверьте лог доступа на количество запросов по адресу клиента и по пути: если доминирует один эндпоинт и больше ничего не загружается — это атака. Если отдаются те же страницы, которые захотел бы увидеть человек, а referrer настоящие, у вас проблема с ёмкостью и счастливой причиной для неё.





### 03
Какое единственное действие даёт наибольший эффект во время атаки?



Включить полностраничное кеширование для анонимных посетителей и настроить отдачу устаревшего содержимого, когда бэкенд испытывает трудности. Ограничение частоты запросов отклоняет работу; кеш делает так, что работы вообще не возникает. Запрос, который стоил бы обращения к базе данных, рендеринга шаблона и воркера приложения, превращается в чтение файла, и то же самое железо, что падало при паре сотен динамических запросов в секунду, отдаст десятки тысяч закешированных. Это также единственная мера из всего списка, которая одинаково помогает и против реального трафика, поэтому, в отличие от ограничения частоты запросов, она не может ударить по вашим же пользователям.





### 04
Почему моё ограничение частоты запросов в nginx перестало работать после того, как я поставил CDN спереди?



Потому что теперь каждый запрос приходит с адреса CDN, а не посетителя, и ограничение на клиента считает весь интернет одним клиентом. В зависимости от порога оно либо никогда не сработает, либо разом забанит весь ваш трафик. Настройте источник реального IP — в nginx это доверенные диапазоны прокси плюс заголовок, который прокси передаёт, — чтобы ограничение снова ориентировалось на настоящего посетителя. Ограничьте это доверие диапазонами самого прокси: если принимать заголовок, который может подставить любой клиент из открытого интернета, атакующий сможет подделывать новую личность на каждый запрос и проходить сквозь любое ваше ограничение.





### 05
Достаточно ли fail2ban, чтобы остановить DDoS-атаку?



Нет. fail2ban читает логи с интервалом и банит адреса-нарушители после превышения порога, что подходит против перебора с небольшого числа источников. Распределённая атака приходит за секунды с тысяч адресов, каждый из которых шлёт лишь горстку запросов, поэтому порог никогда не достигается, а время реакции в любом случае слишком велико. Хуже того, набор правил, разросшийся до десятков тысяч записей, может потреблять больше ресурсов, чем сама атака. Оставьте fail2ban для SSH и эндпоинтов входа, а с флудами боритесь кешированием, ограничением частоты запросов и фильтрацией выше по потоку.





### 06
Стоит ли использовать CDN или лучше запустить собственный обратный прокси спереди?



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





### 07
Обойдётся ли атака мне ещё и в деньги, а не только в простой?



На тарифе с учётом трафика — да: трафик, который вы не запрашивали и не могли отклонить, всё равно засчитывается в лимит, а затяжной флуд способен породить счёт за перерасход больше, чем стоимость года хостинга. Это и есть практическая причина, по которой безлимитный трафик значит куда больше, чем кажется по строчке в спецификации: он превращает финансовый риск в чисто технический. Стоит также знать заранее, что если атака угрожает общей инфраструктуре, провайдеры могут временно отправить адрес в null-route — это стандартная повсеместная практика, а не сбой именно у вашего хостера.





### 08
Повышает ли переезд на офшорный или no-KYC хостинг вероятность атак?



Сам по себе выбор хостинга нейтрален; внимание привлекает то, что вы на нём размещаете. Игровые серверы, форумы, стриминг, маркетплейсы и всё, у чего есть конкурент или недоброжелатель, притягивают атаки независимо от юрисдикции. Что действительно меняется офшорно — это ваши гарантии: вас с меньшей вероятностью отключат за неудобство, и у этого есть обратная сторона — защита здесь техническая, а не договорная. Выбирайте локацию с реальной транзитной ёмкостью, берите безлимитный трафик, держите адрес источника скрытым и относитесь к уровню 7 как к своей ответственности с первого дня, а не с первого инцидента.




Похожие руководства

## Читайте также


[### Как выбрать офшорную юрисдикцию для хостинга в 2026 году

Перед покупкой


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


FAQ из 6 вопросов](https://servghost.com/ru/guides/choosing-an-offshore-jurisdiction)
[### VPS против выделенного сервера для задач с требованиями к конфиденциальности

Перед покупкой


Когда VPS достаточен, когда общая аренда становится уязвимостью, а когда bare metal — единственный честный ответ. Аппаратная изоляция, риски гипервизора и соотношение цены и модели угроз.


FAQ из 6 вопросов](https://servghost.com/ru/guides/vps-vs-dedicated-for-privacy)
[### Собственный VPN на VPS без KYC: WireGuard против OpenVPN

Эксплуатация


Почему собственный VPN превосходит коммерческих провайдеров, и как WireGuard и OpenVPN реально сравниваются по конфиденциальности, производительности и операционным рискам в 2026 году.


FAQ из 6 вопросов](https://servghost.com/ru/guides/self-hosted-vpn-wireguard-vs-openvpn)
[### RTX 4090 vs H100 SXM5 для AI-инференса (и где помещается RTX 5090)

Перед покупкой


Руководство по выбору GPU: какая NVIDIA GPU подходит для self-хостируемых LLM, изображений, видео, голоса и файнтюнинга в 2026 году. RTX 4090 vs RTX 5090 vs H100 SXM5 vs двойной H100 — VRAM, пропускная способность, $/токен, когда каждый из них выигрывает.


FAQ из 6 вопросов](https://servghost.com/ru/guides/rtx-4090-vs-h100-for-ai-inference)
[### Офшорный Windows RDP для форекс-трейдинга MT4 / MT5 / cTrader

Эксплуатация


Полное руководство: зачем нужен Windows RDP для форекс-трейдинга, как выбрать офшорную юрисдикцию с низкой латентностью, настройка MT4 / MT5 / cTrader / Expert Advisor, латентность до брокерских серверов и путь no-KYC чекаута.


FAQ из 6 вопросов](https://servghost.com/ru/guides/offshore-windows-rdp-for-forex-trading)
[### Хостинг с игнорированием DMCA: что это реально означает в 2026 году

Перед покупкой


Что на самом деле даёт хостинг с «игнорированием DMCA», какие юрисдикции действительно его поддерживают, для каких задач он нужен и какие авторско-правовые ловушки этот термин не покрывает.


FAQ из 6 вопросов](https://servghost.com/ru/guides/dmca-ignored-hosting-explained)
[### Анонимная регистрация домена за криптовалюту: WHOIS-приватность в 2026 году

Конфиденциальность


Практическое руководство 2026 года по регистрации доменов без раскрытия личности: режимы WHOIS по TLD, выбор регистратора, варианты оплаты криптовалютой и операционные ошибки, которые всё равно вас раскроют.


FAQ из 6 вопросов](https://servghost.com/ru/guides/anonymous-domain-registration-with-crypto)
[### Криптоплатежи за хостинг: Monero против Bitcoin против USDT

Конфиденциальность


Как выбор монеты влияет на то, что провайдер узнаёт о вас. Конфиденциальность, комиссии, финальность и уязвимость к анализу блокчейна для XMR, BTC и USDT — с чёткой рекомендацией.


FAQ из 6 вопросов](https://servghost.com/ru/guides/crypto-payments-monero-vs-bitcoin-vs-usdt)
[### Действительно ли офшорный хостинг анонимен? Честный ответ

Конфиденциальность


Офшорный хостинг без KYC избавляет от идентификации, которую собирает обычный провайдер, — но «анонимность» зависит от способа оплаты, логирования у провайдера и Вашей собственной opsec-дисциплины. Вот что на самом деле можно отследить.


FAQ из 6 вопросов](https://servghost.com/ru/guides/is-offshore-hosting-truly-anonymous)
[### Первый час защиты VPS: чек-лист

Эксплуатация


Конкретный, последовательный чек-лист для защиты нового VPS менее чем за час: SSH-ключи, файрвол, fail2ban, автоматические обновления и сокращение поверхности атаки, которое останавливает большинство оппортунистических атак.


FAQ из 6 вопросов](https://servghost.com/ru/guides/first-hour-vps-hardening-checklist)
[### Что такое хостинг без KYC? Определение, законность и принцип работы

Конфиденциальность


Хостинг без KYC позволяет арендовать сервер без какой-либо проверки личности — без имени, электронной почты и документов. Здесь подробно объясняется, что это означает, как работает технически, законно ли это и как выбрать надёжного провайдера.


FAQ из 6 вопросов](https://servghost.com/ru/guides/what-is-no-kyc-hosting)
[### Законен ли офшорный хостинг? Честный ответ 2026 года

Перед покупкой


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


FAQ из 6 вопросов](https://servghost.com/ru/guides/is-offshore-hosting-legal)
[### Как оплатить хостинг через Monero (XMR) — пошаговое руководство

Конфиденциальность


Пошаговое руководство по оплате VPS или выделенного сервера с помощью Monero (XMR): почему XMR — наиболее приватный вариант, как его приобрести и как работает оформление заказа — от выставления счёта до запуска сервера за считанные минуты.


FAQ из 6 вопросов](https://servghost.com/ru/guides/how-to-pay-for-hosting-with-monero)
[### Как анонимно разместить сайт — практическое руководство 2026

Конфиденциальность


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


FAQ из 6 вопросов](https://servghost.com/ru/guides/how-to-host-a-website-anonymously)
[### Как настроить WireGuard VPN на VPS — пошаговое руководство

Эксплуатация


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


FAQ из 6 вопросов](https://servghost.com/ru/guides/how-to-set-up-wireguard-vpn-on-a-vps)
[### Как самостоятельно разместить LLM на GPU-сервере — руководство 2026 года

Эксплуатация


Запустите собственную большую языковую модель на арендованном GPU-сервере: почему самостоятельный хостинг превосходит API, какой GPU и модель выбрать, настройка с Ollama или vLLM и стоимость.


FAQ из 6 вопросов](https://servghost.com/ru/guides/self-host-an-llm-on-a-gpu-server)
[### Bulletproof-хостинг против офшорного хостинга — в чём разница?

Перед покупкой


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


FAQ из 6 вопросов](https://servghost.com/ru/guides/bulletproof-vs-offshore-hosting)
[### Как купить VPS за Bitcoin — пошаговая инструкция (2026)

Перед покупкой


Понятное руководство для начинающих: как купить VPS за Bitcoin — получить BTC, выбрать тариф, оплатить счёт и запустить сервер без банковской карты и без привязки личных данных.


FAQ из 6 вопросов](https://servghost.com/ru/guides/how-to-buy-a-vps-with-bitcoin)
[### Лучшие страны для хостинга, игнорирующего DMCA, в 2026 году

Перед покупкой


Где размещать серверы, недосягаемые для американских требований о снятии контента: юрисдикции, которые реально работают, что на самом деле означает «игнорирование DMCA» и как сделать правильный выбор.


FAQ из 6 вопросов](https://servghost.com/ru/guides/best-countries-for-dmca-ignored-hosting)
[### Как разместить скрытый сервис Tor (сайт .onion) — руководство 2026 года

Эксплуатация


Настройте onion-сервис Tor на VPS: что такое скрытый сервис, почему это наиболее надёжная форма анонимного хостинга, полная инструкция по настройке и способы сохранить реальную анонимность.


FAQ из 6 вопросов](https://servghost.com/ru/guides/how-to-host-a-tor-hidden-service)
[### Настройка офшорного почтового сервера — самостоятельный хостинг частной почты в 2026 году

Эксплуатация


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


FAQ из 6 вопросов](https://servghost.com/ru/guides/offshore-mail-server-setup)
[### Руководство по хостингу криптонод — запустите блокчейн-ноду на VPS

Эксплуатация


Как разместить блокчейн-ноду на сервере: зачем запускать собственную ноду, как подобрать конфигурацию для Bitcoin, Ethereum, Monero и других сетей, настройка и обеспечение конфиденциальности.


FAQ из 6 вопросов](https://servghost.com/ru/guides/crypto-node-hosting-guide)
[### GPU-хостинг для Stable Diffusion — запустите собственный сервер генерации изображений

Эксплуатация


Запустите Stable Diffusion на собственном GPU-сервере: зачем самостоятельно хостить генерацию изображений, какой GPU выбрать, как настроить веб-интерфейс и во сколько это обойдётся по сравнению с облачными сервисами.


FAQ из 6 вопросов](https://servghost.com/ru/guides/gpu-hosting-for-stable-diffusion)
[### OpSec сервера — Как оставаться анонимным при управлении сервером

Конфиденциальность


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


FAQ из 6 вопросов](https://servghost.com/ru/guides/server-opsec-staying-anonymous)
[### Руководство по настройке сидбокса — создайте собственный приватный сидбокс в 2026 году

Эксплуатация


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


FAQ из 6 вопросов](https://servghost.com/ru/guides/seedbox-setup-guide)
[### Как обойти DPI-цензуру с помощью собственного VPS (гайд 2026)

Конфиденциальность


Ваш VPN перестал работать? Как обойти DPI-цензуру с помощью собственного VPS: что на самом деле обнаруживает глубокая инспекция пакетов, какой из пяти протоколов 2026 года побеждает какую блокировку, и полное пошаговое руководство по VLESS+REALITY.


FAQ из 6 вопросов](https://servghost.com/ru/guides/bypass-dpi-censorship-with-your-own-vps)
[### Полнодисковое шифрование на VPS: LUKS и что оно реально защищает

Эксплуатация


Как зашифровать VPS с помощью LUKS: тома данных, полное шифрование корня с удалённой разблокировкой по SSH, параметры для небольшого сервера и честный разбор того, от чего защищает шифрование диска.


FAQ из 8 вопросов](https://servghost.com/ru/guides/full-disk-encryption-on-a-vps)
[### Скрытие IP исходного сервера: CDN, обратный прокси и утечки

Конфиденциальность


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


FAQ из 8 вопросов](https://servghost.com/ru/guides/hiding-your-origin-server-ip)
[### Бэкап VPS: шифрование, второй провайдер, проверенное восстановление

Эксплуатация


Хостер не хранит бэкапы. Что убивает серверы, почему push-бэкап умирает вместе с сервером, restic против Borg, забытые ключи и как проверить восстановление на практике.


FAQ из 8 вопросов](https://servghost.com/ru/guides/vps-backup-strategy)
[### Свой сервер Matrix: федерация, метаданные и что не скрывает E2EE

Эксплуатация


Что даёт свой сервер Matrix на практике: Synapse против Conduit, server_name, который нельзя изменить, диск, который съедает медиатека, и что раскрывает федерация.


FAQ из 8 вопросов](https://servghost.com/ru/guides/self-host-a-matrix-server)
[### Как перенести сайт на офшорный хостинг без простоя

Эксплуатация


Порядок, который делает миграцию хостинга скучной: снизьте DNS TTL заранее, держите оба сервера параллельно, замораживайте запись на минуты, а не часы, — и подчистите след из пассивного DNS, Certificate Transparency и WHOIS, который оставляет переезд.


FAQ из 8 вопросов](https://servghost.com/ru/guides/migrate-website-to-offshore-hosting)
[### How to Self-Host a Crypto Payment Gateway with BTCPay Server

Эксплуатация


Run your own non-custodial checkout on an offshore VPS: BTCPay Server, a pruned Bitcoin node, Lightning and Monero — how to size the disk, why the private keys must never touch the machine, and where KYC quietly reappears at the cash-out.


FAQ из 8 вопросов](https://servghost.com/ru/guides/self-host-a-crypto-payment-gateway)




## Разместите сервер там, где флуды фильтруют за вас



Офшорные KVM-серверы в семи юрисдикциях с L3/L4-фильтрацией DDoS, безлимитным трафиком, полным root-доступом и NVMe-накопителями. Без KYC, оплата криптовалютой, развёртывание через минуты после подтверждения транзакции.


[Тарифы VPS](https://servghost.com/ru/vps)
[Выделенные серверы](https://servghost.com/ru/dedicated)
[Офшорный хостинг](https://servghost.com/ru/offshore-hosting)


## Structured data (JSON-LD)

```json
{
    "@context": "https://schema.org",
    "@type": "Organization",
    "@id": "https://servghost.com/#organization",
    "name": "ServGhost",
    "url": "https://servghost.com",
    "description": "Офшорные VPS и выделенные серверы в 7 юрисдикциях. Без KYC, без логов, только криптовалюта. Приватность — не функция, а архитектура.",
    "logo": {
        "@type": "ImageObject",
        "url": "https://servghost.com/ServGhost.webp",
        "width": 512,
        "height": 512
    },
    "foundingDate": "2025",
    "areaServed": [
        {
            "@type": "Country",
            "name": "Iceland"
        },
        {
            "@type": "Country",
            "name": "Panama"
        },
        {
            "@type": "Country",
            "name": "Moldova"
        },
        {
            "@type": "Country",
            "name": "Romania"
        },
        {
            "@type": "Country",
            "name": "Switzerland"
        },
        {
            "@type": "Country",
            "name": "Netherlands"
        },
        {
            "@type": "Country",
            "name": "Russia"
        }
    ],
    "knowsAbout": [
        "Offshore hosting",
        "Offshore VPS",
        "Bare-metal dedicated servers",
        "DMCA-ignored hosting",
        "No KYC hosting",
        "Cryptocurrency payments",
        "Privacy engineering",
        "Token-based authentication",
        "Anonymous domain name registration",
        "No-KYC domain registrar",
        "WHOIS privacy",
        "Cheap .com domains",
        "Crypto-paid domain names",
        "NVIDIA GPU compute",
        "Windows RDP hosting",
        "Agentic commerce"
    ],
    "contactPoint": {
        "@type": "ContactPoint",
        "contactType": "customer support",
        "url": "https://servghost.com/contact",
        "availableLanguage": [
            "en",
            "ru",
            "zh",
            "es",
            "fr",
            "de",
            "pt",
            "ar",
            "ja",
            "ko",
            "hi",
            "id",
            "it",
            "tr",
            "fa",
            "vi"
        ]
    },
    "sameAs": [
        "https://servghost.com/canary",
        "https://servghost.com/press"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "WebSite",
    "@id": "https://servghost.com/#website",
    "url": "https://servghost.com",
    "name": "ServGhost",
    "publisher": {
        "@id": "https://servghost.com/#organization"
    },
    "inLanguage": [
        "en",
        "ru",
        "zh",
        "es",
        "fr",
        "de",
        "pt",
        "ar",
        "ja",
        "ko",
        "hi",
        "id",
        "it",
        "tr",
        "fa",
        "vi"
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "Article",
    "headline": "Защита VPS от DDoS: где заканчивается хостер и начинается уровень 7",
    "description": "Пакетные флуды фильтрует хостер, флуды запросов — ваша забота. Как работает фильтрация L3/L4, почему атаки уровня 7 проходят сквозь неё, и что удерживает небольшой офшорный сервер на плаву: кеширование, ограничение частоты запросов, потолки соединений.",
    "image": "https://servghost.com/assets/img/guides/surviving-a-ddos-attack-on-your-vps.webp?v=1788769011",
    "author": {
        "@type": "Organization",
        "@id": "https://servghost.com/#editorial",
        "name": "ServGhost Editorial",
        "url": "https://servghost.com/about",
        "description": "Operator-side editorial team writing about offshore hosting jurisdictions, offshore server architecture, self-hosted privacy stacks and crypto payments.",
        "knowsAbout": [
            "Offshore hosting jurisdictions",
            "Data retention law",
            "MLAT and judicial cooperation",
            "WireGuard and OpenVPN deployment",
            "Tor relay operation",
            "Monero and Bitcoin payment privacy",
            "KVM virtualization and bare-metal hosting",
            "DMCA-ignored hosting"
        ],
        "parentOrganization": {
            "@id": "https://servghost.com/#organization"
        }
    },
    "publisher": {
        "@id": "https://servghost.com/#organization"
    },
    "datePublished": "2026-09-07T00:00:00+00:00",
    "dateModified": "2026-09-07T00:00:00+00:00",
    "mainEntityOfPage": "https://servghost.com/guides/surviving-a-ddos-attack-on-your-vps",
    "inLanguage": "ru",
    "keywords": "защита от DDoS для VPS, как остановить DDoS-атаку на сервер, защита от атак уровня 7, ограничение частоты запросов nginx, офшорный хостинг с защитой от DDoS, защита от SYN-флуда, как скрыть IP исходного сервера, что делать при DDoS-атаке на сайт",
    "articleSection": "Эксплуатация",
    "wordCount": 4537
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "FAQPage",
    "mainEntity": [
        {
            "@type": "Question",
            "name": "Значит ли фраза «Защита от DDoS включена», что я защищён от всего?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Нет, и пробел здесь вполне конкретный, а не расплывчатый. Включённая защита — это фильтрация на сетевом уровне: она отбрасывает объёмные флуды — SYN-флуд, UDP-амплификацию, потоки мусорных пакетов — ещё до того, как они достигнут вашего порта. Это именно та категория, с которой вы объективно не справитесь в одиночку, поэтому её и включают по умолчанию. Она не анализирует ваше приложение, поэтому HTTP-флуд в несколько тысяч запросов в секунду по дорогому эндпоинту проходит сквозь неё нетронутым и кладёт сайт, пока все сетевые графики выглядят нормально. Уровень 7 — это конфигурация, за которую отвечаете вы сами: кеширование, ограничение частоты запросов и потолки соединений."
            }
        },
        {
            "@type": "Question",
            "name": "Как отличить DDoS-атаку от всплеска трафика?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Спросите себя, хочет ли этот трафик чего-то конкретного. Реальные посетители — даже внезапным потоком с популярной ссылки — запрашивают существующие страницы, подгружают их ресурсы, приходят с правдоподобными referrer и распределены по множеству сетей естественным образом. Атака обычно долбит по одному пути, игнорирует ресурсы, шлёт неправдоподобные или отсутствующие user-agent и показывает распределение, которое выглядит синтетическим. Проверьте лог доступа на количество запросов по адресу клиента и по пути: если доминирует один эндпоинт и больше ничего не загружается — это атака. Если отдаются те же страницы, которые захотел бы увидеть человек, а referrer настоящие, у вас проблема с ёмкостью и счастливой причиной для неё."
            }
        },
        {
            "@type": "Question",
            "name": "Какое единственное действие даёт наибольший эффект во время атаки?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Включить полностраничное кеширование для анонимных посетителей и настроить отдачу устаревшего содержимого, когда бэкенд испытывает трудности. Ограничение частоты запросов отклоняет работу; кеш делает так, что работы вообще не возникает. Запрос, который стоил бы обращения к базе данных, рендеринга шаблона и воркера приложения, превращается в чтение файла, и то же самое железо, что падало при паре сотен динамических запросов в секунду, отдаст десятки тысяч закешированных. Это также единственная мера из всего списка, которая одинаково помогает и против реального трафика, поэтому, в отличие от ограничения частоты запросов, она не может ударить по вашим же пользователям."
            }
        },
        {
            "@type": "Question",
            "name": "Почему моё ограничение частоты запросов в nginx перестало работать после того, как я поставил CDN спереди?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Потому что теперь каждый запрос приходит с адреса CDN, а не посетителя, и ограничение на клиента считает весь интернет одним клиентом. В зависимости от порога оно либо никогда не сработает, либо разом забанит весь ваш трафик. Настройте источник реального IP — в nginx это доверенные диапазоны прокси плюс заголовок, который прокси передаёт, — чтобы ограничение снова ориентировалось на настоящего посетителя. Ограничьте это доверие диапазонами самого прокси: если принимать заголовок, который может подставить любой клиент из открытого интернета, атакующий сможет подделывать новую личность на каждый запрос и проходить сквозь любое ваше ограничение."
            }
        },
        {
            "@type": "Question",
            "name": "Достаточно ли fail2ban, чтобы остановить DDoS-атаку?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Нет. fail2ban читает логи с интервалом и банит адреса-нарушители после превышения порога, что подходит против перебора с небольшого числа источников. Распределённая атака приходит за секунды с тысяч адресов, каждый из которых шлёт лишь горстку запросов, поэтому порог никогда не достигается, а время реакции в любом случае слишком велико. Хуже того, набор правил, разросшийся до десятков тысяч записей, может потреблять больше ресурсов, чем сама атака. Оставьте fail2ban для SSH и эндпоинтов входа, а с флудами боритесь кешированием, ограничением частоты запросов и фильтрацией выше по потоку."
            }
        },
        {
            "@type": "Question",
            "name": "Стоит ли использовать CDN или лучше запустить собственный обратный прокси спереди?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Это зависит от того, что вы размещаете, а не от вашего бюджета. Коммерческий CDN даёт поглощающую способность, с которой вам не сравниться, и страницу проверки в один клик, но вместе с ним вы наследуете его канал для жалоб, и он видит ваш трафик — а для офшорных или чувствительных к DMCA проектов это часто самое слабое звено в остальной аккуратно выстроенной схеме. Собственные фронт-узлы требуют больше работы и имеют реальные пределы ёмкости, зато в пути запроса нет третьей стороны, а атакованный фронт можно заменить новым адресом за минуты. В любом случае источник должен быть закрыт файрволом так, чтобы принимать веб-трафик только от фронта, — иначе вся схема превращается в декорацию."
            }
        },
        {
            "@type": "Question",
            "name": "Обойдётся ли атака мне ещё и в деньги, а не только в простой?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "На тарифе с учётом трафика — да: трафик, который вы не запрашивали и не могли отклонить, всё равно засчитывается в лимит, а затяжной флуд способен породить счёт за перерасход больше, чем стоимость года хостинга. Это и есть практическая причина, по которой безлимитный трафик значит куда больше, чем кажется по строчке в спецификации: он превращает финансовый риск в чисто технический. Стоит также знать заранее, что если атака угрожает общей инфраструктуре, провайдеры могут временно отправить адрес в null-route — это стандартная повсеместная практика, а не сбой именно у вашего хостера."
            }
        },
        {
            "@type": "Question",
            "name": "Повышает ли переезд на офшорный или no-KYC хостинг вероятность атак?",
            "acceptedAnswer": {
                "@type": "Answer",
                "text": "Сам по себе выбор хостинга нейтрален; внимание привлекает то, что вы на нём размещаете. Игровые серверы, форумы, стриминг, маркетплейсы и всё, у чего есть конкурент или недоброжелатель, притягивают атаки независимо от юрисдикции. Что действительно меняется офшорно — это ваши гарантии: вас с меньшей вероятностью отключат за неудобство, и у этого есть обратная сторона — защита здесь техническая, а не договорная. Выбирайте локацию с реальной транзитной ёмкостью, берите безлимитный трафик, держите адрес источника скрытым и относитесь к уровню 7 как к своей ответственности с первого дня, а не с первого инцидента."
            }
        }
    ]
}
```

```json
{
    "@context": "https://schema.org",
    "@type": "BreadcrumbList",
    "itemListElement": [
        {
            "@type": "ListItem",
            "position": 1,
            "name": "Главная",
            "item": "https://servghost.com/ru/"
        },
        {
            "@type": "ListItem",
            "position": 2,
            "name": "Руководства по приватному хостингу",
            "item": "https://servghost.com/ru/guides"
        },
        {
            "@type": "ListItem",
            "position": 3,
            "name": "Защита VPS от DDoS: где заканчивается хостер и начинается уровень 7",
            "item": "https://servghost.com/ru/guides/surviving-a-ddos-attack-on-your-vps"
        }
    ]
}
```