tcp-keepalive - не спасет.

Т.к. сервер шлет усиленно данные в сокет

В большинстве случаев через 20-50 секунд сервер всё-таки замечает подвох. Но изредка вообще не чухает и только по таймауту падает

Ммм, есть там какая-то настрока ну уровне TCP tcp retransmit timeout что ли...

А чего он туда будет слать? Это же HTTP - там данные сначала в одну строну идут от клиента, и потом уже сервер возвращает ответ. Пока он не примет данные от клиента, серверу нечего ему передавать

У тебя долго запрос обрабатывается?

https://stackoverflow.com/a/35278688/6190175 вроде как-то так можно

Сам запрос не долго - это фактически прокся. Читает данные от клиента и тут же отправляет их в  HTTP конект к другому сервису.

Похоже то что тебе надо в nginx называется client_body_timeout

У меня там haproxy. nginx поверх другой HTTP-прокси - как пятая лапа у собаки.

И таймаут - это не самое лучшее решение. Я не могу его сделать совсем мелким. Клиент реально может тормозит (через 2G заливать файл)

А вот мелкие пакеты с keepalive-ом вероятно смогут и через 2G проскочить (хотя надежды не очень много)

если у клиента в буфере на отправку жирные пакеты с чего мелкие вне очереди пролезут?

а может тебе вообще ничего не надо фиксить? вернется клиент через n времени - докачает файл по тому же сокету, не вернется - отвалится по таймауту. вроде норм

Ну видимо так и придётся разработчикам клиента делать - терпеть, иногда до 5-и минут

А разве через sysctl  на сервере подтюнить не подойдет? Я, правда, с ходу не скажу подходящую настройку..

Я понял что проблема в том что клиент делает ретрай когда ресурс залочен на старом запросе. Почему бы по новому запросу не прерывать старую блокировку/запрос и делать новую?

Хм, надо подумать.

Есть вероятность что в первом запросе всё ОК, и просто клиент "тупой" начал делать новые запросы раньше времени.
И ещё такому решению мешает "протокол" дозаливки. Сначала клиент дёргает HEAD запрос, что бы узнать на каком месте случился обрыв. Эта операция не лочится никогда. После этого идёт запрос на заливку оставшегося куска. И если к этому моменту место обрыва связи не будет совпадать с тем, что передаст клиент - это ошибка.

Но в целом принудительное завершение первого запроса, при поступлении следующего - это более оптимистичное решение, чем ждать клиенту 30-300 сек.