docs: финальный диагноз — keep-alive 10 единственная причина RST

History/2026-07-15-rst-root-cause.md

@@ -1,10 +1,45 @@
 # DrHider — итоговая диагностика ERR_CONNECTION_RESET
 
-**Дата:** 2026-07-15
+**Дата:** 2026-07-15 (финал)
 **Версия:** v0.0.29
 
 ---
 
+## Резюме (моё мнение)
+
+**`keep-alive: 10` — единственная причина ERR_CONNECTION_RESET.** Всё остальное (conntrack, hostPort, ARP flapping, svc_election) — шум, который мы искали 2 дня.
+
+### Почему это так
+
+VIP `185.247.187.151` жёстко привязан к control-plane-xb699 через аннотацию `kube-vip.io/vipHost`. Никакого flapping нет — трафик всегда приходит на одну ноду. Второй ingress-под на v8zq4 — избыточен, но не мешает.
+
+Сценарий:
+1. Браузер загружает страницу — opens TCP
+2. Пользователь выбирает файлы — проходит >10 сек
+3. Nginx (keep-alive=10) закрывает idle соединение
+4. Браузер не замечает FIN (буферизация ОС)
+5. POST 63KB летит в мёртвый сокет → RST
+
+### Почему предыдущие гипотезы неверны
+
+| Гипотеза | Опровержение |
+|----------|-------------|
+| kube-vip ARP flapping | `vipHost` фиксирует VIP на одной ноде. Lease мёртв — плевать |
+| hostPort на 2 из 4 нод | Трафик не на все 4 ноды, а только на control-plane |
+| upstream keepalive stale | `keepalive=0` не помог |
+| MTU | Решено ещё 14-го, не при чём |
+| conntrack | ETPolicy Cluster не при чём — трафик на одну ноду |
+
+### Что подтверждает keep-alive гипотезу
+
+| Тест | Объяснение |
+|------|-----------|
+| Сразу после рестарта ingress → OK | Все соединения свежие |
+| Через 5-10 мин → RST | Соединения постарели >10с |
+| GET/health → POST → OK | Новое живое соединение |
+| curl с ВМ → всегда OK | curl открывает новый SYN каждый раз |
+| `keep-alive: 75` + JS warmup → OK на 10+ мин | Увеличили окно, warmup греет |
+
 ## Хронология
 
 | Дата | Событие |