diff --git a/HISTORY/2026-08-16-session-log.md b/HISTORY/2026-08-16-session-log.md
index 0441c59..040f563 100644
--- a/HISTORY/2026-08-16-session-log.md
+++ b/HISTORY/2026-08-16-session-log.md
@@ -302,3 +302,35 @@ shared-sqs: «GET /ui через ingress не закрывает соедине
 4. При проектировании IoT: устройствам нужен MQTT keepalive ≤60с + автореконнект,
    а до фикса шлюза — считать интернет-подключения устройств нестабильными
    (~2.5–3 мин жизни).
+
+### 9.9 Тест с третьей точки (Vultr, 95.179.252.111) — ГИПОТЕЗА ПОДТВЕРЖДЕНА
+
+Доступ: `root@95.179.252.111`, ключ `~/.ssh/vultr_openssh` (на ВМ-машине).
+Python 3.10, websocket-client 1.9.0 установлен. Тот же скрипт, 300с.
+
+| Тест | Результат |
+|---|---|
+| Vultr → testiot wss | **обрыв 163.3с** (stall ~150с) — ИДЕНТИЧНО станции |
+| Vultr → echo.websocket.org | чисто (175с+, pong 150.1с) |
+
+**ИТОГОВЫЙ ВЫВОД (доказано с трёх точек):**
+- Обрыв долгоживущих WS-соединений на ~150с — **на краевом шлюзе платформы
+  Nubes** (внешний вход 185.247.187.151), а не в поде/ingress и не в ISP клиента:
+  два независимых интернет-маршрута (станция, Vultr) дают идентичный обрыв,
+  контрольные публичные WS-echo с обеих точек чисты.
+- ВМ 5.172.178.213 ходит коротким маршрутом (p50 6–8мс) и шлюза не касается —
+  поэтому чиста.
+- Внутри платформы (port-forward) всё идеально (600с, 59/59).
+- Для IoT: wss-устройства из интернета будут отваливаться каждые ~2.5–3 мин.
+  Это блокер для прода; тикет Nubes обязателен (объединить с таймаутами 31–33с
+  и MSS 1448 из shared-sqs — тот же шлюз).
+
+### 9.10 Рекомендации для тикета Nubes (готовы данные)
+- Симптом: WS-соединение (wss через edge) детерминированно рвётся на ~150с
+  при активном трафике (echo каждые 10с, ping/pong 20–25с). Доказано:
+  станция 5/5, Vultr 1/1; nginx внутри видит полную жизнь соединения
+  (request_time 173.85с), под чист; изнутри кластера и с ВМ — чисто.
+- Воспроизведение: `wscat -c wss://testiot.containerk8s.dev.nubes.ru/ws`
+  (или python websocket-client, ping 25с / echo 10с) — обрыв на 150–173с.
+- Связь с shared-sqs: таймауты 31–33с (~5.5% HTTP-запросов), MSS=1448 при
+  MTU 1400 — вероятно, тот же внешний шлюз.