HISTORY: результаты диагностики платформы (зависание больших POST ~51с, WAF) + platform_probe

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

@@ -642,3 +642,28 @@ C. Известные аномалии: GET /ui через ingress висит ~1
 D. TCP: retransmit-счётчики пода (/proc/net/snmp) до/после.
 Итог: таблица «локаль vs ВМ vs внутри пода» — что режет платформа, а что сервис.
 
+## РЕЗУЛЬТАТЫ диагностики платформы (tests/platform_probe.py, 14.08.2026)
+
+**ГЛАВНАЯ НАХОДКА — большие POST-тела зависают на ~51с (защитный слой платформы):**
+- send 2–48KB — 0.09–0.22с; 56–64KB — то быстро, то виснет (порог плавает);
+  80KB/100KB — первый запрос 50–52с, следующие 0.03с.
+- Воспроизводится и с ВМ, и с локальной машины → общий узел DDoS-Guard/WAF.
+- 100KB с БИТОЙ SigV4 — тоже 50.4с (висит путь, не наш auth/сервис).
+- /health параллельно зависшему запросу — 0.02–0.05с (сервис жив).
+- TCP connect+TLS мгновенны всегда (в т.ч. после idle 60/120с).
+- Большие ОТВЕТЫ не режутся: receive 10×256KB (2.5MB) — 0.26с.
+- Long-poll 20с держится честно (20.01с) — платформа не режет до 20с.
+
+**Прочие ограничения платформы:**
+- Заголовки >16KB → 400 Bad Request (8KB проходит).
+- Chunked Transfer-Encoding → 400.
+- POST /health → 400; HEAD /health → 405 (наш mux); HTTP/1.0 → ок (апгрейд).
+
+**Нагрузка на под**: burst 500 × /health: 500/500 ok, p50=2.54с, p95=3.43с —
+это CPU-лимит пода 500m, а не платформа (внутренние запросы мгновенны).
+
+**Следствие**: клиенты с сообщениями >~64KB и read_timeout < 51с получают
+ReadTimeout на первом запросе в окне (это объясняет кластеры ReadTimeout и
+max latency 52с в нагрузочных тестах). Рекомендации: клиентам read_timeout ≥ 60с
+и retries; вопрос про WAF-инспекцию больших POST — в поддержку платформы.
+