HISTORY: уточнение причины 51с — MTU (drhider), решение пользователя по тестам

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

@@ -667,3 +667,33 @@ ReadTimeout на первом запросе в окне (это объясня
 max latency 52с в нагрузочных тестах). Рекомендации: клиентам read_timeout ≥ 60с
 и retries; вопрос про WAF-инспекцию больших POST — в поддержку платформы.
 
+## УТОЧНЕНИЕ ПРИЧИНЫ 51с — это MTU, как в drhider (14.08.2026)
+
+**Гипотеза WAF выше — НЕВЕРНА.** Найдено в `~/nubes/drhider`:
+- `PROBLEM-AND-SOLUTION.md` «Проблема 1: 51-секундная задержка (MTU)»: POST из
+  внешней сети — пауза 51с; внутри кластера — мгновенно. Причина: underlay Nubes
+  MTU 1450, Cilium Geneve +50, MTU пода 1500 → cross-node пакет 1550 → фрагментация
+  → дроп → retransmit ~51с. Решение: `cilium mtu: 1400` (1400+50=1450).
+- `docs/about1500.md`: готовый текст обращения в поддержку Nubes.
+- VIP drhider — тот же `185.247.187.151`, что у `sqs.containerk8s.dev.nubes.ru`.
+
+**Проверено у нас (факты)**:
+- Cilium кластера iot-naeel: `mtu: 1400` — внутренний участок УЖЕ исправлен;
+  под eth0 MTU 1400 ✓.
+- ВМ: ens192 MTU **1500** → сегменты 1460 не влезают в underlay 1450 на участке
+  ВМ→шлюзы платформы (traceroute: 10.10.102.1 → 100.64.x.x → 10.200.x.x → 5.181.12.1).
+- Локальная машина (интернет → DDoS-Guard): та же 51с.
+- Большие ОТВЕТЫ (под→клиент, 1400-байтные сегменты) проходят быстро.
+- Порог зависания плавает ~56–64KB: зависит от необходимости полных 1460-байтных
+  сегментов.
+
+**РЕШЕНИЕ ПОЛЬЗОВАТЕЛЯ (14.08.2026)**:
+- КОД НЕ МЕНЯТЬ (лимит размера остаётся 262144/AWS).
+- kubectl — только для диагностики; прод — кластер облака БЕЗ нашего доступа
+  (править MTU можем только там через поддержку Nubes).
+- ТЕСТЫ — без больших сообщений: valid-тела ≤48KB; сценарий «превышение лимита»
+  через очередь с MaximumMessageSize=1024 и телом 2KB (граничное условие
+  сохраняется, большое тело не шлётся).
+- Ограничение платформы (51с на большие POST) остаётся для реальных клиентов —
+  адресовать в поддержку Nubes текстом из drhider/docs/about1500.md.
+