Ночь, пик 14 тысяч RPS, nginx перед апстримами внезапно дает 502 и рост connect latency с 2 до 1800 мс. CPU 31 процент, апстримы отвечают, ping чистый. Поверхностный диагноз про провайдера умер на первой команде: ss -tan state time-wait дало 28431 сокета, netstat -s показал рост TCPTimeWaitOverflow, а в /proc/net/sockstat использовано 31200 сокетов при ip_local_port_range 32768 60999. Каждый короткий запрос без keepalive создавал новый исходящий коннект, proxy закрывал его первым и честно платил 60 секунд TIME_WAIT. Проверка ядра: sysctl net.ipv4.tcp_tw_reuse net.ipv4.tcp_timestamps net.ipv4.tcp_max_tw_buckets, ss -tan dst 10.250.0.15:8080, tcpdump -i any -nn -tttt host 10.250.0.15 and tcp port 8080. Выяснилось три вещи. tcp_tw_reuse равен 1 только в host netns, а в контейнере proxy стоял 0. timestamps на части апстримов отключены, а без них reuse ядро не применит. Главное, до одного dst ip и порта уникальность определяется четверкой src ip, src port, dst ip, dst port, поэтому один исходящий адрес дает потолок около 28 тысяч одновременных TIME_WAIT на направление. Лечение было не магическим sysctl, а архитектурным: включили upstream keepalive на 256 соединений, подняли пул, добавили второй source IP для proxy, расширили диапазон портов и только потом оставили tcp_tw_reuse 2 для исходящих. tcp_tw_recycle не существует в современных ядрах и правильно, он ломал клиентов за NAT. Через 20 минут TIME_WAIT упал до 3100, overflow остановился, p99 connect вернулся к 3 мс. Итог инцидента простой: TIME_WAIT это не утечка и не грязь, которую ядро обязано подмести флагом. Это протоколная гарантия против старых сегментов, и ее цена считается портами на конкретное направление, а не процентами CPU на дашборде. Разбор и практика эксплуатации: https://ftops.space/?utm_source=telegram&utm_medium=smm&utm_campaign=ftops&utm_content=tcp-time-wait-agoniya-pochemu-tcp-tw
