В 03:12 reverse proxy начал отдавать 502 при живом upstream. Поверхностный мониторинг винил backend и сеть, p99 вырос с 40 мс до 2,4 с, а ошибки росли ступенями каждые несколько минут. На хосте ss -s показал 482 317 сокетов в TIME_WAIT при диапазоне эфемерных портов 32768-60999, то есть всего 28 232 порта. Новые исходящие соединения падали с EADDRNOTAVAIL, хотя CPU был на 31 проценте, а свободной памяти оставалось 14 ГБ. Диагностика заняла десять минут: ss -tan state time-wait | wc -l, cat /proc/sys/net/ipv4/ip_local_port_range, ss -tan state time-wait и разбор по destination. tcp_tw_reuse стоял в 1, но он переиспользует TIME_WAIT только для новых исходящих соединений с корректным timestamp, а часть клиентов и backend его не присылали. Дополнительно proxy сам первым закрывал короткие keepalive-соединения, поэтому висяки копились именно на его стороне, а не у клиентов. Лечение было архитектурным, а не одним sysctl: увеличили keepalive и время жизни upstream-соединений, убрали закрытие после одного запроса, расширили ip_local_port_range до 1024-65535 и развели backend по нескольким локальным адресам. tcp_max_tw_buckets подняли только как предохранитель, а не как решение, потому что его переполнение молча роняет новые соединения. Через 20 минут TIME_WAIT упал до 41 тысячи, 502 исчезли, p99 вернулся к 38 мс. Разбор и чеклист диагностики: https://ftops.space/?utm_source=telegram&utm_medium=smm&utm_campaign=ftops&utm_content=tcp-time-wait-agoniya-pochemu-tcp-tw