# MTProto Proxy via alexbers/mtprotoproxy + Caddy TLS

## Отличие от seriyps/mtproto-proxy

Существующий скилл `mtproto-proxy` описывает образ `seriyps/mtproto-proxy` с Fake TLS и переменными `MTP_*`. Это **другой** образ. `alexbers/mtprotoproxy` использует:

- **Python-конфиг** (`config.py`) вместо переменных окружения
- **Реальные TLS-сертификаты** (через nginx/Caddy reverse proxy) вместо Fake TLS
- `network_mode: host` вместо bridge

## Docker Compose (с Caddy)

```yaml
services:
  mtproto:
    image: alexbers/mtprotoproxy
    restart: always
    network_mode: host
    volumes:
      # Сертификаты от Caddy (LetsEncrypt)
      - /opt/caddy/caddy_data/caddy/certificates/acme-v02.api.letsencrypt.org-directory/domain.ru:/certs:ro
      # Конфиг
      - ./mtproto:/config
    command: python3 mtprotoproxy.py /config/config.py
```

## config.py

```python
# MTProto proxy config
PORT = 443  # or whatever port Caddy forwards TLS to
USERS = {
    "tg": "ee" + "32-hex-chars-secret"
}
# Optional: stats reporting
# SECRET = 123456  # for stats (unsafe, optional)
```

## TLS via Caddy

Caddy reverse proxy ставится перед MTProto:

```yaml
labels:
  caddy: domain.ru
  caddy.reverse_proxy: / "{{upstreams 443}}"
  caddy.reverse_proxy.transport: http
  caddy.reverse_proxy.transport.tls: "insecure_skip_verify"
```

Caddy получает LetsEncrypt сертификаты и пробрасывает HTTPS-трафик на MTProto (который внутри слушает без TLS).

## Ссылка для подключения

```
https://t.me/proxy?server=domain.ru&port=443&secret=eexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
```

Секрет с префиксом `ee` — Telegram на клиенте сам определяет что это Fake TLS / реальный TLS.

## Медленное подключение (3+ минуты) — возможные причины

1. **DNS resolver на сервере** — MTProto прокси использует DNS для проверки Telegram API. Если DNS медленный или блокируется, задержка большая. Лечение: проверить `/etc/resolv.conf`, поставить `1.1.1.1` / `8.8.8.8`.

2. **Caddy появляется раньше MTProto** — если Caddy стартует быстрее, он выдаёт ошибку вместо прокси. Telegram клиент пытается переподключаться, что добавляет задержку. Лечение: настроить `depends_on` или restart политику.

3. **TCP keepalive** — MTProto держит соединения. Если между клиентом и сервером есть NAT с таймаутом меньше 3 минут, соединение разрывается и восстанавливается. Это может выглядеть как "3 минуты подключается".

4. **Медленная загрузка сертификатов** — если сертификаты лежат на WebDAV/Yandex Disk, mount может тормозить. Проверить `mount` и права доступа.

5. **Проверка:** внутри контейнера `docker exec mtproto cat /config/config.py`, снаружи `ss -tlnp | grep mtproto`.