# 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-статики не критично).