v0.7.1

## [0.7.1](https://github.com/sleep3r/mtproto.zig/compare/v0.7.0...v0.7.1) (2026-04-06)

### 🇷🇺 Release notes (RU)

**Что исправлено и улучшено**
- Исправлен `middleproxy` handshake в туннельных/NAT-сценариях: для key-derivation теперь используется детектированный публичный IPv4 egress.
- Добавлен fallback `middleproxy -> direct` для media-path (DC203), чтобы медиа не отваливались полностью при сбоях ME-рукопожатия.
- Стабилизирован event loop под high-churn: ограничен batch в accept-цикле и добавлен budget на timer scan за тик, чтобы снизить риск CPU starvation на 1 vCPU.
- Улучшен деплой через AmneziaWG:
  - `TUNNEL_MODE=direct|preserve|middleproxy`
  - сохранение promo `tag`
  - восстановление `tag` из `env.sh` при необходимости
  - обновление `setup_tunnel.sh` через `update.sh` с backward-compatible fallback.
- Обновлены дефолтные лимиты под небольшие VPS:
  - `max_connections = 512`
  - `idle_timeout_sec = 120`
  - `handshake_timeout_sec = 15`

**Важно по масштабированию**
- Текущий proxy loop однопоточный, поэтому рост производительности **не** линейный по vCPU.
- Для больших серверов лучше масштабировать горизонтально (несколько инстансов), а не только поднимать `max_connections` у одного процесса.

### 🇬🇧 Release notes (EN)

**Fixes and improvements**
- Fixed `middleproxy` handshake in tunnel/NAT deployments: key derivation now uses detected public egress IPv4.
- Added `middleproxy -> direct` fallback for media-path (DC203), so media does not hard-fail when ME handshake is degraded.
- Improved event-loop stability under high churn: bounded accept batch and timer-scan budget per tick to reduce CPU starvation risk on 1 vCPU hosts.
- Improved AmneziaWG deployment flow:
  - `TUNNEL_MODE=direct|preserve|middleproxy`
  - promo `tag` is preserved
  - `tag` can be restored from `env.sh` when missing
  - `setup_tunnel.sh` is updated by `update.sh` with backward-compatible fallback.
- Updated small-VPS defaults:
  - `max_connections = 512`
  - `idle_timeout_sec = 120`
  - `handshake_timeout_sec = 15`

**Scaling note**
- The proxy event loop is single-threaded, so performance does **not** scale linearly with vCPU count.
- For larger hosts, prefer horizontal scaling (multiple proxy instances) over only increasing `max_connections` for a single process.

---

## Recommended VPS presets (starting points)

| Profile | `max_connections` | `idle_timeout_sec` | `handshake_timeout_sec` | `middleproxy_buffer_kb` | Notes |
|---|---:|---:|---:|---:|---|
| 1 vCPU / 1 GB | 512 | 120 | 15 | 256 | New default preset |
| 2 vCPU / 2 GB | 1024 | 120 | 15 | 256 | Good first step for mixed traffic |
| 4 vCPU / 4 GB | 1536-2048 | 120 | 15 | 256 | Raise gradually and monitor churn |
| 8 vCPU / 8 GB | 2048-3072 (per instance) | 120 | 15 | 256 | Prefer 2+ instances over one huge cap |

### Tuning guidance / Рекомендации по тюнингу
- Start from the profile above, then increase `max_connections` in +15-25% steps.
- Monitor: `conn stats`, reconnect/error rate, and sustained CPU.
- If new clients intermittently fail under churn, reduce `max_connections` by ~20%.
- If memory pressure appears, keep `middleproxy_buffer_kb=256` unless you have tested lower values with your client mix.

---

This PR is managed by Release Please.