TCP Possible SYN flooding: что означают очереди SYN/accept и как настроить somaxconn/backlog

Иногда в kernel log появляется неприятная строка: TCP: Possible SYN flooding on port 443. Sending cookies. На первый взгляд это выглядит как «нас атакуют», но на практике не реже это симптом перегруженного приложения, маленького listen backlog или ситуации, когда воркеры слишком медленно делают accept(). Ниже — практичная памятка: что означает предупреждение, какие очереди реально переполняются, как это увидеть в ss и что тюнить без “магии”.

Что означает «TCP: Possible SYN flooding … Sending cookies»

Это сообщение пишет TCP-стек Linux, когда видит давление на очередь полуоткрытых соединений во время рукопожатия (SYN → SYN-ACK → ACK). В ответ ядро может включить SYN cookies — механизм, который позволяет пережить всплеск входящих SYN без хранения состояния на сервере.

Важно: это предупреждение не доказывает DDoS. Оно говорит о том, что входящих попыток соединения больше, чем стек/очереди/приложение успевают «переварить» в текущих лимитах. Типовые причины:

• реальная SYN-flood атака или агрессивные сканеры;
• всплеск легитимного трафика (релиз, рассылка, резкий рост запросов);
• приложение/прокси медленно вызывает accept() (CPU, блокировки, GC, IO);
• слишком маленький listen backlog у Nginx/HAProxy/приложения и/или ограничение сверху через net.core.somaxconn;
• сетевые проблемы (потери, retransmits), из-за которых рукопожатия «висят» дольше и копятся.

Ключевая задача — понять: упираетесь в SYN backlog (полуоткрытые соединения) или в accept queue (полностью установленные, но ещё не принятые приложением).

Две очереди, которые часто путают: SYN backlog и accept queue

Вокруг listen backlog часто говорят про одну «очередь», но практически полезно разделять две сущности:

• SYN backlog — очередь соединений на стадии рукопожатия (обычно проявляется ростом SYN-RECV и сообщениями про cookies). На неё влияет net.ipv4.tcp_max_syn_backlog и общая динамика TCP.
• accept queue (её же часто называют listen queue) — очередь соединений, которые рукопожатие уже завершили и готовы быть отданы приложению через accept(), но приложение не успевает их принимать.

Срабатывание SYN cookies может происходить даже при “здоровой” accept queue — и наоборот, accept queue может быть забита из-за медленного приложения, даже если по SYN backlog всё относительно спокойно.

Если вы держите публичный фронт на небольшом сервере, иногда проще и надёжнее сразу брать VDS с запасом по CPU, чтобы пики на TLS и accept() не превращались в постоянную борьбу с очередями.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Как проверить очереди: ss -ltn и состояния TCP

Начинать стоит с того, что происходит на слушающем порту прямо во время инцидента.

Смотрим listen-очередь через ss -ltn

ss -ltn

Для сокетов в состоянии LISTEN у ss важны колонки Recv-Q и Send-Q:

• Send-Q — лимит backlog (сколько соединений ядро готово держать в очереди для этого LISTEN-сокета).
• Recv-Q — текущее количество соединений в очереди (сколько «накопилось» и ждёт, пока приложение примет).

Если во время проблемы Recv-Q стабильно близок к Send-Q на 80/443 — это типичный признак забитой accept queue: приложению/воркерам не хватает скорости на accept() и дальнейшую обработку.

Фильтруем конкретный порт

ss -ltn sport = :443

Смотрим состояния соединений (SYN-RECV/ESTAB) по порту

ss -ant sport = :443

Если видите всплеск SYN-RECV — есть давление на рукопожатие (часто совпадает с cookies и темой SYN backlog). Если много ESTAB и при этом LISTEN Recv-Q растёт — чаще узкое место в приложении/воркерах/FD.

Если привычнее netstat

netstat во многих дистрибутивах уже устаревший, но иногда полезен для быстрого взгляда на LISTEN.

netstat -lnt

Смысл тот же: оценить очереди для LISTEN-сокетов и найти порт, где backlog забивается.

Какие sysctl реально влияют: somaxconn и tcp_max_syn_backlog

В большинстве разборов «Possible SYN flooding» фигурируют два параметра:

• net.core.somaxconn — верхний предел backlog для listen(), то есть ограничение сверху для accept queue.
• net.ipv4.tcp_max_syn_backlog — лимит очереди полуоткрытых соединений, то есть для SYN backlog.

Проверяем текущие значения

sysctl net.core.somaxconn
sysctl net.ipv4.tcp_max_syn_backlog

Нюанс: backlog в приложении и потолок ядра

Backlog задаётся приложением (например, Nginx через параметр backlog в директиве listen), но реальный предел будет ограничен net.core.somaxconn. Поэтому ситуация «в конфиге backlog большой, а по факту очередь маленькая» — распространённая.

Что тюнить и в каком порядке (без маскировки первопричины)

