tf_docs/HISTORY/2026-09-02_sonnet_analysis_and_critique.md

2026-09-02 — Анализ Соннета по tf_docs + критическое мнение

Вопрос (что отдавали Соннету)

Анализ финальной архитектуры отдачи MkDocs-документации через «вечный» бесплатный домен tf-docs.nodejsk8s.dev.nubes.ru: браузер → под nodejsk8s (reverse-proxy) → ВМ 5.172.178.213 (nginx/статика). Просили: правильна ли схема, можно ли ускорить международный маршрут без платных доменов, скрытые риски.

Ответ Соннета (суть)

1. Архитектура верна, но есть конфигурационный дрейф: в репо deploy-vm/nginx-ip-5.172.178.213.conf всё ещё location / { proxy_pass http://127.0.0.1:8888/; } (на остановленный llmui), хотя на ВМ уже return 301.
2. Обрывы ~16–36 КБ — похожи на инцидент tf_registry (там виноват локальный прокси), но у нас Германия без прокси тоже режет + ВМ напрямую режет → маршрут в РФ фильтруется на границе. Предложил включить gzip, чтобы «сжать страницу ниже порога обрыва».
3. Риски: SPOF на ВМ, ВМ не выделенный хост, location / открыт по IP, timeout 30с (idle), TLS только на ingress.

Моё критическое мнение

Главное: рекомендация gzip — ошибочна. Порог обрыва — СЕТЕВОЙ (~16.7 КБ), а не «по объёму контента». Доказательство из замеров этой же сессии:

• файл .test_20k.bin (ровно 20000 байт) обрывается на 16775 байт;
• файлы 50/100/200 КБ — тоже ровно на 16773–16775;
• favicon 1017 байт — проходит полностью.

То есть обрыв наступает на ~16.7 КБ независимо от content-length. Сжать HTML 133 КБ gzip до <16.7 КБ нереально (текст жмётся до ~25–40 КБ) — ответ всё равно упрётся в сетевой порог. gzip меняет размер контента, но не лимит маршрута. Гипотеза «сжать ниже порога» не сработает. Вывод: для страниц 133–200 КБ gzip проблему не решает.

Остальные пункты — валидные, но в основном уже известные/принятые trade-off'ы:

• дрейф 8888 в репо — подтверждён, реальный риск при повторном применении файла из git (файл стоит синхронизировать с ВМ);
• SPOF на ВМ, timeout 30с, TLS-только-ingress — верно, но «ВМ-буфер» и есть осознанное решение (весь код на ВМ);
• «location / открыт по IP» — натянуто: ВМ и так публична по IP, новой дыры нет.

Итог: анализ полезен, но ключевая рекомендация (gzip) технически неверна; реально ценное — пункт про дрейф 8888 (нужно синхронизировать файл в репо).

Статус

• Дрейф deploy-vm/nginx-ip-5.172.178.213.conf (8888) — ИСПРАВЛЕН: файл синхронизирован с ВМ (return 301 /nubes-test/ + absolute_redirect off). Файл gitignored, в git не входит — риск «применения из git» не подтвердился, это локальная справочная копия.
• gzip — НЕ делать (не решает).
• Range-проброс в server.js — НЕ делать (для MkDocs-статики не критично).