Инцидент начался как «service unavailable» под пиковой нагрузкой. Мониторинг показывал рост CLOSE_WAIT и исчерпание ephemeral ports. Поверхностный анализ указывал на утечку сокетов в приложении. Но netstat -tan | awk '/TIME_WAIT/ {print $4}' | cut -d: -f2 | sort | uniq -c | sort -nr выявил тысячи TIME_WAIT на один и тот же локальный порт. Conntrack был переполнен: dmesg | grep 'nf_conntrack: table full' подтвердил это. tcp_tw_reuse не помог — он требует уникальности (src_ip, src_port, dst_ip, dst_port), а reverse proxy использовал фиксированный src_ip и один backend-порт. Решение: увеличение net.ipv4.ip_local_port_range, включение net.ipv4.tcp_tw_recycle (осторожно! только в изолированной сети) или переход на SO_REUSEPORT на уровне бэкенда. Подробнее: https://ftops.space/?utm_source=telegram&utm_medium=smm&utm_campaign=ftops&utm_content=tcp-time-wait-agoniya-pochemu-tcp-tw