HISTORY: Фаза 0 — nginx max 68мс/499=0 (ответы теряются nginx→клиент); kube-vip ошибки leaderelection каждые 1с

HISTORY/2026-08-14-session-log.md

@@ -1051,3 +1051,32 @@ ISP, port-forward, таблица доказательств); Sonnet — стр
 (консоль Nubes → скопировать → на ВМ: xclip -o > ~/.kube/config или заменить
 файл). После обновления продолжить: nginx access-log → kube-vip логи →
 логи пода.
+
+## 2026-08-15 — Фаза 0 ВЫПОЛНЕНА: nginx чист, kube-vip с ошибками leaderelection
+
+Окно теста: 08:26:47–09:00 UTC (30-мин тест 12:27–12:57 локального времени).
+
+**nginx access-log (оба пода ingress, за окно):**
+- 874 записи к нашему хосту: 862×status=200, 12×404 (боты).
+- **max ingress_request_time = 0.068с** за весь тест.
+- **status=499 = 0** (ни одного клиентского обрыва).
+- Вывод: с точки зрения nginx ВСЕ запросы обработаны за миллисекунды и
+  успешно. 49 клиентских таймаутов по 30с nginx НЕ видит → ответы теряются
+  МЕЖДУ nginx и клиентом (обратный путь/шлюз), либо часть запросов не дошла
+  до nginx (записей 862 против 888 операций — но боты засоряют счёт, точный
+  сплит не выводим).
+
+**kube-vip (новое подозрение):**
+- Под shturval-vip-dp24p (нода control-plane) — **каждые ~1с ошибка**:
+  `leaderelection: error initially creating leader election record: namespaces
+  "0a42bef3-7ce1-42b7-aa80-4274c4d9568f" not found`.
+- Под пытается создать запись лидера в НЕСУЩЕСТВУЮЩЕМ namespace — похоже на
+  настроечный баг платформы. Влияние на VIP неизвестно — нужны логи остальных
+  4 vip-подов (кто лидер, были ли флапы).
+
+**Наш под:** 682 строки логов за окно, ошибок нет; 13 warnings «Receipt Handle
+not found» только в 08:58–08:59 (фаза cleanup — норма).
+
+**Следующие шаги Фазы 0:** логи остальных kube-vip подов (лидерство/флапы) →
+externalTrafficPolicy сервиса ingress → Фаза 1 (PMTU-зонд + новый тест с
+timestamp таймаутов).