502 при свободном CPU — ещё не перегрузка backend. Разберём отказ: reverse proxy открывает отдельное TCP-соединение на каждый запрос к upstream и первым закрывает его. TIME_WAIT копится на исходящей стороне proxy. Для одного исходного IP и одного IP:port назначения заканчиваются доступные комбинации портов. connect() возвращает EADDRNOTAVAIL, SYN не выходит. Увеличивать backend в этот момент — оплачивать ложный диагноз. Проверка в network namespace proxy: ss -tan state time-wait dst 10.0.0.10:8080, затем sysctl net.ipv4.ip_local_port_range net.ipv4.tcp_tw_reuse. Сопоставьте число TIME_WAIT к этому upstream, частоту новых соединений и ошибки connect(). nstat -az TcpExtTW показывает накопленный счётчик переходов в TIME_WAIT, а не текущее количество сокетов. Одного глобального графика TIME_WAIT для диагноза недостаточно. При tcp_tw_reuse=2 повторное использование разрешено только для loopback. Значение 1 расширяет область применения, но не отменяет проверки безопасности TCP, включая условия по timestamps и возрасту соединения. Это не команда «освободить все порты». tcp_fin_timeout здесь тоже мимо: он относится к осиротевшим FIN_WAIT_2, а не сокращает TIME_WAIT. Если отказ находится в SNAT или conntrack, подкрутка локального reuse не устраняет его причину. Исправление начинается с upstream keepalive и ограниченного пула соединений; мультиплексирование помогает, если его поддерживает upstream-протокол. Затем проверяют лимиты пула, таймауты обеих сторон и реальную скорость открытия соединений. Расширение диапазона портов даёт запас, но не устраняет churn. Kubernetes не отменяет конечность TCP-пространства, а облачный autoscaling умеет выставлять счёт за неверный диагноз. https://ftops.space/?utm_source=telegram&utm_medium=smm&utm_campaign=ftops&utm_content=tcp-time-wait-agoniya-pochemu-tcp-tw
