Согласен. Может быть все что угодно НАТ - это один из возможных случаев.

Если "то слышно, то не слышно" значит где-то в правилах фаервола, НАТа иногда попадает в разрешенные правила, а иногда нет.

Отчет: Every 2.0s: netstat -na | grep 5038 Thu Jan 10 11:10:56 2019 tcp 0 0 0.0.0.0:5038 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:41242 127.0.0.1:5038 TIME_WAIT tcp 0 0 127.0.0.1:5038 127.0.0.1:40154 ESTABLISHED tcp 0 0 127.0.0.1:40154 127.0.0.1:5038 ESTABLISHED tcp 0 0 127.0.0.1:5038 127.0.0.1:40122 ESTA...

Вполне допускаю некорректную работу самописного АМИ-клиента.
Но при этом наблюдал такие же подвисшие сессии с адреса 127.0.0.1 на 127.0.0.1 (Работал ФриПБХ).
Про tcpdump не подумал, нужно будет посмотреть.

Конфигурацию в плане tcp не трогал в системе.

Был тот, который был по умолчанию в фриПБХ. Увидел глюки, поставил более свежий.
Таки действительно, какой-то глюк. Смотрел в винде такого соединения не было, а нетстат в линуксе показал, что есть.

На 15-ом была такая же проблема.
Тестил проблему далее. Таки через некоторый таймаут сбрасывает. Помониторю еще.

Немного провел экспериментов. Имеем: 1. Подключились с виндового клиента. 2. Рубанул коннект на роутере (правилами блокировки). 3. Отключил виндовый клиент. 4. АМИ не видит обрыва соединения и пуляет в буффер соединения далее. 5. Отключаю блокировку на роутере, разрешаю соединения. 6. Подключаю ново...

Похоже, что проблема таки в подвисшем соединении, если есть второе от туда же. Осталось понять, почему оно виснет.

Это потеряное соединение. С той машины уже есть новое. Как его убить?
Кстати размер очереди там не меняется.

iotop в основном по нулям, но в моменты событий пишется в базу и логи. Total DISK READ : 0.00 B/s | Total DISK WRITE : 536.42 K/s Actual DISK READ: 0.00 B/s | Actual DISK WRITE: 289.74 K/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 23496 be/4 mysql 0.00 B/s 234.93 K/s 0.00 % 2.36 % mysqld...