К содержимому
DDoS·Protect
Платформы

Next.js и Node.js: защита SSR, API-маршрутов и серверных действий

Серверный рендеринг делает каждый запрос к странице работой для процессора. Если страница не закэширована, HTTP-флуд по ней быстро исчерпывает ресурсы Node.js-процесса. Рекомендации ниже относятся к приложениям, которые вы запускаете сами: через next start, в Docker или под управлением pm2.

Где Next.js тратит ресурсы

АдресНагрузкаПравило
Страницы с динамическим рендерингомРендер на каждый запрос, обращения к базе и внешним APIЛимиты и проверка браузера для подозрительных источников
/_next/imageМасштабирование и сжатие картинок на летуЛимит на уникальные сочетания url, w и q; кэш результатов
/api/* и Route HandlersКод приложенияЛимиты по сессии, токену и методу
POST с заголовком Next-ActionServer ActionsЛимиты по пути страницы и заголовку
/_next/data/* (Pages Router)JSON для переходов между страницамиТе же правила, что для самих страниц
/_next/static/*Статика с хешем в имени файлаКэшировать надолго, не ограничивать агрессивно

Оптимизатор изображений принимает параметры url, w и q. Ограничьте в next.config список разрешённых источников (images.remotePatterns) и размеров (deviceSizes, imageSizes): тогда запросы с произвольными значениями получают ошибку, а не запускают обработку.

ISR и revalidate

Страницы с revalidate отдаются из кэша и перегенерируются в фоне, поэтому они устойчивее к флуду. Но маршрут, который вызывает revalidatePath или revalidateTag по запросу CMS, нужно защитить секретом и лимитом: иначе его можно дёргать, чтобы постоянно сбрасывать кэш.

Middleware

Файл middleware.ts (в Next.js 16 — proxy.ts) выполняется на каждый подходящий запрос. Ограничьте его через config.matcher, исключив /_next/static, /_next/image и файлы статики, — иначе даже запросы картинок проходят через лишний код.

Реальный IP в Node.js

У next start нет настройки доверенных прокси: приложение видит X-Forwarded-For в том виде, в каком его передал предыдущий узел. Поэтому адрес нужно восстановить на nginx модулем real_ip по адресам фильтра и перезаписать заголовки, а не дописывать к ним. В Express и Fastify для этого есть настройка trust proxy со списком доверенных адресов.

# nginx перед Next.js; $remote_addr уже восстановлен модулем real_ip
location / {
    proxy_pass http://127.0.0.1:3000;
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $remote_addr;
    proxy_set_header X-Forwarded-Proto $scheme;
}
Заголовки перезаписываются, поэтому подделанный клиентом X-Forwarded-For до приложения не дойдёт
// Express: доверять только локальному nginx и узлам фильтрации (адреса условные)
app.set('trust proxy', ['loopback', '203.0.113.0/24']);

Что исключить из проверки браузера

  • Вебхуки в /api/webhooks/* и подобных маршрутах — их подлинность проверяет подпись отправителя.
  • Маршрут on-demand revalidation, который вызывает CMS.
  • Запросы мобильного приложения к API: для них — лимиты и подпись запросов.
  • Задачи по расписанию, запускаемые HTTP-запросом, — по адресу источника и секрету.

Типичные ошибки

  • Жёсткий лимит частоты на /_next/static: при первой загрузке страница запрашивает десятки файлов, и настоящие посетители получают 429.
  • Страница стала динамической из-за чтения cookies или headers там, где её можно было отдать из кэша.
  • Порт 3000 открыт наружу — атаку можно направить на приложение в обход nginx и фильтра. Закройте его и скройте IP сервера.

Вопросы и ответы

Подходит ли это для приложений на управляемых платформах вроде Vercel?

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

Работают ли WebSocket и потоковый рендеринг?

Фильтр уровня L7 рассчитан на HTTP, HTTPS и WebSocket. Для потоковых ответов (streaming SSR, Server-Sent Events) важно, чтобы промежуточные узлы не буферизовали ответ целиком: в nginx это proxy_buffering off или заголовок X-Accel-Buffering: no на нужных маршрутах.

Ранний доступ

Подключим ваш сайт одним из первых

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