diff --git a/HISTORY/2026-08-16-session-log.md b/HISTORY/2026-08-16-session-log.md
index 679abfe..0441c59 100644
--- a/HISTORY/2026-08-16-session-log.md
+++ b/HISTORY/2026-08-16-session-log.md
@@ -259,3 +259,46 @@ shared-sqs: «GET /ui через ingress не закрывает соедине
   WS-соединений на ~150–173с происходит на краевом шлюзе Nubes.
 - Для IoT это значит: wss-устройства будут переподключаться каждые ~2.5–3 мин,
   пока шлюз не починят (тикет Nubes, объединить с таймаутами 31–33с и MSS).
+
+### 9.7 Финальные результаты всех тестов
+
+| Тест | Путь | Клиент | Результат |
+|---|---|---|---|
+| Тест 1 | станция → внешний wss | python | обрыв 173.1с |
+| RUN1 | станция → внешний wss | python | обрыв **ровно 173.1с** |
+| RUN2 | станция → внешний wss | python | обрыв 163.4с (stall на ~150с) |
+| RUN3 | станция → внешний wss | python | обрыв 163.7с (stall на ~150с) |
+| VM-ext | ВМ → внешний wss | node+ws | **чисто 300.2с, 29/29 echo** |
+| VM-int | ВМ → port-forward → под | node+ws | **чисто 600.1с, 59/59 echo** |
+| echo.org | станция → публичный WS-echo | python | **чисто 200с+ (тест 300с)** |
+| proxy | станция → прокси 172.17.192.1:10808 → wss | python | обрыв 163.9с (как прямой) |
+
+**Выводы:**
+1. Под/сервис/nginx платформы — полностью здоровы (VM-ext 300с чисто,
+   VM-int 600с чисто; nginx request_time = полное время жизни, ошибок нет).
+2. Обрыв воспроизводится ТОЛЬКО с рабочей станции, причём и напрямую, и через
+   локальный прокси (172.17.192.1:10808) — 5/5 обрывов, точка сбоя ~150с.
+3. Публичный WS-echo (echo.websocket.org) с той же станции — ЧИСТО. Значит
+   сеть станции в целом здорова; страдает именно маршрут станция → Nubes
+   (185.247.187.151).
+4. ВМ (другой маршрут до платформы, p50 6–8мс по данным shared-sqs) — чисто.
+5. ⚠️ Нюанс для вывода «шлюз Nubes»: станция и ВМ ходят разными маршрутами.
+   Если ВМ обходит внешний шлюз Nubes (короткий путь/пиринг) — то «таймер
+   ~150с на внешнем шлюзе Nubes» подтверждается. Если ВМ проходит тот же
+   шлюз — тогда проблема в маршруте станции (ISP/прокси-сеть). Точно
+   различить может только тест с третьей независимой точки входа
+   (другой ISP, мобильная сеть).
+6. Взаимосвязь с shared-sqs: таймауты 31–33с (HTTP) и MSS 1448 наблюдались
+   с той же станции — вероятно, тот же проблемный маршрут/шлюз. Наши данные
+   добавляют к картине «~150с на долгоживущие соединения».
+
+### 9.8 Следующие шаги (предложены, ждут «делай»)
+1. Тест wss с третьей независимой точки (другой ISP/мобильная сеть) — решает
+   вопрос «шлюз Nubes vs ISP станции».
+2. HTTP-цикл с той же станции на /health (запрос каждые 10с, 5 мин) — связать
+   с таймаутами 31–33с shared-sqs.
+3. Тикет в Nubes: wss-соединения с интернета рвутся на ~150с (детерминированно),
+   + таймауты 31–33с и MSS 1448 (данные shared-sqs).
+4. При проектировании IoT: устройствам нужен MQTT keepalive ≤60с + автореконнект,
+   а до фикса шлюза — считать интернет-подключения устройств нестабильными
+   (~2.5–3 мин жизни).