# Диагностика ERR_CONNECTION_RESET в браузере

**Дата:** 2026-07-14

---

## Хронология

### Фаза 1: MTU (решено)

Проблема: 63KB POST из браузера → `ERR_CONNECTION_RESET`. Причина: MTU 1500 + Geneve 50 = 1550 > underlay 1450.
Решение: Cilium MTU = 1400. Проверено curl с ВМ (30/30).

### Фаза 2: HTTP/2

HTTP/2 → `ERR_HTTP2_PROTOCOL_ERROR`. HTTP/1.1 → `ERR_CONNECTION_RESET`.
Решение: `use-http2: "false"`.

### Фаза 3: Поиск корневой причины RST

Баг: браузер → свежая страница → POST 63KB → `ERR_CONNECTION_RESET`.

## Полная матрица тестов

| # | Сценарий | Результат |
|---|----------|-----------|
| 1 | Браузер: свежая страница → POST 63KB | ❌ RST / `⏳ 100%` hang |
| 2 | Браузер: свежая страница → GET (до Flask) → POST 63KB | ✅ 200 OK |
| 3 | Браузер: свежая страница → POST 10B → POST 63KB | ✅ 200 OK |
| 4 | Браузер: свежая страница → GET (nginx сам, 405) → POST 63KB | ❌ RST |
| 5 | `curl` с ВМ (5.172.178.213) → POST 63KB | ✅ всегда <100ms |
| 6 | Сразу после `kubectl rollout restart` ingress → браузер | ✅ работает |
| 7 | Через 5-10 мин после рестарта → браузер | ❌ снова RST |

## Что исключено

| Гипотеза | Статус | Почему |
|----------|--------|--------|
| MTU | ❌ исключено | 1400, curl с ВМ всегда работает |
| HTTP/2 | ❌ исключено | `use-http2: false`, та же проблема |
| XHR vs fetch | ❌ исключено | оба метода падают одинаково |
| `proxy_request_buffering: off` | ❌ исключено | `on` для `location /` |
| `client-body-timeout: 10` | ❌ исключено | 63KB < 1 сек |
| FD/worker-лимиты | ❌ исключено | 1M FD, 16K connections, 62MB mem |
| OOM/Restart | ❌ исключено | 0 рестартов, нет OOMKilled |
| Stale upstream keepalive | ❌ исключено | `keepalive=0` не помогло |
| nginx→Flask (upstream) | ❌ исключено | curl с ВМ доказывает что работает |

## Эксперименты

### Перезапуск ingress временно чинит

После `kubectl rollout restart` — браузер работает. Через 5-10 мин — снова RST. Накопление состояния.

### Ресурсы в норме

```
worker_rlimit_nofile: 1047552 (1M FD)
worker_connections:    16384
worker_processes:      4
Memory:                62 MiB, CPU: 3-7m
Restarts: 0, OOMKilled: нет
```

### `upstream-keepalive-connections: 0` — НЕ фикс

Баг вернулся через 5-10 минут. Keepalive pool не при чём.

## Критическое противоречие

- `curl` с ВМ (тот же датацентр) → POST 63KB → **всегда 200 OK <100ms**
- Браузер через 5-10 мин после рестарта ingress → **ERR_CONNECTION_RESET**

curl и браузер идут через один VIP (185.247.187.151), на одни ingress-поды.
Разница: клиент (curl vs Chrome) и сетевой путь (локальная сеть ДЦ vs интернет/VPN).

## Текущая конфигурация (2026-07-14)

| Параметр | Значение |
|----------|----------|
| `use-http2` | `"false"` |
| `upstream-keepalive-connections` | `"0"` |
| `error-log-level` | `debug` |
| `proxy-body-size` | `1024m` |
| `client-body-timeout` | `"10"` |
| `keep-alive` | `"10"` |
| Cilium MTU | `1400` |
| `externalTrafficPolicy` | `Cluster` |
| Ingress controller | `1.12.6` (Штурвал) |

---

## Вопрос к Claude (Sonnet/Opus)

### Симптом

Браузер (Chrome/Electron, Windows) → POST 63KB multipart/form-data → `ERR_CONNECTION_RESET` или зависание на `⏳ 100%`. Тело уходит полностью, ответ не приходит — TCP RST.

### Окружение

```
Кластер:       bare-metal K8s 1.34.1, 4 ноды (3 worker + 1 control-plane)
CNI:           Cilium Geneve, MTU подов = 1400
VIP:           kube-vip 185.247.187.151 (ARP на все 4 ноды)
Ingress:       nginx-ingress (Штурвал Helm), контроллер 1.12.6
               2 реплики, externalTrafficPolicy: Cluster
Приложение:    Flask/Waitress, 1 реплика (Штурвал managed)
```

Конфиг ingress:
```yaml
use-http2: "false"
upstream-keepalive-connections: "0"
client-body-timeout: "10"
keep-alive: "10"
worker-processes: 4
worker-rlimit-nofile: 1047552
worker-connections: 16384
proxy-body-size: 1024m
proxy-request-buffering: on   # для location /
error-log-level: debug
```

### Критическое противоречие

- `curl` с ВМ (5.172.178.213, тот же датацентр) → POST 63KB → **всегда 200 OK <100ms**
- Браузер через 5-10 мин после рестарта ingress → **ERR_CONNECTION_RESET**
- Сразу после рестарта ingress → браузер работает

