diff --git a/HISTORY/2026-08-16-session-log.md b/HISTORY/2026-08-16-session-log.md
index 743197f..679abfe 100644
--- a/HISTORY/2026-08-16-session-log.md
+++ b/HISTORY/2026-08-16-session-log.md
@@ -204,3 +204,58 @@ shared-sqs: «GET /ui через ingress не закрывает соедине
    проблема ближе к поду.
 4. Держать обычное HTTP-соединение через ingress >150с — сравнение с WS.
 5. По результатам — тикет в Nubes (лимит соединений на ingress/шлюзе).
+
+---
+
+## 9. Диагностика обрыва (16.08, команда «делай тесты»)
+
+### 9.1 Инфраструктура пробника на платформе (через ВМ, kubeconfig живой)
+- Namespace пробника: `2d9b96ff-0a50-41e5-a5d5-1cd9e5621555`, deployment
+  `containerk8s`, под `containerk8s-5dc7dcbfcf-d4ch6` (IP 172.16.2.227),
+  service `containerk8s` ClusterIP 10.106.45.135:8080.
+- Рядом стандартные: pod vmagent (метрики), ns shared-sqs `f1ffb134-...` (2d9h),
+  старый чужой ns `df36c8af-...` (30d) — не трогали.
+- Ingress платформы: ns `ingress`, `shturval-ingress-controller-controller`
+  (2 пода: 172.16.0.73 / 172.16.3.149), LB 185.247.187.151 (kube-vip).
+  DNS `testiot.containerk8s.dev.nubes.ru` → 185.247.187.151.
+- В логах пробника источник WS-подключений = IP ingress-подов (172.16.0.73 /
+  172.16.3.149) — соединения терминируются на nginx.
+
+### 9.2 Серверная сторона обрыва (логи пода)
+- Тест 1: сервер получал echo каждые 10с до 04:28:40 UTC, затем ПАУЗА ~24с,
+  в 04:29:04 пришли СРАЗУ ДВА сообщения (echo-15 задержан на ~14с, echo-16 на
+  ~4с) и сразу `ws read error: close 1000 (normal)` — закрыл КЛИЕНТ после
+  своего ping-timeout. Серверных ошибок нет.
+- Вывод: сервер и под ни при чём — соединение застряло между клиентом и nginx.
+
+### 9.3 Nginx (ingress) — чисто
+- Access-логи обоих подов: `/ws` → 101, `request_time` = 173.851с / 173.850с
+  (полная жизнь соединения), статус 101, ошибок нет. Nginx НЕ закрывает
+  соединение и не видит аномалий.
+- X-Forwarded-For показывает клиентов как 192.168.255.10 / 192.168.255.71 —
+  перед LB есть краевой шлюз/NAT (внешний путь Nubes).
+- В error-логах за окно обрыва — только фоновые SSL-сканеры и посторонние
+  POST /graphql — к нашему обрыву отношения не имеют.
+
+### 9.4 Воспроизводимость (внешний путь, 3 прогона)
+- RUN1: обрыв **ровно на 173.1с** (ERROR ping timeout 170.1с, CLOSED 173.1с,
+  sent=17, echoed=15) — идентично тесту 1. Детерминированно.
+- RUN2: запущен, ожидание (ожидаемый обрыв ~08:38:39 по `date`).
+- Прогоны идут на РАЗНЫЕ ingress-поды — обрыв не зависит от пода.
+
+### 9.5 Внутренний путь (port-forward с ВМ) — ИДЁТ
+- `kubectl -n 2d9b96ff-... port-forward svc/containerk8s 18080:8080` (ВМ),
+  клиент node+ws (модуль `ws` установлен на ВМ в /tmp/wstest).
+- Тест 600с, старт 07:34:55 MSK. На 155с — ЗДОРОВ: PING сервера каждые 20с,
+  PONG клиента каждые 25с (с 25-й секунды!), ECHO ok[12] на 120с.
+- Различие с внешним путём видно уже по pong-каденсу: внутри pong приходит
+  с 25с, снаружи первый pong только на 50с — внешний шлюз «съедает» что-то
+  уже на 25-й секунде.
+- Если внутренний тест доживёт 600с — обрыв окончательно локализуется на
+  внешнем краевом шлюзе (вне кластера), как и таймауты 31–33с shared-sqs.
+
+### 9.6 Предварительный вывод
+- Контейнер, под, сервис, nginx — здоровы. Детерминированный обрыв внешних
+  WS-соединений на ~150–173с происходит на краевом шлюзе Nubes.
+- Для IoT это значит: wss-устройства будут переподключаться каждые ~2.5–3 мин,
+  пока шлюз не починят (тикет Nubes, объединить с таймаутами 31–33с и MSS).