Тюнинг очередей — это буфер, а не ускоритель. Если воркеры хронически не успевают, увеличение очередей даст более длинное ожидание у клиентов, а не “вылечит” проблему. Рабочий порядок действий такой: фиксируем факт (чем забито), убираем прикладное узкое место, затем аккуратно увеличиваем очереди под профиль нагрузки.

1) Если забита accept queue: поднимаем somaxconn

Если по ss -ltn видно, что Recv-Q упирается в Send-Q (и это именно LISTEN), начните с поднятия net.core.somaxconn — хотя бы для теста.

sysctl -w net.core.somaxconn=8192

Дальше наблюдайте в нагрузку: вырос ли фактический Send-Q у LISTEN-сокета и снизилась ли доля отказов/таймаутов на установлении соединения.

2) Если давление на рукопожатие: увеличиваем tcp_max_syn_backlog

Когда много SYN-RECV и в логах регулярно появляется «Sending cookies», имеет смысл поднять net.ipv4.tcp_max_syn_backlog.

sysctl -w net.ipv4.tcp_max_syn_backlog=8192

Это особенно актуально для публичных 80/443, где фоновый шум (сканеры, боты) неизбежен.

3) Согласуем backlog на уровне nginx (nginx backlog)

Если фронтом стоит Nginx, backlog задаётся прямо в listen. Пример конфигурации (как текст):

<server>
  listen 443 ssl http2 backlog=8192;
</server>

Значение всё равно будет ограничено net.core.somaxconn, поэтому изменения в Nginx без sysctl не всегда дают эффект.

4) Проверяем лимиты файловых дескрипторов (FD)

Иногда backlog забивается не из-за “маленьких очередей”, а из-за того, что процесс банально не может принять новые соединения: упёрся в лимит открытых файлов. Быстро проверьте лимиты процесса и системы:

ulimit -n
cat /proc/$(pidof nginx | awk '{print $1}')/limits | grep -i 'open files'
sysctl fs.file-max

Почему это случается на живом сайте: типовые сценарии

Сценарий A: воркеры заняты, accept() происходит редко

Мало воркеров, дорогой TLS, тяжёлые запросы, медленный upstream. Соединения успевают установиться, но приложение не принимает их вовремя — растёт accept queue, а клиенты видят задержки/ошибки.

Что делать: повышать параллелизм, оптимизировать “тяжёлые” места, включать кэширование, проверять CPU steal (в виртуализации), мониторить задержки к upstream. Если у вас ещё и миграции/переносы, держите под рукой план без простоя: план переноса сайта без даунтайма помогает не усугублять пики.

Сценарий B: много SYN-RECV из-за потерь/качества сети

При потерях пакетов рукопожатие занимает больше времени, полуоткрытых соединений становится больше — SYN backlog заполняется. На вид похоже на атаку, а по сути — деградация канала/маршрутизации.

Что делать: смотреть retransmits, ошибки интерфейса, MTU/PMTU, состояние аплинка. Поднятие tcp_max_syn_backlog может помочь пережить всплеск, но первопричину в сети не заменит.

Сценарий C: сканеры и боты создают пики коннектов

Публичный сервер постоянно «щупают». На небольших серверах с дефолтными sysctl это приводит к периодическим предупреждениям. Тут уместно умеренно увеличить очереди и добавить аккуратный rate limiting на уровне L7/L4, не ломая легитимный трафик.

Как закрепить sysctl-параметры корректно

Команды sysctl -w — удобный тест, но после перезагрузки значения пропадут. Для постоянного применения добавьте параметры в конфигурацию sysctl вашей системы (обычно это отдельный файл в каталоге sysctl.d) и примените их.

sysctl -p

После этого снова проверьте фактические очереди через ss -ltn в момент нагрузки — важно видеть реальную картину, а не “ожидаемую по настройкам”.

Мини-чеклист перед тем, как «лечить SYN flooding»

• Есть ли корреляция с реальным всплеском трафика (RPS, релизы, рассылки, логи)?
• Что показывает ss -ltn sport = :80 / ss -ltn sport = :443: Recv-Q близок к Send-Q или нет?
• Как выглядят состояния по порту: есть ли пик SYN-RECV?
• Хватает ли воркеров/процессов и нет ли упора в CPU/IO/лимиты cgroup?
• Достаточно ли FD (лимиты процесса и fs.file-max)?
• Согласованы ли backlog в Nginx и net.core.somaxconn?
• Нет ли сетевых проблем: потери, retransmits, ошибки интерфейса?

Практический вывод

«TCP: Possible SYN flooding» — это сигнал о давлении на очереди входящих соединений или о том, что приложение/сервер не успевает принимать и обрабатывать новые коннекты. Часто решает связка: диагностика через ss во время пика, устранение узкого места (воркеры, TLS, upstream, FD), и только затем аккуратный тюнинг net.core.somaxconn/net.ipv4.tcp_max_syn_backlog и backlog на уровне Nginx.

Если фронт критичен (например, интернет-магазин/кабинет) — настройте мониторинг на рост Recv-Q и долю SYN-RECV, чтобы ловить проблему до того, как ядро начнёт “кричать” в логах.