curl и браузер идут через один VIP (185.247.187.151), на одни ingress-поды. Разница: клиент (curl vs Chrome) и сетевой путь до VIP (локальная сеть ДЦ vs интернет/VPN).

### Вопросы

1. Почему рестарт ingress помогает на 5-10 минут, а потом браузерные запросы снова получают RST, при том что curl с ВМ продолжает работать?

2. Может ли `externalTrafficPolicy: Cluster` + kube-vip создавать conntrack-записи, которые со временем ломают соединения из интернета (с другими TCP options/MSS) но не из локальной сети?

3. Стоит ли попробовать `externalTrafficPolicy: Local`? Какие риски?

4. Какие ещё эксперименты можно провести без tcpdump (нет доступа к нодам по SSH, нет tcpdump в подах)?

---

## TODO

- [ ] Ответ от Claude
- [ ] `externalTrafficPolicy: Local` — эксперимент
- [ ] Воспроизвести с `curl` из WSL на машине пользователя
- [ ] tcpdump через `kubectl debug` (требует координации)
- [ ] Обновить ingress controller 1.12.6 → актуальный
- [ ] Проверить `client-body-timeout: 60` + `keep-alive: 75`

---

## Ответ Claude (Sonnet) — 2026-07-14

### Два независимых механизма

Симптом объясняется наложением двух механизмов:

### Механизм 1: kube-vip ARP flapping + conntrack asymmetry (основной)

Именно это объясняет 5-10-минутное окно и разницу между browser и curl.

**Как работает с `externalTrafficPolicy: Cluster`:**

```
Browser → VIP → Node N1 (kube-vip leader) → iptables DNAT+SNAT → nginx pod
                     │
                     └── conntrack entry создаётся на N1:
                         (browser_ip:srcport → 185.247.187.151:443)
                          ↔ (N1_ip:eph → nginx_pod:443)
```

Проблема возникает когда kube-vip меняет лидера:

```
kube-vip: N1 → N2 (истёк lease или GARP от N2)
Коммутатор: обновляет ARP-кэш, VIP теперь на N2

Browser (старое HTTP keep-alive соединение):
  → PSH/ACK 63KB → попадает на N2
  N2: нет conntrack записи → TCP RST

curl (новое соединение):
  → SYN → попадает на N2
  N2: создаёт новую conntrack → всё ОК
```

**Почему 5-10 минут:** время жизни ARP-записи на коммутаторе или интервал переизбрания kube-vip лидера. "ARP на все 4 ноды" — периодические GARP-анонсы могут уходить с разных нод.

**Почему GET-to-Flask чинит последующий POST (тесты #2 vs #4):**
- GET → Flask: создаётся *новое* TCP-соединение (новый SYN) → правильный conntrack на текущей ноде. POST идёт по *тому же* соединению → conntrack жив → OK.
- GET → 405: nginx отвечает сам и закрывает соединение с `Connection: close`. POST создаёт *новое* соединение, но VIP уже на другой ноде → RST.

### Механизм 2: `keepalive_timeout: 10s` — слишком агрессивно

`keep-alive: "10"` в ConfigMap = `keepalive_timeout 10s` в nginx.

```
T=0:  Browser загружает страницу (GET /)
T=10: nginx закрывает idle соединение (отправляет FIN)
T=?:  Пользователь заполняет форму (>10 сек → почти всегда)
T=X:  Browser отправляет POST по "живому" с его точки зрения соединению
      → nginx уже закрыл socket → RST
```

Браузер не всегда замечает FIN немедленно (TCP буферизация ОС). curl — каждый раз новое соединение.

### Почему curl всегда работает

| | Browser | curl |
|---|---|---|
| Соединение | HTTP keep-alive, долгоживущее | Новое для каждого запроса |
| conntrack | Создано при SYN, может устареть | Новый SYN на каждый вызов |
| keepalive | Держит idle >10s | Сразу POST → не ждёт |
| VIP flap | Пакет идёт на новую ноду без conntrack | SYN на новой ноде создаёт conntrack |

### Ключевой инсайт

> Разница не в TCP-опциях (MSS, window size). Разница в **типе пакета**: curl всегда начинает с SYN → conntrack создаётся на правильной ноде. Browser держит соединение между запросами → когда VIP мигрирует, браузерные пакеты (ACK/PSH) приходят на новую ноду без предшествующего SYN → нет conntrack-записи → RST.

### Итоговая таблица причин

| Причина | Механизм | Почему не curl |
|---|---|---|
| kube-vip ARP lease renewal | Смена ноды → conntrack orphan | Новый SYN всегда |
| `keepalive_timeout: 10s` | nginx закрывает idle conn → browser не замечает | Нет idle |

Оба фактора вместе: рестарт сбрасывает состояние, 5-10 минут → kube-vip переизбирается / браузер держит соединение дольше 10s → RST.

### Рекомендации

1. **`keep-alive: "75"`** — исключить механизм #2 (самое простое, безопасное)
2. **`externalTrafficPolicy: Local`** — исключить механизм #1 (риск: потеря source IP для других сервисов)
3. **JS: Connection warmer** — GET на Flask при загрузке страницы (уже доказано тестом #2)
4. **JS: пересоздавать соединение** — использовать `fetch()` без keep-alive (credentials: 'omit' или отдельный subdomain)