tf_registry/HISTORY/incident-2026-09-01-proxy-s3-dns.md

Инцидент 2026-09-01: обрыв скачивания провайдера + медленный DNS на ВМ

Симптом (исходный)

• GET /v1/proxy?key=... отдавал HTTP 200 + Content-Length: 13083236, но поток обрывался на ~18–23 KB (curl (28) Operation timed out).
• Range-запросы игнорировались — сервер заново отдавал весь файл и зависал.
• Гипотеза: кластерный ingress-шлюз режет исходящий streaming (по аналогии с drhider, где резались входящие тела >64 KB).

Диагностика

• s3.msk-1.ngcloud.ru публично доступен: DNS 185.228.248.165/166/167, HTTP 200 (Ceph Object Gateway).
• gitea.services.ngcloud.ru НЕ доступен с ВМ сборки 5.172.178.213:
  • публичный IP 194.31.9.41:443 — TCP таймаут;
  • внутренний ClusterIP 10.96.52.11:443 (gitea.mgmt.nubes.ru) — TCP таймаут (подсеть 10.96.0.0/16 с ВМ не маршрутизируется);
  • с локальной машины gitea доступен (200 за 0.36s). → «в одном облаке» ≠ открыто: сети изолированы security-group/маршрутизацией.

Причина обрыва — НЕ кластер, а локальный прокси

• На локальной машине задан HTTP_PROXY/HTTPS_PROXY=http://172.17.192.1:10808 (v2ray/clash-тип).
• Через прокси режется любой большой исходящий поток (~16–23 KB) — и старый стриминг через кластер, и прямое скачивание с S3.
• Без прокси (curl --noproxy '*') файл качается полностью: 13 083 236 байт за 6.3s, unzip -t — OK.
• С ВМ (без прокси) тот же файл: 13 083 236 байт за 11.3s, unzip -t — OK.
• Вывод: исходная гипотеза «кластерный шлюз режет» не подтвердилась.

Фикс registry: redirect на pre-signed S3 URL (выполнено)

• server/proxy.go, proxyHandler: убраны GetObject/Stat/io.Copy; вместо этого PresignedGetObject(ctx, bucketName, key, 15*time.Minute, nil) + http.Redirect(w, r, ..., http.StatusFound).
• Удалён неиспользуемый импорт s3.
• server/main.go: VERSION 0.0.2 → 0.0.3.
• Проверка: go build ./... — OK.
• Коммит 422736f, запушен в master.
• Образ: docker build (локально, т.к. gitea недоступен с ВМ) → gitea.services.ngcloud.ru/nail/tf_registry:latest и :0.0.3.
• Digest: sha256:e3f8510d521025f4980c65226507f31aa9f4defe68e3bc50862591992792bda5.
• Инстанс пересоздан в UI Nubes с образом :0.0.3.

Проверка фикса

• GET /v1/proxy?key=... → HTTP 302 + Location: https://s3.msk-1.ngcloud.ru/...?X-Amz-... (presigned, креды reader 6DDP5...).
• curl -L — 13 083 236 байт за 6.3s (без прокси), архив валиден.

Проблема terraform init на ВМ: медленный DNS

• terraform init на ВМ падал: failed to retrieve authentication checksums ... context deadline exceeded (2 попытки).
• Причина: DNS на ВМ. resolv.conf = 8.8.8.8 + 1.1.1.1, оба недоступны с ВМ (nslookup → communications error: timed out).
• Каждый резолв доменов Nubes висел ~10 сек: dns=10.6s (registry), dns=10.0s (s3).
• Terraform делает много резолвов → суммарный таймаут. Сама передача файлов работала нормально.

Решение: статические записи в /etc/hosts на ВМ

• Добавлено (бэкап: /etc/hosts.bak):
  • 5.172.178.231 tf-registry.containerk8s.services.ngcloud.ru
  • 185.228.248.165 s3.msk-1.ngcloud.ru
• После правки резолв мгновенный: dns=0.0003s, registry total=0.022s.
• terraform init в ~/tf_provider/TEST_STAND/PGwNewRegistry — успех: Installed ... nubes v5.0.5 (self-signed, key ID CB3A0DF161ECC416), Terraform has been successfully initialized!.

Итоговые выводы

1. Обрыв больших файлов на ~16–23 KB — локальный прокси на машине тестирования, НЕ кластер.
2. Фикс registry (302 → presigned S3) корректен и полезен: registry больше не участвует в передаче файла.
3. terraform init с ВМ ломался из-за недоступного внешнего DNS; лечится /etc/hosts (или рабочим внутренним DNS).
4. Gitea с ВМ сборки недоступен по сети — для сборки образа использовать машину с доступом (локальную).