# Инцидент 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 с ВМ сборки недоступен по сети — для сборки образа использовать машину с доступом (локальную).